Lambda the Ultimate

... its importance is greatly overrated

I agree. I think that the same comment applies here as in the "mechanics" discussion. The best languages are the ones that are slightly below the radar. They are popular enough to be well-designed and supported and unpopular enough not to have to pander to the lowest common denominator.

"Emerging languages" is the best idea I had so far...

"Emerging" has a nice spin to it, in that it suggests a continuing process of unfolding into the wider consciousness. "Submerged" would describe their current state.

I like the sound of "submarine languages" - run silent, run deep...

High-yield languages?

They are for those who carry big sticks.

For American English, localize them as "speak easy" languages :-)

The best languages are the ones that are slightly below the radar. They are popular enough to be well-designed and supported and unpopular enough not to have to pander to the lowest common denominator.

I'm a bit concerned with this idea as a rule-of-thumb for PL evaluation.

If Oz suddenly became the "next Java" in terms of popularity, would that necessarily make it a worse language?

Sure, it would come under new pressures from vested interests, but that doesn't mean it would necessarily lose what makes it good to begin with.

Conversely, does being just under the radar guarantee that a language is good? Languages with manifest design short-comings seem to be able to hold devoted "cult" followings just as easily as well-designed ones.

Though I think it is interesting to consider if any substantive design choices can influence relative popularity, I would be just as concerned to over-value less popularity as to over-value more popularity.

The best languages are the ones that are slightly below the radar. They are popular enough to be well-designed and supported and unpopular enough not to have to pander to the lowest common denominator.

I'm in philosophical disagreement with this point. Most languages, natural and otherwise, are organic, not configural. Programming languages exist in an ecology that includes machines, programmers, organizations, and (ideally) semanticists whose activities are probative of a language's fitness, and the fitness criteria subsume the quality criteria..

The leap from fitness to evolutionary theory is not consequent but is seductive. Evolution counterpoints design. Design is inventive and (temperamentally) extravagant. Design strives for optimality, reifying whatever is necessary to achieve it. However, programming language design sometimes forgets that the components of what were reified (i.e., machine primitives, programmer prowess, mindshare, consistent semantic model) may not exist in the ecology. Evolution, on the other hand, is conservative. Evolution works with what is available, producing forms that are good enough rather than ideal. Further, programming language evolution is able to guarantee that the components exist in the ecology.

That said, there's plenty of evidence for evolution in popular programming languages: Java and Python to name just two. Java is simply a variant of a particular imperative strain that began with BCPL. Python is evolving toward type annotations driven by (I'm supposing) selection for type annotations as aids to programmer reasoning and as targets for optimization--both of which could have been predicted from trends in PL history.

Since languages evolve, it follows that, somewhere in the compromise between what is ideal and what is practical, they end up being just good enough. Consider that if programming languages won mindshare based solely on the merits of their respective designs, certainly the much-maligned Ada and my beloved Haskell would be far more popular.

Seen in this way, it's wholly unsurprising that most new programming languages fail and that others survive only in the niches for which they were designed. Taken altogether then, a language's popularity is only orthogonal to its quality in the case where the language suits "out of the box", which is highly unlikely. Otherwise, a language's popularity is important. In fact, popularity may be integral to a language's fitness and, ostensibly, to the language's quality.

Otherwise, a language's popularity is important. In fact, popularity may be integral to a language's fitness and, ostensibly, to the language's quality.

Yes, this is why the language should be just below the radar. That means that the language is popular enough, in an absolute sense, to enjoy the advantages of getting better through evolution.

Programming languages exist in an ecology that includes machines, programmers, organizations, and (ideally) semanticists whose activities are probative of a language's fitness, and the fitness criteria subsume the quality criteria.

That is seductively phrased (one wants to write "Discuss." immediately after it).

It also suggests that a language's success might depend on its ability to alter that ecology to further its own prosperity, rather than simply occupy a niche.

Since languages evolve, it follows that, somewhere in the compromise between what is ideal and what is practical, they end up being just good enough. Consider that if programming languages won mindshare based solely on the merits of their respective designs, certainly the much-maligned Ada and my beloved Haskell would be far more popular.

I think we are in danger of over-simplifying both evolution and language popularity here.

