Computer Language Mailing Lists

I like learning new computer languages -- especially languages that do certain things better than the languages I already know. I think it's exciting to write real code in a language I've never used before because it's always a great learning experience.

By my experience, if you're venturing into unfamiliar territories, especially places where the cool stuff isn't mentioned in books because it's actually just been committed to CVS, your best resource for answers is often the developer mailing lists. On the mailing list, you can often get answers from real experts to almost any question you have. In many cases, a language's mailing list is almost an important a resource as the language's reference documentation. Yes, you can live without it, but you probably don't want to.

Generally, the more active a list is, the greater the chances are that somebody will give you useful advice when you run into trouble. Following this train of thought, I thought it would be interesting to measure the activity levels of mailing lists for different languages, so I looked the archives of several mailing lists and compiled the results into this lovely graph, which shows the number of postings on each mailing list for the month of April, 2006 (In a couple of cases -- C++/Boost and Ruby On Rails -- I just looked at libraries and/or frameworks that I believe are a central hub of activity for the language).



Despite Java's undeniable popularity, I didn't get any data on its mailing list activity because I just couldn't find "The" Java mailing list" after some searching on Google.

The Ruby On Rails has list nothing short of a phenomenal level of participation, which fuels the RoR's rapid development. PHP, Python, and C++/Boost have a very respectable level of community activity as well, reflecting their popularity among developers. OCaml and Haskell are great languages but judging by their mailing list activity, they haven't made it into the mainstream (yet?). haXe, despite its young age and small number of developers, has a relatively active community, which I attribute to its origins from the popular MTASC flash compiler its rapid improvement by its creator, Nicolas Cannasse. Erlang, which I think is underrated given its unparalleled concurrent and distributed programming capabilities, doesn't have a highly active mailing list in comparison to C++/Boost, Ruby, PHP and Python.

Hope you find this interesting. If you want to dispute my conclusions, go ahead and write a comment and I will make sure to promptly delete it.

Just kidding.

Here's where I got the data:

Ocaml
http://caml.inria.fr/pub/ml-archives/caml-list/index.en.html

haXe
http://lists.motion-twin.com/pipermail/haxe/2006-April/thread.html

Erlang
http://www.erlang.org/ml-archive/erlang-questions/200604/threads.html

Haskell
http://www.haskell.org/pipermail/haskell-cafe/2006-April/thread.html

PHP
http://marc.theaimsgroup.com/?l=php-general

Python
http://mail.python.org/pipermail/python-list/2006-April/thread.html

C++/Boost
http://lists.boost.org/boost-users/
http://lists.boost.org/Archives/boost/

RubyOnRails
http://wrath.rubyonrails.org/pipermail/rails/2006-April/thread.html

Got a MacBook!

I just got a shiny new MacBook at the Apple store in Soho... it is sweet! I knew I wanted to get one as soon as it came out. At first I had some reservations about the glossy screen, but when I looked at it side by side against the MacBook Pro's screen, I realized that the glossy screen actually looks much crisper and brighter and its reflectivity is not an issue unless there's a bright light source right behind you.

Before I got the MacBook, I made sure to order a bigger hard drive and 2 GB of RAM. I knew I would need the upgrades and unless you're rich or just a sucker you shouldn't buy it at the Apple store. I got the cheapest MacBook available for $1099 because I knew I would get the upgrades from NewEgg anyway, and I really don't care about 166 MHz difference or the black shell of the more expensive MacBooks.

Unfortunately, I haven't been able to install any of my upgrades yet because I don't have a tiny enough screwdriver to remove the metal piece covering the expansion slots in the back. So much for the promise of easy upgrades -- upgrading the Powerbook's RAM was much easier

The antenna is excellent. The MacBook picks up my wireless network from a much greater range.

I haven't run any serious performance tests yet but the MacBook definitely feels snappy, and that's without any upgrades.

haXe: to Type or Not to Type?

