Scala School(twitter.github.io) |
Scala School(twitter.github.io) |
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
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.
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...
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 second the reccomendation for Chuisano and Bjarnasaon's "Functional Programming in Scala".
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
I thought at first that it's been updated to some 2.1X version but, judging by the github repo, it hasn't been touched for years.
I'm still into alternative languages that run on the JVM...however I went and learned Go Lang in a weekend and it meets a lot of my needs for building out newer services.
Also, for my team the overhead of learning another JVM language (we already use Groovy quite a bit) didn't seem worth it in the end, even though I was a bit of a fan of the Scala idea for a few months.
I might still learn Scala some day, but we're not even on Java 8 at my current job, and that would alleviate a lot of my current Java grievances....
The way I learned was reading from front to back "The Scala Programming Language" by Martin himself and starting a new project completely in Scala (which I'm launching soon). I'm sure that's not the best approach for everyone but using Scala in a practical environment in an idiomatic way really helps ground the concepts which can at first seem intimidating and difficult to comprehend.
Mastery is a whole other story...
p.s. I recommend Scala Cheatsheet if you are just learning: http://docs.scala-lang.org/cheatsheets/
After that you could look into the spray.io source: it is quite complex, but the API it exposes and how extensible it is is amazing... They also coined the _magnet pattern_ which is pretty cool, and probably less abused than the cake pattern.
1. Watch a 1-hour video that teaches HelloWorld-stuff in Scala: https://www.youtube.com/watch?v=DzFt0YkZo8M
2. Then read first 45 pages (free sample) of my book https://leanpub.com/modern-web-development-with-scala
This book does an interesting thing:
> For each chapter (and occasionally for individual sections), I indicate the experience level. The chapters progress through levels A1, L1, A2, L2, A3, L3.
The number is the expertise level, from junior to expert; A stands for Application developer, L for Library developer.
I often find myself unsure about wheter a book or text is intended for the kind of user I am for whatever the topic is. Skimming through a book trying to identify what parts you should focus is not always easy.
Do you know of other books that do this kind of thing?
You keep telling developers that they are not good enough but they should rest assured that some smarter people are working on the problem and they'll come back with the answers.
When in reality, I think that all developers, when using a library, would like to think that they could have written it themselves, it they would have had the time or the interest.
You can probably list a large chunk of the big banks. I know quite of few of City of London's big investment banks all continually look for scala developers. In the same breath I would probably list the gambling companies which seems to be on scala bandwagon as well...
In the UK the public sector (GDS) are investing in scala based projects. E.g The HMRC have about 200 scala developers (me included).
Searching around the web I see other users including Netflix, Tumblr, Xerox, Sony, Siemens, UBS, Ask.com, AT&T, Bloomberg, IBM, Bank of America, Amazon, TomTom, NASA, Credit Suisse, Autodesk, Nokia, Apple, AOL, eHarmony, Gawker, HSBC, Klout, Novell, SAP, UBS, Allan Gray, Telefonica, Weather Channel, The Guardian.
https://www.quora.com/What-startups-or-tech-companies-are-us...
http://www.indeed.com/jobs?q=scala
https://www.quora.com/Any-companies-using-Scala-in-Berlin?sh...
Net-a-porter too.
The compile times are probably a bit slower than a standard java project, but not bad - something like 5-30 seconds depending on if it's a full rebuild.
I use android-sdk-plugin with SBT along with Scaloid. Wrestling with proguard to hide appropriate warnings can be a little bit of a pain, but even with no prior Android knowledge I was able to figure everything out.
Everything works as expected. There are a few minor issues where Java expects null and that's not normal Scala style, but other than that, nothing important to speak of. My binary builds to 4-5mb.
[1] https://play.google.com/store/apps/details?id=com.nutomic.en...
Indeed.com job data suggests that the answer to your suggestion is an obvious "No": http://www.indeed.com/jobtrends/scala.html
Lots of other very active open source projects (e.g. Kafka, Akka, Mesos) are written in Scala.
Hey, I'm interested in that! What proponent? What language? If it was Raffi Krikorian would you mind having a look at https://en.wikipedia.org/wiki/Scala_%28programming_language%... and perhaps update it?
No, we're not. Probably just some rumor.
And that's a shame, because Scala is language I love for writing a few dozen lines of code, and expressing a domain concept. It's a fantastic language for solving a homework problem set (and it's origins may be part of the reason why). But every library feels like it was concocted as a search for purity with zero attention given to the user experience.
The community is badly missing a DHH or Kenneth Reitz -- someone saying: "Ok, it's cool that we have this academic purity stuff and all that, now let's get serious about shipping software, and making tools that help people ship software." It's not that this view needs to dominate a community, but right now it's thoroughly unrepresented in Scala land.
Just the infix operator syntax plus implicits can lead to stack trace confusion all around
And try understanding some of the type signature funkiness! It can be difficult
I definitely think that Scala is a harder language than most to grasp, if only for the feature support not seen since C++
I often end up making a "super elegant" version and, almost invariably, end up scrapping it for a (hopefully...) more bread-and-butter version, which may or may not incorporate some lessons learned from the concise version. Even if not, it's not all loss, because coming up with the elegant version is intellectually rewarding and super fun.
Add lots of in-line (not just scaladoc) comments helping the reader along. Extract vals for intermediary steps. Variable naming is always important, but even more so when you don't explicitly declare the type.
Play framework itself is pretty straightforward with not much in the way of advanced Scala concepts (implicits are probably the most you have to understand). Testing is baked right in and they even handle setting up the application for you in your fixtures.
Coming from the .NET world, it was a huge relief to see that I could just use activator/sbt to compile and publish my artifacts on a build server, just as it works on my local machine. Setting up continuous integration was super easy in comparison to what Microsoft has historically offered (but looks like they're improving with .NET Core).
As for other frameworks and libraries, you may be right on a number of them, but I wouldn't say that all or even most Scala libs are designed to be pure. I have a number of dependencies that are very easy to reason about even if you aren't aware of advanced features.
(Also my old company, PagerDuty. Wee bit lower profile than the other three, admittedly.)
Edit: And to clarify. I think part of this is because there's a serious case of imposter syndrome among Scala developers. I feel like much Scala code I've written would make legitimately useful open source projects, but I'm not really happy with the interface, and I feel the innards could be a bit cleaner, so I don't release it, because it feels just hackish enough that I trust it myself, but don't want the outside world depending on it. I'm probably not the only one here.
What about Spark, Kafka and Akka? I actually think the Scala community is working very hard to improve user experience, it's just that they don't do in the expense of soundness.
As a ruby -> Scala developer, I don't miss DHH.
On the Akka side: Try picking up Akka-HTTP and use it to write an API client (which seems like something one would do with an HTTP library). There are lifecycle issues that are undocumented, and it really feels like this wasn't a considered use case throughout the entire development process.
I don't necessarily think DHH is right on everything, or even most things. But I do think it's valuable having a voice saying: "Does this help us ship" or "We're adding this feature because it's solving a real problem we encountered multiple times during the development of real software, and it would be nice to have a standardized solution".
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.
The type signatures can be complex but only when you're doing complex things with them - if you stick to doing the kind of things you'd do in another language you'll get similarly simple types.
You're absolutely right that the native stack traces are poor, but you can use tools that understand them better, e.g. Takipi.
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 had one conversation 5 years ago with Raffi about which language something should be built in. He advocated strongly for me doing it in whatever I felt made the most sense. I think this is typical of his management style -- which is to establish goals and let the people responsible for achieving those goals work out how to do it. Raffi had left the company by the time the JVM standardization discussion happened.
Oh, no, I was asking mostly as a noob. I've since decided to have a go at learning Scala, and your answer reinforces that decision.
There are a few "copy-cats", but it shows that the creators lacked the experience and time to really think about how to achieve coherence of language constructs and how different parts play together.
In addition to that, Scala has a huge head-start and is quite stable and mature. The language is expressive enough that I can't envision many features which couldn't be expressed with the existing language. For example, Scala.js didn't require any language extensions at all.
[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.
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.
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.
[1] I acknowledge this is debatable, but it's an opinion I agree with.
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.
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.
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
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.
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...
It's true SBT is not suitable for beginners. Regrettably, neither is Maven. I don't know which tool is...
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
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.
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.
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.