Hacker News Reader

Comment by badminton1 | Hacker News Reader

Linus said once that if the only benefit of using C for Linux was excluding C++ programmers, that was enough of a benefit.

Sounds really negative, but to be honest, sometimes if the only benefit of Scala is excluding people that are not comfortable with advanced programming, for a project that requires it, then great. You saved your recruiters the job of looking over a lot of resumes that you didn't want anyways.

Scala is not incredibly hard. I am not gifted and I managed to learn it to an extent in which I could solve practical problems.

That being said, I think learning Scala comes out more naturally when you have some exposure to Java. Since many Scala constructs are really shorthands for longer Java code.

I have to accept though that some people go really hardcore on the functional side (like the typelevel/scalaz folks) and that can be really intimidating.

View on HN

> I think learning Scala comes out more naturally when you have some exposure to Java.

My experience at the office is different. I come from Java, but I've seen people who literally never programmed in Java or any other Java-like language succeed with Scala (and then they get horrified when they find out what Java looks like). They have none of the bad habits that come from years of writing Java code. It's enlightening, really. A few years ago this experiment wasn't possible -- of course everyone doing Scala was a Java expat. Not anymore, though!

I couldn't disagree more with you about excluding people. Excluding newcomers is always bad, but also, don't people "comfortable with advanced programming" deserve good documentation? Of course they can and will succeed in the absence of it, but only after wasting valuable time.

Linus' statement is controversial and shouldn't be quoted as gospel. In any case, he argued against C++ programmers because he thinks they -- and their chosen language -- suck, not because of advanced programming or whatever (note: not my opinion!).

(That's why I started saying "I think", to emphasize it's an opinion rather than a fact.)

My personal experience has been that it is easier to explain people Scala when you can explain it in Java construct terms... But I can see how someone coming from, let's say, Swift, can have an easier time writing idiomatic Scala.

I am against excluding people for the sake of excluding people but you need to consider that communities have some core values, and the core values behind the Scala community are different to that of, let's say, PHP. You know what I mean.

I fully agree about the community values, but how is having no good documentation helpful for building said community?

Also, it'd be VERY disappointing if the reason for this lack of documentation was the explanation from the root comment in this thread.

As the Scala team lead at Lightbend, I'm truly saddened to see posts like this. It couldn't be farther from our intentions and interests! We absolutely want outstanding Scala documentation, and would never stand in the way of improving them in any way.

My whole team has worked extremely hard this year to bring you the best 2.12 compiler we can. We also spend as much time as possible helping out with polishing documentation, but we feel a coordinated push for better documentation belongs under the umbrella of the Scala Center (whose mission is to "Independently guide and support the Scala community" and to "Provide deep, and quality, educational materials for Scala"). We'll be thrilled to collaborate, but we (as veteran Scala users) are not the best placed to write getting started guides.

EDIT: It was brought to my attention that my comment about the Scala Center could be misinterpreted. I meant to say I would support a proposal to the Scala Center advisory board about improving Scala's documentation, with a focus on the getting started experience.

Let me give you a 'fer instance' (this may be the only one that exists, but it's one that had me WTFing until I found the correct documentation to read via stack overflow)

Calling grouped on a Seq.

I've been playing around with some API requests, and needed to batch a long Seq to make reasonable sized GET requests.

So I called grouped on a Seq, then to sanity check I called .length on the grouping.

Then suddenly I had an empty iterator.

Maybe I should have known better, yeah, but the documentation I was reading http://www.scala-lang.org/docu/files/collections-api/collect... doesn't mention this fact about iterators. Again, maybe I'm the only person in the world who didn't realise the problem with calling .length on what I thought of as a regular old batched set.

It wasn't until I hit on the right google combination that I found http://www.scala-lang.org/api/current/#scala.collection.Iter... from a stack overflow reference, and the lightbulb finally went on.

Thanks for the example. We agree that this is a tricky part in the collections. For Scala 2.13, our headline feature will be simplifying/refining the collections API. One of the areas we'd like to improve is to make the transitions from eager to lazy more clear. Also, we'd like to keep immutable (more) separate from mutable collections. Once we switch gears from 2.12.0 to 2.13 milestones, we'll be sure to provide a convenient way to share gotchas like this, so we can see how to prevent them.

I think there is some good Scala documentation.

By core values of the Scala community I refer to trying to create idiomatic ways of solving problems, and trying to get the most out of the language. One evidence of this is the amount of domain specific languages created in Scala.

Twitter's Scala school was a good resource for me, the official tutorial by Odersky in Coursera is a good starting point too. You can also watch Scala talks in YouTube, to supplement documentation reading.

Those resources are good. Twitter's Scala school is more relevant as a reference than Odersky's progfun course (if that's what you mean by "official tutorial"), because progfun is more about FP and less about Scala-the-language (this made it even more interesting for me, but also makes it less useful as a reference). Note, however, those resources are external.

I understand what you mean by core values. I don't understand how they are improved by a lack of documentation.

The tour of Scala lost me initially. I used "Another tour of Scala", I found that one to be easier to digest.

I'm not sure that's such a good filter in this case. There are a lot of cool new languages out there, and most people would rather spend their time learning rather than fighting with poor docs. Anybody "comfortable with advanced programming" will also be aware that there are many other languages with better documentation.

Also, I think it attributes the bad documentation complaint to the wrong thing.

Look at the tutorial, for example: http://docs.scala-lang.org/tutorials/tour/tour-of-scala

The intro page just lists a few selling points: OO, functional, static typing and extensible. The second page has no continuity and is about "Unified Types," with a big complicated diagram and a blob of code. No explanation what to do with the code to compile it, run it, load it in a REPL or anything. I need a tutorial just to be familiar enough with Scala to use the tutorial. The entire "tutorial" is like that with no continuity and no connection with anything coming before it.

A person can go to haskell.org, navigate to the documentation, start with the tutorials, and eventually learn the language. That would be nearly impossible using the scala-lang.org page, without a huge amount of pre-existing Java and functional coding experience.

I think the two examples are different because you are suggesting that Java knowledge become a sort of pre-requisite for learning Scala, whereas the Linus' quote mentions C which, AFAIK, doesn't have a pre-requisite-other-language-that-you-have-to-learn-first (if anything, I would suggest new programmers to learn C before moving to higher level languages!).

Interesting to note that the most natural translation of Linus's statement is:

"if the only benefit of using Java was excluding Scala programmers, that was enough of a benefit."

Scala adds multi-paradigm heavily complexified syntax on top of Java.

Scala : Java :: C++ : C

> (like the typelevel/scalaz folks)

well I was scared about that as well, but than I bought https://www.amazon.de/Learn-You-Haskell-Great-Good/dp/159327... and used cats (XorT,OptionT) and now I don't want to miss those two.

P.S. I am not gifted also and I guess I managed to learn it to an extend, too. Basically I'm always afraid when writing mutable/imperative code now.

Yes. Haskell's Maybe / Scala's Option was a fantastic finding for me. I quickly incorporated that in all of my code, I think it filters out a lot of problems, especially the "billion dollar mistake" (null reference exception).

You're also saving your recruiters the job of looking over a lot of resumes from people who have productive full-time jobs in another language and have limited time to pick up a new language because they're busy delivering business value in their existing language. It's a very high-false-positive strategy.

Very true, geofft. Sometimes you can formulate your job posting like: Scala or Java, with preferred Scala experience. I had issues when trying to recruit for a Scala position, and we expanded the search a little bit to include senior Java programmers too.

Reply on news.ycombinator.com