Static Languages: Rationalizations and Myths
February 5th, 2008 | Published in dynamic languages, emacs-lisp, erlang, perl, python, Ruby | 33 Comments | Bookmark on Pinboard.in
I see my old pal Bill is spreading dynamic language FUD again. I’m the “dynamic language evangelist colleague” to whom he sent the email he mentions.
First, I find it funny that he calls me a “dynamic language evangelist.” I’m really more of a multi-language evangelist, or as Ola Bini recently put it, a polyglot programmer (in fact much of Ola’s recent thread on this topic matches up well with what I said on the closing JAOO 2006 panel). This year marks my 20th year of using C++, for example, and I still use it every day, so that probably automatically disqualifies me from membership in any dynamic language clubs. But this year also marks my 20th year of using both Perl and emacs-lisp, so maybe there’s hope for me yet.
Bill gets irrationally upset when I tell him I write in five different languages every day. They are, in no particular order, Erlang, C++, Python, Perl, and emacs-lisp. I really like Ruby but unfortunately don’t get much chance to use it at the moment. I even have to delve into SQL every now and again. Apparently, this notion drives Bill crazy not only because I don’t use Java (though I’ve written my share of it in the past), but also because it means I can’t use an IDE, since no IDE can handle all of the above. Apparently, if you can’t use an IDE to automatically rename your methods for you every 10 minutes or so, you’re not a real programmer.
Bill’s posting, like his original email to me that sparked it, is yet another “we’ve got to put these dynamic language folks in their place” postings (read to the bottom of that link for the context). He basically says so himself. His posting is full of the usual misunderstandings, rumors, poor guesses, and misinformation.
Issue 1: Dynamic Language XXXX didn’t do well against Java in XXXX benchmark
According to Bill, glaring differences between languages in how they perform on benchmarks must be recognized. Yes, that’s true — if all languages performed equally for all tasks, then we wouldn’t need multiple languages. Unfortunately, monolingual developers like Bill don’t view it that way; instead, they view benchmarks as some sort of strange competition where you can try to build up your self-esteem by gloating over the benchmarks for which your one language looks good.
I asked Bill why anyone would choose a language not known for its number crunching capabilities and actually try to use it for real code requiring number-crunching, like calculations involving the Mandelbrot set. He didn’t answer.
In reality, we need multiple languages because there are so many trade-offs to make. One way to address the need to make trade-offs is to choose a general-purpose language like Java and hope that it’s good enough for whatever you have to work on. Another way, and the way I prefer, is to be adept at multiple languages so that you can use the right tool for the job and handle unforeseen requirements. When a monolingual developer runs into a task for which their one language is ill-suited, they typically either bend the problem to fit their language, or they just avoid solving it altogether. Hammer, meet nail. Either way, they’re out of luck, or actually, their customer is out of luck. We polyglots don’t have that problem.
Issue 2: Ruby VM cannot support kernel threads
This issue is already addressed in comments in Bill’s blog, where several people mention all the current work on Ruby internals. But I would add that someone who’s writing authoritatively about Ruby should at least do his homework and already know that this “burning” issue is actually not an issue. Bill mentioned both in his email to me and on his blog that even his beloved Java still needs work, citing the need for “typesafe closures to complement annotations,” “a standard, non-code generating way of adding behavior to annotations,” and “a structural syntax to make initialization easier.” I assume therefore that the fact that Ruby also needs work will not be held against it.
Dynamic languages like Ruby, Python, etc… are not typesafe/statically typed
This is where Bill gets into the IDE religion. When I told him I use five different languages every day and said that I don’t need an IDE, he got mad and called me a name. It wasn’t even a particularly imaginative name, so perhaps he could get his IDE to automatically rename that name for him to turn it into a better insult. I asked if he could recommend a good IDE that could adequately handle all those languages for me, but he didn’t answer.
I use emacs. I’ve used it since 1985. I used Eclipse over the past few years for my Java work, and I really had strong hopes for it for other languages, but it’s still too Java-centric, and my current work doesn’t involve Java anyway. I am highly productive with emacs, and I see no reason whatsoever to change.
Bill asks why we can’t have a dynamically statically typed language. We can; see for example Haskell, and go look at all of Erik Meijer’s work.
Lack of type safety doesn’t scale well to large teams
Prove it. This is pure conjecture, nothing more, nothing less. Scaling development has everything to do with the team members and how they work and work together. Saying that “my buddy Jason was on a team that had to put type names in their Python function names” is certainly not even close to being solid evidence of your claim, Bill. For that particular example, BTW, why not describe the typing expectations for a function in its docstring, thus making it easily accessible to actual human programmers from their interactive Python prompts? That’s way better than applying some weird brittle Hungarian notation convention.
Lack of static typing does not allow for reliable refactoring in modern IDEs
The contrived Ruby example that Bill uses to “prove” this is, well, contrived. Why would anyone write code like that or suddenly get the urge to rename init to init2? I’m no Ruby expert, but I’d probably rename the method and then stick a method_missing in there to catch any call instances I might have missed with my editor. I’m sure a stronger Ruby developer can suggest a better way. Either way, it’s really not a big deal, Bill. I’m sure I could get it done well within the timespan you waste on fantasy football every day. ;-)
In 20 years of writing some pretty large C++ systems, for example, I don’t really recall ever having to go and rename a whole bunch of functions across a codebase. I recently had to move some classes from one C++ namespace to another, but a few lines of elisp automatically fixed 3000+ files for me, all without breaking the build (and yes I’m aware of namespace aliasing, thanks).
I asked him if these magical modern IDEs that raise productivity and eliminate common errors also eliminate defects caused by missing or misunderstood requirements, missed use cases, or just plain ol’ bad programming. Again, no answer. The reason I asked this is that those are the bad bugs; syntactical errors are really the least of your worries. Even if the IDE spits out common idiom/pattern skeletons for you, it’s still quite possible to screw up the code logic, and neither the IDE nor the compiler is going to prevent that.
I asked Bill if he’s ever considered that Java IDEs are the way they are due to issues with the Java language itself that must be compensated for. Consider its verbosity, for example, which is why IDEs spit out those skeletons. I can’t remember if he called me a name for asking that, or if he just didn’t answer. Either way, I got no response.
Bill asks if we can’t just learn how to type, but isn’t it the other way around? Shouldn’t he be asking why he needs the IDE to type for him? Odd.
Considering how old Java is, it’s obvious that it’s taken quite a bit of time to get these IDEs to where they are today. I asked Bill if everyone should have to wait a long time, on the order of 10-15 years, before an IDE truly becomes valuable for a given language. No answer. Personally, I’d rather stick to my emacs and UNIX tools, with their infinite applicability and flexibility that can be used for development in pretty much any language, than wait around for someone else to give me a far less functional IDE that barely addresses only one language. But then again, if one language is all you got, then I guess you have no choice.
The rest of the myths Bill cites just circle back to the same weak IDE arguments again, so I’ll skip those, save for this one:
Software Engineers should use the best language for the job
Yes, this is true, unless you’re an elitist.
Like Bill, I’ve spent much of my career writing middleware. However, unlike Bill, I’m not happy to sit around thinking that C++ or Java is the best we can do. I wish I would have known about Erlang 10 years ago, for example, so I could have saved myself countless development hours and headaches. In hindsight, I wasted way too much time trying to build in C++ and Java what Erlang basically gives you for free. I have only my own ignorance to blame, but now I know better. Thankfully, I now work in a place that lets me apply the right language for the right job, and our productivity is significantly higher than any place else I’ve ever worked.
I told Bill that if he wanted to do benchmarking, he should go benchmark the Yaws web server, written in Erlang, against Apache or some Java web server. Needless to say, that would be far more realistic to a lot of developers than Mandelbrot calculations. His response was that he didn’t need to, because Apache would win. That kind of poor assumption is much like the mindset that led me to poorly reinvent half of Erlang in my years of middleware work. These days, though, if I saw this graph I’d be highly intrigued — and in fact, I was when I first saw it — so much so that I’d want to run my own tests to see if those claims were accurate. My own tests were smaller scale than what that graph shows, but the results were basically the same. I’ve rerun my own tests and some others as well, and I get the same results every time. So Bill, rather than guess and make assumptions, why not try it for yourself? Or are you afraid to find out that dynamic languages actually are quite useful?
The things I write about in this blog are based on significant hands-on experience. Unlike many developers, I’ve heavily used approaches and techniques from both sides of the fence, and based on all my experiences, I’d rather use dynamic languages than static ones. I have more success with them, and the systems I use them for turn out better. That’s not wishful thinking or fabrication, that’s simply the cold, hard, factual truth. I wonder, then, why Bill and others like him insist of trying to “cure” me and others like me of our successes?
If you don’t like dynamic languages, then don’t use them! Leave us alone and go back to your monolingual world, and maybe rename your methods again. You can even have my IDE, since I’m not using it, which should double your productivity yet again, right?
February 5th, 2008 at 8:24 am (#)
What is a “dynamically statically typed language”? If Haskell fits this, does ML family (e..g SML, OCaml) doo to? Usually we use static in opposition to dynamic (irt type strategies), so in that sense “dynamically statically” is meaningless.
February 5th, 2008 at 8:45 am (#)
Well put. I myself use many languages (currently I do a lot of work in D, Prolog, and Lua). I may not agree with your use of emacs (I’m a vim person), but that’s just a matter of opinion. Certainly, if emacs is an “os disguised as an editor”, then a gui IDE would be “the world wide web disguised as an editor” [/hyperbole].
February 5th, 2008 at 9:02 am (#)
He is trapped in the world of thinking in IDEs.
IDE in, brain out.
Emacs or vim in a way are IDEs too, but the biggest problem is actuallying thinking that any language relies more on an IDE than on one’s brain.
I must say though, the java folks are extremely religious about their language. I think it has to do with doing it like everyday and liking it, even though there are better languages out there.
February 5th, 2008 at 9:14 am (#)
Daniel: I’m not entirely sure. The nearest thing I could guess at what Bill meant by a “dynamically statically typed language” was the type inferencing that languages like Haskell do.
February 5th, 2008 at 9:47 am (#)
Java didn’t do well against C/C++ in a benchmark.
Then again, C/C++ didn’t do well against assembler in a benchmark.
Plus ca change, plus ca meme chose.
What a hoot!
February 5th, 2008 at 9:49 am (#)
‘nuther thought:
Domain-specific languages can often out-perform (both on raw performance and productivity of dev/maint) more generic languages.
With the proliferation of XML into everything, the XRX stack (XML, REST, XQuery) can be an order of magnitude more productive than the usual dynamic language suspects (eg. Ruby, Python, Perl, et al). XQuery as a higher level scripting language…interesting concept!
Funny how that works.
February 5th, 2008 at 10:20 am (#)
“His response was that he didn’t need to, because Apache would win.”
Who said anything about needing to? He should do it for the same reason I’m sure he watched the Superbowl: for the joy of seeing his team clobber the other guys.
February 5th, 2008 at 10:52 am (#)
Reg. statically typed dynamic languages, someone brought up OCaml and that reminded me of Microsoft’s F# which is also derived from the same family. So I went to the F# site and true enough their section about types confirms my suspicion.
“F# is statically typed. This means that all expressions are given a type through the static typing rules of the language. F# code is also dynamically typed in the sense that certain values permit the runtime discovery of type information through type tests, and dynamic types such as obj can represent essentially any F# value.”
(http://research.microsoft.com/fsharp/manual/quicktour.aspx#QuickTourTypes)
February 5th, 2008 at 10:55 am (#)
@Daniel: What I mean about “statically typed dynamic language” is features that allow us to do AOP-like things at runtime, but in a statically typed way. Like being able to attach a Mixin to a particular object instance at runtime. Others would be being able to make schema changes (add fields, methods, etc..) to a class at runtime without having to recycle the entire classloader. Again, without breaking static typing.
@Andrezj: I think with annotations + closures we can have it both ways: A generic language + DSL. Also, getting all these DSL’s and dynamic and statically typed languages under one VM would be HUGE.
@Steve: I find it funny that you have inferred that I am both elitist and closed minded particularly when we had some pretty heated private arguments about REST. Arguments where I thought it was silly to choose REST over CORBA or WS-*. Well, our conversations had intrigued me so I researched it and changed my mind. I’m a big REST fan now because of it.
This debate though is entirely different. Unlike REST, I do have decent experience with dynamic languages (which you continue to ignore entirely). I was also in the emacs/vi/I-scoff-at-IDEs camp for a long long time before I changed my mind in 2002 when Intellij came out.
Anyways, I called you a “dynamic language evangelist” because a) it sounds better than “big-brother-figure-ex-colleague” b) a lot of the junk you through at me is stuff I’ve read before from different DL-evangelists, and c) I did not want make it personal, and name you directly. I guess you have no qualms about making things personal, so if there is a next time, I’ll just name you directly.
February 5th, 2008 at 10:56 am (#)
You raise a number of good counter-points, but I think you missed a very important one. Bill’s argument against dynamic languages seems to be that the current state of the industry is as good as software development can get. But the current state of the industry is absolutely abysmal! (Check out this Coding Horrors article for some background: http://www.codinghorror.com/blog/archives/000588.html).
In the vast majority of cases, businesses aren’t hurting because of the runtime performance of their software, they’re hurting because of the delivery performance of their software development process! Dynamic languages may or may not be the answer, I think they are, but realistically the jury is still out. But at least they are an *attempt* at finding a better way. Pretending that the current standard software development methods and tools are adequate is basically sticking your head in the sand.
February 5th, 2008 at 11:18 am (#)
Bill: how else would you suggest that I comment about what you wrote in your blog without naming you? Should I have paraphrased your whole blog entry without linking to it, to somehow keep you anonymous? Instead, I chose to link to it, given that it is publicly visible, and since your name is clearly and prominently displayed there, I didn’t think mentioning your name would be such a big deal. In other words, I would have mentioned your name whether you were blogging about me anonymously or not.
Also, note that there’s absolutely nothing personal directed at you in the blog posting above, nor was there anything personal in the email response I sent in reply to your email flame. If there is, please show me where. There are a few funny remarks about IDEs and method renaming, true, but certainly no more than the snide remarks in your own blog posting.
February 5th, 2008 at 1:36 pm (#)
There are two threads under discussion here from what I can see: 1. Dynamic vs Static typing; 2. Poly- verses Mono-lingualism.
Neither argument is black or white:
For 1. Groovy, for example, can be dynamically typed but it is source compatible with (statically typed) Java. It even ships with an ant task which will optionally compile both groovy and java source. So from a certain point of view it can be seen as both statically and dynamically typed.
http://groovy.codehaus.org/The+groovyc+Ant+Task
For 2. There is an upper limit to the number of languages a person or team can be proficient with at any given point in time.
Steve, you’ve rekindled my interest in Erlang for example. Erlang differs from most ‘popular’ languages in that it is a shared-nothing ‘concurrency-oriented’ programming language.
Once you’ve grokked a conditional statement or coroutine or try-catch block or list comprehension or … in one language it is easier to translate to another. It is ‘more difficult’ to learn how to program in a single-assignment-variable language if you haven’t developed in one before.
How polyglotic is enough? How much is too much?
These are questions easier asked than answered IMHO…
Darach.
February 5th, 2008 at 1:56 pm (#)
“One Language to rule them all, One Language to code them, One Language to solve them all and in the benchmark bind them.”
February 5th, 2008 at 2:58 pm (#)
Erm… no. 21st century optimizers know more about specific behaviour of a CPU’s branch prediction, pipeline and caching than you do. Most computing-intensive algorithms written in C will be faster than their hand-written Assembler equivalent (unless the Assembler programmer _exactly_ knows what she’s doing).
February 5th, 2008 at 4:20 pm (#)
1. It’s incredibly awesome to me that Java is now using the C/C++ argument of “your language is too slow”. I remember when the argument against Java was that it was 4 times as slow as C/C++. How times have changed.
2. Ruby and Python were released before or right near Java. If Java is dying because it is a dinosaur how come Python and Ruby are growing at such strong rates?
3. Who needs an editor? When I can do in 1 line of code (in Ruby or Python) what it takes 10 lines of code to do in Java do I really need an editor to rename functions for me or perform various “refactoring” activities?
February 5th, 2008 at 4:38 pm (#)
The term “dynamically statically typed” is meaningless. I think the term you are probably looking for is an “implicitly typed” language – one where types are determined at compile-time, but they are determined through inference, rather than relying on the programmer to specify them explicitly.
I find this to be a good explanation of how to classify type systems: http://cdsmith.twu.net/types.html
February 5th, 2008 at 7:28 pm (#)
Another Vinoski myth:
“Java IDEs are the way they are due to issues with the Java language itself that must be compensated for”
Reality: Let me go through the list of Code Gen and Refactoring items and see what is not useful in, let’s say, Ruby. There are 30 refactorings in IntelliJ + Java. Only 8 out of 30 are NOT useful to Ruby. For the “Generate..” code generation tab. 2 out of 5 are not useful for Ruby. I think the “Surround With..” tab is useful. The thing is, out of these 35 things, I *DO* use one of them *at least* every 10 minutes.
Code Gen…
Constructure: true
Get/Set methods: false
equals/hashcode: true
Override methods: true
Implement methods: false
Refactorings…
Change Class Signature: false
Change Method Signature: true
Convert Anonymous to Inner: false
Convert to Instance Method: true
Copy/Clone Class: true
Encapsulate Fields: false
Extract Include: false
Extract Interface: false
Extract Method: true
Extract Superclass: true
Generify: false
Inline: true
Introduce Constant: true
Introduce field: true
Introduce parameter: true
introduce variable: true
invert boolean: true
make class static: false
make method static: true
Migrate: true
Move: true
Pull members up: true
Push Members Down: true
Rename: true
Replace Constructor with Factory: true
Replace inheritance with Delegation: true
Replace method code duplicates: true
replace temp with query: false
Safe Delete: true
Use interface where possible: false
RENAME: true
CHANGE SIGNATURE: true
MAKE STATIC: true?
Convert to instance method: true?
Safe DELETE: true
MOVE: true
COPY: true
Extract Method: true
Replace Method Code Duplicates: true
Extract Superclass: true
Pull members up: true
Push members down: true
Introduce field: true
Introduce variable: true
Introduce
February 5th, 2008 at 7:30 pm (#)
Bill: so let me get this straight. In your original blog posting, you were “proving” that IDEs couldn’t be used for dynamic languages, but now you’re “proving” that they can? Which is it?
February 5th, 2008 at 7:40 pm (#)
yet another Vinoski myth:
“I asked Bill if everyone should have to wait a long time, on the order of 10-15 years, before an IDE truly becomes valuable for a given language.”
Reality: One, I don’t remember him asking me this. Two, I think the IDEs (at least Intellij) are so well designed now that they can easily support a variety of languages fairly quickly. Add to this fact that their APIs are open (not OSS, but open) and have a great community. For instance, on a quick search I found plugins for Ruby, Python, AspectJ, XML, XML Schema, and Scala. The interesting thing about Intellij, is that it also has support for frameworks. For example, it has syntax checking and code completion for embedded Hibernate/JPA QL. Refactoring integration between Spring, JavaEE and Java. I haven’t looked at their RoR support, but I bet it is awesome. I continually find it AMAZING how these guys bang things out. They are either an army of people (doubtful) or just have an incredibly architected product (probable).
February 5th, 2008 at 7:50 pm (#)
Bill: One: go re-read your email; it’s in there.
Two: again, you’re contradicting yourself. Originally your blog posting pointed out how poor dynamic languages are because modern IDEs can’t work their magic on them, but now you’re pointing out how all these IDEs support all these dynamic languages. Which is it? What’s your actual point?
It goes back to what I suggested to you in my email over the weekend: if you haven’t tried using some of these IDEs recently with these dynamic languages and with an open mind on a real project that doesn’t involving renaming
inittoinit2, you might actually find them useful (though I can’t say for sure, of course, given that as I’ve made abundantly clear, I don’t need an IDE). Would you judge the effectiveness of today’s Java IDEs by your experiences with the IDEs that were available for Java 6 or 8 years ago? Of course not. So why do you insist on denouncing them when it comes to dynamic languages, even though you haven’t tried them recently?February 5th, 2008 at 9:01 pm (#)
[…] my evangelist colleague was in my “Dynamic Languages: Rationalizations and Myths” blog, wonder no more. Please go read Steve Vinoski’s comments, they are a good read. One of my major points […]
February 5th, 2008 at 9:01 pm (#)
I don’t have anything to contribute, but I just wanted to commend you on this fantastic quote:
“This is where Bill gets into the IDE religion. When I told him I use five different languages every day and said that I don’t need an IDE, he got mad and called me a name. It wasn’t even a particularly imaginative name, so perhaps he could get his IDE to automatically rename that name for him to turn it into a better insult.”
That’s probably the funniest thing I’ve read in a programming blog in a long time.
February 6th, 2008 at 5:44 am (#)
Several years ago I was asked to justify a decision to introduce a “scripting” language (Tcl) into our team. I spent some time in background research, and found that there are a small number of academic papers on the topic.
The most relevant papers I am aware of are by Lutz Prechelt, and compare of C, C++, Java, Perl, Python, and Tcl. Prechelt compares factors like execution time, development time, reliability/defects, and code size over 80+ implementations of the same specification in different languages.
The general conclusions (of Prechelt and others) are that dynamic languages produce compact code of comparable readability, higher reliability and higher maintainability than Java/C, with execution times often in excess of Java (circa 2000, probably no longer true); and that the languages are viable development platforms.
Prechelt’s papers can be found on his home page http://page.mi.fu-berlin.de/prechelt/Biblio/ ; the relevant ones are “An empirical comparison of seven programming languages” and “Are Scripting Languages Any Good?”
February 6th, 2008 at 5:55 am (#)
Lordy, I sure do tire of all these performance claims. In the universe of software applications, the number of projects that fail due to performance reasons can be counted on one Yakuza hand… and in those spare instances the explanation is more likely found in poor data structure / algorithm selection. Given the speed of modern processors, language execution speed is a minor issue for the vast majority of applications.
The reason Developers are flocking to “alternative” languages like Ruby, Python, etc. is because main-stream languages such as Java fail on the following counts:
(1) conciseness – Java’s bracketed syntax, its insistence upon type annotations even where types are trivially inferred, its lack of support for list comprehensions, built-in list syntax, user defined operators, etc. lead to a significantly larger code surface area.
(2) reuse – Java’s inability to parameterize aspects of an algorithm via closures or first class functions is a real weakness which leads to unnecessary code duplication.
(3) inflexible type system – a statically typed language can be a real boon to developers working on large code bases. Type annotations provide excellent documentation of a code’s behavior and static typing catches a lot of errors that might manifest themselves erratically at runtime. But… static typing really encumbers development during the prototyping phase, when the shape of key abstractions is in flux.
So, I strongly agree with you, except on the issue of static typing aiding large scale development. Using type annotations to document and enforce behavioral contracts
between components that are authored by different developers/teams is REALLY important. As the size of a team or project grows, the ability to enforce and communicate conventions and paradigms decreases drastically – this is a sociological fact that extends beyond the world of software.
And so, in this regard, I would argue that Java falls short of the mark. For large scale development, Eiffel style pre and post condition declarations are highly desirable.
February 6th, 2008 at 7:41 pm (#)
[…] Static Languages: Rationalizations and Myths :: Steve Vinoski?s Blog – A very good answer to a really bad “dynamic languages are bad” article. […]
February 6th, 2008 at 8:30 pm (#)
[…] (or rather, against the assertions many dynamic language fans make) followed by this post by Steve Vinoski who debates/counters the points Bill […]
February 7th, 2008 at 2:07 am (#)
The right way to do Mandelbrot set in python:
http://www.dalkescientific.com/writings/NBN/c_extensions.html
February 7th, 2008 at 5:13 am (#)
Steve, I suggest trying Wing for your Python editing. It has the best emacs emulation I have seen (I only have 16 years of muscle memory but that is enough to make me hate an editor that doesn’t make me feel at home) and the code completion alone is worth giving up elisp for. It’s worth trying, at least. :)
(Komodo is almost as good at editing Python and also does Perl, so that might be even more useful.)
February 7th, 2008 at 2:02 pm (#)
Wow. I’ve been flat out fighting the flu for seven days, and come back to this. I’m sick to my stomach all over again.
Bill Burke seems a troll.
February 9th, 2008 at 4:56 pm (#)
You can have typesafety in Perl (for basic types requires module from CPAN, for classes – integrated in Perl itself).
February 10th, 2008 at 9:11 pm (#)
Steve,
I loved this post. I’ve been using Ruby quite a bit lately and I’ve been blown away by how productive it is. I hear a lot of skepticism from some, especially about the issue of scaling to a large project or team. I haven’t done it yet, so I can’t say whether it works or not. But given the productivity boost, it has got to be worth going down the path to see. Hopefully I’ll be able to report on that soon – my team is about to rebuild our site with Rails (moving from ASP.NET).
Tim-
February 13th, 2008 at 9:54 pm (#)
@Mark Snyder — I completely agree with your 3 points, EXCEPT that “static typing really encumbers development during the prototyping phase, when the shape of key abstractions is in flux”. For me, static typing is especially valuable when things are changing fast, and I want to have my key abstractions as explicit structures, not buckets of random name/value pairs.
March 23rd, 2008 at 5:58 pm (#)
[…] me ha llevado a este artículo, que es realmente interesante de por sí. Pero la cuestión es que me ha hecho saber sobre Yaws, un […]