As an aside, part of why Odersky's course work so well is that it's influenced by SICP (Structure and Interpretation of Computer Programs) by Abelson and Sussman.
First of all, there's a lot of choice in how to organize a solution to a given problem. Say you've just started to grasp the idea of algebraic data types and manipulations thereof. You might still find it hard to know how to apply it in a given situation, because there are several ways to do it [1]. As you gain experience, you start to get a feel for which option is more appropriate in a given situation.
Secondly, a lot of the basic concepts of Scala are super general, so you can sometimes see language elements used in ways that are surprising. In my experience, you start to build a mental model for actual usage of language elements, but it's still intimidating at first. See this question and answer about the `object` keyword [2].
But then, even as you master the language, there are all sorts of little gotchas you learn to navigate. This is true of any language of course, but it can be more frustrating when you're operating at a higher level of abstraction. The Dotty project seeks to rewrite the Scala compiler in line with an improved framework of some of the more innovative type system features of Scala. I think it's ultimately going to lead to a better foundation with less gotchas. But it's still a long time coming.
Oh yeah, and the `implicit` system is a beautiful concept, but pretty unique to Scala, and intimidating at first.
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 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
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...
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.
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.
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.
IntelliJ ships with Scala support doesn't it? And the eclipse-based scala-ide comes with maven support, no? So it's just:
- Install scala-ide
Even if you do combine those steps, there are still further steps a user would have take after they install everything. You described the set up as just being as simple as "Push the button, choose the scala template, give it a groupId and artifactId, done". However, I don't think it is that simple. As far as I'm aware, no IDE will give you a Scala project with a Maven POM. You can choose to create a 'Scala project' or you can create 'Maven project'. You can't create a 'Maven Scala project'. So you will have to figure out how to add Scala support to Maven manually. Also, you may have to figure out how to let your IDE know that your project is both a Maven project and Scala project.
When you hit "new maven project" you choose a template (archetype). Some of those are already set up for Scala. No?
> Also, you may have to figure out how to let your IDE know that your project is both a Maven project and Scala project.
Scala-ide (or any eclipse-based system with the m2eclipse-scala plugin) will detect that automatically.
It's true SBT is not suitable for beginners. Regrettably, neither is Maven. I don't know which tool is...
I particularly liked the "should", "must", "where", etc. DSL. If I remember correctly, this style of testing comes from the Rails community. I guess it's a matter of taste, but I would definitely recommend it to newbies.
The point of DSLs is that they feel natural for their job, regardless of how they are implemented. You can use a DSL without understanding how it works "behind the scenes". To me, ScalaTest with WordSpec seems more natural than JUnit, and at least my own experience shows I'm right: I've successfully introduced it in a team of newbies.
What's to understand? You write a method in plain old java, and the framework runs it.
> The point of DSLs is that they feel natural for their job, regardless of how they are implemented. You can use a DSL without understanding how it works "behind the scenes".
The point of "embedded DSLs" is that they follow the ordinary rules of the host language. Otherwise they're no better than an external config file, Cucumber-style (which some people apparently like, but I find utterly unusable).
> at least my own experience shows I'm right: I've successfully introduced it in a team of newbies.
When they make a change to code that breaks a test, and you're not there, how long does it take them to understand what's gone wrong? That's the real test of a test framework, and IME ScalaTest does very badly on it.
Yes, when a WordSpec test starts failing, junior devs know how to fix it without my assistance. I haven't noticed any difference in dev effectiveness between ScalaTest and JUnit.
To use Cucumber you have to understand a whole new grammar. To use ScalaTest you have to understand relatively obscure parts of Scala (implicit conversions, "word word word" style method calls, by-name parameters, ...) - or else treat it like a config file and learn a whole new grammar. To use JUnit you just write plain old Java/Scala.
[1] I acknowledge this is debatable, but it's an opinion I agree with.
For me Scala has a little bit more upfront cost to learning (but if you come form Java and C#, it should almost be second nature) but the things you can do with it once you get a hold of it is amazing. Go (for me) on the other hand is very easy to write simple Hello World programs, but if you want to do complex applications, it has much more down payment.
There's a also a problem that most powerful Scala techniques are there "by accident" [1] and unlikely will (or should) appear in official guides.
Also I disagree that "Scala for impatient" is good book for start. It make me feel Scala is dump of random unrelated features, it's very easy to disappoint.
However, despite all above I think Scala is definitely worth to invest some time. It made all other learning curves (for languages, techniques, concepts) more flatten.
[1] https://meta.plasm.us/posts/2015/07/11/roll-your-own-scala/
The rift pollutes and bloats your dependencies, and causes problems with unexpected behavior and unreadable documentation. Trying to shoehorn libraries into my projects that pollute their code with these new standard libraries with lazy functionality and its accompanying monadic bullshit[1] is a huge thorn in my side. I wish the typelevel crowd would just accept the fact that Scala is an ML language, and adopt Frege instead if they can't handle that.
[1] https://existentialtype.wordpress.com/2011/05/01/of-course-m...
Newbies to Scala, especially those coming from Java, couldn't care less whether it looks more like ML or like Haskell. Both languages would be alien to them. Robert Harper's "Existential Type" blog is hardly aimed at the average programmer.
I'm pretty sure this is not the worst part about Scala :)
That said, I've had plenty of success applying Scala at work without bringing in overt category theoretical concepts into my codebases. Scalaz remains very much an opt-in community.
I find learning Haskell definitely does this and although I can't do the same things in C# a lot of the ideals (immutable state, keeping things separate and simple as possible) not having a complex unpredictable state to manage with lots of 'actors' trying to mangle with it.
Haskell has design patterns which are only what in the OO GoF context you couldn't even dream of. The free monad interpreter pattern alone can probably achieve what all of the other patterns do and then a few more light years. It is amazing stuff and to bring a single drop of this greatness back to the mortgage-paying languages is nice to do. Rx anyone?
However, I do feel like you're right. For instance, the section on XML literals probably should have been avoided, since that feature doesn't fit nicely with the rest of the language and most of the time isn't necessary to know.
You'll see yourself wanting a number of features you'd expect in a modern language, and end up discovering the motivation and approach behind how Scala or Haskell work. Operator overloading (ad-hoc polymorphism) and modular implicits are two of the ones I come across the most.
I have always felt that Haskell and Scala (and OCaml sorta) are way too complicated. However, spending time learning Standard ML and the foundations of this family have been really illuminating - you'll discover how powerful Haskell and Scala really are. For an analogy, you can think of switching to FreeBSD from Linux to get closer to Unix roots so you can understand Linux (the historic decisions and reasons) better.
Take a look at the /r/sml wiki [0] if you need help getting started.
As someone with a lot FP experience having to work with some Java libraries, getting started with the "This is more pleasant than Java" style of Scala takes very little time. To the point where the typing it saves you in a week roughly equals the cost of skimming through Scala for the Impatient to get started.
Granted the "This is more pleasant than Java" style of Scala is the equivalent of the "C with Classes" style of C++. But as far as getting started learning Scala I've found that it is quicker than most FP languages to just dive in and get things done, refactoring as you learn more idiomatic approaches to problems.
For me the big risk for Scala that I've seen is the same as C++: The language is so big and so flexible that you can have two developers write the same programs and get results that are difficult to see as being the same language. And because you can get stuff done without writing idiomatic code it's very easy to stop learning and be quite far from what experienced Scala developers would consider a Scala programmer.
I never thought I would like statically typed languages, but now I don't know how I can live without them.
Scala is also more functional than Ruby or Python. I use it in a hybrid OO/Functional style. I probably lean 80-90% functional though.
As for people complaining it being hard to read, I disagree. Sure, some people try to be clever and play the, "how much can I reduce this code down to as few lines as possible" game. But if you break things out and not chain too many combinators or use too many symbolic operators, it can be readable. I don't find it any more difficult or easy compared to any other languages out there. It's just how you write it.
I think the biggest hurdle is to find a good mentor to give you the ah ha! moment when learning Scala (or any other functional language). I don't think many people can learn it by themselves. But once someone shows you how you can write your app in a more functional way, you begin too see some of the benefits of FP.
In terms of elegance and succinctness, Scala is somewhere in the middle between Java's bureaucratic verbosity and Python's terseness.
Ruby forces new lines for many expressions that Scala doesn't. (Think class with accessors vs a typical case class.) as things get more advanced, Scala allows you to express things that can be very difficult or awkward in Ruby. Like function composition, currying, pattern matching.
There's not really a case where a Ruby program will typically be shorter than a Scala program (well, excluding imports since there's no shared global namespace in Scala), even if you're avoiding typelevel style programming.
"Java Python programs are generally expected to run slower than Java programs, but they also take much less time to develop. Python programs are typically 3-5 times shorter than equivalent Java programs."
I think Python performance wise a less attractive options than Java or Scala. At least according to the authors. Development time is a different question.
I second the reccomendation for Chuisano and Bjarnasaon's "Functional Programming in Scala".
[1] https://github.com/jruby/jruby/wiki/DifferencesBetweenMriAnd...
The whole point of Kotlin is that it does not need its own ecosystem - it is intended to be used seamlessly (unlike Scala or Ceylon) and, like, today with all existing Java libraries and frameworks. Sure, more idiomatic solutions would always be nicer to work with (and they would probably appear at some time), but you do not need to wait for them - just go with your existing codebase. As for the tooling, Kotlin IDE support way better than Scala's. It is not surprising, however, due to the fact that main language kontributors are JetBrains.
Hmm ok, that does seem to provide equivalent functionality. Is it implemented?
> in Scala I cannot simply use interfaces with bounded type parameters without some dirty hacks, just because compiler will generate weird errors and/or incorrect bytecode
Example? I've never seen that happen and I've done a fair bit of mixed Java/Scala.
> The whole point of Kotlin is that it does not need its own ecosystem - it is intended to be used seamlessly (unlike Scala or Ceylon) and, like, today with all existing Java libraries and frameworks.
Scala was intended for that at first. It turned out to be a bad approach. Interfaces are important, library APIs have a surprisingly far-reaching impact on the code that calls them.
> As for the tooling, Kotlin IDE support way better than Scala's. It is not surprising, however, due to the fact that main language kontributors are JetBrains.
That one specific tool perhaps. In terms of the much larger ecosystem of third-party JVM tools, Scala support is naturally more mature.
As for your other point, tying Java interop with existential types is pretty absurd.
I'd say both Kotlin and Scala are about equally good when it comes to interoperating with Java.
So do you really think Kotlin is used 4x as much as Java? Or is it possible that this is a pretty poor measure of actual usage?
> As for your other point, tying Java interop with existential types is pretty absurd.
Only as absurd as Java. Java libraries contain methods that return existential types (e.g. List<?>) everywhere. If you can't represent that type in your type system (note that it's not the same type as List<Object>), you can't have full Java interop.
I don't know what libraries you are looking at but these are extremely rare these days. At least for the popular ones. You seem to be talking about Java like it was written eight years ago.
The terseness is probably what makes the learning hardest, but there is utility there, because you don't have to focus on the boilerplate, but can see more of the algorithm at once.
Also, anything that moves you more towards fp is a good thing, because again, when you start to get it and manage to apply it in the correct way, it is extremely elegant and composable.
For a startup, you don't want to your programmers to learn cause its a heavy investment in terms of time. Adding and subtracting works just fine so they often advocate that route. You definitely get to the end goal, but when it comes to learning new things, you are never certain what the outcome will be.
On a separate note, I leared scala and clojure nearly at the same time and I'd say that learning clojure actually helped me grow in scala as well.
edit: Reply fail. This was a response to hythloday -----
Even if someone (a fan of Scala) doesn't believe it's that hard, the fact that this comes up again and again should really be an indication that it's truly an issue for people new to the language [1]. It is difficult, and it is intimidating. I would not have learned Scala if it weren't for the extrinsic push of learning it for a job.
[1] This applies to other things that people new to a language constantly complain about: Python's problem with v2 and v3, etc.
1. organise open source projects around Scala
2. organise and develop online teaching
Here is what worked for me to learn the basics well: I started off with the book 'Scala for the Impatient', the first half of the book is freely available. I then used Scala School as a list of topics and researched on each using Google. StackExchange has some amazing answers that helped me a lot.
Free part of Scala for the Impatient: http://fileadmin.cs.lth.se/scala/scala-impatient.pdf