Scala's Maturing Community(skipoleschris.blogspot.com)
skipoleschris.blogspot.com
Scala's Maturing Community
http://skipoleschris.blogspot.com/2013/12/scalas-maturing-community.html
2 comments
I would humbly disagree with your second assessment on two fronts:
1. It's not that hard to get people using immutable data structures. You just have to remind them during code reviews. It's not that "var" doesn't have its place (within function calls but not escaping them.) It's that it'll take someone a week or two to really get comfortable with immutability.
2. Akka, can come after they learn about Futures and how to use them in for-comprehensions. Once they make that mental leap and have adopted #1, other things fall into place with much more ease.
Granted, neither #1 or #2 comes without someone who has done some Scala lending a guiding hand. If it's purely Java devs showing other Java devs, then they will be doing what C programmers did when switching to C++ (writing Java in Scala.)
1. It's not that hard to get people using immutable data structures. You just have to remind them during code reviews. It's not that "var" doesn't have its place (within function calls but not escaping them.) It's that it'll take someone a week or two to really get comfortable with immutability.
2. Akka, can come after they learn about Futures and how to use them in for-comprehensions. Once they make that mental leap and have adopted #1, other things fall into place with much more ease.
Granted, neither #1 or #2 comes without someone who has done some Scala lending a guiding hand. If it's purely Java devs showing other Java devs, then they will be doing what C programmers did when switching to C++ (writing Java in Scala.)
The irony is that using "immutable data structures" like an immutable map requires using "var" more often than if a mutable structure was used (which could just be assigned to a "val").
The elegance of immutable local variables is interesting, and it can be argued that functional programming style can lead to more robust coding.
However, there is an orthogonal advantage of immutable (or persistent) data structures, namely simplify sharing of state in concurrent programming, and this works well regardless on where the "handle" of a data structure is stored.
However, there is an orthogonal advantage of immutable (or persistent) data structures, namely simplify sharing of state in concurrent programming, and this works well regardless on where the "handle" of a data structure is stored.
That persistence can be quite expensive for non-linked collection classes (like say lists, maps), finger trees non-withstanding; though at least in 2006, such immutable collection classes were implemented as being mutable with some safe sharing for performance reasons.
These decisions must be made pragmatically and being ideological about it isn't very useful. Scala is a great language for both functional and imperative programming when you need it.
These decisions must be made pragmatically and being ideological about it isn't very useful. Scala is a great language for both functional and imperative programming when you need it.
This is no longer the case, in Scala 2.8 they were replaced with persistent collections based on the work by Phil Bagwell, afaik they are faster than the old implementation.
Didn't the old implementation have issues when you started sharing these maps between threads?
I haven't used Scala since 2006, so I'm not sure; I always avoided immutable collections (beyond lists sometimes) in favor of mutable ones given the nature of my work then (IDE development). I suspected they weren't thread safe, but Martin was confident at the time.
No it doesn't. If you think that way then you have more to learn on how to structure your code.
Oh believe me, I do; it involves calling a spade a spade! When you need mutable state, go straight to a mutable collection to get it. It is only some people just learning Scala that get confused about the issue and we wind up with immutable collections being coupled with mutable vars (incidentally, the immutable collections were optimized for this case circa 2006 using safely shared mutable state, not sure what is done now).
I understood something different from the article. The author seems to be saying it may be unwise to believe everyone else is doing FP with immutability (which is understood in the article to be The Right Thing) because programmers less experienced with Scala, especially those coming from Java and OOP, may not be aware FP is the recommended way (or that they still "haven't made the transition" into thinking the FP way). Not because there are cases where the OO style makes more sense.
Impressive turnout at Scala eXchange, both in terms of registrants (400 or so attendees) and speakers (Simon Peyton Jones, Jonas Boner, Victor Klang, David Pollack, etc.), not to mention the venue, a big time conference (for Scala) on all fronts.
Scala.io in Paris was quite small in comparison; however, the after party in Paris (free drinks all night long, woo hoo ;-)) blew away the staid affair in London (single round of drinks on the house, some inane blah, blah question/answer session re: the same old, why is Scala so complex, followed by most everyone leaving).
Anyway, the conference itself was well worth its weight in pounds, hope to make the trip again next year, this time with Scala 2.11 in full swing, good times ahead.
Scala.io in Paris was quite small in comparison; however, the after party in Paris (free drinks all night long, woo hoo ;-)) blew away the staid affair in London (single round of drinks on the house, some inane blah, blah question/answer session re: the same old, why is Scala so complex, followed by most everyone leaving).
Anyway, the conference itself was well worth its weight in pounds, hope to make the trip again next year, this time with Scala 2.11 in full swing, good times ahead.
I haven't been to any Scala events yet though I did watch a number of the videos from Scala Days 2013 and I'm hoping to attend 2014 in Berlin.
What exactly made London so bad?
What exactly made London so bad?
Nothing was bad about the London conference, quite the contrary.
Was just pointing out the difference in the after party between scala.io Paris and scala eXchange London, not a big deal at all, both of the _conferences_ were great.
Was just pointing out the difference in the after party between scala.io Paris and scala eXchange London, not a big deal at all, both of the _conferences_ were great.
The article does raise a good point about immutability and functional programming. It's something that shouldn't be assumed, especially for Java developers making the transition (there seem to be plenty of Java developers switching to Scala lately). Scala combines functional and OO programming, and there are use cases where OO style coding makes more sense. Martin Odersky even mentioned that in a presentation a while back. Immutability and asyc are very powerful, but not everyone uses these approaches. Selling folks on Scala is one thing, getting them to make a jump to an (awesome) library like Akka is a bit too big a jump to make in one step.