4 ms·

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

by gfodor 13y ago

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.

kvtrew76557 13y ago
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.
- gfodor 13y ago
  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.)
  - pkolaczk 13y ago
    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.
    - geoka9 13y ago
      > 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.
voyou 13y ago
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?
- pkolaczk 13y ago
  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.
  - kasey_junk 13y ago
    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.
- gclaramunt 13y ago
  http://docs.scala-lang.org/style/ http://docs.scala-lang.org/style/

by gfodor 13y ago

kvtrew76557 13y ago

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.

gfodor 13y ago
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.)
- pkolaczk 13y ago
  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.
  - geoka9 13y ago
    > 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.

voyou 13y ago

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?

pkolaczk 13y ago
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.
- kasey_junk 13y ago
  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.
gclaramunt 13y ago
http://docs.scala-lang.org/style/ http://docs.scala-lang.org/style/