The price of freedom is eternal vigilance.

| 4 Comments

Kevin Barnes has written a nice piece on "freedom" languages, his word for Ruby, Python, Perl, etc. He compares these with "safety" languages, such as C++, C#, Java, VB, Delphi.

He starts off by saying "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." and continues to compare and contrast the strengths and weaknesses of each kind of language.

In the end, he decides that "Safety isn't safe and freedom isn't free" but that he prefers freedom but notes that "the price of freedom is eternal vigilance". Too true, and I think that's where I have a problem with freedom languages and the kind of environments that I've worked in. Sure it would be nice to let everyone loose with Python or Ruby and I'm sure the very good and very disciplined can be much more productive if they don't have to keep building artificial walls to keep their concepts where they want them but what about the rest of us? I've dabbled with Python in the past but I find that I like the rigidity of safety languages because it protects me from myself. When I'm feeling good I can build constructs that will help support me when I might otherwise give in to the quick fix... I'm a pretty disciplined guy and even I hear the siren's song of the hacky fix sometimes how do the less disciplined fair in such situations when using languages that are more forgiving? Doesn't everything just quickly degenerate towards no design?

Then again, I'm not sure that some of the truly appalling C++ that I've seen over the years could have been any worse, so perhaps Kevin is right; safe isn't safer anyway, it just appears to be... I guess it's time to get a Ruby book and learn a bit more...

4 Comments

Well I'd have to say that the "truly appalling C++" you've seen could _always_ be worse in perl or PHP (having seen retch worthy samples of both) ... Python seems to fair somewhat better, but mainly because the muppets tend to stay away and use perl or PHP instead. Mainly, I think, because it's less muppet friendly ... sorry, I mean does annoyingly "strict" things like not autoconvert a string to an int or let you alter globals without declaring you'll do so (also possibly because there are less "users" so it's less copy and paste friendly), I haven't tried ruby but I wouldn't be surprised if it faired as well as Python for similar reasons.

Second, when you have bad C or C++ it's almost always _obvious_ to _everyone_. For instance if an application crashes, it doesn't take a coding genius to work out something might not be going well with development (I've even heard that managers can work it out in this case :).
In the same respect you can easily have 100% crap with perl and/or PHP and everything "seems" to be fine, well most of the time anyway -- and those occasional glitches are just a normal part of all development, right? ... right?

Saying all that I love perl, and I've seen some beautiful solutions to problems in perl that would take much more time in C and then likely not be as esthetically good.
But if I had to inherit one of two similar "working" large projects, and one had been done in a perl and the other in C then (given no other information) I'd take the C one everytime.

Thanks James. I've avoided perl because whenever I looked at any it always looked so ugly ... I have a thing about code looking nice and I just don't think I could ever find a version of "nice" that included how perl looks to me...

So, are you saying that you think muppets can do more damage in "freedom" languages than in "safety" languages?

Well perl is certainly unique :) ... and it's unfortunate that basically all IDE's can't parse it for highlighting or indenting, but again to be fair ... it can be nice.

I think "do more damage" is the the wrong way to express the problem, probably "get away with more damage, for longer" is probably closer.
A similar argument can be seen in part of "Worse is better" by Richard P. Gabriel, published 1991, (yes, I'm blantantly appealing to authority):

http://www.ai.mit.edu/docs/articles/good-news/subsection3.2.2.html

...the argument there being that "less than brilliant" lisp programers wrote simple code that performed terribly.
My argument is that the performance is just a general trend in quality, because using C there's this significant quality minimum where you'll just fail completely and utterly if you are below the bar. Almost all of the "easier" languages, as well as making it easier to write certain things above the quality bar, lower this bar (and thus the minimum level of 1quality. And, again, perl/php seem to almost remove the bar completely.

To take a specific example, from another article from the code craft site:

http://www.journalhome.com/codecraft/8106

...the third complaint here is basically that "memory management is hard, use GC" and while yes, it has a veneer of truth and certain error paths can be especially annoying. For at least 99% of the code I write in C managing memory (as well as all the other resources) just isn't a problem[1], and I find it hard to believe that anyone else with a general standard of "good quality" elsewhere in their code is having major problems knowing when to call free().
And to come full circle, while a lot of quality problems aren't going to be obvious to a manager type if the application is leaking memory that's a large visible indicator that something isn't going well.

[1] Note that I'm not saying I _never_ make a mistake, but due to good (IMNSHO) interfaces it doesn't happen often and when I do the mistake tends to happen all the time for that code path and the debug code will tell me about it on the next automated test run.

I agree with you regarding "get away with more damage, for longer" and with the problem of lowering the bar. I say as much in my latest response to RHS's "Moving away from C++" series, here. Code with memory problems usually has a whole host of other problems too and the memory problems are a good way of making sure everyone is aware of the state the code is in...

I don't think there's a solution; well, apart from insisting that only people who actually understand pointers are allowed to write code ;)

Leave a comment