Well, gosh, it must be terrible, avoid it all costs!

> I'm repeating the same line for the third time today.

You're obviously not a fan of the language if you find yourself bashing it 3 times in a day, fair enough.

> I find that Scala is for people who find Haskell too simple

Scala is for those that want to get shit done without dealing with Java's endless boilerplate, while still running on the performance beast that is the JVM and benefiting from Java's massive ecosystem. As a bonus you get FP out of the box, so you find yourself, without consciously being aware of it, favoring immutable constructs (map,flatMap,fold, etc.) over imperative mutable boilerplate ridden hacks to achieve the same, thereby, in complete disagreement with the article at hand, becoming a better programmer.

With Haskell you get purity, unhindered FP elegance, and minuscule ecosystem, a language interoperable with...itself it seems.

While it's true that Scala is perhaps overly feature rich, with the to be released 2.11 the focus has been on aggressively stripping out unused features from the language and improving compiler performance.

Following that, perhaps for 2.12, Odersky recently proposed on Twitter a revision of the type system that had FP devotees up in arms since the proposed change removes some of the complexity that makes libraries like Scalaz possible.

At any rate, with Java8 there will be a squeeze in the JVM landscape, alternative languages will be fighting for users as lousy legacy Java is soon going out the window.

What you've described is what Scala programmers want Scala to be, or what they use; not what it really is. It seems to me that you've actually described Kotlin.

BTW, I agree that the JVM is a tremendous asset. I develop for the JVM every day and I love it.

The reality is that Kotlin ships a milestone about every 4 months; they're still on 0.6 and the 1.0 release will be a beta release, so we can expect to see Kotlin stable in what, maybe 18 months? That's a long way away when you consider that...

Java8 (arguably the bigger threat to Kotlin than Scala is) will already have launched (looks like Q2 2014 last I checked) and grabbed frustrated Java teams everywhere.

So, Scala trimming down and Java fattening up. Kotlin? A bit late to the party. Java8 will keep existing Java shops intact, and Scala already having made significant inroads into the enterprise, will continue to thrive as _the_ statically typed Java alternative.

My take at any rate, will be fun to find out how it all shakes out in the coming years.

Because then the computer knows what I'm doing, and not just me. Whenever I write a cast, I am assuming I'm smarter than my computer--so smart I never, ever need the computer to check it. This is pretty stupid, because I'm not that smart. (Neither are you.)

> What you've described is what Scala programmers want Scala to be, or what they use

This is a pretty silly line of demarcation. Scala is what people use. So is JavaScript. There's no prescriptive use case for it.

I'd like to like Kotlin, but it wasn't done enough soon enough and I now know Scala intuitively enough that there's no real reason for me to use it. It's just-different-enough from Scala to throw me, while being a step back down the continuum of expressivity. If Kotlin had come out three years ago, it might have grabbed me, but at this point it holds no value to me.

I've always wondered about this argument. Haven't modern Java IDEs more or less automated away the boilerplate?

Using a tool like IntelliJ IDEA or even Eclipse for that matter, I'm really hard pressed to find something that could be autocompleted or generated that hasn't been. They even have views that collapse or otherwise hide away unnecessary verbosity.

Sure, you have a little more code to look at. But frankly, sometimes this can improve readability vis-a-vis excessively concise and overloaded syntax. It can make it easier to grok someone else's code.

I'm not saying there's no difference, just that it's a little odd that this is the NUMBER ONE advantage always cited for Scala vs. Java. Am I crazy?

They may automate some of the typing of boilerplate, but that just means the language you are entering isn't the same language you are reading, which is another problem.

The boilerplate is still there, and its still in the way.

> Sure, you have a little more code to look at. But frankly, sometimes this can improve readability vis-a-vis excessively concise and overloaded syntax.

IME, its more often the case that the boilerplate that Java requires makes code hard to read than that the conciseness that Scala permits (but generally does not require) makes it hard to read. And, since the concise options in Scala are generally options, a programmer who is aware of a case where being maximally concise impedes clarity can opt for a more explicit expression, whereas the Java-required boilerplate isn't optional, so even if the programmer is aware of it getting in the way of readability, they can't eliminate it.

I don't think that's true. Your phone has an autocomplete function for text input. You're still typing and reading the same language.

> a programmer who is aware of a case where being maximally concise impedes clarity can opt for a more explicit expression

By the same token, readers are held hostage by the poor decisions of overly concise Scala programmers. This is not theory, it really happens a nontrivial amount of time. You can blame the programmer if you want, but it's a point for Java readability.

Now you're simply overstating the case. Why?

This is a perfect example of my claim. There is this emotional component to the "Java boilerplate" argument that belies rationality. There is some other unstated reason advocates want Scala and are fitting the argument to that conclusion. Because it's cool? Big fish small pond syndrome?

  List<String> list = getListofStrings();
  List<String> capitalized = new ArrayList<String>();
  for(String st : list)
    if(Character.isUpperCase(st.charAt(0)))
      capitalized.add(st);

  val list = getListOfStrings
  val capitalized = list.filter(_.head.isUpper)

Second, a lot of the concision comes from omitting type declarations. I will argue this decreases the readability of the Scala example.

