Lambda the Ultimate

There are a bunch of extensions to java, at least, that add new functionality. Off the top of my head, I can think of Pizza (generic types, parametric polymorphism), Generic Java (generic types), AspectJ (aspect-oriented programming), and multimethods (I forget the name or names). Maybe the real win of java is that the language is sufficiently simple that it's easy to add such extensions. Unfortunately, the java syntax was not designed to be extended, so some of these extensions end up looking quite odd. But Generic Java, at least, stands a very good chance of becoming part of the core language. That's a good sign, because my impression is that the java folks have been awfully conservative with language extensions. Guy Steele's OOPSLA talk on "Growing a Language" (don't have the link, sorry) talks about this and strongly advocates an evolutionary approach to language design. This approach seems to be working out well for perl and python, at least, which have formal procedures for adding features to the language (so does java, but very few features are ever added).

One rule of thumb I use when evaluating languages is this: what features of this language should have been implementable directly by users? For instance, in lisp you can write your own object system (or systems), be they multi-methods or not. In java you take what they give you and that's that. I don't think java is a *bad* language, but one of the consequences of its design is that it can be extremely tedious to write certain kinds of code. For instance, try writing code in a functional style. You can fake this using objects, but the syntactic pain is immense. And because there are no macros, there is no way to change this; you just have to grin and bear it.

I think it would be cool to have an S-expression based syntax for java and allow users to write syntactic macros like in lisp for java.

Ocaml, as I mention in the article, is quite happy to give users an enormous amount of power. This leads to a lot of perplexed users and a long learning curve, but at least you don't feel stifled. They also have an amazing code generation system (camlp4) which I suspect will do for ocaml what template metaprogramming did for C++.

• Nice (java + multimethods + ML-sub type system) (LTU discussion)
• Java Syntactic Extender
• Maya (LTU discussion)
• OpenJava

IMHO, I think it somewhat depends on what your goal is.

If your goal is in your own programming tasks, and you are not "employer constrained" (and that includes clients), I think you are better off using the "full powered" languages.

If you are "employer constrained" (say, to Java) then perhaps this is the best way to allow you to use the power (though I have been using an alternate here - generative programming).

If your task is education then it has been shown (PLT) that you are better off starting "full power" (Scheme).

If your task it "to change the world", Gabriel might suggest to (almost) forget it, on the basis that the powerful languages cannot be used by the masses, even subsets of powerful features. The features require real mathematical thinking, which the masses are deficient in (by choice or capability).

I've worked a bit with java lately, and I must say I'm impressed with how much can be accomplished with a really big API, even if the language isn't that powerful. Now, I assume that the pain that went into creating that API and the classes that instantiate it would have been greatly reduced in a more powerful language. However, I can see some logic in the notion that you don't want people to use features that they can't understand (there are lots of horror stories of this kind of thing in C++ projects, for instance). Whether that justifies neutering the entire language is another matter. Perhaps you could have a single language that has "beginner", "journeyman" and "expert" levels at which you could program, with average programmers never going beyond the journeyman level. This would only work if even the expert level code exported APIs that could be used by journeymen.

Here's a copy of the NY Times article about the research http://www.geocities.com/jrstrader2000/Incompetent.htm (I looked through quite a few google results and this is a good ref)

Perl, C++ and, to a lesser extent, Java all suffer from this problem. Java has been able to mitigate it by striving to be simple and restricting powerful features to obscure libraries (e.g the reflection APIs). The only safe way to have different language levels seems to be to have 2 levels-- a level for ordinary programmers and another level for the language's implementers. This way the onus is on the language implementers to use the power that only they have, to build useful/flexible libraries for the ordinary programmers who will use the language.

I agree with what you originally worte, that good languages provide better tools for creating abstractions. So how bad can a lgnauge be, if it can be used to design and implement good libraries (aka APIs)?

Saying that language features influence library design sound trivial. But the issues here are rather subtle.

When you start to design a substantial library, you soon realize that small defects in the language can be very annoying, and rule out certain approaches to the design of the library. "Bigger" problems with the language may turn out to be not that problematic.

One would have thought that the lack of parameterized types in Java would be a huge problem for a Collections API. Turned out, that an ugly (SE-wise) solution works, and a fairly decent Collections library can be designed.

As another example, I can mention my experience thinking about the optimal design of a Collections library for Ada, which has many great features for library design. Turns out, combining them to produce a good library is much harder than one might expect, and small issues with the language, can be really problematic (e.g., Ada, trying hard to be as safe as possible, has some scoping rules that combine badly with the way consturctors and destructors are defined).