As I've argued before, popluarity is, by strict evolutionary criteria, the only objective evidence of evolutionary fitness.

However, this tells us nothing about the fitness criteria (fitness functions) that acted on the population to produce that outcome.

The interest (for me anyway) lies in trying to figure out the fitness functions, and in particular to see if any are directly attributable to the design or features of the language itself, taken separately from purely sociological phenomena. (e.g. a charismatic or powerful popularizer)

Note that the notion of "quality" simply begs the question (in the traditional logical sense): quality is just a particular notion of fitness. A particular quality (theoretical purity, say) can be a big fitness boost in one environment (e.g. PLT academia), and a big negative in some other environment. (e.g. hobbyist-only programmers).

The sweet-spot that I'm looking for is the environment that intersects theoretical well-foundededness and industrial strength development. Is there a fitness function that combines both qualities?

I hope so.

I think we are in danger of over-simplifying both evolution and language popularity here.

How so? Simplicity is the goal of abstraction by which complexity is reduced. After all, human limitation must still be accounted for. The evolution metaphor is cogent because the notion of fitness is both more tractable and testable than intuitions about quality.

The interest (for me anyway) lies in trying to figure out the fitness functions, and in particular to see if any are directly attributable to the design or features of the language itself, taken separately from purely sociological phenomena. (e.g. a charismatic or powerful popularizer)

I can see how trying to deduce fitness functions could be...diverting. However, the effort is probably futile because the problem would be combinatoric if it weren't undecidable. The fitness functions may not be deducible from examination of the (extant) members of a population because fitness may result from the interaction of multiple, concurrent selection pressures acting constantly, intermittently, sporadically, or randomly across generations.

As I've argued before, popluarity is, by strict evolutionary criteria, the only objective evidence of evolutionary fitness.

If fitness is a qualitative judgment about a genotype based on its incidence in succeeding generations, then fitness can also be judged from the incidence of memes in succeeding generations of programming languages. The interest (for me anyway) lies in trying to figure out the memes.

For instance, are there memes which recur across PL families and across generations of PL's? If so, what are they and is each primitive? If they exist and are primitive, can a programming language be formulated from them that satisfies each concern (machine, programmer, organization, semanticist) enumerated in my previous post?

Now those are interesting questions!

However, this tells us nothing about the fitness criteria (fitness functions) that acted on the population to produce that outcome.

Does it have to?

Note that the notion of "quality" simply begs the question (in the traditional logical sense): quality is just a particular notion of fitness. A particular quality (theoretical purity, say) can be a big fitness boost in one environment (e.g. PLT academia), and a big negative in some other environment. (e.g. hobbyist-only programmers).

Well said.

The sweet-spot that I'm looking for is the environment that intersects theoretical well-foundededness and industrial strength development. Is there a fitness function that combines both qualities?

I hope so.

Me too!

:^)

How so? Simplicity is the goal of abstraction by which complexity is reduced.

I think a good chunk of our conversation is proof that evolution as a metaphor can cause misunderstanding. ;-)

The main problem is that there are a few different common meanings that confuse the issue. Pure evolution is stochastic and fitness is a moving target as subtle changes in the environment occur with big effects. But we also talk about the linear evolution (development or improvement) of things through time.

Even if you know better, you can mix these up! ;-)

However, the effort is probably futile because the problem would be combinatoric if it weren't undecidable.

This assumes a strictly mathematical analysis of the problem. ;-)

I think we are saying the same thing here, using slight variations on the metaphor of evolution. When I say "find the fitness function", I mean uncover the factors that influence success and assess their relative weight. I think this is the same idea as your

The interest (for me anyway) lies in trying to figure out the memes.

See, this evolution stuff is tricky! ;-)

Does it have to?

I think the causes of popularity are at the root of this whole discussion. Some have assumed that popularity is necessarily a sign of taint, and that a "good" language would become necessarily tainted by popularity.

I'm more inclined to believe that popularity has a number of causes, some of which are purely sociological but some of which are related to the design decisions of the language.

I don't want us to throw out the latter with the former.

I think a good chunk of our conversation is proof that evolution as a metaphor can cause misunderstanding.

The main problem is that there are a few different common meanings that confuse the issue. Pure evolution is stochastic and fitness is a moving target as subtle changes in the environment occur with big effects. But we also talk about the linear evolution (development or improvement) of things through time.

