Relevant: "Functional Programming Principles in Scala" starts in 4 days on coursera, which was created by the author of scala. https://www.coursera.org/course/progfun
Scala 2.11.0 Release Notes
51–60 of 77 posts
Re: Scala 2.11.0 Release Notes
#52Re: Scala 2.11.0 Release Notes
#53Earlier quoted context omitted.
async/await and removal of the case-class/tuple 22 field limit are the big ones I think. (edit: the limit is still in effect for Tuple apparently. Only removed for case-classes.) In database (or Actor ask) heavy code dealing with a lot of Futures async/await has the potential to fairly significantly influence code style. for-comprehensions often don't cut it when you're dealing with a Future[Option[User]] and need to…
> for-comprehensions often don't cut it when you're dealing with a Future[Option[User]] and need to pull in their assigned roles from a Future[Seq[Role]]. If you aren't familiar with Monad Transformers, yes, it can be tricky. However it's trivial using an Option monad transformer (OptionT[Future,A]]) to have the same semantics. for { user Look at http://github.com/scalaz for already built Monad Transformers (Either/S…
I like the async/await stuff. Especially after attending the ScalaDays presentation on it. The idea that it produces a state machine in the background feels like it's very easy to reason about.
I actually (personally) find for-comprehensions the least useful feature of Scala probably. They rarely produce the most readable code IME with just a couple transformations in play, and it's not often I find myself dealing with compatible types in the more complex cases.
So I guess I consider async/await the readable/prettier alternative to direct mapping that for-comprehensions mostly fail to deliver on. for-comprehensions are probably Scala's second biggest wart IMO (not harmful, more just mostly useless). YMMV. Sort of like `__DATA__` or `=BEGIN/=END` in Ruby.
Re: Scala 2.11.0 Release Notes
#54Earlier quoted context omitted.
> for-comprehensions often don't cut it when you're dealing with a Future[Option[User]] and need to pull in their assigned roles from a Future[Seq[Role]]. If you aren't familiar with Monad Transformers, yes, it can be tricky. However it's trivial using an Option monad transformer (OptionT[Future,A]]) to have the same semantics. for { user Look at http://github.com/scalaz for already built Monad Transformers (Either/S…
I've used ScalaZ a bit (don't remember exactly why, but something to do with Future transformations), but I found it to crush the compiler. Especially combined with IntelliJ. I like the async/await stuff. Especially after attending the ScalaDays presentation on it. The idea that it produces a state machine in the background feels like it's very easy to reason about. I actually (personally) find for-comprehensions the…
You may not see the advantage of for comprehension for sequencing a few operations over Future. However, when you have a large number of calls you have to sequence along with filter (which for comprehension can do) it's indispensable.
Check this out: https://www.youtube.com/watch?v=MHw-dDxC8Z4
Re: Scala 2.11.0 Release Notes
#55Earlier quoted context omitted.
Have you seen the follow up course "Principles of Reactive Programming" too? It's also by Martin Odersky, but also with Erik Meijer and Roland Kuhn. https://www.coursera.org/course/reactive
I took both classes, but I really didn't care for Reactive as much. The first Coursera class really turned me on to the elegance of functional programming with Scala's unique type system, but much of that elegance is really lost dealing with some of the structures introduced in the second class, in my opinion. Reactive is split into three "subclasses". The beginning part, taught again by Odersky, was a pretty useful…
Erik Meijer's lectures -- at least in the first iteration of the course; maybe they've gotten better -- were riddled with errors, confusing exercises, and an overall lack of coherence with the rest of the course. It pains me to say this because Erik seems like a cheerful guy and I really wanted to like his lectures, but they are a mess.
Even Roland Kuhn's lectures, which are pretty good and a lot clearer than Erik's, didn't manage to sell reactive programming to me. One glaring problem was that the actor model seems to throw away most of Scala's static type checking, which we had learned on the previous functional course. Suddenly it's ok to pass whatever message to actors in a way that seems closer to dynamic typing.
Re: Scala 2.11.0 Release Notes
#56Relevant: "Functional Programming Principles in Scala" starts in 4 days on coursera, which was created by the author of scala. https://www.coursera.org/course/progfun
This is a great course, love it and recommend any developer taking it. Having that said, if all you want is to "switch from imperative language X to Scala", (e.g. from Java) and you want to learn first how to do the "non functional" stuff in Scala, then keep in mind that this course is teaching functional programming first, Scala later. You can do (if you want) very imperative and object oriented style of coding in S…
Re: Scala 2.11.0 Release Notes
#57Re: Scala 2.11.0 Release Notes
#58I want to be writing scala so bad, but there doesn't seem to be any jobs in my area. Are there any scala specific job boards out there?
Re: Scala 2.11.0 Release Notes
#59Relevant: "Functional Programming Principles in Scala" starts in 4 days on coursera, which was created by the author of scala. https://www.coursera.org/course/progfun
A nice complementary one on coursera is proglang, taught by Dan Grossman (at least the first run was), uses racket/sml/ruby. Very nice, with a focus on interpretation and comparison points between paradigms.
Re: Scala 2.11.0 Release Notes
#60Earlier quoted context omitted.
I really hope that you guys aren't planning to pull a Python 3 with the 3.x series. We're using Scala quite heavily in our production systems and the naysayers will have a great "I told you so" moment of we end up sitting on a ton of critical Scala code which no longer compiles in a future version.
We've been thinking about this a lot, even though Scala 3 is a couple of years out. Our current thinking is to bring the 2.x series as close to 3.0 as possible, with the remaining breaking changes being compelling enough to switch. Please share your ideas/concerns over at scala-internals! Part of the solution will be tooling, and the team at EPFL has started prototyping a migration tool that generates patches to turn…