Which bring me back to my observation, that worse languages often have better libraries. This is something language designers should think about

This just sounds like a big stick likely to be wielded by someone defining competence in terms favorable to themselves.

But I do believe that "humility is a virtue" and is the best mindset for increasing your competence.

My experience in consulting led me to believe that there were all sorts of opportunities for using innovative software methods, but what usually drives a deal is special relationships and specialized domain knowledge. You may learn about innovative software methods in academia, but the last two items....are most likely gained by immersing yourself in some thoroughly non-academic business.

This just sounds like a big stick likely to be wielded by someone defining competence in terms favorable to themselves."

It does, but the studies seem to be convincing. The explanation was that the same skills were required to do a task well as to judge your own ability to to the task. The more you understand of a subject the more accurately you can assess the depth of your knowledge.

But...

These (Java, VB, C#, ...) are "Languages for the Masses" - high volume sales to support the development of lots of APIs (libraries).

More concretely, why would you not, for example, use Franz Commom Lisp? Large libraries (including Web, Database, ...), interoperability with Java (so use all those features you want), interoperability with COM and Corba (so all those features), C FFI,...

AND a LFSP to boot.

why would you not, for example, use Franz Commom Lisp?

This has nothing to do with which language I use! Don't you realize I am an egghead talking about ideas in the abstract?!

Anyway, one of the things Common Lisp lovers like to say about Scheme is that Common Lisp is better suited for production work than Scheme is, beacuse of its libraries. But is there a language design reason why all these libraries can't be written in Scheme? I really don't know enough Common Lisp to answer.

This doesn't mean that type systems always do so, but this is something that should be asked when you look at the type system of any given language.

For example see Kernighan's paper on Pascal.

Aside: Scheme can be seen as a cleaned-up core of Common Lisp. Since CL can be implemented in Scheme, Scheme can certainly do what CL does.

Another aside: The Data General CL system developed at DG's RTP facility ca. 1983-1986. It was derived from a Scheme system implemented by R. Kent Dybvig as part of his PhD work.

This is not always cut and dried; ocaml, for instance, imposes static typing on the programmer whether he/she likes it or not (I know that some lisp folks like Paul Graham find this very unpleasant). But ocaml provides so many ways to abstract designs that the benefits far outweigh whatever drawbacks static typing might have.

This paper is worth reading just for the Pittsburgh bank robber story- "Unskilled and Unaware of It: How Difficulties in Recognizing One's Own Incompetence Lead to Inflated Self-Assessments" Justin Kruger and David Dunning http://www.apa.org/journals/psp/psp7761121.html

>"smart people" vs. a language for "the masses" "Why are "languages designed for smart people" (LFSPs) so much more fun to program in than "languages designed for the masses" (LFMs)?"

I'm suprised that no one has questioned the assertion that one group of programming languages "were designed for smart people" and another group "were designed for the masses" (masses aka dumb people?)!

I guess we are all "smart people" ;-)

Can someone find language design documents that show this criteria has been used?

http://java.sun.com/docs/overviews/java/java-overview-1.html

Here's a quote:

"We wanted to build a system that could be programmed easily without a lot of esoteric training and which leveraged today's standard practice."

And another:

"Java omits many rarely used, poorly understood, confusing features of C++ that in our experience bring more grief than benefit. These omitted features primarily consist of operator overloading (although the Java language does have method overloading), multiple inheritance, and extensive automatic coercions."

An even more telling point for me is that many of the java developers (notably James Gosling and Guy Steele) have been serious Lisp programmers in the past (Steele is the author of "Common Lisp, the Language" and the co-inventor of scheme). So there is no way that they couldn't know about the features of lisp that give it its high abstraction level. They deliberately left these out because learning to use them requires "esoteric training" and is not "standard practice".

Understand, I'm not blaming them for what they did. But it's pretty clear that java was designed for average programmers and not for wizards.

Now let's deal with the assertion that there are "languages designed for smart people". Is there an example of a language explicitly designed for "smart people"?

... languages for the masses [say], in effect, "here are the rules and you just have to learn to live with them" whereas languages for smart people say, in effect, "you can make your own rules" ...

Cowboys "make their own rules" and do not care whether anyone else can understand their programs. There is a tendency (not overwhelming, but distinct and noticeable) for very smart people to believe that anyone who "thinks different" is less smart. Sometimes they're right -- but not always.

