Lambda the Ultimate

If I had to cram it into one sentence: it’s faster to write software in dynamic languages, and the (real) benefits you get from an anally type-sensitive compiler can be had more cheaply with modern testing disciplines.

But the theory doesn’t matter, because the action is in the practice, and a whole lot of programmers out there have noticed that, in practice, they can get the job done quicker in Perl or Python or Ruby or whatever, and it runs just as fast and breaks less and they get promotions and raises.

I'm with Isaac: my experience with statically-typed, but type-inferred, languages that have pleasant interactive development environments (I'm thinking of O'Caml at the moment) is that they offer all of the RAD benefits of the "dynamic languages" under discussion, but also support the benefits of static typing and block compilation, in particular with respect to performance. In fact, lately I've been talking up interactive development to people, because sometimes the ability or inability to do it doesn't fall along language lines the way you'd expect. O'Caml is a good example of a statically-typed language with a native-code compiler that nevertheless has an interpreter into which you can type code without many, if any, type declarations and tinker until it works. Conversely, Gwydion Dylan, with "Dylan" standing for "DYnamic LANguage," has the Mindy interpreter and d2c compiler; Mindy to this day doesn't implement all of Dylan, and in any case you can't use the EMACS mode to develop interactively in Mindy and then compile with d2c. Finally, Java, no one's idea of a good interactive development language, nevertheless becomes one in IBM's Eclipse IDE, which implements incremental compilation as you type in your source code.

That's not to say that Perl or Python or Ruby haven't earned their popularity. But I do question whether the purported ease-of-development benefits have anything to do with being dynamically typed, or even whether they exist relative to some potentially surprising alternative choices of languages.

Ummm, it is really is the unsubstantiated generalizations I find sad - I make no comment on languages or IDEs or productivity or ...

(How am I supposed to check the validity of the statements?)

Sorry; didn't mean to put words in your mouth. I took the "unsubstantiated generalization" to be "dynamic languages are more productive to develop in than non-dynamic languages," and was attempting to offer some counterexamples based on a hopefully-consensus view of what "dynamic" vs. "non-dynamic" language means... but of course, in the process, I believe I blurred the distinction, as was very much my intention.

also, i've been thinking about kay's comments in teh croquet video, which i only watched recently. that project has been a heck of a long time coming. there was a new spate of "it's almost ready" messages to the mail list recently, but how late is it now? two years? i'm starting to wonder if, certified geniuses, or not, they're stuck in a mess of undocumented type-unsafe goo....

Existential types permit this.

then "wait, what about all the interactive top levels?!". i was left wondering just how well they work: can you define (or redefine) new modules at the top level prompt

If you define a module as a record type quantified by an existential, sure.

does anything support introspection? currently i think the heap/instropsection v source code is just an implementation detail

