I’ve never met a coding God who didn’t know at least one “freedom language” that they thought was great.  Many know several.  Some refuse to program in anything else.

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.

Right now the “hottest” new freedom language is Ruby with Python second, but the most heavily used freedom language is Perl with Smalltalk second (my estimates, no science involved).  The popular safety languages are C++, Java, C#, VB and Delphi. These collectively dominate modern programming.  Other less popular safety languages include Haskell and Nice.

Can’t we all just get along?

I picked the terms freedom and safety because they represent a philosophical split that I’m not sure some of the advocates of these languages realize is present.  You can sense this split when you listen to the words that the various pundits use when discussing the merits of different languages.

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.

The advocates of freedom languages tend to talk first about the speed and efficiency of the individual programmer.  They discuss the expressive power of different constructs and focus on all the powerful features that the safety languages lack.  They point out complex patterns and show off twenty-line systems that do the same thing.  They talk more about the ease or purity of things than the safety of things.  They are dismissive of static-type-safety and compile-time validation in general.

Tell me when I break it

The preeminent dividing issue is the dreaded “strongly-typed” debate.  For a long time almost all of the freedom languages were labeled as “weakly-typed” by the safety advocates.  This is inaccurate technically.  Most tend to be dynamically-typed, but for many people this is a distinction without a difference.  The safety advocate wants the “compiler” to tell him that function X wants an int but function Y is passing it a string.  None of the freedom languages do this.

This seemingly simple request (static-typing) is, of course, impossible to achieve 100% of the time, and the closer you get to achieving it the more energy you waste.  It has a logarithmic complexity curve.  Casting is largely a tacit acknowledge of this complexity.

A language that is completely statically typed is also limited in what features it can implement.  Features like an “eval” statement, or dynamic function replacement, or a host of dynamic polymorphic behaviors become nearly impossible.  Many templating and function-passing features also become extremely cumbersome in statically-typed languages.  As a result safety languages have eschewed a wide variety of very powerful features as being unsafe or overly hard to use (and hence unnecessary). 

Const-ness and checked exceptions (which have natural appeal in a safety language) have similar qualities.  Creating systems that manage them with strong guarantees also creates systems that are difficult to use.  In C++, the const qualifier has resulted in massive duplication of methods and increased use of templates.  In Java, checked exceptions have lead to the worst excesses of code bloat.

Freedom languages have decided that the value of static-type-safety (and static-const-ness and checked exceptions) aren’t worth the cost (in missing power and flexibility) and abandoned these notions altogether. 

Protect me from myself

Another place that the difference in philosophy has impacted implementation is in what you are allowed to change.  Safety languages tend to restrict what kinds of components can be extended or altered.  Freedom languages do not.  Smalltalk is, in many ways, the ultimate example of this:  

In Java, on the other hand, it is not possible to extend the Integer or String classes (they are final).  In Ruby not only can you extend them it is possible to change the behavior of the parent class itself.  It is open for extension and (in a sense) modification!

This is no small matter.  If you can’t extend things, replace factory methods, or do other ‘dangerous’ things then you are forced to use some pretty fishy workarounds.  This is especially true for testing (which is ironic).  In C# or Java, you may find yourself turning unnecessarily to dependency injection because you have no other way to replace a behavior with a mock behavior in a test.  In Ruby or Perl you probably won’t (which will let you use your constructor parameters for setting the state of the object and not the state of its environment).

Me too

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?

What language is this snippet from?

int calculate(int count, int value) {

  int i;

 

  for (i = 0; i < count; i = i + 1) {

    value = value + value;

  }

  return value;

}

How about this one?

def calculate(count, value)

  count.times do

    value += value

  end

  value

end

If you can’t tell which language the first snippet comes from, it’s legal syntax in (at least) six safety languages.  The second example is Ruby.

Writers of freedom languages are, by their very nature, iconoclastic (sometimes to an annoying degree).  In these languages there is no fear about changing an element of syntax that might be common in other languages.  Throw and Catch in Ruby, for example, have a much different meaning than in most other languages.

Safety isn’t safe and freedom isn’t free

Both sets of languages are making tradeoffs about what they view as the most important features of a language.  The freedom languages are choosing powerful feature sets and the safety languages favor clearer contracts and commonly readable syntax.  These are choices about how best to achieve the goals of programming.

Unfortunately, the safety languages get very little of the safety they seek.  In the end, anyone who is writing code can bypass the “security” features associated with making the String class final, and not having multiple inheritance hasn’t yet prevented anyone from writing bad class hierarchies.

Type-safety is likewise meaningless if the code subverts types in order to get around difficulties stemming from static-type-safety (an extremely common practice).  I’ve probably seen a dozen database systems where the integer id values associated with the various “objects” are left as integers thereby subverting both compile time type safety and run time type safety.  These coding practices are much more common in systems where there is a dividing line between values that are objects and values that are not.

Strangely, even the safety in numbers of having a huge base of knowledgeable language experts provides less safety than people believe it does.  In practice the bulk of the learning that a new employee goes through (for large systems) is related to either the domain or the specifics of the code base.  If the code base is massively bloated and complex, being the best C# expert in the world wont make any difference.  The real expertise required when crafting code is much more about design than it is about syntax.

If safety isn’t safe, freedom isn’t free either.  Languages like Smalltalk or Python do come with risks.  People can do bizarre and “inspired” damage with any language.  You will eventually face a hard to figure out dynamic-type issue, and someone will eventually modify a value that was “supposed” to be const. The price of freedom is eternal vigilance.  You need to understand complexity and scale in the application and provide people tools to eliminate it.  If your project is large you may need pair-programming, code review, extensive unit testing, and continuous refactoring. 

Ring the bell for freedom

All other things being equal, I think I’ll choose freedom (if I have the choice).  I can risk having to debug an occasional run time error if I can keep my class structures simple.  I’m not afraid of confusing someone by strange use of iterators, and bandwagons are noisy and full of hay.  The next time I have a large program to write I’ll take a closer look at the available freedom languages and pick the one that fits my needs the best.  Maybe Ruby, Martin Fowler thinks it’s pretty hot

[P.S. I have added a meta discussion of this article here.]