What kind of data structure does getListOfStrings return? With Java you know with complete certainty that it returns a List of String (and only String). With Scala you have to infer it from the method name and hope it's honest. Likewise with the filter function. Whatever your opinion is of explicit type declarations, they are not mere "boilerplate".

There are certainly other savings in your Scala example apart from types, like the filter lambda function. I'm just a bit incredulous that Scala advocates genuinely think this saves them large quantities of time over the course of a project vs. an IDE-assisted Java version. I mean, how much longer would it take you to write or grok that Java for loop? Seconds? How much longer to do it 100X in a project? Minutes?

There has got to be a deeper underlying emotional reason why people advocate Scala -- which is not to invalidate that reason at all. It's important to feel love for your tools. But be honest about it. It's not about saving hundreds of hours of time writing boilerplate.

when your mental/visual pattern machinery have been trained for 15+ years on the latter case? :)

It can transform for loops into linq statements (and vice versa) quite easily

And even the best IDEs can't help with much of what I've seen in large Java apps.

What is the proposed change, exactly? Do you have more information?

and the Twitter thread is here: https://twitter.com/odersky/status/382833314286956544

As someone who switched from scala to haskell, I find your mis-characterization rather amusing. The haskell ecosystem is far better than the scala ecosystem. The ecosystem is more than just libraries, and using java libraries in scala is giving up much of the benefits of scala. And scala interoperability has been one of the biggest things everyone complained about, probably not a good choice to criticize other languages for.

>Following that, perhaps for 2.12, Odersky recently proposed on Twitter a revision of the type system that had FP devotees up in arms since the proposed change removes some of the complexity that makes libraries like Scalaz possible.

"Don't worry, they are going to make it 1% simpler by giving up 25% of its expressiveness!" is a pretty terrible sales pitch.

What does that even mean? There's full Java interop, so I just add a dependency on JodaTime and voila, a kick ass library at my finger tips. That is by and large the ecosystem, a massive wealth of functionality, followed by community and tooling (which in Scala is admittedly a weak point).

With Haskell you have Haskell's ecosystem, nothing less, nothing more. So if a Haskeller hasn't developed, for example, a PDF generator to produce client invoices, you're SOL short of writing it yourself.

Scala has a strong, somewhat modernish type system. That protects against many bugs. Java does not. Java libraries can contain code that breaks assertions the scala language makes.

>With Haskell you have Haskell's ecosystem, nothing less, nothing more

Sure. But haskell's ecosystem is miles ahead of scala's. So it is less common to need to resort to using a C lib than it is to have to resort to using a java lib from scala. Yes, tooling and documentation are a huge part of the ecosystem, and scala is pretty awful in that regard.

What's scala designed for? Programming - not just highly concurrent programming, not just quick scripts to do some text manipulation, not just web services for millions of requests, but all these things and more. It's the most generally applicable language I've ever seen, and there's real value in being able to write your whole platform in a single language which is nevertheless a good fit for a very wide range of problems.

I don't think it's fair to say each feature is piled on to plug a specific hole; rather, a lot of the power of scala comes from the interaction of several features that are individually quite simple. E.g. unlike Haskell's typeclasses which have to be built into the language, in scala that's simply a pattern that you write in regular code. 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.

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.

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

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.

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.

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

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.

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

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.

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.

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.

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

Coherency/conceptual integrity are things I look for in computing environments they make reasoning things much simpler as logical deductions can be made, I don't find myself doing that with Scala.

I used to have the same concern you're expressing, and a few others besides--I've written comments on HN along the lines of "I'm writing Scala that I can't read the next day"--but I got past that stage not too long afterwards, and I find it remarkably predictable and consistent in everyday use.

[1] - this isn't a fair characterization, see deeper in the tree

Scala isn't a pure-FP language, and trying to treat it as one doesn't really...work. Square peg, round hole. For me it falls in the "neat hack, but" bucket. That it can be done as Scalaz does is cool, but the practical value of it seems vastly oversold and I'm uncomfortable with the functional-everywhere political viewpoint pushed by some of its leaders (and fortunately Odersky seems opposed to a lot of it, which IMO bodes well for Scala's future).

Why do you say this? vals and immutable data strucutres are clearly emphasized in Scala, so how can you say that FP isn't at its core?

>Scala isn't a pure-FP language, and trying to treat it as one doesn't really...work

Why do you think scalaz concerns itself primarily with enforcing 'purity'? Scalaz' effects library isn't even part of it's core repo.

Oh the irony.

The company I work for is a Scala shop, and we've found success in codifying our coding style using the Scalastyle linter. The combination of a linter and peer code reviews has been very helpful for us in figuring out which language constructs and libraries we use and which we shy away from.

And there's a bigger problem. Do you shy away from Scala collections? Because I have no idea how the types works there, I didn't want to spend who knows how many hours just to understand how a simple list is coded, and I certainly wasn't going to use something I couldn't understand. So while you may easily understand your own code, I don't know if your team understands this simplest, most basic of libraries.

From what I've read, that's exactly the design philosophy: we don't know what people will (eventually) want from our language, so we'll be sure to make it very extensible. And so the Scalable Language was made.