Have language researchers gotten it all wrong?

[dsimcha]

== Quote from David B. Held (dheld at codelogicconsulting.com)'s article
> Derek Parnell wrote:
> > [...]
> > This I suspect is why dynamic typed languages are proving popular, because
> > you can get a 99% correct program shipped without having to spend 200% of
> > the money available.
> The main problem I see with dynamically typed languages is simply that
> they are too concise.  That is fine for small-scale development with
> just one or two programmers on a team who own the software for its
> entire lifetime.  When it comes to enterprise software, the author might
> own the code for less than 6 months before they move on to another team
> or get reorganized into a different area.  Not only that, the software
> most likely has to interact with other software, and people on other
> teams must then understand its interfaces.
> Because dynamic languages explicitly leave out the details from the
> interface, you have to rely on the documentation that the original
> author didn't write to figure out how to use that software.  You also
> have to rely on the tests they didn't write to verify that it works
> correctly.  Static typing doesn't fix any of this by itself, but it does
>   prevent the stupid-but-all-too-common errors where you call a function
> with the wrong number of arguments, transpose some arguments, etc.  It
> also self-documents what is generally expected for each function in the
> interface and what kinds of objects will get constructed and passed around.
> The more dynamic languages cater to large-scale development, the more
> they begin to look like statically-typed languages.  So the argument
> that "it's faster to prototype with dynamic languages" is only relevant
> for small-scale software, IMO.  In every case I've seen where there is a
> large system written in a dynamically typed language, I see a push by
> the newer engineers to rewrite it in a statically typed language, for
> all the reasons I stated above.
> The economics of large-scale software engineering are such that writing
> the code constitutes only a small portion of the time creating the
> software.  All that "burden" of writing types and making sure they match
> is very, very small compared to the additional safety they provide in an
> environment that will eventually be full of bugs by the time it hits
> production.
> Of course, that implies that for tasks which do not require a lot of
> engineering, it is entirely appropriate and even advantageous to use a
> dynamic language.  This tends to be utility/infrastructure coding to
> automate things in 1,000 lines or less.  Perl is great as long as the
> user of the Perl script is a programmer.
> So I think the whiner in the original article is missing the point.
> Dynamic languages are not, as far as I can tell, taking over the
> world...  They mostly take up a small-scale niche where they can press
> their strengths.  I would be very surprised to hear about a large-scale
> project in Python/Ruby/etc. (100k+ lines).
> Dave

1.  Perl is a straw man argument.  It is a language that was shoe-horned into
being a "real" programming language and bears way too much cruft from when it was
really intended for just simple scripts.

2.  Yes, the lack of type checking lets large *numbers* of bugs seep into code,
but they're usually the kind of bugs that are easy to find and fix.  Your code
craps out with a decent error message, a line number and a stack trace when you
pass a non-duck to a function that expects a duck.  No ambiguous "segmentation
fault" kinds of error messages.

3.  In addition to dynamic languages becoming more like static ones, I think D
represents the reverse happening.  When programming in D, my programming style is
to use so many templates and auto type inference that I almost feel like I'm
programming in some super-efficient dynamic language, rather than a "real" static
language.

4.  I don't know if it's just me, but I can never figure out how to use an API
written by someone else if the docs suck, even if it is written in a static
language.  If the docs suck, I usually figure the code sucks too and I may as well
roll my own.  Heck, even if the docs are good, if it's overengineered and
shoe-horned into a poor excuse for a language like Java, where there is One True
Way of programming, it still can be a PITA.  (Weka machine learning software comes
to mind.)  At least with dynamic languages (and D, which, with templates is a
kinda-sorta dynamic language), you can design an API so that it is intuitive,
flexible and maps well to the problem domain instead of jumping through hoops to
satisfy the compiler's requirements for explicit type information at the API's
compile time.

That said, efficiency and the existence of templates are my main argument in favor
of static typing. While dynamic languages can be made efficient in speed, it's a
heck of a lot harder than with a static languages, and it still probably has tons
of memory overhead and doesn't let you do close to the metal stuff.  Furthermore,
with D's templates and type inference, I hardly even notice that the language is
statically typed, and it very seldom gets in my way.