> Unlike Erlang's built-in notion of actors, in scala Akka is "just" a library.

So what? In Erlang it's part of the language because Joe Armstrong et al. thought that this is how modern software should be written. They figured they'd need immutability, process isolation, and message passing. In Scala you can do that in a library minus (guaranteed) immutability and isolation, which were the whole point to begin with.

Same for Haskell. They've figured that an unbreakable type-system with functional purity will make it easier to write bug free code. So Scala takes the rich type system (that has its own mental cost), but removes the purity and the safety which are the the whole purpose of the exercise (or much of it, at least).

I could go on and on (with macros, implicits and more), but Scala never fails to miss the mark. It adopts a feature without adopting the philosophy that makes the feature powerful.

> Mutability and inheritance are good solutions to certain classes of problems, and it's valuable to have them in your toolbelt.

Sure, but not if I have to pay the price of such a complex type system, that was designed for languages without mutability and inheritance! Each of these features is good in isolation, but combine them, and you get a mess. Scala is a the pizza-ice-cream-soup-steak-salad. Each has its place, but not as part of the same fucking dish! What is wrong with using one coherent language for one problem, and another for a different one? That's what Scala's designers don't seem to get. They simply have no taste. They're gluttons.

I certainly wouldn't mind the generality if only the mental price I had to pay for it wasn't so high. A lack of guidance is not bad in and of itself - C offers no guidance and no guarantees, and is fit for many tasks - but combined with so many haphazard features and mind-boggling complexity, it becomes a liability rather than an asset. You end up paying the price for each of the features, but reaping few of the rewards. I think programmers are the last people this language is for. In fact, I think Scala is mostly made to amuse its compiler writers.

Scala reminds me of nothing so much as C++. Yeah, you may not want to use what is to you some obscure corner-case feature, but it's 100% certain that you will encounter some code written by someone with a different view of what is and isn't critical. So you need to keep this enormous pile of abstractions and their interactions in your working set, or you're off to the documentation.

I don't entirely see the value in having these "big-tent" languages, where everyone writes their own dialect but imposes that mental cost on all of the other readers. Odersky is clearly a very smart guy, but I'm not persuaded around his way of thinking.

Scala is more expressive than Java-the-language (it'd be difficult to be less so), but that's not the only metric one should use [1].

[1] PLEASE DO NOT READ THIS AS AN ENDORSEMENT OF JAVA-THE-LANGUAGE.

> 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.

It's not a mess. It's a language in which you can do what you did in Erlang, or what you did in Haskell, or what you did in Java, not because it's taken all their features but because the core language is expressive enough that you can write a library rather than making a separate language. You can shape the language to the problem, not because it's complex but because it's simple. It reminds me of go (the game, not the language) - yes, you can build up these very high level patterns, consisting of dozens of pieces, and sometimes you look at a master's beautiful play and wonder how he ever found it. But the underlying rules are very simple, and it's always possible to take a pattern apart and see why it works.

So you get the expressiveness of a language like perl, or yes, C++; you can write in a huge variety of styles. But you don't get the problem where no-one can read anyone else's code, because underneath it all those styles are using the same language primitives. So even if you haven't seen a typeclass before, you can understand scala code that uses them, because it's just passing an implicit parameter of a certain type. Even if you haven't seen an actor before, you can understand code that uses them, because it's just a library of funny-named methods with particular semantics, and using pattern-matching in a particular way.

Yes, you could write two actors that access mutable fields in another object. Yes, you could write a method in the I/O monad that also calls println. But you wouldn't do these things by accident. In 3+ years of professional scala development (with several quite inexperienced team members) I've never seen a bug caused by inappropriate mutability or inheritance. Yes, it would be nice if the compiler could draw a distinction between pure functions, those that performed I/O, those that modified state, and those that had other kind of effects. But it doesn't seem to be necessary in practice.

Being able to use a single language means being able to use one set of tools, one set of infrastructure (the maintaining of which is often one of the more tedious parts of the job). It means not having to context switch, and not making mistakes because a similar-looking operation means something different in another language. It makes code reuse much easier (yes, even on the JVM - while it's possible to call from one language to another, an API designed for a different language will be cumbersome because it uses different conventions). Ultimately it's just a lot less mental overhead.

> What is wrong with using one coherent language for one problem, and another for a different one?

Some shops really hate doing work in multiple languages. If designing a language for general industrial use, I'd think long and hard before writing a language that was not at least somewhat sort of decent at everything.

The scala scripting is an oft-overlooked feature, and I think it's pretty great. You can compile your codebase into a jar, upload it to a server and link to it from a script in Scala you're editing there in a console text editor. Advantages:

- no compilation required, while still maintaing static typing checks

- since the script is the same Scala language as your main codebase, you can copy/paste code snippets into script for increased productivity

From my experience, it's been great for one-off data processing jobs done on the server.

In Scala 2.11 you will be able to use Scala as a standard Java scripting engine: http://docs.scala-lang.org/scala/2.11/