

How We Thought We Could Use Scala and Clojure and How We Actually Did - ahmicro
http://ontwik.com/clojure/how-we-thought-we-could-use-scala-and-clojure-and-how-we-actually-did/

======
djhworld
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.

~~~
dxbydt
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.

Here's a simple example:( <http://bit.ly/kOczaj> )

~~~
djhworld
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.

------
bokchoi
The original blog posting for the video:

[http://blog.fogus.me/2011/01/10/dancing-monkey-gibbers-on-
ab...](http://blog.fogus.me/2011/01/10/dancing-monkey-gibbers-on-about-scala-
and-clojure/)

------
lpolovets
If someone watches the video, please comment on whether it was worth 30
minutes of attention. =)

~~~
fogus
I personally found it well worth the 30 minutes. And then some!

~~~
mark_l_watson
Hello Michael - heard in your talk that you work at SAIC - good company, I was
there off and on for 20+ years.

~~~
fogus
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. ;-)

------
abecedarius
I wish the abstract gave some hint of what conclusions were reached.

