Freedom vs. Safety

Now here's an article I can really get behind - Kevin Barnes draws a rough categorization of development languages - between "freedom" languages (Smalltalk, Ruby, Python, et. al.) and "Safety" languages (Java, C#, et. al.). He's made some very good points, and also makes it clear that his (and my) side of this argument does involve a few tradeoffs. First off, take a look at his definitions:

What, pray tell, is a “freedom language”? Freedom languages are those languages that put the individual programmer at the center of their philosophical world. They work hard to remove any language constructs that reduce programmer freedom, and add the most powerful constructs available. Many are post-modern languages and most tend to be syntactically dense.

The other kind of language is the “safety language.” Safety languages think first about the creation of contracts between modules, objects and functions. They focus on teams rather than individuals. They remove language features that are confusing or frequently misused so that there are fewer opportunities to make mistakes and so there can be clear separation of concerns and maximum verifiability. These languages are full of barriers and check-points and well-defined paths and they tend to be syntactically verbose.

With that out of the way, we get to something I've always found irritating - the presumption by "safety" advocates that the (so called) scripting languages are just toys:

The advocates to safety languages tend to deride freedom languages as “scripting” languages or “fringe” languages. They are only fit for hacking out small projects and putting together demos and whatnot. They focus on static-type-safety as one of the most fundamentally critical elements for ensuring program completeness. They may also talk about execution efficiency (memory, speed, etc). They tend to view freedom languages as improper for a larger team of programmers with mixed skill sets. The heart of their arguments is basically that these languages are not “safe” for large projects.

Kevin makes some great points about this, and I'm not going to try to quote his entire article - you should just read it and see what you think. I do like this, from near the end of the piece:

There is one other strange quality to the safety languages. They all look the same. The safety ideal has manifested itself in even the simplest elements of syntax. The providers of safety languages want constructs and syntax that will be comfortable to people who write code in other “major” languages. They want companies to be safe from an inadequately small developer pool. Many languages that started out looking different (Basic or Pascal) have over time morphed to take on the look and feel of the other safety languages. It’s very easy for someone familiar with C++ to read C# or Java or VB or Delphi. They have a lot harder time figuring out Ruby or Smalltalk or Python. Think I’m exaggerating?

Kevin points out that this presumed familiarity is less valuable than you think - stepping into any large project, the idioms and strategies (i.e., the design) used by the developers will matter more than the language selection in terms of getting up to speed. In any case - as I said - read the whole thing. I agree with almost everything Kevin's said here, including his caveats.