Lambda the Ultimate

would'nt it be 4^5 (five standard components) ?

Oops, that's what I meant: 4 * 4 * 4 * 4 * 4 = 1024...

A number of senior software people know that we are in deep trouble and that we don't have a get-well plan, but it's not profitable to talk too much about it -- except as a sell point for the new miracle product of the day.

You can find the word "formal" in every other paragraph. It sounds like a higher level declarative layer where you can specify some things (my understanding is very fuzzy) about large components.

I am totally lost on the "open-file" process. I have no idea if the detection of the isomorphism is manual or automatic, and why the VM designers care (what kind of mistake could the VM designers have done??)

It's really a lot of handwaving and it's a fake interview (the interviewer is 100% satisfied with her answers; no follow-up questions, etc.) It's just a way of publicly stating that they're doing something.

Translated into English, here's how I read that part of the interview:

A number of senior software people know that we are in deep trouble and that we don't have a get-well plan, but it's not profitable to talk too much about it -- except as a sell point for the new miracle product of the day.

Q: Do you [have such a miracle product]?

A: [Yes.]

This is hilarious.

I have delivered projects, in Java, on which I've never needed a debugger once during development. It's a question of discipline and learning techniques that support the development of robust code. That's a people issue, not a technology issue. New programming languages won't stop lazy/poor programmers churning out crap.

As for requirements, programming languages express solutions, not requirements. Requirements need to be expressed in a way that makes sense to non-programmers; a programming language is not the right tool.

Just because your not using a debugger does not mean youre not debugging.

As Li said, just because your not using a debugger, doesn't mean your not debugging. So either your trying to tell us that you don't use a debugger to do your debugging, in which case your argument is a red herring, or your trying to tell us that you have written programs that were bug free and hence didn't need to be debugged. Unless those Java programs were non-trivial, I find it rather hard to believe that they were bug free. If they really were bug free, then you are perhaps the best programmer in the whole world (congratulations). Since everybody that writes code that contains bugs is either a lazy programmer or a poor programmer (or perhaps both), it must mean that every other programmer in the world is either a lazy or poor.

Okay, perhaps I'm being somewhat hard on you, but I'm trying to make a point. (No hard feelings? Good.) I can understand what your are saying (or at least what I believe you are saying). Yes, it is true that with some discipline, a programmer can write better code, but even then a programmer is bound to make mistakes, and what is wrong with developing a language that helps you along the way? Why should you work alone? Why shouldn't my compiler tell me when I make a stupid mistake (or maybe I'm the only one who finds myself making such mistakes). Now, I'm not a good programmer, as I haven't been programming long enough to be good (I just graduated from college last May!), but I'm sure that even after 20 years of programming I will still mix up what I'm trying to write between my brain and my fingers, and I would like tools that would help my own discipline and techniques out a little.

I think that Nat is saying that the software crisis will not be solved with better runtime debuggers, cleverer compilers, or languages that can better express requirements. I think that not needing a Java debugger is his representative example.

I think Nat is saying that this software crisis is a cultural issue rather than a tool support issue.

I agree with that viewpoint, for whatever that's worth.

I've been programming professionally for about ten years, twenty three years for fun. In my opinion, if MSDN and the Sun Java tutorials both included a section on test driven development in their prerequisites, much of the software crisis would disapper.

They do talk about it but in their own style.

I recently started asking my students to write unit tests and to use assertions. I don't see why this goes against also using the type system and the various modularization technqiues provided by the programming language. If better abstractions and/or abstraction mechanisms are found, I will be glad to have them.

To sum up: it can be a people problem and a language problem.

...if MSDN and the Sun Java tutorials both included a section on test driven development in their prerequisites, much of the software crisis would disappear

I don't know if it would disappear, but at least it would help out a lot. Note, that I'm not saying that we shouldn't be disciplined, in fact I'm a big fan of test driven development, however I also believe that it's worth having a language help me out (when it doesn't get in my way). For example, a type system that tells me when I pass an argument of the wrong type. I guess what I was trying to say is along the lines of what Ehud said: Why can’t it be both? Certainly test driven development can find the same types of errors that a strong type system can find (and more!), but the type system can find them sooner and point them out better. This allows me to be more productive (even if only a little more productive), and this is a good thing because its all about productivity in the end, isn’t it?

So, we need both. I need the programming language to tell me right away when I make a stupid mistake that it knows about, and I need test driven development to help me find the stupid mistakes the compiler has no way of knowing about.

Perhaps I make a mistake. I suppose that Nat may have been simply pointing out that compilers can't solve the problem, where I thought that he was making a much stronger statement: languages can't solve the problem and we don't need the language to help solve the problem if we are disciplined enough. For that I apologize.

John Meacham's Supertyping Suggestion for Haskell seems related

(Btw, something like what your quote describes is already possible,
e.g. in Haskell, making a type an instance of a type class is separate from defining the type,
also Scala's views seem to perform a similar purpose wrt traits)

Sather has this, for the exact reason you mention.

Two things come to mind. One is a way of getting around the lack of structural typing. The other is adding new methods to some group of already existing classes.

Well, Erlang's formal specifications do not appear in the results of a simply-minded Google query (though I heared they exist), so I put a smiley.

I would suggest that you take a look at Lars-Ã…ke Fredlund's PhD thesis for a formal semantics of Erlang.

You might be interested in Core Erlang - the linked page includes the "Core Erlang Language Specification" and "An Introduction to Core Erlang".

I'm not seeing any formal semantics in those papers, but since they describe a fairly small functional language core, the semantics are fairly "obvious".

Oz (http://www.mozart-oz.org/) was the first thing I thought of when reading that article.

I was struck that the most "exotic" language she mentioned in that interview was Java and the others were Fortran, C and C++. That's setting the bar pretty low. I suspect that she's a whiteboard architect rather than an experienced developer and hasn't done much of anything with any modern languages.

She also seems not to have read End-to-End Arguments In System Design by Saltzer, Reed and Clark.