Lambda the Ultimate

Can he come up with a way to kill a language, now that Java has grown and grown and grown - to the point of suffocating everything that's good and holy?

Not sure how they had to do that... Given the amount of code written against J2SE, I don't see how to refactor J2SE into smaller pieces of compliance (multithreading, classloaders, security) without making half of Java world mighty unhappy.

Creating a major version without backward comBatAbility using Feather/Middleweight Java as a spec to implement is probably not an option as well.

You haven't seen Java 2.0?

(class MyButton (extends java.awt.Button)
  (method (public) void buttonClick ()
    (System.out.println "Goodbye, popularity!")))

Actually I had almost forgotten that Java exists. I never see any in the subset of the real world that I participate in.

I never see it, but I constantly hear about it, which I suppose is even worse.

No, no, trust me, actually using it (professionally and unavoidably) is worse. Sometimes I wonder if Java will be indirectly responsible for hastening the adoption of functional programming languages by providing a caricature of procedural OO.

No, no, trust me, actually using it (professionally and unavoidably) is worse.

I second that. To quote Frank, I almost thought I've written that myself :-)

Sometimes I wonder if Java will be indirectly responsible for hastening the adoption of functional programming languages by providing a caricature of procedural OO.

What are current realistic candidates for full-scale industrial adoption? As a platform, I think Parrot, any other candidates? As a language, I mostly don't care, as long as the platform does not dictate all the important choices to PL designers (I know this can be very costly in terms of performance, but otherwise it's another Java).

Oops, almost forgot about .NET, it looks like MS is moving much quicker than Sun. Is it just me? Can anybody using .NET comment on what are the current .NET limitations, and whether there is a plan to cure them?

BTW, are there any problems backing Oz by Parrot? Or is it done already? :-) Probably Peter can comment on what is the long-term plan for Oz' platform (sorry if I missed other Oz/Mozart guys on LtU)?

Objective Caml is, I think, the only one, but I doubt it will happen. Instead it will be a newer language, which is novel enough to draw people's attention and get a front-page Slashdot posting. (No, not Arrow. :)

This is A Good Thing since it means that a revolution is possible, but it also means that it is very hard to predict what will happen, beacuse it depends on who is going to champion the new language, and what it will look like.

Are the research variants on C# a reason for hope? I am not sure the answer is a straight out "no."

IMHO, Java (mostly VM, but the language as well) was not designed to be a growing language, and despite my respect to Guy Steele, I don't think it will ever lose its warts.

To back this statement, several warts I don't think can be cured (most of them apply not only to Java):

1. No first-class continuations and no easy way to introduce them.

I know this can be _very_ expensive if done improperly, but judging by Parrot, performance lost may be acceptable. Not sure this can be implemented in a way that completely removes costs from the code not using this feature, though. But, yes, I believe first-class continuations are required for general purpose PL (GPPL).

2. Overly complicated language for the covered feature set.

It bothers me not only because of cognitive strain, but also because it makes lives of metaprogramming for the language much harder (and I definitely need metaprogramming). I don't even hope for simplicity of Scheme, but I believe GPPLs do need simple model that can be augmented by DSLs by any user of the language.

3. Basic features like classloading done in incredibly convoluted ways, described without sufficient rigor.

The protocol of NoClassDefFoundError/ClassNotFoundException is undocumented, the overall process is described in the legalese prose, making it almost impossible (for me, at least) to reason about it. This one could be cured by adopting formal methods, but because of 2. it looks practically impossible.

Well, it almost look like hate-mail :-) Also, after re-reading all this it almost looks that Scheme is the language to bind them all ;-) What does Scheme lack to make it the mainstream sequential language? Static typing? Concrete syntax? VM? Huge libraries?

(Trite must be my word of the day.)

I guess it's about time I mastered a new language; I think it's been a year or two since the last one. OCaml, Scheme, Erlang, Smalltalk, and Java are the leading candidates; Java primarily because of Eclipse and the libraries.