I believe that some of the features omitted from Java were omitted because they tend to result in less readable programs. I know, there's a slippery blame-shifting thing going on here ("readable -- by whom?"), but most programs are not just written for computer consumption. There are human readers too. In any kind of writing intended in part for humans to read, the writer has some responsibility to make that writing understandable for his or her intended audience.

In the programming industry, there is also a time issue. Even the smartest programmer, if under a time crunch, will have trouble understanding a program that is built too much out of its own poorly-documented little domain-specific language made of idiosyncratic macros, operator overloadings, and/or home-grown preprocessors. Not all programs written in LFC's are like that, but enough of them are for Steele and Gosling to have rejected some of those features.

It's a matter of degree, and of taste.

Stating that programming languages I like are "languages for smart people" and the ones I like less have been dumbed-down by design, for the masses, isn't the high-standard of debate I've become used to on LtU.

"An even more telling point ... there is no way that they couldn't know about the features of lisp that give it its high abstraction level. They deliberately left these out because..."

...because they'd decided the lisp features weren't much use? ;-)

Let's not put words into peoples' mouths - anyone can do that.

I appreciate the sentiments Michael raised, but I suggest we go back to our regular program, featuring discussions of specific issues, and programming language features...

"Dumbing-down" is surely an essential meta-feature of programming language features.

I'd argue the reverse of the above: I like Haskell less because it doesn't sufficiently dumb down some of its features, likes *Hugs type extensions*, essential for the modular monadic semantic definition of languages in LPS, and for which to-date I have yet to find anything that helps me understand all the issues or even which extension is being used where. :) ...

I always thought there was a time and a place to be smart, like when you're selecting the tools you're going to work with, anticipating problems and debugging unanticipated problems, and a time and a place to be dumb like using simple idioms when coding so other people don't have to be smart to understand you....even the most complex ideas can be expressed in a simple manner.

BTW: When I write code I try to be as dumb as I can, while still getting the job done (and a quality I can live with).

Some days it feels like every other dismissive, rude or intolerant remark comes from a Lisp user. It's got to the point where, if I'm emailing someone to try and get them to make a more useful contribution (something above "heh heh your language sucks") I've started asking whether they're Lisp users. I keep getting surprised "yes, why do you ask?" replies...

Why are Lisp users so socially inept?

Sorry if Lisp users find this post offensive. I had a good friend at school who had bad body odour. I regret never talking to him about it. I'm now trying to change my ways...

Hmmm. Wonder what the origin of the phrase "lusers" really was?

But then again, maybe Paul wouldn't see the subtextual message in being labelled a cowboy. Or maybe he wouldn't care.

I think a good answer to the debate came from Will Clinger during a Language Wizards Panel. His guiding philosophy is that "Humans are Stupid." See the April 24 video stream for his full monologue; the gist of it is that we need to rely on abstraction to get anything done.

If you buy that, then you can see that the debate should really be, "Okay, given that we're all stupid, does the abstractive power of a so-called LFSP outweigh its cognitive overhead."

BTW I agree that we're all stupid ;-)

As for why lisp people have bad manners, I'm pretty sure the reason is that so many good ideas that seem to be new were actually standard in lisps of the past, and lisp rarely gets the credit it deserves. I think most programmers think that the java developers invented garbage collection, for instance. Also, given that you're writing a dynamically-typed language, it's hard to outdo lisp, and lisp programmers get annoyed to see scripting languages constantly reinventing bits of lisp. Someone once said "those who do not understand lisp are doomed to reinvent it".

Of course, static typing is a whole other ball game, and much of the history of static type systems is an attempt to recover the flexibility of lisp with the safety/speed benefits of static typing -- a noble pursuit IMO, and one I hope succeeds (although the obstacles are large).

BTW Paul's manners are not bad compared to many other lisp people. Just check out comp.lang.lisp and look at some posts by Erik Naggum -- he gives a whole new meaning to the term "sociopathic" ;-) I jokingly refer to c.l.l. as "comp.lang.pointless-flamewar".

(i'm just playing; no more from me on this; i'm sure there are female lisp users too; not all lisp users are "lisp users"; contents may settle during transit).

ps the links near the start of this thread, and ehud's initial comment, are still very interesting.

Highly amusing. We should introduce him to LtU.

But seriously, I'm amazed that such an enormous bandwidth on a PL specific group should be devoted to the manners (or lack there of) of a single poster. Sort of reminiscent of the endless postings, and counter postings, about Dave Winer's integrity.

Can you give the archive URL?

Models of Software Acceptance: How Winners Win
p46 onward dealt with programming languages - Lisp, Smalltalk, Java, C++