[dextorious]

I might not get the joke. Do you mean this ironically?

There sure is reason to have different programming languages, and it's called specialization (see: necessary engineering compromises).

My first comment says: two objects having the same generic functionality, does not mean that one and the same object can implement their specific (non generic) functionalities.

My second comment says: the same thing, basically.

[pacala]

I mean that (programming) language is a special kind of object that has enough versatility to express any idea in a reasonable form. Historically, our programming languages weren't that good in versatility and made various utterances an universally agreed on pain. But we are getting better and there is no law in the universe saying that we'll be forever stuck in Babel.

To some extent, your point is that Shakespeare is better in English than in its German translation for style reasons. My point is that it doesn't really matter and that an universal language is better than Babel because of network effects. Life is too short to erect artificial communication barriers.

[dextorious]

"Historically, our programming languages weren't that good in versatility"

Well, we're not yet to the point that barrier between systems and web programming languages to be eliminated. You seem to imply that the problem is the inflexibility of the languages, but to me it's not a problem, it's a feature: I want different abstractions to work in different problem domains (e.g. systems vs web). So it's not that the languages are not flexible enough, but rather that we, as language designers and users, have MORE flexibility, to use a different tool for a different job.

Also: yes, Shakespeare is better in English than in its German translation. And it's not just the language, it's also the cultural universe that Shakespeare presupposes. For business use, maybe, but for culture I don't like universal languages, network effects be damned. Life is too short to reduce world languages and communication to a lowest common denominator [and that is inevitable, because any wannabe universal language will lack the historical and cultural ties and shared substructure of any particular population).

[pacala]

> Well, we're not yet to the point that barrier between systems and web programming languages to be eliminated.

We are one or two iterations away. Look at this thread. A lot of people were expecting something looking closer to Go. Go itself is an example: statically typed, garbage collected "systems" language. If you ignore the differences in the type system and the slice syntactic sugar, that sounds conspicuously close to Java. And Dart itself sounds closer to Java than Javascript as well. Not that I believe we'll converge on Java, given the glacial pace of evolution in that community.

But the edges of the state-of-the-art are getting closer in this generation. Next generation (5-10 years from now) will be even closer, if not identical.

On a technical note: what exactly do you have in mind when making a distinction between "web" and "systems"? Backends qualify as "systems" in my book and I'd be a fool if I'd want to develop in two distinct languages when there is just one app. Thanks to GWT and now Dart, I don't have to.

[dextorious]

Well, by "web programming" in the context of the original comment, I was talking mostly about web backends. If you mean that, then yeah, we'd develop those in one language, in fact we already do in some case (node.js et al).

But I don't qualify that as "systems programming", to quote Wikipedia:

"System programming (or systems programming) is the activity of programming system software".

and:

"System software is computer software designed to operate the computer hardware and to provide a platform for running application software".