Lambda the Ultimate

Here's the condensed LtU guide to the static types vs dynamic types debate:

• Haskell-vs-Scheme is an issue on which reasonable people differ.
• Ruby-vs-Java is an issue on which unreasonable people differ.

Everything else is details. :-)

And let me just add that I agree with your judgment call, and with those who are disappointed to find Mr. Gosling lapsing into common errors in the Java vs. current dynamic language debate. There are valid points on both sides in the general static vs. dynamic debate; unfortunately, neither side makes them in this article.

disappointed to find Mr. Gosling lapsing into common errors in the Java vs. current dynamic language debate
Would you like to be specific?
(Someone in the audience asked a question)

"Toy", "not enterprise-ready" - we've heard it all about Java when it was the new thing.

if only we had listened..

Java is (and was from the start) so much more programmer-friendly than C++ that it isn't even funny. Garbage collection, real modules, Unicode strings, free stacktraces, safe casts, language support for multithreading...

The industrial leap from C++ to Java was actually a lot larger than the leap from Java to Ruby. I admire Gosling for making it possible.

"industrial leap from C++ to Java was actually a lot larger than the leap from Java to Ruby"

Marketing and hype-driven adoption

Java was a toy for creating multiplatform web applets back then. Somehow, when M$ put the foot in the adoption of java as a client programming environment, people were able to push it behind the scenes and sell the technology as a heavyduty server platform, despite being dog-slow...

and you know? it worked...

I get annoyed when people talk about things java "brought out-of-the-box", like threading. It's a misconception, because java is a language + stadard libs + lots of good 3rd party libs + a runtime running all that code. If you wish to make a fair comparison to C++, choose a specific platform in the role of the VM and go from there, like: C++ + STL + Boost + POSIX platform + all available libs in said platform...

there you go...

"You can't compare Rails to PHP, because Rails is a framework and PHP is a language. Throw in some PHP libraries for a fair comparison."

Said by... guess who... a PHP fan. Don't remember where exactly.

See, this isn't really a technical debate. This is a marketing debate, and all marketing debates in IT are pretty much isomorphic :-)

It's a misconception, because java is a language + stadard libs + lots of good 3rd party libs + a runtime running all that code. If you wish to make a fair comparison to C++, choose a specific platform in the role of the VM and go from there, like: C++ + STL + Boost + POSIX platform + all available libs in said platform...

True and false.

I program in C++ and Java (among other languages). Once I have decided that a project will be written in C++ -- or once someone has decided this for me -- I still have to choose a core library for datastructures and i/o (STL ? ATL ? another template library ? a library without templates ?), a library for database, a library for ui, a library for threading, etc. Oh, and I have to evaluate these libraries for portability and compatibility with each other.

In Java, OCaml, Ruby, Python or just about any half-recent language, most of these things are part of the standard distribution. In any of these languages, unless my needs are so specific that I know exactly what I want, I will only ever use on array type, one container library, one threading library, etc. -- all of them portable. This will make my life easier. In addition, this helps with keeping third-party libraries somewhat compatible with each other.

So what ? Well, so nothing. Just I believe that naked languages, like base C++, or even C++ + STL, are a thing of the past.

From a theoretical point of view the main question is whether a language provides sufficient features to build the rich libraries we've come to expect. But if you are interested in language success, it is quite important to think about the standard library. I think most language designers accept this fact (e.g., Ada2005 adds a standard container library, something I campaigned for in the past for exactly this reason).

Both these perspectives were discussed here in the past, by the way.

P.S.

Another reason to build good standard libraries is that this process can influence language design and evolution.

As far as I can see, in lots of interesting programming environments the standard library is not expressible in the language. Can I write a Web browser in Javascript? An HTTP server in PHP (well yeah, i could, but why?) A Flash player in ActionScript?

It seems to me that interesting languages emerge and gain popularity as scripting languages for interesting tools. Like Unix/C, or databases/SQL :-) Or we can say, for example, that Perl is a scripting language for a powerful text-processing tool (Perl). The rise of Java was due to applets, the rise of Ruby due to Rails...

But you're confusing DSLs with general-purpose languages. Yes, many DSLs are interesting, but they are (I believe) outside the realm that Ehud was discussing.

It seems to me that interesting languages emerge and gain popularity as scripting languages for interesting tools. Like Unix/C, or databases/SQL

UNIX/C doesn’t fall in this category. C isn’t (and wasn’t created to be) a scripting language for UNIX (perhaps UNIX/Sh would be a better example?). C was created to implement UNIX and hence became a popular language for writing UNIX programs (is this what you meant?).

I think I see your point. Would your point be more valid if it was “languages emerge and gain popularity as languages for interesting applications and domains?” By “applications and domains”, I mean in the big sense (systems languages, AI languages, web/network languages, etc. general purpose languages that specialize for writing applications in a specific domain), not in the classic DSL “subdomain” sense (a path finding language, which could be considered a subdomain of AI languages, perhaps). It is still important to be able to have a language that is flexible and expandable via a module/library system for these general purpose languages (especially since a general purpose language that specializes in a application domain would be great for creating DSLs in subdomains of that domain).

Exactly. It's very very hard to shove a new general-purpose language down people's throats. To become successful, a new language needs to pose as a DSL for some interesting value of D. Language quality (flexibility etc) only begins to matter on the next phase, when lots of people start to abuse it :-)

The same argument about efficiency was at one time used to make a language divide along the lines of native compilation vs. virtual machine/intermediate bytecode. A virtual machine just added too much dang overhead to be considered an industrial strength PL. It's interesting that the inventor of the PL that finally busted this myth (for the masses) is himself drawing another arbitrary line in the sand - though he makes sure to put Java on the side where VMs were once excluded.

