Hacker News Reader

Comment by gfodor | Hacker News Reader

Several years ago I picked up Odersky's book. I got a few hundred pages in, considered the types of problems I had encountered in my career so far, and decided life is too short to be spending my time learning some hyper-complex programming language that seemed, like C++, to seem unable to say "no" to introducing complexity where it would provide minimal upside in Getting Shit Done.

Instead, I learned Clojure. I use Ruby, the epitome of comfortable languages, for most things, and when the hard problems come up, I use clojure. My next major scientific computing problem, rare as they are, will be in Julia instead of Matlab for prototyping and java for production. Scala seems to be the hard language for easy problems. No thanks.

View on HN

Unlike you I finished reading the Odersky book and am very easily "Getting Shit Done" much faster than I ever did in Ruby. It did take effort to learn the language, but it was worth it. Having apps running an order of magnitude faster with better response times is just icing on the cake. Perhaps consider getting a gentler introduction to the language, the Odersky book is rather long and goes into excessive detail about obscure corners of the language you will seldom ever see in a production system.

I've been in enough code reviews of Scala that did simple things like string processing that inevitably got sidetracked into a navel gazing discussion about type theory, pattern matching, and functional programming to not go near the language again anytime soon. You simply couldn't understand the code without understanding tons of incidental complexity about the language.

The Clojure community has its navel gazing of course, but every time I've been exposed to some crazy idea in that community it was always through the lens of providing real leverage for real problems. Most of the time when I've dealt with people trying to explain concepts to me for Scala code, I've walked away wondering what the point of it all was (beyond the fun Computer Science.)

Maybe you should first learn the language? It would save your time, really. You must know the language to understand programs in that language. Simple as that.

If you don't want to learn FP or you don't value type-safety, Scala is simply not for you.

> Maybe you should first learn the language?

Is it actually possible? I've been using Scala for over a year and still have to spend more time learning about the language than writing code in it.

Scala reminds me of C++ too, but it's impressive that, in a mere 10 years, Scala has achieved all the multi-paradigm incoherence it took C++ 30 years and tortuous backwards compatibility constraints to attain.

Actually, I spent some time over the weekend trying to get familiar with Scala by using it to solve some Project Euler problems, and it was pretty entertaining. Still, the language's bias towards there being more than one way to do anything does worry me; it does seem that the kind of mutually incomprehensible code bases the OP talks about are likely. I would assume that, like C++, you need a strong style guide for a Scala project laying down which parts of the language you are going to use. Does anyone have any recommendations for guides on writing comprehensible, maintainable Scala?

Multi-paradigm incoherence? There is a huge difference between throwing multiple features/paradigms into one language (as C++ does) and integrating them so that they are orthogonal and don't get into your way (as Scala does). The integration part is the hardest thing and Scala designers did the great job there, assuming the constraints that were given.

Scala does have some rough edges but they are not the kind of C++ ones, and even the complexity of the most powerful features (implicits) is very controllable.

Seriously - which features would you like to remove from Scala? I'm really curious because I don't find any redundant ones. All are pretty complementary and very useful.

I'm not sure I'd remove any, but there is a huge incoherence in what is and is not "idiomatic" scala.

The most obvious example that comes to mind is whether you should use mix in traits or type classes for api design. Another one is the "magic-ness" of map/flatmap/filter for for comprehensions but no way to extend that for Functor/Monad/Monoid type classes.

Finally, the Scala community is a huge advocate of Algebraic Data Types yet don't support Disjoint types making any sufficiently complex system cumbersome to model as an ADT.

http://docs.scala-lang.org/style/

Thanks, that's really useful. It answers a lot of the irritating little questions that Scala's flexible syntax gives you, like whether or not to use dots for method invocation. I see that Twitter has a document on the best ways to write Scala, which looks interesting: http://twitter.github.io/effectivescala/

Reply on news.ycombinator.com