Another resource for learning Scala is Werner Hett's 99 problems in Scala: http://aperiodic.net/phil/scala/s-99/. I tried it after doing Odersky's Scala class (https://www.coursera.org/course/progfun). If you've done the class, it's not a bad way to get some practice with constructs that weren't particularly useful in the class.
If you haven't done the class, the problems are simple enough that you could probably learn scala by just working through the problems and googling for relevant syntax. They start to get more involved around problem 50, but, by that point, you'll have a good grasp of the syntax.
If you want to try them out, I have unit tests for the problems I've done (only up to 58, so far) here: https://github.com/danluu/ninety-nine-scala-problems. The tests are pretty rudimentary; I'm sure there's at least one github repo that has more comprehensive tests, but I looked around at tens of repos of other people's tests on github when I first started and I didn't find much.
P.S. If you're in Austin, there's a Scala group that gets together that isn't a meetup, and hence, isn't findable from Graham's link in step 9: https://groups.google.com/forum/#!forum/austin-scala-enthusi.... The majority of the folks there actually use Scala in real production code.
the Coursera course "Functional Programming Principles in Scala" just ended but they're keeping all the content online until the next run of the course
the lecturer, by the way, is the designer of Scala
Not convinced on Scala being a good language to use for multi-person projects anymore. Same as with C++, you would have to heavily push code reviews and coding standards (disallow everything from that link?) in order to have even slightly maintainable code...
That's only a superficial impression and I recommend you give it a second chance.
If you're worried about the equivalent of "open classes" from Ruby, first of all in Scala implicit conversions are always scoped and statically type-checked, and second, that article is out of date.
Can't you use traits and type member to simulate open classes? At least, this used to be possible, but then the compiler stopped letting us define type member bounds recursively around the time I left the project.
Implicit conversions are a poor substitute to real open classes.
I don't think this is a good guide for Learning Scala.
The Introduction from scala-lang.org and a Tour of Scala are not good introductions. They are meant as a TL;DR that will leave you scratching your head and reading the list of features without the larger context of a language is an awful way to learn about that language.
IntelliJ IDEA with the Scala plugin is a good IDE, but the article should have included a link to the Scala-IDE plugin for Eclipse. It's not friendly for beginners to make them install a plugin, which is why Typesafe is already providing a download of a completely configured
Eclipse here: http://typesafe.com/stack/scala_ide_download
Also, when starting out with a language I would rather use a plain text editor and the compiler directly, because complicated tools bring with them complicated problems ... Hello World with just the compiler is just one text file that you can directly execute, versus the notion of whatever a project is in an IDE. And you should start with the REPL anyway.
"Scala for Java Refugees" is an article series that's out of date and not that good frankly. There already is a comment here from somebody saying he was scared when he saw in that series the usage of implicit conversions - a feature that in Scala 2.10 is considered experimental, for really advanced use-cases and that has to be enabled manually, as for most purposes there are better solutions available - but on the other hand, the context of a feature matters a lot. Implicit conversions are great for dealing with the "expression problem" and through their means, Arrays (a fundamental JVM data-structure with a broken interface) behave like plain Seqs in Scala, while Strings are considered to be lists of chars (as in Haskell or Lisp).
I didn't like Alex Payne's "Programming Scala" book. It's boring, it's poorly organized and it's out of date - for instance a big part of it involves dealing with Scala's Actors, but Scala's Actors were terrible, which is why in Scala 2.10 the implementation in the standard library gets replaced with Akka, which is the defacto standard anyways, but it also has a slightly different API and concepts. Actors are also the kind of powerful construct that's not easy to tame, being an awful way to start learning Scala ... before Akka Actors, look into Scala's Parallel collections, or into Akka's Futures and Promises or into ScalaSTM.
Speaking of Parallel Collections and Futures and Promises, no mention of Scala's Documentation project?
A much better introduction to the language is "Scala for the Impatient", a book that wasn't mentioned and one third of the book (enough to get you started) is available from Typesafe's website: http://blog.typesafe.com/free-pdf-from-typesafe-scala-for-th...
You also cannot write about learning resource, without mentioning "Programming in Scala" by Odersky, a wonderful book also meant for human beings. Its only problem is that it's a tome of information and you may not have the patience for that, but it's not a hard to digest book so if you've got the time and patience, then this is THE book you should read: http://www.artima.com/shop/programming_in_scala_2ed
And you must also mention "Scala in Depth" by Joshua Suereth, which is like the equivalent of "Effective Java", a ~ 300-pages book you definitely must read once you're done with "Scala for the Impatient": http://www.manning.com/suereth/
On the other hand the Coursera Course taught by Odersky on Function Programming is awesome. I've took it and it was worth every minute of it.
> You also cannot write about learning resource, without mentioning "Programming in Scala" by Odersky, a wonderful book also meant for human beings. Its only problem is that it's a tome of information and you may not have the patience for that, but it's not a hard to digest book so if you've got the time and patience, then this is THE book you should read: http://www.artima.com/shop/programming_in_scala_2ed
+1
The book is huge, but that's more to do with the fact that Scala is one kitchen sink of a language than the writing.
The book is huge because it goes to great length at explaining good design practices, the rationale of features in the language and how they are implemented under the hood, not mentioning functional programming and OOP concepts ... many of the exercises from SICP also appear in this book.
It's a complete reference to the language and I've never seen a reference that isn't huge.
Scala is not a kitchen sink. The number of features included is quite small and for the most parts orthogonal, but because those features are very powerful, their combination is a little overwhelming for beginners. This happens in every language that's not meant for assembly lines. Even for Java, learning is not complete without reading another book on patterns and another one on effective usage of it.
They also spend time on external libraries, such as Akka. Part of the appeal of Scala is that its design for extensibility can make libraries feel like part of the language and Akka is one of the best examples of this (and indeed was designed with input from Odersky as a replacement for native Scala actors).
It really is a great book. I never thought I would read this type of technical book on a Kindle but it reads really easily and I have read far more of it than I would on paper (even though paper is better for a reference book, I don't want to read a big heavy book in bed but I really do with the Kindle).
Totally forgot to mention the standard library, which is getting quite big. Just yesterday I read the chapter on parser combinators. Good book :)
Although I haven't encountered mentions of Akka in Programming in Scala by Odersky. There is a chapter on Actors but I skipped it and went straight to http://akka.io
Btw, for technical books I'm using an iPad, as you can read PDFs with colors on it and it's easier to go back and forth between pages and zoom-in, zoom-out, being closer to the way I normally read technical books. I then put PDFs I buy in Google Drive and open them in Acrobat Reader, also available on iPads.
So don't buy eBooks from Amazon, prefer the original publisher instead, to also get a DRM-free PDF in addition to the Kindle format (you never know when you'll use it).
Lua's design philosophy is to keep it simple, which works well for their user base and domain of use (lots of embedding in games as a scripting language). Scala is not meant to be a simple scripting language, its more like a power language. Both are very good languages.
Implicit conversions are not considered experimental in 2.10. Also they are not disabled by default in 2.10. They may disabled in future versions. Scala 2.10 will just give you a warning if you use implicit conversions without explicitly enabling them.
Sorry, I never got much into Scala 2.10, I'm on 2.9.2 and this impression I got from Odersky's pieces of opinion about it, as from what I remember the initial proposal was for disabling those features, instead of plain warnings, but I guess that changed and it's my fault for not double-checking before giving it as argument (as a disclaimer I'm not an authority on the matter, I'm a rookie too).
I've explained in another comment below what I meant when using the word "experimental". Indeed I don't remember M Odersky ever using this word, but he did use "cutting edge" when giving the rationale for SIP 18.
There are some interesting resources in the above comment. However, by criticising all the introductory material and replacing it with nothing, it misses the point of having a guide to learning Scala. The "plan" it suggests is essentially this:
1. Ignore the freely available, expert-written introductory material on the internet;
2. Don't use tools that will highlight simple mistakes for you quickly;
3. Buy this Scala book and read it;
4. Buy this other (very similar) Scala book and read it;
5. Buy this more advanced Scala book and read it.
Leaves me wondering whether bad_user works for a bookshop.
Apart from it's not all accurate. Implicits have been part of Scala from the start and are used heavily throughout all the core libraries and many large projects so they will not be going anywhere... the changes in 2.10 allow you to use implicit classes on top of the current uses (and using implicit parameters is considered good practice), though they generate a compile time warning if you don't import implicitConversions.
Implicit conversions are used heavily, they aren't going anywhere, but their usage is taking a back seat to other means for achieving the same thing, like context bounds, which is a cheap(er) and safer mechanism for type-classes (jargon doesn't help in learning sadly, type-classes are like open interfaces, such that you can make any existing type implement it - think about adding Ordering to an existing type, like integers and then using it in a sort() that then works on all types with Ordering implemented).
Also implicit classes are only a subset of implicit conversions. Implicit classes are like "extensions methods" from C# (only a little more potent, in the true Scala fashion :)). Their usage is simpler, reasoning about them is simpler, if the implicit class inherits from AnyVal, then performance is better since the compiler will not create wrapper objects, and so on.
It's a subset because implicit conversions allows for viewing any type A as any other type B. This is powerful, but also has gotchas that people fall into ... for one, these conversions are not transitive. So if type A can be viewed as type B and type B can be viewed as type C, that doesn't make type A viewable as type C. To make this work you have to deploy really complicated logic to help the compiler do what you mean and it turns out that in most cases that's not what you really wanted to do anyway. It's also unclear how adding transitivity will interact with other features or what gotchas that may have, while making the compiler slower and more complicated, but put plainly - this is not the kind of feature that does the right thing.
I said "experimental", because the feature itself is a feature where the bounds of what you can and cannot do aren't at all clear and require extensive knowledge of the compiler's decision process, which means it's ripe for replacement as soon as something better comes along, equally powerful, but without the gotchas. This hasn't happened yet, but it probably will, though as a disclaimer I'm also a beginner so I have no way of knowing that.
Either way, I'm happy that Scala is not a frozen language and the team working on it is trying to find ways to safely evolve it. It's pretty bad having to live with broken features for legacy reasons.
I also said "implicit conversions", not implicit parameters. All languages have implicit parameters, even if we are talking about the Singleton pattern / global state or dependency injection.
Scala's mechanism for implicit parameters is better, because it's light, lexically scoped, overridable and compile-type checked, having the side-effect that it scares beginners away since those implicits end up in function definitions ... but I think that's better than carrying around implicits of which you don't know about and anything that helps with referential transparency is Good.
Anyone has a good summary of Scala vs Go? I know a bit of the former (with typeface for high-concurrency) and was wondering what Go might have to offer.
Go is far simpler and smaller. You can learn go in an evening. It comes with a nice standard library, but the ecosystem isn't as lively as what you get on JVM. But if you have native library for a task, using it from Go is straight forward. Web frameworks are in their infancy. Writing network programs in Go is a pleasure. You write code in the natural way(no callback spaghetti) using go-routines, and go takes care of making it non-blocking. The go oop is structural sub-typing based. Though it might seem lacking at first glance, it's actually quite wonderful.
Bottom line: Learning go is far simpler than learning Scala. Read and write some programs, and make up your mind. Here is an example you should read through to get a feel of the language.
Yeah, I like modern languages that don't need an IDE or other complicated mechanisms to get started. Go seems to have made a lot of good design choices too.
Scala takes more time to learn, but targets a different audience. Scala runs on the JVM which lets you leverage Java libraries etc. For long-running apps Scala is usually faster than Go, but will use more memory than Go.
Well, both have good support for concurrency through Actor implementations. They have a little bit similar syntax, both have a basic level of type inference. After that, pretty much everything is different about them.
There are really too many differences to consider, but some things come to mind first. I apologize for the problems in this description. At some point I may write a detailed article with examples, so any feedback on inaccuracies in this would be helpful.
Go is designed as a minimalist language. This has some benefits and drawbacks.
Scala is design as a language that is small but very extensible, making for a much larger programming system that you have to learn to use effectively.
Scala has lots of advanced language features from functional programming. Idiomatic Scala uses these features extensively. Go has closures, but not any other features for functional programming - for example it has no immutable data structures, no pattern matching, no tail optimization.
Scala has advanced features from object-oriented programming; everything is an object but basic types are compiled to JVM primitives where possible. It has traits/mixins which provides a way to implement multiple interfaces but they can also provide implementations which makes it a lot easier to provide default implementations so that a previously-written class can be declared with that Trait even though it does not know how to satisfy the interface. Go has a simplified and in some respects novel approach to OOP. It has interfaces and duck-typing which may be familiar but you really have to learn "the Go way" to understand what is happening with features like embedding which may seem to have some superficial similarity to inheritance in Java/C#.
Both provide a means to multi-plex Actors (Goroutines) onto threads. Using the Akka package with Scala provides an Actors implementation which will work with both in-process and out-of-process Actors. Google's netchan package was dropped before 1.0 and I do not know if there is any productive development being done in this direction. So to scale goroutines out of a single-process you'd need to use RPC, zmq or some other low-level socket approach.
So far, the Scala code I've looked at in different open-source projects seems fairly consistent. While the language-space seems big, I have not seen the fragmentation problems that some people may have predicted. With Go there is little chance of this, often there is only one reasonable way to do a given thing.
Go compiles to native code but the compilers are optimized for very fast compile times - the code produced is 2-3x slower than Scala in doing math-intensive benchmarks. For most apps we'd actually write, I'll bet they are pretty close. Go statically links a runtime and has garbage collection. It starts up VERY fast compared to any JVM application.
The two problems I have with Scala are: (1) it tries to be too much by allowing optional types and the clarity of the code suffers- either embrace duck typing or don't, (2) Play v2 killed all chance of it becoming a decent web developer's go-to language.
For those that are learning Scala just for the hell of it, great. But, don't intend to make a career out of it unless you've checked into other languages first, like Ruby, Python, Haskell, Go, Clojure, etc.
1) The typing isn't actually optional, you just don't have to write it as long as it can be inferred, which is the best of both worlds. If you're ever unsure of which type it is just mouse over in the ide, or specify it and wait for an error
1. I'm not sure I understand the complaint about arguments. From you example it looks to me like the problem is that Scala requires type declarations and supports default arguments. I don't understand how this is worse than the equivalent Java example. I also don't understand how the Ruby version is inherently better. The only difference seems to be static vs. dynamic typing.
2. I don't understand how Play 2 screwed over Scala developers. It seems like Play 2 is much better for Scala developers. Scala is now a first class supported language instead of just an add on module. I also don't understand how Play 1 was 'the' thing that was bringing web developers to Scala. It wasn't in any way a core part of the framework. It was just something you could optionally use. Scala is something you could optionally use in any Java web framework.
> "For those that are learning Scala just for the hell of it, great. But, don't intend to make a career out of it unless you've checked into other languages first, like Ruby, Python, Haskell, Go, Clojure, etc."
I did, and am currently making a career out of Scala.
> "Play v2 killed all chance of it becoming a decent web developer's go-to language"
We're quite happy with Play2, don't know why anyone would even consider picking Play v1 over it...
(1) when speaking of dynamic typing versus static typing, it's not a black and white issue - it's actually full of color, but if it helps, you can think of it as an axis where languages are the dots.
Clojure is a dynamic language, but Ruby is more dynamic than Clojure, hence the machinery for running on the JVM is more complicated, which is why Clojure has better performance. Java is considered a static language, but because it is able of runtime introspection, runtime code generation and runtime dispatch, it is much, much more dynamic than a language like Haskell - which for the moment is the most static language out of all languages known to the mainstream.
The issue of dynamic versus static is also not an issue of specifying types. In fact it has nothing to do with that. The real difference comes from what the compiler does at compile-time. By definition compilers using static typing will reject pieces of code that are correct if it cannot prove that the types used support the operations you say they support. With dynamic typing on the other hand you can basically make shit up and have it executed and fail at runtime instead of compile-time ... but where the boundaries lie between compile-time and runtime differs from language to language, a language being considered either static or dynamic depending on which side the balance is inclining ... and btw, ironically languages like Java are somewhere in the middle.
I'm seeing programmers making a confusion between duck-typing and structural-typing or type-inferencing - like all the time, even though these concepts are fundamentally different, which shows unfamiliarity with either one or the other, but mostly with duck-typing, as duck-typing is really NOT about the lack of manifest-typing, which is just a side-effect.
(2) Play v2 is not a language. I personally don't like it, as I don't like big frameworks, being more the kind of person that prefers smaller libraries that compose well.
But Play v2 brings with it some really cool tools - statically type-safe templates, Iteratees for dealing with Comet/WebSockets, etc... if you evaluate Play v2 for building simple apps, like freaking blogs and such, some of the abstractions may seem over the top, but those abstractions are there to help you with other things you may need, as Play's philosophy is to be a "scalable" framework, while still being easy to use, just like Scala is a scalable language. The amount of pain you have to endure if you want to deal with Comet/Websockets in popular Ruby/Python frameworks is really breathtaking, while Play makes all of that easy and natural.
Play v2 is more immature than Play v1, but it has better foundations and is just getting started. Play v1 wasn't going anywhere the way it was and sometimes major architectural changes are needed, even though the spirit remains the same - Rails 3 is also architecturally different from Rails 2 and 1, as the needs of web developers evolve and many companies haven't migrated.
> unless you've checked into other languages first, like Ruby, Python, Haskell, Go, Clojure
I second that argument. You should pick languages that are more suitable to personal style and more optimized for the problems you work on - however you have to be careful about it, as the metrics commonly used (e.g. beauty of syntax) are not so important as the resulting artifacts and also, language choice may be important, but is not as important as everything else (tools, libraries, ecosystem, community, etc...).
Also, mentioning particular languages as having priority over Scala is weird. I have problems believing that you learned all of those languages you mention. If you specified 2, maybe 3, then I'd believe you, but why give advice for preferring languages you don't know?
In particular, if you like Ruby and Python, you simply cannot mention Haskell in that same sentence as Haskell is everything that Ruby and Python aren't. And if you like Haskell, then placing Ruby and Python in that same sentence is some kind of abomination.
You might check out the book "Seven Languages in Seven Weeks" which has a chapter on Clojure (and Scala, Ruby, Io, Prolog, Erlang and Haskell too). I took a class that used it and I thought the format was quite good.
Thanks for mentioning the book, after reading your comment I looked for the book, and it looks pretty good, probably the next book I'm going to buy. Thanks!
No. I mean, you should learn what you want to learn; there is no strict set of new technologies that you should learn and others that you shouldn't. Sorry we can't provide you with better guidance.
If you haven't done the class, the problems are simple enough that you could probably learn scala by just working through the problems and googling for relevant syntax. They start to get more involved around problem 50, but, by that point, you'll have a good grasp of the syntax.
If you want to try them out, I have unit tests for the problems I've done (only up to 58, so far) here: https://github.com/danluu/ninety-nine-scala-problems. The tests are pretty rudimentary; I'm sure there's at least one github repo that has more comprehensive tests, but I looked around at tens of repos of other people's tests on github when I first started and I didn't find much.
P.S. If you're in Austin, there's a Scala group that gets together that isn't a meetup, and hence, isn't findable from Graham's link in step 9: https://groups.google.com/forum/#!forum/austin-scala-enthusi.... The majority of the folks there actually use Scala in real production code.