5 ms·

I did the two FP courses from Mr. Odersky using Scala as the main language and then continued playing with the language for small experiments. While the langua

I did the two FP courses from Mr. Odersky using Scala as the main language and then continued playing with the language for small experiments. While the language is awesome in general, I would not recommend it at work.

wtetzner 12y ago
Any particular reason you wouldn't recommend it at work?
- deleted 12y ago
  [deleted]
- dmacvicar 12y ago
  As the author of this post mentioned the culture of the Java developers, the "architect" thing and the frameworks, Scala has its own similar problems: it attracts a group of academics on type systems and creates over-engineering in a completely different direction. Also, while I think Scala is simple at its core concepts and syntax, it gets complex because it has too many features and tries to support all features present in other programming languages. Why do you want structural typing there?. Also, I hated sbt.
  - frowaway001 12y ago
    > it gets complex because it has too many features and tries to support all features present in other programming languages Which things do you have in mind? > Why do you want structural typing there? Isn't that a simplification? Instead of saying "here are types which you can use as e. g. parameter types, and here are types which you can't use (like in Java)", it says "all types work the same way".
    - dmacvicar 12y ago
      I understand what it is. I don't see the need of it if you already have a class-based system. Go uses structural typing. But it is the only thing they have. Rust has traits, and it is the only thing they have. I can't think now of more stuff but I remember you could even write xml in the language.
      - frowaway001 12y ago
        > I don't see the need of it if you already have a class-based system. Like in Java? new Object() { void foo() {}}.foo(); // Works Ooops. The point about XML is so stale already that I won't even bother commenting on it.
        dmacvicar 12y ago
        You seem to be stuck in the topic of how useful structural typing is. Which I agree with.
        frowaway001 12y ago
        Eh what? No. I couldn't care less about structural types. I care about simple, consistent rules. "X is a type, you can use it wherever you want" is one. "X is a type, but there is also Y, which you can't really express in position A and B unlike X, but can only use it if you carefully avoid doing things #1 to #4" isn't one.
        dmacvicar 12y ago
        I agree with partly with you. I don't think it helps for consistency when you have to ask yourself why some functionality is defined in terms of a trait if it could be defined in terms of the structural type and just providing the methods would be sufficient.
- dmacvicar 12y ago
  Oh, I also disliked implicit conversions a lot. I considered them a wart at some point. Made everything hard to read and reason about. Almost every other way of "extending" a type would have worked better in practice eg. Xtend’s Extension Methods.
  - frowaway001 12y ago
    Extension methods have mostly the same drawbacks as implicits, but none of the advantages. It's not like Scala developers didn't know extension methods before designing implicits. Instead, they tried to come up with a more useful, principled way, which also covers a lot of the stuff which is hardcoded and implemented ad-hoc in other languages (like implicit conversions in Java). In the end, I think they made the right call: - Implicit parameters are the basis for abstractions which unify the "strategy pattern" of OO languages with FP's typeclasses, - implicit classes provide extension methods, but are better in pretty much every regard (higher reusability, less error prone) and - implicit conversions cover the ad-hoc conversions everyone takes for granted, without having to hard-code these hacks into the language (e. g. don't like Java's/C#'s/... implicit convert-everything-to-String conversion? Don't import it in Scala).
hibikir 12y ago
The secret of Scala is that it can be used in a wide variety of ways by a wide variety of teams. Yes, you can end up hiring people that would rather work in Haskell, or those that hate the type system and would rather code in Clojure. I've seen people that attempted to make Scala look like Java, or even Javascript. My current team, working in Scala, has had plenty of people like that. But the fact that you can get too academic with Scala does not mean you have to. Some parts of our codebase really work better with said academic style, so we keep them. In others, the type system was used in ways that did not make any sense, and were rewritten. Scala's strength is precisely that it can look like anything you want. If you are not interested in said freedom, then sure, avoid Scala at work. But for us, using the style that works better in each part of the system without actually having to change languages is extremely powerful.
- Shorel 12y ago
  I will steal that argument for D.
  - dmacvicar 12y ago
    I think D has a completely different of issues starting by a) small community b) reference compiler is not fully free software c) free compiler (ldc) is not finished d) very few people work on both compilers, etc.
    - Shorel 12y ago
      IMHO, D is a better teaching language than Python and a better systems language than Java. I wish Android was written in D. I can't enjoy using a language with significant whitespace or extremely forced OOP. The core language is good enough already, and better than most. They way it defines functional purity is the way it will be taught in universities in the future. It also embraces concurrency, and this will only become more important as computers get more processors. What it lacks is libraries, therefore you are right about point a. The lack of a library like Ogre3D is an issue. The lack of an equivalent to jdbc for D is an issue. That's the reason for me to mention D here, the more exposure it gets, the better. But about points b and c, no way. You deliberatedly ignore the third compiler GDC, which integrates the open source D front end with GCC and produces faster binaries than DMD.

