Pensieri di un lunatico minore

Freedom of expression

In “Code Craft,” Kevin Barnes writes about Freedom languages. I’ll let him put it in his own words:

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.

This is in contrast to what he calls “safety languages,” but I would just call boring:

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.

He goes on to talk about how languages like Ruby, Python, Perl, Smalltalk (and leaves out Lisp, though it’s the most “free” by his definition) are free, and the more traditional choices, like C++, Java, etc., are “safety” languages. I think of them more as straight jackets for the programatically insane. Read his writing for a great explanation of his perspective.

Here’s mine.

The safety languages are designed to protect people from themselves as much as anything else, and their first, second, third, and as far as I can tell all, priority is to restrict what people can do for fear that they might shoot themselves in the food. Unfortunately, what they do is put a cap on the maximum amount of productivity one can achieve.

As for the team argument, it is my opinion that good teamwork is defined not by rigid enforcement of “modules,” but instead by a high level of testing and discussion of interdependencies. Instead of pretending that they can be wished away with a few static declarations, they need to be embraced. We need to test our assumptions and work with them, not pretend that we can declare them a non-issue.

My experience is that “teams” for Smalltalk, Lisp, Python, Ruby, etc., are small. Often they are composed of 5-10 people maximum. At Digital Creations we had a product in Python that competed against another company writing everything in Java. We had 5-6 “core” developers at the time. Our competitor? 300-500. Maybe when you have that level of mediocrity, you need the straight-jacket.

But then, maybe, you need some diapers to clean up the mess they create.

[via James Robertson]