Originally posted: September 16th, 2008
(I wrote this a while ago, but didn't post it for some reason. So I'm posting it now.)
I've been very vocal about my distaste towards many of the features of various dynamic programming languages (at least for the purposes of any non-trivial program). Recently, while reading the first chapter of "Practical Cryptography" (by Niels Ferguson and Bruce Schneier), it occurred to me that authors' explanation of "The Evils of Performance" was very relevant to my opinions of these languages.
In that first chapter, the authors stress the importance of security being made the single top priority. They make this point by looking at security as an engineering discipline. As they point out, good engineering has always been about making safety and reliability the primary concerns. No other concern should ever be optimized to a point where it could interfere with safety or reliability.
The authors go on stating that, in the same way, the computer industry needs to prioritize security far ahead of efficiency. To illustrate, they present the explanation: "We already have enough fast, insecure systems. We don't need another one."
I'd argue that in computer programing, reliability deserves a similar status ahead of efficiency. Just as in other forms of engineering though, this doesn't just mean placing reliability ahead of the actual product's efficiency. This also means placing it ahead of the efficiency of the development process itself. We already have enough unreliable software being churned out.
Which brings me back to dynamic programming languages: The reason I so strongly dislike many (albeit, not all) of the characteristics of these languages is because they treat short-term programmer productivity as a holy grail (sometimes even stating it as the single primary goal), while allowing good engineering principles like reliability to fall by the wayside. The real irony, though, is that maintaining an unreliable program is itself a drain on programmer productivity, thus hijacking any long-term productivity gains. So for any non-trivial project, these languages would have been more productivity-friendly by going the engineering route and making design decisions that focused on aiding the creation of reliable software at a reasonable speed rather than potentially buggy software at rapid speeds.
2 comments for "Putting the "Engineering" back into "Software Engineering""
If you only take dynamic languages without any libraries I agree that it's probably hard to write very complex software in an reliable way.
I'll focus on Ruby since it is the most evolved dynamic language I know well (only rudimentary knowledge of Python and PHP can't yet compete in terms of a general purpose language).
Large projects in the Ruby world often (if not always) rely heavily on testing. And there at least Ruby allows you to test your code in a very deep way, thanks to its very dynamic nature (manipulating objects on the fly, inserting stubs, comparing return values using proxies, etc.). Ruby on Rails is a good example for a big and very complex project that is yet every reliable (haven't encountered a bug in 2 years).
I don't have much experience with software engineering in the way that you model your entire software in UML first and then implement it. I only know it from the Java world. From what I've seen there the "engineers" always seemed to be concerned with the bigger picture _only_. This lead to many subtly interdependencies between all parts in the form that the layout of one part simply doesn't make much sense if you don't know the overall architecture.
When looking at Ruby projects I often see that individual parts still make when they are on their own. Some projects even go as far as creating independent libraries out of the (e.g. Rails again). In the bigger picture this still fits together nicely but each part has an existence of it's own instead of just being part of the bigger picture.
I don't know how much this applies to dynamically vs. statically typed languages since I haven't had the same experience with Python so far. But software engineering isn't a discipline reserved for static languages and maybe some features of dynamic languages can help with engineering. :)
Interesting points. I'd argue though that static typing doesn't inherently preclude the types of reliable-engineering practices used in dynamic languages. The D language goes a long way towards proving that. But, as far as I can tell, dynamic typing does inherently preclude the automatic compile-time safeties provided by strong static typing.