The author of a previous quote comments...
It is logically flawed to say that because one lightweight language system has been running very reliably, that static typing doesn't help with reliability.If you read through Joe Armstrong's thesis, he describes several large and small systems built using Erlang. More about the software itself and other conference reports are at the Erlang open source site.
If the Erlang examples are not enough, let's consider other languages.
How about Smalltalk? Read on James Robertson's blog how he's able to debug and update live servers. Read Jay Almarode's articles on Gemstone Smalltalk (index to PDF's), how it provides multiple users a distributed, persistent, versioned dynamic system that's kept applications running in finance, insurance, medical, manufacturing, etc. Read about JP Morgan's use of Smalltalk in their financial management system which won a 2004 Computerworld award.
Maybe you'd like to know about Lisp and how it's used by Orbitz for travel planning. There are many similar successes with Lisp.
The list goes on.
I want dynamic languages to succeed in this scenario too (I'm a python fan), but I don't see any evidence, other than partisan flag waving, which demonstrates the superiority of either methodology in creating reliable systems.There is sufficient evidence that dynamic languages succeed in creating reliable systems. I have not seen a reasonably supported hypothesis for static languages in these situations. That is, I have seen claims that they will catch more errors, or catch them sooner, or reduce testing, but I have never seen substantial evidence in support of these claims.
If you have any such evidence, please let me know. My own experience includes building significant systems in several agile and rigid languages over twenty-four years. Based on that experience I would only choose a dynamic, agile language.
Do you have any actual evidence as to why dynamic languages are better for creating very reliable systems than are statically-typed languages, or just that one anecdote?Read about the systems above. These languages are *agile* in that they support flexibility and evolution of dynamic systems. Static type checking tends to be *rigid* which, in the small without a test-driven approach, provides the illusion of security. As systems get larger, statically specified information become even less important and even more of a hindrance to change.
Our initial intuition is that reliable systems must be specified up front, and since static type information is easy to specify up front, then this must be the foundation of reliable systems. Almost the opposite is the case. We do need up front specifications, but they should be simple expressions of small parts of the ultimate system. Those specifications should be in the form of tests and dynamic (and concurrent) models, and simple solutions that fail fast.
Read about the systems above. The wisdom is not entirely intuitive relative to many of today's popular programming languages and tools. But the history of computing is inevitably moving in this direction.
6 comments:
Great programmers produce great programs. I am sure that there is some benfit to (insert your favorite language here) and yet I would bet the programmer dominates the success factors (though of course I have no hard evidence other than systems I have built -- and Oracle and IBM and Microsoft and ...).
"Static type checking tends to be *rigid* which, in the small without a test-driven approach, provides the illusion of security."
Surely you mean static type annotations, as I can't imagine why statically proving correct behavior (that is, finding the presence of simple-to-detect runtime errors) would be a bad thing. Of course, the extent to which type errors can be found in a language lacking type annotations is significantly reduced (e.g. limited mostly to type inference), but nonetheless referring to the whole thing as 'static typing' == rigid is simply wrong.
There's surely a tradeoff to be had. Some languages take it to the extreme (e.g. interpreted languages which almost always delay such incompatability tests to runtime, or conversely Java which forces you to declare _everything's_ type, arguably reducing the same "agility" gained in the previous example), but it's simply a matter of where you prefer to dial it.
Patrick,
thank you for taking the time to respond to my earlier comment. It came out a little firier than I wanted, and for that I apologize.
Upon further reflection, what really bothered me about the post I commented on was what I saw as the attitude of "It is stupid to think that static languages assist reliability; as proof, here's one very reliable dynamic language system". It seemed smug in its assumptions, assumptions which I don't think are certain in any way.
This post seems much better, not in that it gives several more anectodal examples of reliable dynamic systems (I'm sure there are many reliable java/c/c++ systems as well), but that it argues the benefits of dynamic languages without first assuming that they're better.
Live updating is a powerful feature, one that is possible in python but easy in smalltalk, and a point to be argued in this debate.
The importance of testing over trusting in a fairly simple static type checking scheme (java, c, c++) is also an important point in this debate.
I don't yet understand erlang's concurrency, or whatever other language features it has that support reliability, but it's something I've been meaning to study in detail. I will try to read the thesis you referenced; the abstract is interesting.
Finally, I admit that I played devil's advocate in the last post, because I wanted to see you delineate why you felt that "agile" languages were so superior to rigid ones in a more logical way. Since I don't think anyone can give enough examples of reliable agile systems to serve as any sort of valid base for a conclusion, I think it's important to argue the virtues of agile languages from a more abstract viewpoint - sell them on their features, not on a few examples of good systems.
If the Erlang examples are not enough...Let's see, are Erlang systems reliable because the language does not have static-type-checking; or because the language is a single-assignment functional language designed around process-isolation?
How about Smalltalk? I've seen superb Smalltalk systems and dreadful ones.
How about Orbitz? Hmmm iirc a large part of their system is built around Jini...
On a related note, I have been fleshing out Adam Bosworths idea that sloppy systems have a better chance of surviving changes and why certain sloppy systems get wide adoption while others don't.
This blog is awesome! If you get a chance you may want to visit this malicious software site, it's pretty awesome too!
Post a Comment