[lmm]

You can be just as productive as you would be in Python/Ruby/JavaScript/Go from day 1 in Scala - usually the same code will work, with minor syntax differences and maybe the occasional type annotation. The difference is there's more to learn in Scala that will make you even more productive, but that should never be a downside, and you don't have to learn it if you don't want to.

[argonaut]

You are really stretching things by saying you'd be productive on day 1. Scala code has an immediate upfront complexity cost.

[mafribe]

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.

[argonaut]

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.

[mafribe]

   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.

[goldbrick]

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.

[lmm]

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.

[JackFr]

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.

[lmm]

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.

[eeperson]

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

[lmm]

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

[the_af]

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

[lmm]

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.

[mafribe]

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.

[the_af]

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.