blog.zacbrown.org - just run away, now.

I saw a reddit question today that was something along the lines of “I’d like to learn 16 languages in a year, which ones should I learn?” This of course sounds ludicrous to me and I definitely advocate against that. I think a better goal for working in a year (and this is stretching it) is to learn a language from the four major language groups (in my opinion) well. This is by no means an authoritative list of languages, but rather a list of languages that just by learning them can teach you things that other languages wouldn’t and thus make you a better programmer.

Lisp - It seems that many ideas and features people look for, Lisp already has, so take some time to learn them here, it’ll definitely make you a better programmer.

Haskell - Everything is a function, and thus you have no side effects. This will teach you to right better code in that you will end up trying to reduce side effects in your Java/C++/Python etc. code.

Erlang/Smalltalk - The beauty of message passing comes out in both these languages, Erlang more in a truly distributed manner. I personally am learning Erlang and love it.

C/Assembly - Working in lower level languages like these two will teach a you a lot about thinking about how you write something will effect different architectures. I know C and haven’t had a chance to really play with Assembly yet.

I’m half way through that list, that is I’ve learned C & Erlang pretty well, next is Lisp. I think those are some of the best you learn. Learn a few things well, the others will come, languages are merely syntax, its the idioms, paradigms and skills that will make you a better programmer, not the language.

So I’ve been playing with SmallTalk for the last couple days. “Why would you want to use a 30 year old programming language?” you might ask. Well thats simple: a friend of mine was starting a project with another fellow and the goal was to create a SmallTalk-80 VM & interpreter built on top of the JVM. The goal is to have a cross-platform SmallTalk environment available to the public.

There have been several debates in our development group as to why a VM/interpreter instead of a bytecode compiler and the primary reason is that in the true spirit of SmallTalk-80, we must be able to dynamically load code into the running software. This is probably possible by creating a bytecode compiler, but the question is how much JVM knowledge-fu would be required to implement code hot-swapping. One of our members noted that the JVM is best viewed as a black box and left to the realm of those who write it.

On another note, SmallTalk is especially frustrating to work with since there’s no one environment that provides all the lovely tools one desires. Gnu-SmallTalk is great as far as a platform goes for running code but currently is more of a “scripting environment” than a development environment. Although from what I’m hearing RMS has asked the GST team to move towards competing with VisualWorks and Squeak as a more approachable development environment. It seems that there’s no one SmallTalk implementation that I can find myself comfortable with since I can find something each that bothers me, though GST bothers me the least.

================

On another note, Lisp has finally seduced me and I’m enjoying every minute of it. A friend of mine has be touting Lisp for a while now and egging me on to try it but I’ve just not had the time to devote to it. I had a free afternoon yesterday and began playing with it and much to my surprise, it was very accessible. The parentheses may bother some initially but I’ve found its actually a better notation than using several different characters to symbolize different things.

I’ve been looking into a language to translate one of my biological models into which Lisp may end up being perfect. It seems to translate more easily to some of the functions I deal with. As of now, its just trudging along with Lisp.