I see what you mean now. I appreciate your discernment.

This assumes a strictly mathematical analysis of the problem.

Yes, I confess that I probably focused too early on outlining an operational definition of quality by way of fitness.

I think the causes of popularity are at the root of this whole discussion. Some have assumed that popularity is necessarily a sign of taint, and that a "good" language would become necessarily tainted by popularity.

I don't want us to throw out the latter with the former.

You've said well. Thanks for the good will.

:^)

If Oz suddenly became the "next Java" in terms of popularity, would that necessarily make it a worse language?

Yes, I think it would. I think that becoming worse is actually a necessary condition for Oz becoming the "next Java". Since we don't want to do that, there's no risk that Oz will become the next Java :-).

Does being just under the radar guarantee that a language is good?

I agree with you that this converse does not hold.

Why do you think that becoming worse is a necessary condition for Oz to be the next Java?

Obviously I'm not Peter, but my own feeling about this is that popularity and fitness-to-purpose don't correlate. In my opinion, the historical record thus far bears this out. Or at least it seems to be fair to say that programming languages' use eventually expands beyond their intended domain (I guess this is just the Peter Principle applied to programming languages: a programming language eventually rises to its level of incompetence). C was a fine vehicle for porting UNIX to new hardware, i.e. it was better than assembly language for that purpose. But suddenly people were writing things other than UNIX kernels and device drivers in it. The next thing you knew, people were writing word processors and spreadsheets and databases in it, God help us all.

The notion of being "the next Java" is itself telling, as Java is deliberately designed to be a low-ceiling language. Java is a shining example of the observation, from Richard Gabriel I think, that "our current popular languages are designed to help losers lose less." The idealist in me would like to believe that a genuinely powerful, orthogonal, multiparadigm language like Oz could become popular in spite of its quality. The working programmer of over 20 years in me doesn't see it working out that way.

popularity and fitness-to-purpose don't correlate. In my opinion, the historical record thus far bears this out.

I think there are two problems with this position.

First, we would need to explore how "fitness-to-purpose" applies here: what features of a language determine what purposes it is fit for?

Second, given that we have not yet reached the plateau in the history of the development of computation (IMO, though I think we are getting close), it is pretty hard to induce universal laws from the evidence.

When computation is undergoing rapid advance, the mainstream language of the day is bound to lag behind what people want to do with it.

While it is always flattering to use a language "reserved for smart people", I think we underestimate the ability of the mainstream to eventually catch up, however slowly.

Java is deliberately designed to be a low-ceiling language

I think this is a biased perception from communities who thought that THEIR favorite language should have been the next big thing, and who have taken refuge in the "language for smart people" notion. ;-)

I think Java was intended to be an incremental improvement over C++, and in many ways it is.

While it is always flattering to use a language "reserved for smart people", I think we underestimate the ability of the mainstream to eventually catch up, however slowly.

Of course they will catch up! They have no choice! Software and the problems software solves are getting more complex and I don't see any reason for it to stop.

You can build a house using a handsaw, but it will take much more time, effort, and unless you are a wizardly handsaw user it will produce a lower quality house. For a skyscraper a handsaw is simply out of the question. You can solve the time problem by hiring an army of "handsaw technicians", but that doesn't solve the quality problem, in fact it will exasperate it, and the chances of all of the technicians being wizardly decreases the larger the army.

Marc Hamann, quoting me: Java is deliberately designed to be a low-ceiling language.

Marc: I think this is a biased perception from communities who thought that THEIR favorite language should have been the next big thing, and who have taken refuge in the "language for smart people" notion. ;-)

