3 ms·

Scala Best Practices: 1. Don't use Scala 2. Rule #1 is blatant opinion.

by jrobn 12y ago

bad_user 12y ago
Hello, I'm the author of this list, which I hope to grow to be something more than a single-author thing. Until now I've done non-trivial amounts of work on the job in Java, C#, C++, PHP, Python, Perl, Ruby, Javascript and Scala and I've played in my free time with half a dozen others, like Scheme, Clojure, Rust and Haskell. Take what you will from this, but I found Scala to be the most sane thus far. My opinion may change in the future, since I don't really have loyalty for programming languages, but regardless - I find it more constructive and better for your knowledge to verbalize your dislikes with clear arguments, maybe there's something you're missing.
- jrobn 12y ago
  I don't have any particular loyalty either. But, in my opinion, and after taking considerable time looking into scala, it's not my preferred language. The syntax can quickly devolve into soup. It's entangled with Java too closely (unlike say clojure). And last time I tried it compile times were...awful. All of this is my opinion and if scala works for you that's great. This guide is a great start for scala devs not to shoot themselves in the foot.
  - bad_user 12y ago
    > It's entangled with Java too closely (unlike say clojure) In some ways it is saner than Clojure btw ... For example Clojure devs pride themselves that their language doesn't have variables, but oh wait, it has Vars and function definitions must be dereferenced on call sites and those Vars can be modified wherever, whenever, as Clojure does not have the notion of "val" or "final". And of course you can do thread-local bindings for those Vars and that's why people have used it for things such as dependency injection, as a poor man's implicit arguments that do not appear in the function's signature. I don't even know if those persistent data-structures could be implemented in Clojure, as you need final's semantics for that and Clojure's data-structures are actually implemented in Java. I also like Clojure's protocols a lot, but they've got limitations as compared to type-classes from Haskell or Scala. For example in LISP lazy by-name parameters are modeled by means of macros, which is OK, but then if you want a macro as part of an interface, tough luck (this is a LISP vs ML thing). Protocols aren't doing interface inheritance either. For example in Scalaz (a Scala library bringing in many goodies from Haskell) the Monoid type-class inherits the interface of Semigroup, because a Monoid really is a Semigroup, I don't think anybody can argue against it and it isn't "complecting" anything. The process of learning Clojure has been very frustrating for me. I get it that the language doesn't have loops, I don't do loops in Scala either, but the absence of loops is the least interesting part of going functional - absence of local mutable state is not solving a big problem. The more interesting part for which I found little guidance is for modeling changes (in user input, or the various data sources that we use). In Scala we use more and more concepts and design patterns coming from Haskell, whereas I found Clojure to be maybe a little too pragmatic for my taste - for example Clojure devs aren't modeling Monads, a fact that is apparent starting with the standard "map", "filter" and "mapcat", builtin functions that work only on the builtin collections; Clojure doesn't even have some kind of Numeric protocol for building your own things that work with the numeric operators; and I hate things like the sorted-set using java.util.Comparable (what's up with the lack of abstractions in the standard library btw?). Of course I could go on - and I'm sure Clojure developers will jump to rectify me - Clojure has a lot of cool things in it and that's why I keep on learning, because some day I might have an aha moment, plus everybody should learn a LISP, just like everybody should learn a functional statically typed language (be it Haskell, Ocaml or Scala).
    - willismichael 12y ago
      I'm somebody who enjoys tinkering around with Clojure, I really wish that I could use it more at my day job, and I'm not particularly interested in Scala. Still, I have to thank you for this well thought out response. So often we have language wars that consist of two sides each with only a cursory knowledge of the other side's technology. I like how pragmatic Clojure is, but I think I can understand when you said that it's "maybe a little too pragmatic". The more I learn about Haskell (which is still very little, to be honest), the more I wish that Clojure had more in common with Haskell. On the other hand, the new work on transducers to me seems to solve some of the problems that you bring up about map, filter, etc., in that transducers work with any manner of data sources and sinks.
      - bad_user 12y ago
        Yeap, I also like the idea behind Transducers and I hope seeing it in other languages as well. As I said, Clojure has some really sweet things in it, which is why I keep tinkering with it as well, because I want this exposure. For example I like how Clojure people are doing what they call "light-weight data modeling". In Scala and Haskell we get too focused on types, sometimes we go overboard, forgetting that the data should stay reasonably decoupled from short-term business needs. So there's something really refreshing about Clojure's approach (which is in general LISP's approach to doing stuff). On the other hand I really like having a potent compiler that can help me deal with accidental complexity, which is why people will never agree on which is better, because it depends a lot on context (i.e. the kind of problems you're working on).
    - mjt0229 12y ago
      I definitely agree that it's really a great, mind-opening experience for developers to learn a LISP and a functional statically typed language. I feel like you might be missing some things about Clojure here, but I'm too inexpert at it to really fill you in. Anecdotally, I find that when I'm faced with a problem in Clojure, I spend a lot of time thinking about what to do, but rarely spend much time actually writing or modifying code. In Scala, I feel like the type system and more familiar syntax (just because of my own experience) lets me just dig in, but I probably do more actual editing/typing/work. I basically really like both languages, even though both have their annoyances and rough edges, and I wish I could use them both at work - Clojure for when it made sense, and Scala the rest of the time.

