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.
3 comments:
"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.
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.
Post a Comment