Unfortunately, this flies in the face of the historical record: various of Java's designers have publicly said that some of the design decisions they made they did so in order to make the language "simpler." The scope of such decisions ranges from the lack of a preprocessor/conditional compilation system to the lack of operator overloading to the lack of generics (until the lack of generics became such a hinderance that one of several proposals to add them to the language in the least intrusive way possible won), and so on. None of this would be a particularly big deal if Java had any kind of linguistic extension mechanism, but it doesn't: it's libraries or bust. Those of us who were present for Guy Steele's wonderful OOPSLA '98 keynote on "Growing a Language" and were aware of Steele's involvement with Java and employment at Sun couldn't help, I don't think, but interpret the keynote as a thinly-veiled concession that there was, and is, work to do on Java in this regard. Even then, this was hardly a news flash: a lot of us in the Scheme community were well aware that Java 1.1's inner classes were designed by John Rose, who had previously written an excellent paper on integrating Scheme with the C world. The inner class spec was ingenious in requiring no changes to the Java 1.0 VM spec, demonstrating Sun's early concerns about the installed base and backward compatibility.

Note that I'm not saying that this form of conservatism is necessarily a bad thing. I do stand by my assertion that some, actually many, of Java's limitations are very real and very deliberate.

Marc: I think Java was intended to be an incremental improvement over C++, and in many ways it is.

The ways in which Java is an improvement upon C++ are precisely those ways in which Java is less expressively powerful than C++, the trade-off being that it's not as easy to shoot yourself in the foot ("and blow off your whole leg") in Java as in C++. That's my experience, anyway, having written Java for a living for about eight years and C++ for about 15 now. Again, I'm not arguing that that was the wrong choice given Java's objectives, but I am arguing that striving to be "the next Java" would indeed mean "dumbing down" an Oz or O'Caml or Haskell.

various of Java's designers have publicly said that some of the design decisions they made they did so in order to make the language "simpler."

You seem to be equating simpler with "low ceiling".

In PL design, taking away ill-considered "powerful" features can be a net plus to the health and fitness of the language. Because you eliminate "macho" features like macro systems, doesn't mean that you limit the utility of the language or cognitive capacity of the language community.

In the Java case, the incremental improvement over C++ was not only negative (what was removed), but also positive (what was added): GC, VM, interfaces, reflection, etc.

striving to be "the next Java" would indeed mean "dumbing down" an Oz

There is nothing inherent about Oz that I can see (especially since it is so paradigmatically flexible) that would prevent it from being used by "dumber" programmers as well as "smarter" ones.

I think the only thing it would require to push it into the mainstream is a more optimized VM and a powerful champion.

...I've always felt that Java was a two time loser before it took off. It was originally designed with embedded network devices in mind. Didn't really make inroads into this space until very recent in its history. Jini and JavaSpaces being the more natural progression of the language but they haven't especially caught on. Anyhow, the language is still saddled with many design choices that took place in that realm.

Then the internet came along and Java got marketed as the new thing - applets being the highlight of the brave new world. Well, all these years later and applets are still stuck in the mud. Ok, so there are some applets still alive and kicking, but they have not proven capable of displacing ancient html form standards - most of the Java applications these days don't deal with applets. (Also, note how poorly AWT was designed - so much so that it was jettisoned years later with Swing.

Then along comes IBM, who put their weight behind Java in order to compete with Microsoft - shifting significantly away from Smalltalk in the process. It is in this frame of reference that Java has been successful - Java has become the glue of enterprise applications. Java the language and Java the Virtual Machine are not the factors that caused success - they are along for the ride. Java the vast API for enterprise apps is why it is "popular".

Language popularity can not be viewed in isolation. It is as much a function of the history of operating systems and competitive forces as it is anything else. Optimal language design is not the driving force of this evolution, so it's not obvious that evolution has favored better design (worse is better and all that other stuff). Evolution of languages is driven by freak accidents and the desire for the few to control bigger and bigger pieces of the pie.

Optimal language design is not the driving force of this evolution, so it's not obvious that evolution has favored better design (worse is better and all that other stuff). Evolution of languages is driven by freak accidents and the desire for the few to control bigger and bigger pieces of the pie.

I'm concerned that we seem to have gone down a fallacious path with such thinking.

The two chains of reasoning seem to be that

• All popular languages so far have had "bad features" (in our opinion), therefore having bad features is a necessary condition of being popular
• Since factors other than pure design affect popularity, pure design has NO effect on popularity

I hope the fallacies are clear when then they are spelled out this way.

I'm starting to suspect that many PL aficionados like being in the "misunderstood cutting edge", but I would rather see a general improvement of PL design for all languages, including the "popular" ones. I can't see why this is inherently impossible just because it hasn't happened so far (by our fairly high standards).