wtetzner 12y ago

Any particular reason you wouldn't recommend it at work?

deleted 12y ago
[deleted]
dmacvicar 12y ago
As the author of this post mentioned the culture of the Java developers, the "architect" thing and the frameworks, Scala has its own similar problems: it attracts a group of academics on type systems and creates over-engineering in a completely different direction. Also, while I think Scala is simple at its core concepts and syntax, it gets complex because it has too many features and tries to support all features present in other programming languages. Why do you want structural typing there?. Also, I hated sbt.
- frowaway001 12y ago
  > it gets complex because it has too many features and tries to support all features present in other programming languages Which things do you have in mind? > Why do you want structural typing there? Isn't that a simplification? Instead of saying "here are types which you can use as e. g. parameter types, and here are types which you can't use (like in Java)", it says "all types work the same way".
  - dmacvicar 12y ago
    I understand what it is. I don't see the need of it if you already have a class-based system. Go uses structural typing. But it is the only thing they have. Rust has traits, and it is the only thing they have. I can't think now of more stuff but I remember you could even write xml in the language.
    - frowaway001 12y ago
      > I don't see the need of it if you already have a class-based system. Like in Java? new Object() { void foo() {}}.foo(); // Works Ooops. The point about XML is so stale already that I won't even bother commenting on it.
      - dmacvicar 12y ago
        You seem to be stuck in the topic of how useful structural typing is. Which I agree with.
        frowaway001 12y ago
        Eh what? No. I couldn't care less about structural types. I care about simple, consistent rules. "X is a type, you can use it wherever you want" is one. "X is a type, but there is also Y, which you can't really express in position A and B unlike X, but can only use it if you carefully avoid doing things #1 to #4" isn't one.
        dmacvicar 12y ago
        I agree with partly with you. I don't think it helps for consistency when you have to ask yourself why some functionality is defined in terms of a trait if it could be defined in terms of the structural type and just providing the methods would be sufficient.
dmacvicar 12y ago
Oh, I also disliked implicit conversions a lot. I considered them a wart at some point. Made everything hard to read and reason about. Almost every other way of "extending" a type would have worked better in practice eg. Xtend’s Extension Methods.
- frowaway001 12y ago
  Extension methods have mostly the same drawbacks as implicits, but none of the advantages. It's not like Scala developers didn't know extension methods before designing implicits. Instead, they tried to come up with a more useful, principled way, which also covers a lot of the stuff which is hardcoded and implemented ad-hoc in other languages (like implicit conversions in Java). In the end, I think they made the right call: - Implicit parameters are the basis for abstractions which unify the "strategy pattern" of OO languages with FP's typeclasses, - implicit classes provide extension methods, but are better in pretty much every regard (higher reusability, less error prone) and - implicit conversions cover the ad-hoc conversions everyone takes for granted, without having to hard-code these hacks into the language (e. g. don't like Java's/C#'s/... implicit convert-everything-to-String conversion? Don't import it in Scala).

hibikir 12y ago

The secret of Scala is that it can be used in a wide variety of ways by a wide variety of teams. Yes, you can end up hiring people that would rather work in Haskell, or those that hate the type system and would rather code in Clojure. I've seen people that attempted to make Scala look like Java, or even Javascript. My current team, working in Scala, has had plenty of people like that. But the fact that you can get too academic with Scala does not mean you have to. Some parts of our codebase really work better with said academic style, so we keep them. In others, the type system was used in ways that did not make any sense, and were rewritten. Scala's strength is precisely that it can look like anything you want. If you are not interested in said freedom, then sure, avoid Scala at work. But for us, using the style that works better in each part of the system without actually having to change languages is extremely powerful.

Shorel 12y ago
I will steal that argument for D.
- dmacvicar 12y ago
  I think D has a completely different of issues starting by a) small community b) reference compiler is not fully free software c) free compiler (ldc) is not finished d) very few people work on both compilers, etc.
  - Shorel 12y ago
    IMHO, D is a better teaching language than Python and a better systems language than Java. I wish Android was written in D. I can't enjoy using a language with significant whitespace or extremely forced OOP. The core language is good enough already, and better than most. They way it defines functional purity is the way it will be taught in universities in the future. It also embraces concurrency, and this will only become more important as computers get more processors. What it lacks is libraries, therefore you are right about point a. The lack of a library like Ogre3D is an issue. The lack of an equivalent to jdbc for D is an issue. That's the reason for me to mention D here, the more exposure it gets, the better. But about points b and c, no way. You deliberatedly ignore the third compiler GDC, which integrates the open source D front end with GCC and produces faster binaries than DMD.