Let me also suggest Oz, supported by Concepts, Techniques, and Models of Computer Programming. If you pursue this course, you'll learn everything that you would have learned by learning O'Caml, Scheme, Erlang, Smalltalk, or Java, and more. And lest you think that the parallels won't be explicit, let me point out that the text draws explicit parallels to Haskell (similar to O'Caml), Erlang, Java, and Prolog. In short, this is a Masters in Computer Science in one language and text.

Having said that, I like O'Caml a lot. In fact, I just spent last weekend bouncing among Common Lisp, O'Caml, and Oz, all of which support interactive development nicely integrated with the EMACS editor. Any of these tools is a joy to work with for that reason if no other, but each has unique benefits: Lisp is uniquely good at loading new code into a running image, so I recommended to a friend that he learn it to write web apps that could be updated without taking down the server. O'Caml uniquely has a toploop, a bytecode compiler, and a native compiler that can generate standalone binaries with reasonable disk and RAM footprints, so I'm thinking of doing robotics with it. Oz uniquely addresses multiple programming concepts, including cheap concurrency and distribution, so I'm thinking of writing an MMORPG with it.

But what these all have in common is their support of an excellent interactive, incremental development system in EMACS. That's an often-undersold benefit of these alternative languages, IMHO.

Isaac: Don't Smalltalk and Erlang play there too?

Yes, sorry; I meant "uniquely within this trio I've enumerated." I was trying to describe some contrasts among them while observing that they all support incremental, interactive development.

Actually, Oz has no problem with this either, either as compiled code (software components, a.k.a. functors, are values in the language, and so are classes) or as source (with the first-class compiler).

That's true; I had forgotten about functors. Hmmm. Has anyone written a web server in Oz? Ah, I see that they have; it's just named oddly: <http://www.mozart-oz.org/mogul/doc/mathweb/httpd>. I might have to change my recommendation to my friend; I can very easily imagine developing a distributed web app in Oz now.

http://www.muppetlabs.com/~breadbox/txt/al.html

Oz sounds pretty interesting, especially from a Grand Unified Theory of Programming standpoint; but I have the impression, justified or otherwise, that these other languages are a lot more pragmatic. Python is currently my favorite language.

Hey, as people here have no doubt noted, I'm pretty free with my opinions. Nevertheless, you're welcome.

Kragen: Oz sounds pretty interesting, especially from a Grand Unified Theory of Programming standpoint; but I have the impression, justified or otherwise, that these other languages are a lot more pragmatic. Python is currently my favorite language.

Python is a very good pragmatic choice along several dimensions: it offers a very nice combination of imperative, object-oriented, and some functional constructs. It has an impressive collection of libraries, and perhaps most significantly, it has a very sizable community. IMHO, Python's weaknesses are that its paradigms aren't especially well integrated—it has non-orthogonalities that bug me a lot—it's a relatively poor runtime performer; and it seems difficult to deliver stand-alone end-user software with it. I don't think any of these are insurmountable: each revision of the language seems like a real improvement; Parrot may help performance, although some of Python's heavily dynamic features will make this a challenge regardless; and some packager for the Parrot runtime + Python code for popular platforms will likely address the last point.

My sense is that by contrast, O'Caml has all of the benefits of Python except quite so large a collection of libraries and community, and none of the shortcomings. I think this is quite significant: I can imagine developing and selling O'Caml software professionally in a way that I can't (yet) imagine for Python. O'Caml is the language that I believe could replace C/C++, today.

As for Oz, I think of it as the best extant integration of all of the programming paradigms known today, with a very powerful development environment, performance certainly on par with Python, and a very small, but focused, community. With the publication of the CTM, I can only see the collection of libraries, and its associated community, growing over time. With Oz's support for easy concurrency and distributed processing, I can also see it targeting much more complex applications than other languages. That really leaves the question of native code and standalone packaging, and here I see it having exactly the same issues, today, as Python.

So perhaps I have a different definition of "pragmatism" than many people, because I see O'Caml as being as pragmatic modulo libraries/community as C/C++, and Oz as being as pragmatic modulo libraries/community as Python. So I suspect that when many people (you may or may not be one of them) say "pragmatic," what they mean is "what everyone else is using," and my thesis is that "what everyone else is using" is given far too much weight (again, not necessarily by you).

Ehud: Both Java and C# show that with enough commercial backing it is possible to significantly influence the direction of the PL market.