For various reasons, I haven't been satisfied with any language that I've encountered in my limited experience. All of them have very good ideas, including the popular ones, but none of them are what I consider the last language that I'll ever have to learn. Indeed, the number of languages I use for various purposes and ends has been growing above a linear curve (though certainly not exponentially).

All popular languages so far have had "bad features" (in our opinion), therefore having bad features is a necessary condition of being popular

Yes I can get the job done in these languages. Unlike many, I don't view Java's limitations as an aspersion on the programming community at large. I view it more as a testament of how clever people are in getting results from a substandard solution - fitting a round peg in a square hole.

Since factors other than pure design affect popularity, pure design has NO effect on popularity

But my take is that we are a long, long way off in developing a strategy to tackle the increasingly complex problems we are being asked to solve with computers. Perhaps it's a problem a computability. But I think it a matter of manageability. Most programming langauges demand an exacting attention to detail - more attention than the humans are capable of comprehending in either small numbers or in large groups.

The other aspect that I see is that the base programming language is but a starting point. Each application written is a mini-language taking on it's own vocabulary and it's own systematic view of the problem at hand. It matters as much how a PL can morph into these mini-languages and cope with the particular jargon of the domain space.

For myself, I much prefer precise languages that have certain proofs built into the algortihms. Upon those base proofs, we can build larger and larger proofs - certainly limited in what can be proved - but the kinds of proofs that escape the naked eye. Tests are certainly necessary, but they shouldn't have to prove what can be written into the specification (yes, I believe the source code is the specification). With this in mind, I believe the ML family of languages built on top of HM type inference offer the best prospect of the way out.

And I'm not one that cares whether ML is not the language de jour. C, C++, Java and C# will play through and 20 years from now they will be as cursed as Cobol code has become. They produce mazes of code that hark back to the days of GOTO. And, no it's not because the programmers are not talented enough. It's an inherent part of the lack of systematic way to specify solutions in a language that is both understood by humans and machines.

The consultant in me says just put a kludge band aid on it and move on to the next paycheck. The engineer in me wants to build things that will last. Afraid that on my current rant I'm on an idealistic kick to find a language that I can use that builds solutions that don't fall over unless you squint your eyes looking at it from an odd angle.

As far as evolution goes, we're still in the green-brown algae stage.

As far as evolution goes, we're still in the green-brown algae stage

Is it really that bad? I'd be more inclined to say that we are just about ready to invent fire and leave the cave. ;-)

I was observing to a friend the other day that studying PLT for a long time has the paradoxical effect of making you appreciate the features of a lot of languages, but not really happy or satisfied with any particular language as a whole.

I think this is partly the inevitable result of being aware of the other choices that are available in the specific design trade-offs that a given PL makes, and partly a healthy sense that there are still new PLT horizons to discover and improve upon.

I too would like to find the perfect language that never let me down and that I could live in all the time, but if you ask me to define all the characteristics that such a language would have, I find that they run out of my hand like a fistful of water.