If your notion of `introspection' is what can be found in languages like Python, etc., then you don't even need implementation support; just tag all your values with meta-information. I guess Java-style introspection requires some implementation support, though.

I think introspection is undesirable, though. It breaks encapsulation.

I agree with the guys who say that the only way to get a real feeling for a language is to do serious programming in it, and so the only way to evaluate whether (say) Python is good for writing programs in is to write some serious programs in it.

Is that controversial?

The way for me to get a real feeling for snow sledding is for me to do some serious sledding.
And yet without that experience I can still understand that wheels work better than runners on hard surfaces, and runners work better than wheels on soft surfaces - we understand the properties of the problem domain (hard and soft surfaces) and we understand the properties of different solutions (wheels and runners).

Are wheels faster than runners? It depends...

Is it "faster to write software in dynamic languages"? It depends...

the only way to evaluate whether (say) Python is good for writing programs in is to write some serious programs in it.
I disagree. I am very happy to learn from the specific experience of others. What I'm able to learn when that experience is generalized into a universal truth - it’s faster to write software in dynamic languages - is quite limited.

Is that controversial?
Is it useful? Too many languages - too little time - satisfice.

i think this is probably a better example than you intended, in that software tends to be more abstract, and have less physical constraints, than meatspace. which means we're making arguments like this when things are so flexible that you can get extremely large diameter, thin, wheels which turn out to look and work just like runners when you focus on the part in contact with the snow....

If the only way I have to evaluate a language is doing serious programming in it, then this evalution serves to none besides me, after all someone else can't evaluate a language by using my evaluation. If we also assume that serious programs take at least a month to be written I would spend my entire life evaluating the existing PLs.

Is that controversial?

No it's just an idea that leaves no room for objective discussion, we are left in the world of fuzzy warm buzzwords and personal taste.

Either you really know a language or you don't. To know it you have to know its philosophy, its idioms, its people. Learning this is what makes new languages so rewarding and so time consuming (one month is extremely optimistic).

For example, I know enough Haskell to write sequential Erlang programs in it, but if I make sweeping generalisations about Haskell (as I sometimes do) it will be very obvious to Frank that I don't "get it". And I don't -- I haven't made the effort yet.

Intelligent people are constantly going out of their depth like this, as is obvious to the other people who really know the subject at hand. Tim Bray's generalisation of "anally type-sensitive compilers" is a great example, but if you look hard enough you can see other instances right here in the discussion forums.

Bringing this back on topic, my suggestion is that there is something very special about programming in interactive, dynamic, introspective languages that you can experience (and that Tim Bray is experiencing). I'm not saying they're better than Haskell. I am saying that type theory etc is not a useful vehicle to appreciate them with. You have to do the programming.

(I put this mildly to be uncontroversial. Really you need not just experience but recent experience to appreciate a language.)

Let me end with two interesting links: http://www.norvig.com/21-days.html, http://groups.google.com/groups?selm=gat-1001021155210001%40eglaptop.jpl.nasa.gov

while i largely agree with you, i think you're being too extreme. while experience counts for a lot, to the extent that computing is a science, you can also work from general abstractions. it's quite possible for a mathematician to make useful contributions to physics in a field they know little about if they happen to recognise some pattern in the associated maths.

obviously it's even better to pair up, physicist and mathematician because the two can complement each other - the theory can provide structure to what is known and provide surprising connections, while the practice provides detail and techniques for avoiding certain problems.

so it's quite possible for theory to provide help and/or criticism of some application, just as it is possible for experience to respond by showing alternative solutions and arguments that change the importance of what the theory has revealed.

surely that is even less controversial than your claims...

Intelligent people are constantly going out of their depth like this

I'm grateful for this comment, as it permits me to acknowledge my sense of being out my depth without requiring me to sacrifice my perception of myself as intelligent ;).

The real depths of the question presumably take a good deal of work to plumb satisfactorily. Frank's comment about existential types reminds me that there's a problem that I have with Haskell that I don't know how to formulate, that may have a solution in Haskell that I don't really understand. Actually, beyond the fringes of what I know and am comfortable with, there are a lot of problems (and putative solutions) like that out there.

What I find sad about the professional cirlce I inhabit is that the region of the known and comfortable is generally such a cramped little maisonette: Python and Ruby on the first floor, Java and C# on the ground floor, C and C++ in the basement. A lot of the arguments about "static" and "dynamic" languages one hears are essentially arguments between first- and ground-floor dwellers...

something very special about programming in interactive, dynamic, introspective languages Sometimes I imagine that the special feeling with Smalltalk boils down to "interactive" - there's a seamless flow. It's not obvious to me how much that seamless flow has to do with a level of expertise, and how much has to do with the language implementation. afaik experienced C++ developers have a similiar experience.

It's not even obvious to me that languages like Smalltalk and Erlang fit in the same box as 'dynamic languages (what we used to call “scripting languages”)' - they might be too single-minded (Smalltalk too OO, Erlang too ...?) in contrast to the hybrid nature of Perl and Python and Ruby and...

which turns out to be the same thing that the Ruby folks invented "duck typing" to mean, not like prototypes where you add methods to objects, but just in the sense of "if it walks like a duck, don't worry about asking whether it's actually a duck." So Duck Typing is just the Ruby way to say "Latent Typing," a term that really does have history in computer science

No, `duck typing' as I understand it means `structural type equality', for a very weak notion of `structure', basically a set. So a type is a set of names, and two types are equal iff they are equal as sets. (Or, with subtyping, one type is a subtype of another iff it is a superset of the other.) This contrasts with so-called `nominal typing', where a type is a name, and a two types are equal iff they are the same name.

More complex notions of `structure' include: a type is a set of names, together with for each name a type; a type is a sum-of-products of types; a type is a regular set of types; a type is a proposition of second-order intuitionistic logic; etc.