[trailfox]

The quality of the original "1-star" blog post was extremely low. Odersky sums it up well with:

This week-end's edition is called "Scala - 1 Star - would not program again", and it's by someone who from reading his post seems to have written Scala all of two weeks after coming form Javascript. I think the interesting bit is not so much that these posts are written, but that they are upvoted so much.

I was also very surprised to see such a low-quality blog post being voted up with such enthusiasm on HN and elsewhere.

[tikhonj]

When somebody reads that X is better than what they're using or that X is the "next big thing", they're liable to feel this as a personal attack. It's like their choices were wrong--they should have gone with X instead. This isn't usually how the articles about X are actually meant to be read, but it's how some people see them nonetheless.

Now, these people are feeling slighted (however unfairly). They're not going to drop everything and pick up X. Fair enough: jumping to every shiny new technology would be madness. But chances are they won't even bother learning about X properly. Instead, they want some plausible sounding reason about why X is not all it's cracked up to be, about why they're actually smarter for not using it than vice versa, about why it's all just more hype. They want to stick it to those smug X-using bastards.

So they vote up critical articles that just happen to be written coherently, regardless of how accurate they may actually be. And so we get dross on the front page. Happily, the HN comments tend to paint a much better picture: they simultaneously debunk the original argument while exploring the actual upsides and downsides to X. With these sort of articles, the contents are worth far more than the actual blog posts.

X here is anything from Scala to NoSQL to functional programming. The recent article about what is wrong with FP and OOP is a perfect example of this, which annoyed me in particular. And yet, I think this sort of thing is virtually inevitable if functional programming is to grow and become more popular, so it's more than a worthy sacrifice.

[tostitos1979]

"two weeks after coming from[sic] Javascript"

Is this not an ad hominem attack? The original post writer joked about Scala syntax giving him a headache. I too felt the same way the three times I've briefly looked at Scala. I think some of the points made in that post were valid.

[scotth]

I think he's suggesting that the author of the blog post had limited programming language experience.

Even though it may not be fair, JavaScript does seem like a good language to pick for labelling someone that way, along with PHP.

[jeremyjh]

I'm very sure it isn't meant that way. Two weeks of exposure to Scala really is not nearly enough time to learn the language if you haven't any previous experience with strongly-typed functional languages. If you have deep exposure to both Java and Haskell then perhaps you could be productive in Scala in two weeks but even then if you wrote a rant like this your criticisms would still likely be on shakey grounds.

[mattgreenrocks]

People love controversy, and Scala is relatively new/unknown.

But the fact that the article got disseminated so widely speaks volumes about the need for curation. Delegating it to users simply ensures it meets a certain minimal threshold.

[nilliams]

Also be aware that people like myself that don't know much about Scala, but are trying to keep it on their radar, may upvote such a post just to try and see where the comment thread goes and see if there are good insights from the defending community.

Often an upvote doesn't mean I agree with the post or even its tone. Just that I want to see some further discussion.

(I don't know if this is in the spirit of HN, I appreciate it must be maddening for some people to see 'low quality' posts get upvotes).

[taude]

I thought the discussion the prior article created was really useful. Learned many things, including some things to look out for while evaluating, and other languages that people seem to like.

[adamors]

I feel the same way, sometimes I upvote controversial articles because I'm interested in the discussion it sparks.

[laureny]

> People love controversy, and Scala is relatively new/unknown.

Scala is ten years old.

[threeseed]

Remember there are a lot of groups who stand to lose if Scala results in a renaissance in the JVM platform. In particular those newer platforms e.g. Go, Clojure, NodeJS etc.

Plus HN has always been a moth attracted to any flame(bait).

[dasil003]

Why is Clojure included in your list of platforms that lose if there is a renaissance in the JVM platform?

[eloisant]

I don't think Clojure has to loose if there is a renaissance of the JVM, however it will have less space to exist if Scala becomes what people think when they think "FP on the JVM" (and it's starting to become the case).

[SkyMarshal]

I don't think Clojure's popularity will be heavily affected by Scala's, but rather by the contingent of people who want to do dynamically typed and/or lisp-y programming on the JVM. I see Clojure competing more with Ruby, Python, jRuby, Lisp, etc than Scala. There may be some subset of those who can and will cross-over to statically typed Scala, but I think that for most part dynamic fans tend to stick to dynamic languages.

[uniclaude]

I disagree.

Clojure is mostly seen as "Lisp on the JVM", and I don't see Scala becoming more popular as anything negative for the Clojure community.

[wwweston]

If there's a language-based JVM renaissance and we don't end up in a place where what targets do rather than what they're written in (beyond "language X makes this problem easier", anyway), then I'm not sure it's really a renaissance.

[kaoD]

I'm sure you work with Scala, because I work with Clojure and I see it "starting to become FP on the JVM".

Confirmation bias.

[SkyMarshal]

None of those will lose if there's a renaissance in the JVM platform. Go is a competitor to C more than the JVM, and is a FOSS Google product that's becoming their 4th official language and is not going away. Clojure is part and parcel of that JVM renaissance. And Node is coming to dominate client-side development by underpinning an emerging build tool standard - Gruntjs, and arguably the CommonJS-based Browserify, which will dwarf the parts of Node that compete with the JVM. None of these are heavily threatened by a server-side JVM renaissance.

[eropple]

Go isn't a competitor to C. Having a mandatory garbage collector makes that pretty clear. Go is instead a competitor to the legion of other high level, predominantly application-focused languages: Ruby, Python, Java.

Rust is an alternative to C and C++, but Go doesn't have a claim to that.

[CmonDev]

" very surprised " - seriously, considering the number of JS fans here? Post something like "[any old/boring stuff] - but in JS/WebGL/HTML/CSS now!" and you will get at least a hundred votes.

[gcv]

Discussion of tools is pretty important, and the "1 Star" blog post summarized a programmer's feelings about a tool. Both of his main complaints, compilation time and impenetrable operator overuse (remember, this is the language that brings us arbitrarily overloadable beauties like _._ and :+= and <%<), have been acknowledged in Martin Odersky's post.

When we, as programmers, choose tools, we make both a bet and an investment. We invest our time — both up-front in learning the tool, and during the course of a project — and bet that it'll pay off relative to using other tools. A blog post which gives a hint as to the expected value of this bet is appreciated. Hence the upvotes.

FWIW, I think Scala is a razor in the hands of a monkey, and it turns me into the monkey. I read Odersky's book 4 years ago, and it left me with a horrible taste in my mouth. I consider myself a competent programmer in Common Lisp, Clojure, Java, both C and C++ (including C++11), JavaScript, and Ruby; yet I do not trust myself with Scala.

PS: And this is just language semantics. Let's assume that Scala will eventually compile faster and solve its binary backwards compatiblity problems.