Sometimes I start with a simple idea of the perfect language (what if Oz was statically typed, what if Haskell was not lazy by default, what if ML wasn't so unaesthetic ;-) ), but quickly realize that this small "improvement" has a whole raft of unintended consequences.

This is partly the excitement of PL design, but also its curse: there will always be another trade-off decision to make, and perfection will always be over that next hill.

First, Marc, thanks for your comments: they're definitely helping me put some more flesh on the bones of my thinking about the issues under discussion, and in a very civil way. This is what I love about LtU.

Marc: You seem to be equating simpler with "low ceiling".

This is a great example of the push to flesh out my thinking. What I wrote earlier is rather obviously incomplete. What I mean, hopefully more precisely, is: a language being "simpler" in the specific sense of having expressive power removed, coupled with a lack of mechanisms for extending the language, is a "low ceiling" language. I find Java an excellent example, and as an excellent counterexample I would choose Scheme: Scheme has many fewer "features," if you will, than Java, so in an important sense it's "simpler" than Java. But it doesn't suffer in expressive power relative to Java, and as if that weren't enough, it's an extensible language!

Marc: In PL design, taking away ill-considered "powerful" features can be a net plus to the health and fitness of the language. Because you eliminate "macho" features like macro systems, doesn't mean that you limit the utility of the language or cognitive capacity of the language community.

I would first point out that "ill-considered" is also a value judgment, and begs the question of whether the "powerful" (why the scare quotes?) feature should be removed or merely considered more thoroughly and perhaps redesigned. If you eliminate "macho" (ditto "why the scare quotes?") features like macro systems, you do, in fact, limit the utility of the language barring some replacement with equal or greater expressive power. It should tell all language designers something that Scheme, one of the most svelte language definitions in the world, includes a standard macro system. I'll grant your last point, however, since I don't buy the Shapir-Worf hypothesis.

Marc: In the Java case, the incremental improvement over C++ was not only negative (what was removed), but also positive (what was added): GC, VM, interfaces, reflection, etc.

By this definition, Lisp 1.0 was a very nice incremental improvement over C++. I have to confess that I don't find this line of argumentation the least bit compelling, precisely because most C++ programmers don't, in fact, end up "incrementing" to Java. Given that we started the conversation talking about fitness to purpose, while I agree that Java has some fitness to purpose (quite a bit of it, actually, as I've written about Hibernate, WebWork, and JMS before), it's in a totally different ecological context than C++, despite the obvious superficial similarities of the languages. That's not to say, by the way, that the choice to use C++ on a project vs. Java is always well-informed. For example, I feel rather strongly that my current employer's C++ project would have been vastly better served by being developed in Java than C++, but that call was made long before I arrived, and the situation is what it is, given what the costs of converting would be—assuming, of course, that I'm correct, which would require a proof by demonstration...

Marc: There is nothing inherent about Oz that I can see (especially since it is so paradigmatically flexible) that would prevent it from being used by "dumber" programmers as well as "smarter" ones.

Leaving aside a less loaded and more precise notion of "dumb" and "smart" programmers, I have to say that this is one of those notions that seems appealing on paper, but always seems to have very little support in the real world. After all, Common Lisp is an excellent multiparadigm (imperative, functional, object-oriented built-in; other paradigms, e.g. non-determinism via Screamer, available upon request) language, complete with kick-butt compilers, and we all know how that's worked out in the industry, CL's quiet rennaisance and the heartening success of "Practical Common Lisp" not(yet)withstanding.

Multiparadigmicity actually seems to turn a lot of working programmers off. I certainly don't think of these programmers as "stupid." After all, I've worked with a lot of them, and know better. On the contrary, they seem to have very well-defined parameters with respect to how to allocate both their cognitive and their time resources. So I think that a challenge that any multiparadigm language faces is how to accomplish the blending of these paradigms in such a way that the use of them arises naturally when the language is applied to a task best addressed by that blending (I think Oz does this reasonably well) and how to do so in a fashion that isn't totally alien to the working C/C++ programmer (I think Oz does this abysmally, but to be fair, I don't think there was even an attempt at this on Oz's part).

But it's rather obviously too early to be sure about all of this: CTM is an amazing resource, in my opinion head and shoulders the best learning-to-program resource in the world. Reading it has been akin to a religious experience for me, one that I can only liken to my first reading of "The Little LISPer" or "Gödel, Escher, Bach:" it's reawakened a joy of programming that the real world had done a pretty good job of beating down. If CTM has a similar effect on many, many people and Oz becomes wildly successful, no one (well, except perhaps Peter, Seif, and their colleagues!) will be happier than me. As of this writing, however, I continue to disbelieve that it will turn out that way, once again taking history (SICP, for example, to which I feel CTM is heir apparent) as my guide.

why the scare quotes?

I think you can get the answer to that here. ;-)

Multiparadigmicity actually seems to turn a lot of working programmers off.

I understand the feeling: I used to feel that way before I read CTM. (To be fair to myself, though, it is still true that multiparadigm is not always so well done.)

However, I'm thinking more along the lines of the fact that, since the multiple paradigms are so well factored and separated in Oz, you could easily choose to program just in the way you were comfortable with without a catastrophic loss of utility.

And, despite the fact that the syntax is "weird" to most eyes, I think it has one of the most clear and unambiguous syntaxes I have seen, which you can easily get used to in a few minutes of working with it.

First, we would need to explore how "fitness-to-purpose" applies here: what features of a language determine what purposes it is fit for?

Yes, that is worthy of exploration.

Second, given that we have not yet reached the plateau in the history of the development of computation (IMO, though I think we are getting close)...

I disagree. I think that the (near-mythical) Cell processor and multicore processors may make parallel computing truly ubiquitous. In effect, exerting a parallelism selection pressure on languages that do not yet offer parallel constructs and intensifying the pressure on those that do. Consider that few computer languages invented since the hegemony of Java--with it's language level support for threads--have failed to include threads, even if they were only cooperative.

While it is always flattering to use a language "reserved for smart people", I think we underestimate the ability of the mainstream to eventually catch up, however slowly.

Agreed. Witness the reef (read: layer upon encrusted layer) of API's Java has evolved to fill every niche from (yes) set-top boxes, to mobile phones, to e-commerce.

I think Java was intended to be an incremental improvement over C++, and in many ways it is.

That's true as well. I know C++ programmers who've said that their forays into Java have made them better C++ programmers.

C was a fine vehicle for porting UNIX to new hardware, i.e. it was better than assembly language for that purpose. But suddenly people were writing things other than UNIX kernels and device drivers in it. The next thing you knew, people were writing word processors and spreadsheets and databases in it, God help us all.

LOL. Is it your contention, then, that all new uses require new languages? That is extravagant! Had that been the case, I think that PL design would suffer a poorer reputation than it does today. That languages which are "good enough" should expand beyond their original niche is predicted by evolution theory. BTW, the irony of appealing to a "scientific" theory that cannot be tested empirically is not lost on me. Still, it's better than nothing.

The notion of being "the next Java" is itself telling, as Java is deliberately designed to be a low-ceiling language. Java is a shining example of the observation, from Richard Gabriel I think, that "our current popular languages are designed to help losers lose less."

That was acute! Do I detect latent elitism here?

The idealist in me would like to believe that a genuinely powerful, orthogonal, multiparadigm language like Oz could become popular in spite of its quality.

Me too.

The working programmer of over 20 years in me doesn't see it working out that way.

We can always hope.

The idealist in me would like to believe that a genuinely powerful, orthogonal, multiparadigm language like Oz could become popular in spite of its quality. The working programmer of over 20 years in me doesn't see it working out that way.

One day, frustrated by the challenges of Prolog and logic programming in general, I momentarily had concluded that multiparadigm languages like Oz were a necessity and indeed would be the future. But that conclusion evaporated a moment later when I realized that I was already using a multiparadigmatic language. My OS, the various compilers, interpreters, filters, and programs composed a language that for ease of use and utility surpassed Oz and probably any other multiparadigmatic language that I could envision.

That realization made me at once more comfortable with Prolog (I now had the freedom to momentarily drop out of it and use C or Lisp), indeed with all the programming tools I use. I realized that I had everything I needed.

If Oz suddenly became the "next Java" in terms of popularity, would that necessarily make it a worse language?

No. However, popularity brings with it an influx of new programmers. While this can be a good thing, it can also be a bad thing. It draws the kind of programmers who are only interested in the language because it's popular.

I've begun to see this with Ruby, and it bothers me. It also concerns me to know that others will be learning from people who write poor code (I've been seeing what is basically garbage-collected C with Ruby syntax), and have little interest in anything other than a superficial understanding of the language.

