Choosing The Best Wireless Gaming Mouse

Wireless Gaming Mouse - The computer mouse is perhaps the most important input device used in games, and using a gaming mouse, well suited, which allows you to play your best. It can be the difference between victory and defeat.

Gaming mouse are available in different versions: optics, laser and ball mice. Mouse balls are old and are virtually dead, and will not be discussed further. Optical

Seven Languages in Seven Weeks: Scala, Day 3

After some functional programming on day two, it's time for the third and final day of Scala in Seven Languages in Seven Weeks.

Scala, Day 3: Thoughts

After two lengthy chapters on the object oriented and functional programming syntax/options in Scala, the third day rushes through some of the most intriguing features, including pattern matching and concurrency via actors. I would have preferred to spend a bit more time on these complicated topics.

In fact, I had the same complaint on Day 3 of IO, where we also blasted through a discussion of concurrency in just a few pages. I respect the difficulties of plowing through seven different languages in a single book and don't expect deep discussions of any one of them, but I think the book would've been stronger if it had a greater bias towards the more advanced "day 3" topics of each language instead of basic syntax discussions in day 1 or 2.

Scala, Day 3: Problems

Extend the "sizer" application to count and size links

Take the sizer application (code, output) and add a message to count the number of links on a page. Follow these links and calculate their size as well, so you get the total size for each page.

The code:

The output:

This problem was a great way to experiment with actors in Scala. The sequential solution is self explanatory, so here's an outline of the concurrent one:

1. The caller creates B Base Actors, one for each of the B base URLs.
2. The caller then calls receive to await a message from each Base Actor.
3. Each Base Actor concurrently loads its base URL, finds the links on the page, and creates L Link Actors, one for each of the L links on the page.
4. The Base Actor then calls receive to await a message from each of its Link Actors.
5. Each Link Actor concurrently loads the page for its given link and sends a message to its parent Base Actor with the size of that page.
6. When the Base Actor has received a message form each of his Link Actors, it sends a message to the caller with the total size.
7. When the caller has received B messages from the Base Actors, we are done.

The sequential code takes nearly 20 seconds to run while the concurrent code takes less than 3 seconds, a 7x improvement. The concurrent code is definitely more complicated, but not unreasonably so. Even though it was my first time using Scala actors, the code took less than 30 minutes to get working, much of it spent learning about the self keyword. In fact, I find it very easy to reason about Scala's actors, which is not something I can say for Java's synchronized keyword, Executors, Runnable, and various other concurrency constructs. 

Wrapping up Scala

I'm a bit torn when it comes to Scala. Most of the time, I saw it as a vastly improved version of Java. The support for closures, functional programming, pattern matching, and actors all seem like genuinely useful tools that would dramatically improve productivity, code readability, correctness, and expressiveness. I've already used Scala in a few of my projects to build some features that would've been nearly impossible or incredibly ugly in Java. 

However, even in my limited exposure to Scala, I've already come across a number of hiccups. As I mentioned on day 1, the API docs are not helpful and look like they are written for academics. The IDE support is vastly inferior compared to Java. I've now tried both Eclipse and IntelliJ, and each one has significant problems: e.g. missing compile errors on some code; finding errors on other code that's actually valid; broken/missing auto complete; issues with the refactor/rename functionality; poor support for running scripts. The compiler is slow. The type hierarchies are complicated. Type inference doesn't always work as well as you'd hope.  

However, there is one issue that worries me above all else: feature overload. It seems like Scala is trying to be all things to all people. It's object oriented; it's functional; it has type inference; it has lots of syntactic sugar; it has actors; it's compatible with Java; it has first class support for XML; they are even trying to add macros. While all of these features could lead to an incredibly powerful language, they could also lead to one that's incredibly complicated and difficult to use.

User experience counts. Not only for products, but for programming languages too.

How many features can you pile into one language before it becomes too cumbersome? How much syntax sugar do you need to understand to be able to read or write code? How many paradigms and mental models do I need to juggle to follow along? Do so many options make a language more flexible or less? Will there be such a thing as "idiomatic Scala" or will it be a free-for-all? Is it better to have a dozen ways to do something or one "proper" and well known way?

I don't know the answers to these questions, but I suspect they'll have a large impact on Scala's adoption. In the meantime, I'll keep hacking away at it to see what I can learn.

On to Erlang

Read on to learn about the next language in the book, Erlang.

Seven Languages in Seven Weeks: Scala, Day 2

After a bumpy start with Scala on Day 1, I've moved onto the second day of Scala in Seven Languages in Seven Weeks.

Scala, Day 2: Thoughts

The second Scala chapter shifts gears to functional programming. Unfortunately, I was impatient on Day 1 and had already looked up all of these concepts (and some more) to build a Tic Tac Toe game. As a result, I breezed through the chapter.

