Hacker News new | ask | show | jobs
by argonaut 3751 days ago
You are really stretching things by saying you'd be productive on day 1. Scala code has an immediate upfront complexity cost.
3 comments

I have to agree with "lmm" and "the_af" here. You can use Scala as a "Java without semicolons", and indeed that's what I recommend to those who want to learn Scala coming form an OO background. There is absolutely no need to use fancy Scala features like higher-kinds or monadic effects. Indeed, there is no need even to use functional features. Scala is a perfectly fine OO language. The one thing I recommend to learn once a learner gets a grip on Scala syntax is pattern matching matching and case classes. It's really easy to understand. And once you understand it, you never want to go back.

I have had a substantial number of undergraduate students learn Scala this way for their final year project and they all got it pretty quickly.

You are advocating that beginners start using Scala without really understanding what they're doing, and being mostly unable to read other code or read the source, while writing what is considered to be bad Scala from the get go. Contrast this to languages like Python or Ruby, where it is totally possible to immediately start writing code you understand that follows the general gist of good Python/Ruby style.

You are certainly right that someone new to Scala can get started quickly this way. You are wrong that Scala is anywhere close to the same level on this dimension as Python or Ruby or Go.

   advocating that beginners start using Scala
No, I was talking about strong Java (or C# or C++) programmers learning Scala, starting with the OO part of Scala. Clearly this is not a large jump, as Scala has class-based OO that is really similar to Java, C# and C++. It is perfectly possible to be productive in this fragment.
I don't at all agree that someone can pick Python or Ruby up and start writing idiomatic (or even "good") code on day one. In fact I make a good living consulting in JRuby shops where they thought they would get some sort of benefit by using Rails but then wrote all the code as if they were still using Java.
I am speaking from direct personal experience. Explicit effect sequencing is optional (in contrast to Haskell), traditional OO with inheritance is available. You may not be able to read all the standard library type signatures on day 1 but the documentation is adequate without them. Anything you could do in Python/Ruby/Javascript translates directly; in the very short term I guess not having a single baked-into-the-language concurrency model like Go is a disadvantage, but the use case where you'd need that on day 1 is pretty rare.
I have found that the issue isn't the language, it's the ecosystem. If you're coming from Java environment set up is not such a big deal, but if your brand new it is not as easy as other languages.
There are certainly poor libraries and bad advice going around (why people tell beginners to use SBT or ScalaTest is beyond me), but that happens in every language. IME the average quality on maven central is if anything better than on PyPi/rubygems/npm/etc., and the IDEs/profilers/debuggers are better than anything you can get for the other languages.
I can think of some very good reasons to suggest SBT to beginners. Probably the most useful features, in this regard, is that a folder with some Scala files in it is a valid SBT project. You don't even need a build configuration file. This is substantially less work than setting up a Scala project through Gradle, Maven, Ant or an IDE.

Also, if you use SBT through Activator[1] you get project templates and an automatically configured IDE.

[1] - https://www.lightbend.com/community/core-tools/activator-and...

> I can think of some very good reasons to suggest SBT to beginners. Probably the most useful features, in this regard, is that a folder with some Scala files in it is a valid SBT project. You don't even need a build configuration file.

Sounds horribly magic/incomprehensible.

> This is substantially less work than setting up a Scala project through Gradle, Maven, Ant or an IDE.

I don't think the work of doing it in Maven with an IDE could be called substantial. Push the button, choose the scala template, give it a groupId and artifactId, done.

Man, you really need to get over your SBT hate.

Maven and Ant are barely maintained anymore despite so many broken things. Just compare artifact resolution/download speed between Maven/Ivy and sbt with coursier.

There is no way in hell I'll ever touch Maven again. SBT works without a single line of configuration, and that IDEs are not able to touch config files is a big fat benefit.

Eclipse developers can't even turn it into a working editor. I certainly don't want Eclipse to deal with my project configuration.

> Sounds horribly magic/incomprehensible

How is compiling everything in a given directory any more magic/incomprehensible than any other build tool?

> I don't think the work of doing it in Maven with an IDE could be called substantial. Push the button, choose the scala template, give it a groupId and artifactId, done

What IDE comes with a 'scala template' out of the box? What if you are not already in the JVM ecosystem? With SBT, the set up is:

- Install SBT/Activator

With your suggested equivalent, the steps are:

- Install Maven

- Install IDE

- Install Scala IDE plugin

I think the SBT option sounds like they would be much less imposing for a beginner.

Out of curiosity, what's wrong with ScalaTest? I particularly like the WordSpec style, which is easy to write and looks newbie-friendly.

It's true SBT is not suitable for beginners. Regrettably, neither is Maven. I don't know which tool is...

I find it makes tests much less comprehensible (and gives them worse IDE integration) than JUnit; it uses gratuitous operator overloading style with e.g. "should". And for a beginner it doesn't really offer any advantage - if you're using generators or the like I can see it might be helpful, but for basic unit testing I find straightforward code with JUnit is much easier.
Using the natural language style assertions is optional though, and only work if you incorporate the 'Matchers' trait in your tests. If that's too magical, you can still use plain old assertions or one of the other styles here http://www.scalatest.org/user_guide/using_assertions
I've found that Scala beginners google around, and come across lot's of blog posts extolling the virtues of Scalaz, implicits, using higher kinded types, embedding DSLs and so forth. All that is worthwhile, but not really accessible to beginners. It's understandable that Scala bloggers want to write about cutting-edge material, but this misleads beginners, who think you need to use Scalaz, monads and the like to be productive. Nothing could be further from the truth.
With a few exceptions, you can program in Scala as if it were Java++. You won't take full advantage of Scala, but it can be done, and beginners sometimes do precisely that.