> Odersky is clearly a very smart guy, but I'm not persuaded around his way of thinking.

He is, and his way of thinking, if you watch some of his talks seems to be: sometimes you have this problem, and sometimes that problem. How can we write a compiler that tackles both?

If you listen to Rich Hickey or Joe Armstrong you see something completely different. They ask what the biggest problems facing software developers are, and what philosophy should modern software development adopt in order to face these problems. The features of the languages they've designed directly follow from their philosophy.

I think it is no coincidence that Martin Odersky is a PL researcher (and hence is interested more in sophisticated compilers), while Hickey and Armstrong come "from the field".

It feels off to me because it feels like applying a technological fix (more complicated compilers!) to what is in essence a social problem. Of course tooling has an enormous weight in how people go about solving their programming problems; but the idea that we can fix the effects of e.g. underpricing technical debt or downward wage pressure on programmers simply by creating better tools (and better by which metric?) is -- in my experience -- a fool's errand.

The value for big-tent languages like C++ and Scala comes pretty much from the following factors:

1) There is an existing language that has become widely used in a domain (or a variety of domains) with a well-developed ecosystem, and

2) There are well-known limitations of that existing language for the domains in which it has become widely used, and

3) The existing alternative languages that take conceptually pure approaches to addressing the problems with the existing dominant language have problems making use of the ecosystem that has evolved around that dominant language and/or pose a difficult transition for programmers versed in the dominant language, and

4) The "big-tent" language provides an easier transition for people versed in the language than purer alternatives (by way of more directly supporting the idioms of the dominant language) and has better support for leveraging the existing ecosystem that has grown up around the dominant language.

Ah, but one of the great points of the JVM is that it provides easy interoperability.

So much of being versed in a language is knowing its libraries, but on the JVM, many of the libraries are shared among languages. I use a lot of my Java and JDK knowledge when I write Clojure, and I'm using Clojure when it makes sense and Java when it makes sense.

There doesn't even need to be a "transition" on the JVM, but a gradual, selective use of languages in certain circumstances.

The JVM is the big tent.

I don't really see Clojure as a particularly "conceptually pure" alternative, but more as another big-tent language like Scala, but one with a syntax less similar Java's (which has plusses and minuses.)

> There doesn't even need to be a "transition" on the JVM, but a gradual, selective use of languages in certain circumstances.

To an extent, that's true on any machine so long as none of the languages interposes its own runtime on top of the machine and the languages use common calling conventions.

But the conceptually pure alternatives to Java pointed out in this thread (like Erlang and Haskell) generally don't run on the JVM. And even when they maybe do (e.g., Erjang exists) they don't provide easy access to the ecosystem.

I don't value purity; I value coherence, and a good sense of direction. I would take JVM interoperability over purity any day, because the value of whatever compromise this entails far exceeds its cost.

In fact, I don't even consider it a compromise because for all their strengths, neither Haskell nor Erlang solve all problems. In that respect Scala is right. Scala is wrong, however, to think that each concept's deficiencies need to be addressed in the same language. It could have worked in theory, maybe, but the result in practice turned out an ugly mess.

I believe in combining forces through a few languages that interoperable over one platform, and the JVM achieves this quite well.

> And even when they maybe do (e.g., Erjang exists) they don't provide easy access to the ecosystem.

Sure they do. Erjang (and Frege, for that matter) support straightforward integration with Java.

What do you find conceptually impure about Clojure?

In the sense in which conceptually pure was being used upthread for langauges which have a very strong opinion on the constructs appropriate for software development (Haskell with pure functional programming, Erlang with actor-model concurrency), I don't see Lisps in general, including Clojure, as being conceputally pure (there is a kind of conceptual purity there, but its at a lower level and in a sense opposed to the kind of purity at issue here, as I see it.)

Clojure is a lisp, but that's not why it's coherent. It's coherent because it has a clear model of data, state, abstraction and computation. It's not only clear, but (like Erlang) resembles the way people think about the world and about computation.

I'd argue the proliferation of languages for the JVM is the biggest endorsement of Java the language. It is the under-appreciated bedrock of modern JVM programming.

I think this is right. I detest Java-the-language, but it is inextricable from the JVM. Being able to drop down to a simple (less charitably, lowest-common-denominator) language when necessary seems to help with the implementation of more interesting languages.

I'd say just the opposite; there have been more languages for the JVM than for the CLR because Java-the-language is a worse language than C#, so people are more motivated to create replacements.

There are more languages for the CLR than the JVM, since, via IKVM, the set of JVM languages is a proper subset of the set of CLR languages.

So, if there being more languages that can be run on the VM is a marker of weakness of the primary language for the VM, ...

Oh come on. I have great respect for Mr.Odersky. C++ was the language that taught us OOP and helped us make so many abstractions that were otherwise not possible.

Also, C++ is not something that people write not critical software with. The browser that I write this reply is written in C++, or the server that processes this may be written in C++.

Scala is also not something that people write "less serious" code. e.g., Twitter frontend services are written in scala.

Every language has solved some or other problem. It is nothing like someone does less serious stuff with it.