haXe is a very cool language with a uniquely versatile type system. It's the only language I know that supports both static typing (explicit and inferred) and dynamic typing. For instance, in haXe, you can type


var str = "hello";

and the compiler will realize that 'str' refers to a String type. In fact, the above statement is equivalent to

var str:String = "hello";

This type inference mechanism is inspired by that of ML-derived languages (Haskell supports type inference as well). Although in most cases, you probably want to explicitly state the types of your variables for because type tags make the code more readable, I find it very convenient to rely on type inference in short code segments that use many temporary variables.

haXe is statically typed by default, so its compiler will complain if you try to do something silly such as


var str = "hello";
str.setColor("blue");


because the String class doesn't have the method setColor.

The fun thing about haXe is that it allows you to cheat. Using the 'untyped' keyword or by declaring an object as Dynamic, you can tell haXe to let you bend the rules and stop complaining. Take this example


var str:Dynamic = "hello";
str.setColor = function(color:String) {str.color = color;};
str.setColor("blue");
trace(str.color);


This is perfectly legal in haXe and it works as expected. Another way of doing the same thing is


var str = "hello";
untyped {
str.setColor = function(color:String) { str.color = color;};
str.setColor("blue");
trace(str.color);
}


Again, the haXe compiler accepts this code segment and moves along in its merry way. haXe's support for Dynamic typing is useful because it allows extend and manipulate objects in ways that don't really fit traditional OOP inheritence chains. For example, aspect-oriented design patterns can be implemented fairly easily in dynamic languages. In addition, the ability to temporarily sidestep its strict static typing typing allows haXe to play well with its dynamic predecessors -- Javascript and Actionscript.

I really like haXe's type system. It gives you all the flexibility of Ruby and Python without abandoning you at times when the compiler has enough knowledge about your code to be useful in finding errors. Dynamic languages fanatics would argue that static type checking provides only a marginal benefit because you have to test your code for correctness anyway, but I think they're underestimating static typing's advantages. By my experience, static typing speeds up development quite a lot -- especially during refactoring, when the compiler often points out where the refactored code has broken existing interactions. On the other hand, static typing zealots often dismiss the benefits of dynamic typing, which great frameworks such as Ruby on Rails show to allow the kind of "magic" that makes programming productive and fun. haXe gives you the best of both worlds. What more can you ask for?

More Worlds, of course!

Instance Variables: Top or Bottom?

A couple of weeks ago, a colleague and I had a discussion on the merits of different programming paradigms. The conversation, like many others, eventually wandered to the topic of the shortcomings of Java, an oppressive land where Everything Is An Object, Nouns are kings and Verbs are pawns, as Steve Yegge tells you in his blog. Java has it all wrong, once more we concluded; programming languages are truly expressive when their primary notions are expressed through functions (verbs), not objects (nouns).

But then my colleague said something that with which I didn't fully agree. He said that if you put a class's instance variables at the top of the file, before the method definitions, it shows bad style. After all, objects (nouns, data) are secondary to functions, and the most important parts of your code should appear at the top; therefore, your methods should appear above your instance variables.

At first I accepted this line of reasoning, but after thinking about it more I realized that I actually disagree. Don't get me wrong -- I'm not trying to make a statement here about the relative merits of different programming paradigms. I just think that since a class's methods refer to its instance variables but not vice versa, the instance variables should appear first. This way, when you're reading the code for the class's methods for the first time, the names of the instance variables are already familiar to you.

Well, that's how I feel about the subject :)

Gmail Works Over HTTPS!

Wow, the most shocking truth has been brought to my attention today: you can access Gmail over HTTPS! Just go to https://mail.google.com/ and let your email messages ride those SSL packets, entirely obfuscated to those evil Men In The Middle, to your heart's content. I had no idea... this is just great! I've always bemoaned the utter lack of privacy those free email services inflict on me, but now my life has changed... all due to a single 's'.