Lambda the Ultimate

What works in all these cases is that the programs were well thought out and the design was done intelligently, based on a clear and well communicated set of organizing principles. The language and the operating system just don't matter...
What makes a piece of software good has a lot to do with the application of thought to the problem being addressed, and not much to do with what language or methodology you used.

Is the main difference source-code volume: write 10x less code and you'll be 10x more productive? (section 7 in Four-fold Increase in Productivity and Quality)

Specific complaints/comments about the paper:

- First he says " It is a very difficult argument to claim that the best way to organize expensive slow cycles is also the best way to organize cheap fast ones" and then complains "meeanwhile burning cycles by the bushel in the name of optimization". So are cycles cheap or not? BTW, the C++ compile time problem is unique to that language.

- C++ doesn't support threads or serialization. Well, that's not a strike against OO.

- "OOP Claims Unmasked" He argues that domain specific languages perform better in their domain, and code reuse is hard. These are valid complaints. OOP is certainly not the last word in modularity. Recent research into units and staged evaluation has created systems where you can compose language layers and evaluation times. This is incredibly powerful and its possible that doing so can provide the abstractions to build the type of modularity the author is asking for.

For the past few decades, programming language design and implementation research has concentrated heavily in a few notable areas: type theory, functional programming, object-oriented programming, and, of course, optimization techniques. Yet most of the recent commercially successful languages (e.g., Perl, Python, Visual Basic, Java) are not particularly interesting when judged in these domains.

Quality of code libraries?
Specific techniques for composing behaviour? Functional composition vs implementation inheritance vs component interfaces (as-if it were an either-or choice!).

What else matters? - Modularity.
research into units and staged evaluation
Sounds interesting! Please recommend some online reading.

Specific complaints/comments about the paper
The theme of the paper seems to be - OOP is not a silver bullet. I find that hard to disagree with but not very interesting. More interesting would be - is OOP (or technology X) a better or worse bullet than Y, and specifically why?

I agree with the basic argument, but let's not take it too far. First of all, language research and language design are two different things. Good language design (esp. DSL design) is about problem domain abstractions. Thinking about these, is really not the job of programming language theorists.

Second, it is a bit extreme to say that the languages mentioned were not influenced by current thinking. Python, for example, has several language constructs that come from functional programming. Java was influenced by OOP (obviously) and OOP research (e.g., why choose single inheritance over multiple inheritance? Why work so hard to add genericity to the language?)

And oh, all this has very little to do with reducing code size. Sure, when you raise the abstraction level of the language, the amount of code is reduced, but this is a very indirect and unreliable indicator.

"Do languages matter?" I was hoping this extreme silly question was so open that it could go off in unforeseen directions. Do languages matter more than intelligent design? More than code libraries? More than...? What matters about languages?

So paraphrasing from one of the comments at LL2 it matters that a capability is in the language rather than in a code library because that changes the way programmers think about the problem.

And oh, all this has very little to do with reducing code size
Maybe we are just looking at the same thing from different directions. Source-code volume by itself makes programming complicated. We can address that by raising the abstraction level of language constructs. I'm looking at source-code volume as a fundamental problem not an "indicator"; it consumes brainpower so designing a language to encourage concise code should be a fundamental goal (Matz' LL2 Ruby talk).
Wondering about the ways in which I find Java more painful than Smalltalk, reminded me how much more "stuff" you have to write/read/understand/debug in Java (language tithe?).

One of the amusing things about individual programming languages is that we choose to hold-tight their identity, after all manner of additions and mutations. Will we reach the point where different languages have more in common with each other, than they do with the original language spec?

why choose single inheritance over multiple inheritance?
After that long-winded introduction, one way to answer this is to look at the Oak spec: p18 "Interfaces solve some of the same problems that multiple inheritance does without as much overhead at runtime." And to look at the histories "The concepts of multiple-inheritance and operator overloading were identified as sources of potential errors, and eliminated in Oak." Was that the result of OOP Research or simply experience with C++?

Java was influenced by OOP (obviously)
Are we making a mistake to think Java was originally anything more than a variation on C++? "His extensions and modifications to C++ (also know as C++ ++ --), were the first steps towards the development of an independent language". OOP was already part of the cloth from which Java was cut.

add genericity to the language?
I think this shows how little they were influenced by OOP research! Weren't generics part of Modula-3 before Oak existed?

it takes a long time for new ideas to take hold
Let's not forget the positive part of the message, which really is a good reason why we shouldn't despair. There's nothing to stop "advanced" programming languages being wildly successful, they just need to be part of a larger change - a disruptive technology.

Why are these language issues and not library issues?
Someone in the audience said it well:

Everybody who uses Java knows that everything is in an extension to Java in the library... The problem is not how do you make solving the problems possible but how do you create a programming language or set of tools that changes the way programmers think about the problem and that's why it's important that these things be in the language as opposed to being in a tool or free in the hardware or in the operating system.
What we are doing with programming languages is really not solving existing problems, but making it possible to think about new kinds of problems - which we ourselves don't know exist yet, until enough people are using our products (sic programming languages).

I am talking as a language user.

See, I agree that you can have disruptive language technologies. They don't even have to be particularly new in order to be disruptive. Java helped many programmer think about mobile code, simply by utilizing the very old concept of "virtual machine."

What I want to see is how the specific ideas discussed at the end of the talk would effect my programming. Would it be enough to get me to switch langugaes? I am not sure.

Because as a language user I think these crucial language features that make you want to switch, seem small but have great impact. Things like the subtle difference between lexical and dynamic scoping. Or template specialization.

Not huge features that are problem domain specific, and don't really influence or interact with the rest of language, like CSP.

Now parsing facilites would make a nice addition, but as I said - it's already here. Check Perl6, and modern macro facilities.

language features that make you want to switch
Let me suggest that your interest in programming languages makes you unrepresentative.
Let me suggest that most programming is dominated by clichéd domain activities - pushing data from database to ui and back again, managing user sessions, blah blah... Give a better way to express solutions for those activities and they'll take functional programming as-part-of-the-package and learn to love it (later) ;-)

don't really influence or interact with the rest of language, like CSP
I've never thought about what a good language-neutral CSP library would be like: I have to trust his judgement on that. Give me a way to express constraints on values in my programming language, and for a while everything will be a constraint satisfaction problem ;-)

Perl6, and modern macro facilities
You missed the smiley! Isn't this a reference to the repeated LL2 jokes on perl regular expressions and mit macros ;-)

How would you characterize Mozart/Oz? A single language? Several DSLs built on top of a core language?

http://lambda-the-ultimate.org/classic/messagx4475 is a good place to start. You can hunt down the references via CiteSeer.