I like Scala, but I'm a bit troubled by this comment in the blurb
The talk will briefly cover the conceptual hurdles that the team experienced when changing from a purely object-oriented mindset to a more functional approach.
I think herein lies the problem with Scala, while it's great to do some functional programming, the functional element is largely idiomatic and not enforced.
You can easily rewrite a Java application in OO Scala with mutable state. Or you can do it with immutable objects and so on but I don't like the way that it's so easy to combine the two that it kinds of turns into a mess if you're not an expert in either camp.
The Java interoperability is a nice touch but again, it mixes the two paradigms for me
Unless I'm just doing it wrong? I'm not sure but for me I'm always wondering what the "right way" is in Scala and it irritates me. Don't get me wrong, it's a great language and much better than Java (a lot better) but it sometimes feels like a mix of ideas.
That's why I'm learning Haskell now, to try and embed myself in a world that's purely functional and not a half way house.
Agree with your premise.
Disagree with your conclusion.
What you've effectively called a bug is in fact a feature.
The whole point is to take the proper-superset aspect of Scala ( ie. every java OO pgm will qualify as a scala pgm ), and then gradually migrate the OO parts to a functional paradigm over time. This allows you to retain giant Java codebases that are in production currently, while gradually moving away from Java by taking these baby steps.
One very practical example - there's a boatload of concurrent code in Java out in production. Unfortunately, threads are not in the average programmer's toolbox. Multithreading, mutexes, locks, schedulers etc used to be stuff that OS guys who wrote IPCs studied. Now all of that has unfortunately become part of the Application Programmer's toolset, simply because Java exposes the threading API & makes it insanely easy to create, suspend, group & destroy threads. So the application programmers go wild & create all manner of multi-threaded Java apps & when stuff gives inconsistent results ( same method accessed by multiple threads, no lock etc. ), they wonder why. With Scala, you can rewrite just those bits using the Actors framework & not worry about relatively low-level constructs like mutexes.
Oh yes, I definitely agree that Scala has a much better approach to threading with Actors and so on and there's definite improvement over Java with lamdas and functions as first class citizens.
What I'm moaning about is, for me, I tend to like doing things "the right way" (i.e. The Scala Way) and it irritates me that there's nothing there to enforce you to do that.
That isn't necessarily a problem with Scala per se, it's an issue with myself, but it's one of the reasons why I've stopped doing development in Scala for now and going down the Haskell route.
Who knows, perhaps once I've got some decent Haskell behind my back, I might be able to transfer those ideas over to Scala and write Scala how I'd want to write it.
Agreed. Scala is a (relatively) messy language because it tries to solve the real-world problem of bringing working devs into the functional fold. Haskell was the laboratory, Scala is the factory.
It's a multiparadigm language. There's nothing wrong with that. You should have a feel for which style is predominant in the codebase, or, if the project is new, which style is preferred by your fellow developers. If there is more than one stylistic choice in a given situation and you don't have a strong preference for one or the other, then according to your own judgment it hardly matters which one you choose.
I'm actually going from Haskell to Scala and have to say part of me really likes not being forced to be pure all the time even if it feels a little dirty. Also for some projects the object oriented nature of Scala feels more natural. That said I still like Haskell better overall as a language (largely thanks to its purity).
I was working for SAIC at the time of the talk, but I've since moved on to another company. I suspect SAIC now has at least one opening for a Scala programmer. ;-)
The talk will briefly cover the conceptual hurdles that the team experienced when changing from a purely object-oriented mindset to a more functional approach.
I think herein lies the problem with Scala, while it's great to do some functional programming, the functional element is largely idiomatic and not enforced.
You can easily rewrite a Java application in OO Scala with mutable state. Or you can do it with immutable objects and so on but I don't like the way that it's so easy to combine the two that it kinds of turns into a mess if you're not an expert in either camp.
The Java interoperability is a nice touch but again, it mixes the two paradigms for me
Unless I'm just doing it wrong? I'm not sure but for me I'm always wondering what the "right way" is in Scala and it irritates me. Don't get me wrong, it's a great language and much better than Java (a lot better) but it sometimes feels like a mix of ideas.
That's why I'm learning Haskell now, to try and embed myself in a world that's purely functional and not a half way house.