Chris Dutton: It also concerns me to know that others will be learning from people who write poor code (I've been seeing what is basically garbage-collected C with Ruby syntax), and have little interest in anything other than a superficial understanding of the language.

Which, in and of itself, isn't a problem. It becomes a problem, though, when such a user community becomes large enough and entrenched enough that they are in a position to influence the evolution of the language in such a way that bad design due to a lack of understanding begins to show up at the language level, introducing idiosyncracies that make it more difficult for more aware programmers to be effective with the language. It takes a strong BDFL designer indeed to resist such pressures.

As I've written before, C++ has the opposite problem: it's gradually evolved good constructs and abilities (exceptions, RTTI, templates, the STL, construction as resource acquisition, Boost, SFINAE...) but the result is a community that's fragmented into wildly different styles and notions of "quality" C++ design, some of which is influenced by genuinely ancient, in C++ terms, frameworks like MacApp and MFC, and some of which is influenced by functional programming. This is just as undesirable a state of affairs, in pragmatic terms, as a theoretically-pure, one-size-fits-all language (Haskell, I'm looking at you...)

Wouldn't the (hopefully) normal process of code review, mentoring etc be a better way of managing how a language is used than building obstructions and limitations into the language itself?

Then, if it should happen that relatively unskilled and poorly-educated programmers should attempt to use recursion, poor uses could be vetoed, nearly-correct uses corrected (hopefully in front of the programmer responsible), and correct(ed) uses permitted to stand (as an example to others).

