Bash-Shell.Net

So I'm done with Seven Languages aside from maybe going back to do some of the exercises that gave me trouble at some point. I really enjoyed working my way through this book, even when it occasionally got frustrating. I've always been a firm believer that being familiar with more languages, styles, and paradigms will make you a stronger programmer, even if you don't use most of them often (or ever) after getting the base knowledge. I believe it gives you more ideas for how to solve problems and a better understanding of how things work. I highly recommend this book to any developer, expecially those that want to be more than just a "Java Developer" or "Perl Developer" that just knows their one area of expertise inside and out.

Seven Languages let me work with, well, seven languages. At least five of these I probably would never have used if not for this book. The other two, Ruby and Scala, were on my radar but were not very high priority. Now Scala is something I intend to work with regularly and have already started a proper project in, an OAuth library and eventual Twitter client. I really liked working with the functional languages and features. Those were enough different from what I normally do that I really felt like I was learning and becoming a stronger developer.

Here are my thoughts on the specific languages.

Ruby: This language has some cool features, but I don't have a whole lot of use for it directly. I've already got experience with Perl, Python, and Tcl. There isn't much that I can't already accomplish pretty easily in an interpreted language with those tools available. The functional concepts that it brings into an OO language are great and are what I like about Python and Scala as well. I'm also not thrilled with the community/maintainer's attitude towards performance. It seemed to be that easier, prettier code is always better and you just shouldn't worry about performance. Your project is not likely to actually need higher performance and on the off chance it does, then you can rewrite it in something else. For small scale personal projects I suppose that's true enough. I've had real world business projects written with that attitude though, and the reality is that as long is it kind of works, management usually doesn't want to spend resources to go back and do it right when you already did it once. I don't see Ruby shaving hours, let alone days or weeks, off of my development time for any projects so I'd rather choose a language that puts more emphasis on good performance. That said, if someone approached me with a job that sounded good and said I had to use Ruby, it wouldn't scare me off from it and I'd probably enjoy the opportunity to get more Ruby experience.

Io: A neat little prototype language. There are objects that are more or less built into the core of the language and you start by cloning and object and then adding to it or overriding its methods and operators as needed. This was a fun one to work with. JavaScript/ECMAScript and Lua are also prototype languages and something I'm far more likely to use in the real world, but Io gave me more insight into how they work and how I can better use them if I need to. Io also has cool concurrency features such as futures and actors that other bigger up and coming languages are have. There are also libraries to work with a ton of things built into the language, which is great, although their documentation is minimal so it can be difficult to figure out how to use them. I'd definitely like to see this language gain more popularity, possibly filling Lua's role as an embedded scripting language in many applications (not that I have anything against Lua).

Prolog: An interesting language with niche usage scenarios. It uses a lot of functional style concepts but is geared specifically towards engines for things like making decisions based on a number of known factors. I struggled with this one and didn't really find it to be my thing, but I can definitely see where this language can be incredibly useful.

Scala: Probably my favorite of the bunch. As I mentioned, I am starting up some projects using Scala. I think Scala did a great job of mixing OO and Functional paradigms and giving you the freedom and power to mix and match to your own needs and comfort level. Having learned on primarily OO languages I really like being able to organize my overall structure using packages and classes like I am used to while having the tools available to write functional style code that rarely, if ever, mutates state. Scala runs on the Java Virtual Machine which means you can get it running basically anywhere and you can access all of the Java classes. This makes Scala incredibly powerful and easy to use anywhere, while providing a number of improvements over Java in terms of code terseness and concurrent programming. Scala 2.9 also has one of the coolest features I've ever seen - the ability to iterate over a collection's elements in parallel. That is something that would give a huge performance boost to the primary application I develop at work in Perl, which sometimes has to iterate over lists of hundreds of thousands of items, but does not need to process them in any particular order.

Erlang: A step further into Functional territory. The language itself was ok, it felt a lot like the more pure functional languages. The "let it crash" mentality and ability to write a mesh of processes that all monitor and restart each other as needed is a great concept. The killer for me was that setting up an independent application to run seemed to really be a lot of hassle compared to other languages. That really soured my overall view of Erlang.

Clojure: This is another JVM based language, but this time yet another step closer to being purely functional. It is a LISP dialect but with a few improvements and access to the Java libraries. The version of Clojure that Debian 6 has packaged in Apt is a bit old, so I wasn't able to do all of the exercises how they were intended, but I was still able to do most of them. I occasionally had to fight with syntax, but it wasn't anything that would cause problems if I were to use the language regularly. I liked the language's take on concurrent programming with Software Transactional Memory. STM basically allows you to create threads and then access variables (or memory, really) through a transactional locking and unlocking, very much like using a database.

Haskell: The only pure Functional language in the book, Haskell was the last to be worked with as the book worked from OO to more and more Functional languages. Overall I enjoyed Haskell and found it to be a good learning experience. Like Clojure, I occasionally fought with syntax even though I had the basic logic correct. I felt like the requirement to have the same number and type of arguments for each version of a function caused me to lose some very useful flexibility in comparison to Clojure. Monads are probably the most frustrating feature of this language. They exist to make otherwise difficult things (things which require mutating state) easy, but the catch is that Monads themselves are not a simple concept, so truly understanding what is going on can be difficult.