One hears this claim quite often. What evidence are there that the popularity of Java/C# is actually marketing-based?

How can one study the causes behind language popularity? Shouldn't the fact that at least four of the most widely used programming languages had either marketing support or OS support count as evidence for something? (I am thinking C, VB, Java and C#, but feel free to add more languages to this list.)

Of course for non C-descendant successful languages (FORTRAN, COBOL, VB...), the reasons for their success must lie elsewhere.

Anyway, these observations would certainly be my starting point for a "study of the causes behind language popularity"... if I ever were to carry out one.

I am not sure I agree with phrase "best representation," but I agree with the gist of this argument.

Another factor is that popularity of a language implies support being available in the future, and this causes positive feedback. See Andrew's pertinent question regarding the longevity of Oz.

Ehud: Let me turn the tables on you...

Of the languages you mention, I think C sets the most striking example. C was developed more-or-less in parallel with Unix, and each probably owns at least some of its success to the other, but it has never enjoyed a mass-marketing push such as Java's or C#'s, and still managed to outdo all its competitors.

It in interesting to note that while in the Unix world C had a considerable edge (because the OS was written in it), in the PC world it started out as just one language out of many. In fact, during the first half of the 80's it certainly looked liked the future was Pascal's (remember Turbo Pascal 3.0?)

(IIRC, Microsoft had three compilers made during the early 80's -- Fortran, Prolog, and C; guess who won :-)

Personally, I agree with Stepanov (mentioned by Marius Amado Alves) that C's advantage was that it closely resembled the machines it run on, so much so that ordinary people like myself can have a look at a compiler's optimized output and still understand how it maps to the source code (or the other way around).

Perl, Python, and PHP seem to be doing quite well in their "target" areas with no apparent commercial backing, so I would say commercial support isn't necessary in today's world for PL to succeed. The question is whether commercial backing is necessary.

I'll now turn the tables back: is it possible that the "commercial" languages (VB, Java, C#) gained popularity because they were created to provide programmers what they wanted rather than what someone thought they needed?

VB (and Delphi) were created when writing Windows GUI applications was extremely laborious, and both succeeded in reducing this load. Java was created when time-to-market and server-side programming were important, making for the first time garbage collection something the masses would use, simply because manual memory tracking is too difficult for most. (I know mid-90's Java was intended to win the client side, but it never did that, probably because its UI libraries weren't good enough.)

I don't think this is the real cause. I know it is a popular explanation (cf. such terms as "bondage & discipline languages") but I think the dynamics are different.

Take .Net as an example (or C & Unix, PL/I & MVS etc.). People wanting to exploit .Net and future OS services from Microsoft are likely to choose either C# or VB.Net. Why? Because Microsoft decided to invest a lot of effort making these the natural choices. So you might say "someone thought the programmers need C#". The other persepctive, i.e. that users use C# because it gives them what they want is equally valid. It's just that C# does this, beacuse someone wanted it to...

A slightly more subtle question is why Microsoft (and others before it) decided to create their own language in this case rather than continue with the previous strategy of providing libraries for C++ or another mainstream language. I think the answer to this question is more enlightening.

One common explanation is that this is simply a way to crush Java. I don't think this is the full story.

Another reason, specific to this case, would be the move to managed code. This is an important factor in the move to CLR and associated languages. But, again, I don't think this is the full story.

Providing a language gives us a very powerful method to influence software construction, control programmer behaviour, and help produce the kinds of software we are interested in (via APIs, compile time analysis and run time support). Likewise, whenever an OS or even an application provider provides a programming language with added support, this will influence programmer behaviour (think VBA; think Javascript; think Guile). There is, yet again, positive feedback.

So it's not just giving programmers what you think they need, it's really about providing some kind of value. But that does not mean that any language that provides useful functionality, APIs etc. is the best tool for each and every software project. It is thus important to distinguish between general purpose languages, and languages used in more restricted domains.

Obviously the dynamics I desrcibed above aren't the only mechanism involved, but it's one of them.

The C-to-machine perfect match is there in the source, *without* looking at compiler output. I recall using K&R as my C tutorial and learning computer architecture for free along the way.