And since he mentions ML, it's probably worth noting that many of the strong typing advocates believe that Java's static typing is not without its own share of runtime dynamic typing behavior (Java really being a mix of static and dynamic typing). And the solution of using silent typing based on assignment seems to be missing the main strength of type inference. Not having to declare types here and there does nothing for me if the type can not be made to polymorphically vary according to the input parameters. The strength of type inference is that functions can be reused with different types (generic programming). Just having the compiler always assign the silent type doesn't buy you much but a couple of keystrokes if the type being inferred can not vary.

I agree with your statement on type inference, but you also get additional flexibility when refactoring your code. Let's say that you're spliting a class in two or just renaming it, using type inference you don't have to modify some types everywhere in your program.

Also, it's not only about keystrokes, but number of words to read when you're maintaining your program. Shorter is often better, although writing the types give you some useful hints when reading some code, but then again type inference doesn't prevent you from adding contraints as well.

As much as I like having parameterized types in Java 1.5, they have tipped the scale from "annoying" to "oppressive" when it comes to declaring all the redundant type info. I also agree with Nicolas that it makes programs harder to read.

The problem of the generics in Java is well known. It's the kind of feature that's very nice and powerful, but it's better to have it from the beginning in the language, or else break backward compatibility.

Parametrized types with type inference are also very good friends, they are both very good type system features that help each-others.

The same argument about efficiency was at one time used to make a language divide along the lines of native compilation vs. virtual machine/intermediate bytecode.
At one time, was that argument valid?
(iirc Java HotSpot really made the difference in those efficiency arguments.)

And this, I think, is the problem. Almost exactly zero programming languages fit into neat semantic categories. Prolog, for example, is definitely a logic language, but it's also imperative, impure and generally defined by its operational semantics rather than first-order predicate logic.

I forget who it was (possibly one of the Erlang luminaries) who coined the term "dominant paradigm". All non-domain-specific programming languages are multi-paradigm when you get down to it, but each has usually has one dominant paradigm. That's why it makes sense to talk of "Lambda the Ultimate Imperative": languages which are dominantly functional can still allow imperative programming.

All this goes back at least to Schopenhauer. He wrote an essay about "games". It turns out to be pretty much impossible to come up with a set of features that are common to all "games", includes card games, board games, the Olympic games, war games, mind games and so on. The best that you can do, he concluded, was to say "these are games, and things like them are games too".

In a similar vein, it doesn't make sense to say "if it has feature X but doesn't have feature Y, then it's a scripting language and not a general purpose language", because real programming languages defy that kind of categorisation. It makes more sense to say, "A, B and C are scripting languages, and so are languages which resemble them".

Everything2 claims that the phrase comes from Kuhn's landmark 1962 book. I suspect that predates Erlang just a bit, though I'm not certain that specifically "dominant paradigm" came from there. And I'm even less sure who coined the "subvert ..." version.

...this is a different use of the term. In the programming language sense, it's the paradigm that dominates the language. The OO paradigm, for example, dominates Java, despite it being a fairly ordinary imperative language (with a not so ordinary portable virtual machine).

Say dominant style and avoid the tangential quarrels.

From my experience, PHP can be made really, really fast. There are tools for that...

Ruby, OTOH, has some serious problems. I can say that as a longtime Ruby fan :-)

a) Slow - I guess there's no reason Ruby can't be made to run as fast as Perl, and Perl is fast enough for lots of big sites, e.g. LiveJournal.

b) No native threads - a serious one, but a non-issue for admin scripting and website development, which are Ruby's two main sweet spots.

c) Buggy GC in the presence of continuations - unfixable without a total rewrite of the interpreter, as Matz said somewhere.

YARV. It should do well enough for a first pass at a bytecode interpeter, if it doesn't JIT as well.

But when? :)

It's been 4+ years now since the hole Rite thing first came up. It was actually promised for last year at one time, and if it misses Christmas'06... then when?

And, at least for me, speed is the least of current Ruby's problems...

...they're waiting for the Perl6 implementation on Parrot to show the way?

*ducks*

"It was actually promised for last year at one time, and if it misses Christmas'06... then when?"

I have a hard time believing Matz ever promised YARV/Ruby 2.0 delivery for any particualr date. And if it wasn't said by Matz (or perhaps Koichi) then it doesn't count.

You're right, promised was too strong a word - my bad. On the other hand, this did have some (including me) believe that was in fact the master plan.

That's true that most of so called "web languages" (perl, php, ruby) have pretty bad performances. It's not a surprise since they are interpreted. OTOH Python use an intermediate bytecode compiler and run a VM. I'm working on Neko which also have very good performances (and soon JIT) - especially compared to such other languages implementation.

However I would say that one of the biggest problems of theses languages is the fact that their compilers are written in C and are part of the VM/interpreter. It makes the whole thing monolitic, more difficult to maintain and a lot more bug-prone.

Since their performances are not so good (again it's not the fault of the languages but implementations), people tend to put even more things on the C side when they need reasonable speed, and it just creates even more problems.

BTW someone started to work on a Ruby compiler targetting Neko. That might be an interesting solution, and is actually the reason why Neko was created in the first place : to provide a common lightweight - still quick - runtime.

Not to get too far off topic but how does Neko compare to Lua performance-wise? It appears to be about the same size as Lua so there isn't much to gain there. If it's not considerably faster then Neko is in trouble. ;) (also consider there is already LuaJIT)