Have language researchers gotten it all wrong?

[Daniel Keep]

Nick Sabalausky wrote:
> (Stuff)

I'm going to have to disagree with you on this from personal experience.

Warning: the below has turned into a semi-rant, semi-story.  Feel free
to disregard in favour of this executive summary, given in response to
your post: nuh-uh!

A few years ago, I wrote a tiny, throw-away tool called DSTP for my
research project.  It was a little 822 (yes, I went back through source
control to find it :P) Python script that I wrote the first version of
in, literally, a few hours.  I'm fairly certain it would have taken
significantly longer had I tried to write it in D.

That said, the program ended up actually becoming a fairly important
part of the research program's toolchain, so I rewrote it to be a little
less hacky, and it eventually grew into a small 2,292 line Python
program.  Lack of static typing was an issue in one or two spots, but
again the speed with which I built it and could modify it outweighed that.

Note that I consider 2k lines "small".  You're right in that "Hello,
World!" is easy no matter what language you use [1].

In the end, the other researchers were throwing large enough files at it
that it being written in Python was becoming an issue [2].  So I took a
few weeks off the main project to rewrite DSTP in D.

It's now a 5,014 line D program that does *most* of what the original
Python program does.  There's still a few things I need to add back in
(like scripting support which is obviously several orders of magnitude
harder in D than in Python) but it's basically the same program.  It
uses the same algorithms and data structures.

It's now about twice the size it was originally, but it *is* around 10
times faster, depending on how you test it.  And you know what?  The D
version isn't really any easier or harder to write or maintain.  I would
say, however, that it's harder to prototype in.  One of the huge
advantages of something like Python that a lot of people, shockingly,
seem unable to grasp is the interactive interpreter.

I can load my program, type in a few lines of code to see how they work,
fiddle with it until it does what I want, then lock that down in to a
function.  Reload and continue.  With D, this is much slower and,
lacking Python's built-in dir() and help() functions, harder.

(Incidentally, please no one argue that D can do this.  It can't.  If
you think it can, you simply don't understand what I'm talking about.)

Really, I think the major benefit of a dynamic language is that it lets
you think about what you're trying to do, as opposed to trying to think
about how to work within the type system.  I lost quite a few nice
internal features of the codebase in the transition, like the ability to
hook up a processing function like this:

> @bind_to('pick-uniform-random', no_contents=True)
> def pick_uniform_random_bind(context, attrs):
>     range,words = bind_exactly_one_arg(attrs,'range,words')
>     integer = get_arg(attrs,'integer')
>
>     context.write(unicode(pick_uniform_random(range,words,integer)))

Let's just say that the D equivalent is... not as pretty.  It's 45 lines
of not-as-pretty.  That one bind_to call does a LOT of work that I can't
really paper over in D that easily; a lot of that is thanks to dynamic
typing.

In contrast, static types would have made the original code easier to
read in some cases.  One problem I had was that I was constantly going
between something like four or so different representations of the XML
being processed, which meant I had to be very careful about which
variables I passed to which functions.

In the end, I think that anyone who takes the stance that either static
or dynamic typing is "right" is just outright missing the point.
Correct tools for the job: dynamic typing mobs the floor with static
typing when you don't know what the types are, and vice versa.

Ok, I'm done.  Now get off-a mah lawn!

:D


[1] unless you've been in the University of Wollongong's introductory
Java subject where the lecturer SERIOUSLY told us that a three-file,
5-page "Hello, World" program was an improvement over the 5-line
version.  I swear I heard someone crying behind me in the hall when he
said "this is Java, this is good!"

[2] to be fair, the actual problem was that Python's XML libraries just
didn't seem to have been built with my use-case in mind.  I was doing
WAY too many copies and transforms of the data to get what I needed.
Slices and having the source to Tango's pull parser helped enormously.