Scala Best Practices: 1. Don't use Scala 2. Rule #1 is blatant opinion.

by jrobn 12y ago

Scala Best Practices: 1. Don't use Scala 2. Rule #1 is blatant opinion.

Hello, I'm the author of this list, which I hope to grow to be something more than a single-author thing. Until now I've done non-trivial amounts of work on the job in Java, C#, C++, PHP, Python, Perl, Ruby, Javascript and Scala and I've played in my free time with half a dozen others, like Scheme, Clojure, Rust and Haskell. Take what you will from this, but I found Scala to be the most sane thus far. My opinion may change in the future, since I don't really have loyalty for programming languages, but regardless - I find it more constructive and better for your knowledge to verbalize your dislikes with clear arguments, maybe there's something you're missing.

jrobn 12y ago
I don't have any particular loyalty either. But, in my opinion, and after taking considerable time looking into scala, it's not my preferred language. The syntax can quickly devolve into soup. It's entangled with Java too closely (unlike say clojure). And last time I tried it compile times were...awful. All of this is my opinion and if scala works for you that's great. This guide is a great start for scala devs not to shoot themselves in the foot.
- bad_user 12y ago
  > It's entangled with Java too closely (unlike say clojure) In some ways it is saner than Clojure btw ... For example Clojure devs pride themselves that their language doesn't have variables, but oh wait, it has Vars and function definitions must be dereferenced on call sites and those Vars can be modified wherever, whenever, as Clojure does not have the notion of "val" or "final". And of course you can do thread-local bindings for those Vars and that's why people have used it for things such as dependency injection, as a poor man's implicit arguments that do not appear in the function's signature. I don't even know if those persistent data-structures could be implemented in Clojure, as you need final's semantics for that and Clojure's data-structures are actually implemented in Java. I also like Clojure's protocols a lot, but they've got limitations as compared to type-classes from Haskell or Scala. For example in LISP lazy by-name parameters are modeled by means of macros, which is OK, but then if you want a macro as part of an interface, tough luck (this is a LISP vs ML thing). Protocols aren't doing interface inheritance either. For example in Scalaz (a Scala library bringing in many goodies from Haskell) the Monoid type-class inherits the interface of Semigroup, because a Monoid really is a Semigroup, I don't think anybody can argue against it and it isn't "complecting" anything. The process of learning Clojure has been very frustrating for me. I get it that the language doesn't have loops, I don't do loops in Scala either, but the absence of loops is the least interesting part of going functional - absence of local mutable state is not solving a big problem. The more interesting part for which I found little guidance is for modeling changes (in user input, or the various data sources that we use). In Scala we use more and more concepts and design patterns coming from Haskell, whereas I found Clojure to be maybe a little too pragmatic for my taste - for example Clojure devs aren't modeling Monads, a fact that is apparent starting with the standard "map", "filter" and "mapcat", builtin functions that work only on the builtin collections; Clojure doesn't even have some kind of Numeric protocol for building your own things that work with the numeric operators; and I hate things like the sorted-set using java.util.Comparable (what's up with the lack of abstractions in the standard library btw?). Of course I could go on - and I'm sure Clojure developers will jump to rectify me - Clojure has a lot of cool things in it and that's why I keep on learning, because some day I might have an aha moment, plus everybody should learn a LISP, just like everybody should learn a functional statically typed language (be it Haskell, Ocaml or Scala).
  - willismichael 12y ago
    I'm somebody who enjoys tinkering around with Clojure, I really wish that I could use it more at my day job, and I'm not particularly interested in Scala. Still, I have to thank you for this well thought out response. So often we have language wars that consist of two sides each with only a cursory knowledge of the other side's technology. I like how pragmatic Clojure is, but I think I can understand when you said that it's "maybe a little too pragmatic". The more I learn about Haskell (which is still very little, to be honest), the more I wish that Clojure had more in common with Haskell. On the other hand, the new work on transducers to me seems to solve some of the problems that you bring up about map, filter, etc., in that transducers work with any manner of data sources and sinks.
    - bad_user 12y ago
      Yeap, I also like the idea behind Transducers and I hope seeing it in other languages as well. As I said, Clojure has some really sweet things in it, which is why I keep tinkering with it as well, because I want this exposure. For example I like how Clojure people are doing what they call "light-weight data modeling". In Scala and Haskell we get too focused on types, sometimes we go overboard, forgetting that the data should stay reasonably decoupled from short-term business needs. So there's something really refreshing about Clojure's approach (which is in general LISP's approach to doing stuff). On the other hand I really like having a potent compiler that can help me deal with accidental complexity, which is why people will never agree on which is better, because it depends a lot on context (i.e. the kind of problems you're working on).
  - mjt0229 12y ago
    I definitely agree that it's really a great, mind-opening experience for developers to learn a LISP and a functional statically typed language. I feel like you might be missing some things about Clojure here, but I'm too inexpert at it to really fill you in. Anecdotally, I find that when I'm faced with a problem in Clojure, I spend a lot of time thinking about what to do, but rarely spend much time actually writing or modifying code. In Scala, I feel like the type system and more familiar syntax (just because of my own experience) lets me just dig in, but I probably do more actual editing/typing/work. I basically really like both languages, even though both have their annoyances and rough edges, and I wish I could use them both at work - Clojure for when it made sense, and Scala the rest of the time.