I quit participating in "static language" vs. "dynamic language" debates for the most part a few years ago. A few pieces have been getting my goat lately, though. There was that piece on "gradual typing" (I won't find it for you).
Now this linked from Lambda the Ultimate...
When scripts in untyped languages grow into large programs, maintaining them becomes difficult. A lack of types in typical scripting languages means that programmers must (re)discover critical pieces of design information every time they wish to change a program. This analysis step both slows down the maintenance process and may even introduce mistakes due to the violation of undiscovered invariants. This paper presents Typed Scheme...The problem is I've seen large programs in all kinds of languages become difficult. Two things can preserve large programs... many good tests, and familiarity. I've seen that work.
Maybe good type systems can help maintain large programs. I don't know, since I've never participated in developing a large program with a *good* type system.
I do know that a good type system is *not necessary* for maintaining large programs. I suspect it would not help as much as many good tests and familiarity.
I await the comments showing up in my inbox. No promises to publish them.
6 comments:
They aren't saying that types are necessary.. they are saying that they provide useful metadata that can be used to understand a program. They aren't intended to replace good tests or familiarity with the code base, they are just there to help!
If a type system isnt a pain in the butt to deal with and doesnt cause you carpal tunnel, why not use it to your advantage? A typechecker is no more than a test suite that writes itself and never goes stale.
"A typechecker is no more than a test suite that writes itself and never goes stale"
Mm-hmm. Your view of type systems differ from mine.
"If a type system isnt a pain in the butt to deal with..."
Even the Haskell and Scala type systems, to the extent I have become competent with them, end up as pains in the butt to me. I get along very well with languages that do not implement static type checking, even those with inferencing.
That's just me.
"When scripts in untyped languages grow into large programs, maintaining them becomes difficult." is not wrong, just overspecified -- like, say, "I never run marathons on wednesdays" (that's perfectly true... just a bit overspecified, as I don't run them on any other day of the week either!-). When a small program ("designed", or, often, "just hacked together", to do just one or two simple things) "grows into" (!) a large one (presumably doing several complicated things), maintenance WILL be difficult -- because of the lack of design and architecture integrity implied by the "grow into" ``organic'' happenstance. A system that is well designed from the start to BE big, on the other hand, or carefully rearchitected and refactored to BECOME big in an artful way, stands a much better chance to be well-maintainable.
_Untyped_ languages (BCPL, machine language, Forth, are some that come to mind), of course, do make it much harder to debug large programs (when compared with languages that _are_ typed, be it dynamically like Python or statically like Boo), which may help explain why untyped languages are out of fashion (while dynamically or statically typed ones have become much more popular in recent decades).
aleaxit, I see what you are getting at. But the original author appears to be trying to place the blame on "untyped languages" per se. (Which gain I interpret him to mean "dynamic languages" and let's not get into what that means precisely, except "languages like Lisp and Smalltalk". Well even that has problems because Common Lisp does have a kind of explicit type declaration, and... oh, well).
BCPL is a good example of a "truly untyped" language. I've only written a hundred or so lines in BCPL, about 20 years ago. I suspect using more Smalltalk-SUnit-like test driven development, a BCPL program could be highly maintainable and become fairly large.
After 9 years developing in many languages (C, C#, java, perl), I've just spent the last two years on a hybrid project using ruby, javascript, and java (for back-end services).
I've come to believe that rigid typing is a very good thing for larger projects, but not primarily for the reasons mentioned here. Rather, I've found immense value in the browsing and refactoring capabilities that are made possible by the strongly-typed languages.
Once you've become accustomed to reliably finding usages, renaming, and extracting code snippets in java or c#, you really long for these capabilities in the more flexible languages. Not having these features in ruby/js slows me down every day.
Yes, there's an initial-time-to-market trade-off -- the flexible languages enable concise metaprogramming flourishes to increase code reuse -- but I insist that the cost of maintaining this clever code is larger, especially due to the the lack of tool support.
Finally, I liked Maurice Codik's point about the typechecker being an auto-generated test suite: instant IDE typechecking feedback and compile-time validation are fantastic time-savers in large projects. (I won't, however, say that the typechecker is "no more" than a test-suite, since it clearly constrains the design and power of the code).
"I've found immense value in the browsing and refactoring capabilities that are made possible by the strongly-typed languages"
Mmm. I'm willing to bet you've never used Smalltalk. Am I right? The tools kick ass. Large ass. Many ass. Python and Ruby tools suck. Period.
Post a Comment