What's really elitist, in my view, is assuming that the boundary between the good programmers and the not-so-good ones is impermeable - and that users of language-for-the-masses Foo# are destined always to remain on the side of that boundary they started out on.

Oblig. Metallica quote: Dear mother, dear father, / you clipped my wings before I learned to fly...

Wouldn't the (hopefully) normal process of code review, mentoring etc be a better way of managing how a language is used than building obstructions and limitations into the language itself?

Code review isn't normal (or very simple) when you are by yourself. Also, when writing a small project for personal purposes, you will probably pick a tool with the path of least resistance. Such a task has probably been done before. Hence, someone probably designed a tool for that specific purpose (out of interest, necessity, whatever), without other tasks in mind. This is probably how you get some languages with "limitations".

What's really elitist, in my view, is assuming that the boundary between the good programmers and the not-so-good ones is impermeable - and that users of language-for-the-masses Foo# are destined always to remain on the side of that boundary they started out on.

Agreed.

Code review isn't normal (or very simple) when you are by yourself.

A solo programmer presumably doesn't need to be told to keep off the (greener) grass for the sake of others.

While there's an argument in favour of making DSLs with limited and pertinent features available to those who need only those features (and need not to be surprised by hidden complexity), it's not the same as the argument in favour of locking down parts of a language in order to make it easier to manage programming teams. My argument is that management issues are better taken care of by managers than by language designers.

Incidentally, I was very surprised by how bad PHP turned out to be as a DSL for web-scripting - how often it violated the principle of least surprise, by needlessly and incompletely emulating more general-purpose languages. I think that web-scripting is a domain in urgent need of some good language design, with less proficient programmers especially in mind as a target user group.

This isn't an either/or choice. Some choose one approach, some choose the other. I am trying to explain, not to legislate.

What's really elitist, in my view, is assuming that the boundary between the good programmers and the not-so-good ones is impermeable

I, for one, never meant to imply this. I totally agree. But one would be foolish to assume this process doesn't take time, and doesn't cost money...

I think we are being elitist, but not because we want good languages - because we assume good, well educated, skilled programmers.

You took the words right out of my mouth.

The tone of the discussion in some parts seems to indicate that the dullards out there should not be allowed to influence langauge design and wouldn't recognize something good if it smacked them in the face. (Perhaps I'm being overly harsh?)

I think the quality of a programming language should be defined by the acceptance rate of its target audience. If Perl explicitly targets a certain group of programmers and it's accepted by 75% of them (making up numbers), I would call Perl a "good language" no matter what features it may be lacking. Similarly, if targets 2% of the entire programmer population and captures the hearts of 85% of that 2%, it is also a very good language no matter what libraries/commercial support/etc. it may be lacking.

Just as some physicists find quantum mechanics "sexier" than other subjects in physics, the features discussed in here tend to be more about the abstract mathematical stuff (sexy!) that Random C. Programmer doesn't like. But let's not brand things "not good" if they are not "sexy" (...at least not until the sexy crowd gets so efficient/large that they can write correct code fast enough to take on Random C. Programmer's job as well.)

However, I am not sure what is referred to by "object pascal", do they mean Delphi, something else, more than one language, or something else.

See here, for instance.

You think 6% of those surveyed used this language? Does this seem right to anyone?

I haven't checked the references, but if the survey was actually conducted at Object World in 1995, then the numbers sound reasonable enough. Object World would have attracted users of languages like Eiffel and the OO Pascals in disproportionate numbers relative to the general population.

Thanks. If it's clear these numbers don't reflect "the general population", I think they can do no harm...