On a side note, I was using Scala on a personal project and rewrote some Java code using Scala. As much as I complained yesterday about Scala's complexity, the slow compiler, and poor IDE support, I must admit one thing: the resulting code was noticeably cleaner, shorter, and easier to read.

The language is certainly not perfect, but I need to make sure I'm not missing the forrest for the trees: it's still likely a vastly superior alternative to Java.

Scala, Day 2: Problems

The functional programming problems in this chapter were extremely simple. I burned through them in a few minutes and present the code without further comment:

String foldLeft

Use foldLeft to compute the total size of a List of Strings.


Censorship

Write a Censor trait with a method that will replace "curse" words with "clean" alternatives. Read the curse words and alternatives from a file and store them in a Map.



On to day 3

Learn about pattern matching and actors in Scala, Day 3.

Seven Languages in Seven Weeks: Scala, Day 1

It's time for a new chapter in the Seven Languages in Seven Weeks series: today, I take a crack at Scala.

Scala, Day 1: Thoughts

After using Java for years, I was curious to try out Scala, which has often been described as the next step in the evolution of Java. Scala's feature list is impressive: object oriented, functional, type inferencing, traits/mixins, currying, pattern matching, concise syntax, interoperability with Java code, an active community, and so on. My previous experiences with Scala had been very shallow/short, so I was excited to take a slightly deeper dive.

The first chapter introduced the imperative and object-oriented features of Scala and walked through the basic syntax. On the surface, the language looks like Java and uses many of the same keywords, so I was able to jump right in. However, I was quickly slowed down by some unexpected differences, including types specified after the variable name instead of before, "static" methods and fields separated into "companion classes" (confusingly named "objects"), and methods definitions sometimes including or omitting an equals sign and or parentheses depending on whether they return values or take parameters as inputs.

I slowed down even more once I started looking at the functional programming concepts and, worst of all,  trying to make sense of the API docs. Although they look thorough, the docs are astonishingly bad when you actually try to use them. For example, here is all the documentation provided for the "reduce" method of Scala's List:


If you're new to Scala's syntax, functional programming, or just a hacker trying to get something done, this sort of documentation is almost useless. Plain, human English or an example would be an order of magnitude more useful. The reduce concept isn't actually that hard to understand, but parsing the dense syntax of the method signature and phrases like "associative binary operator" makes it seem like a PhD is necessary to use this language. Compare this to the reduce documentation for Ruby and underscore.js to see a world of a difference.

The type hierarchy also proved tough to navigate. For example, how do I find the closest common ancestor between List and MutableList? I thought it might be LinearSeq, but there seem to be separate mutable and immutable versions of it. Other classes/traits further up the hierarchy overlap, but are missing common methods I need, such as "collect" or "foldLeft". Overall, this basic search was much harder than, for example, finding the common ancestor between Java libraries like ArrayList and Vector: a glance at the top of the API doc and you're done.

I also ran into difficulties with type inferencing. It definitely saved me some typing and looked beautiful for simple cases and closure parameters. However, type inference couldn't handle many cases that seemed obvious. This was compounded by the sub-par IDE support, at least from IntelliJ 11, which took a while to get working in the first place. I routinely found code that IntelliJ accepted wouldn't actually compile. Oh, and the compiler is slow. Ridiculously slow, given the tiny snippets of code I was testing.

Having said that, I'm still a newbie to the language, and shouldn't complain too much. I'm sure I'll get used to the code, API, and Scala idioms. Still, there is value in being "hacker friendly": one of the reasons Ruby, PHP, and JavaScript have such huge user bases is because you can get started with them in minutes. And there's also something to say about complexity: Scala has a lot of features, syntax, and complicated concepts. I hope that these make the language more powerful and expressive rather than bloated and incomprehensible.

Scala, Day 1: Problems

Build a two player Tic Tac Toe Game

The code:


Sample output:


I tried to keep the code fairly generic, so it should work for any NxN tic tac toe board. I also used this as an opportunity to play with some functional programming, so I intentionally stuffed everything into a List (albeit a mutable one), avoided for loops, too many objects, and so on. To be honest, I'm not thrilled with the result.

I was able to use lots of one-liners, but many are hard to read. I got familiar with the fold, map, and filter methods, but in some cases, a for-loop would've been much cleaner (and faster). Overall, I just get the feeling that the code doesn't communicate its intent very well. I'd love some feedback from how a more seasoned Scala user would've tackled this problem. Would pattern matching be useful? Recursive calls on the head/tail of the List? Or is the imperative style with loops and a 2D array the best way to go?

On to day 2

Continue on to Scala, Day 2.