11 ms·

There are much less complex but precisely as powerful languages out there (like Haskell). Scala's crazy amount of syntax is what makes me avoid it, not unlike C

by lucian1900 13y ago

There are much less complex but precisely as powerful languages out there (like Haskell). Scala's crazy amount of syntax is what makes me avoid it, not unlike C++.

trailfox 13y ago
Does Haskell let me use the many Java libs that are used extensively internally in many organizations (including mine)?
- lucian1900 13y ago
  No, but that still doesn't excuse Scala's syntax.
  - trailfox 13y ago
    We haven't had issues with Scala's syntax. Point is that Haskell isn't a viable option for most use cases.
    - deleted 13y ago
      [deleted]
- virmundi 13y ago
  Terrible, terrible answer if you are mostly doing functional Scala. I've got a blog post that deals with this. Tl;dr: Java libs are good along as they are thread-safe or immutable; if they're not, you're looking at horrible side-effects where there shouldn't be any. http://talesfromannoyance.blogspot.com/2012/05/why-im-looking-at-erlang-over-scala.html http://talesfromannoyance.blogspot.com/2012/05/why-im-lookin... If you want reuse, you need to look at taking those parts and wrapping them up in SOA.
  - trailfox 13y ago
    For many use cases OO Scala works just fine, functional code used where it makes sense. Our goal is to integrate with existing systems, not to seek purely functional code as a goal in and of itself.
    - virmundi 13y ago
      I agree with the concept. My concern is what happens as your team grows to include others whose Scala background is more functional. There is a sense that they should be aware of the old way your code base is put together. Unfortunately things could go awry when they code new functional based code expecting functional based input. Don't get me wrong, I like Scala. You just really have to watch its dual paradigm behavior when dealing with Java code
pkolaczk 13y ago
Uhm, although I admit Haskell is a powerful language, there are quite a few things that Haskell can't express as clearly as Scala. E.g. Haskell can't express nominal subtyping.
- papsosouid 13y ago
  Huh? How is: Monad m => Int -> m Bool not nominal subtyping in action? Any type you create a Monad instance for will be accepted, so subtyping. You have to actually make it an instance of Monad, it can't just have the structure of a monad, so nominal.
  - pkolaczk 13y ago
    Is it polymorphic?
    - papsosouid 13y ago
      Wait, are you saying you don't know anything about haskell at all? Then why are you making claims about what it can't express?
      - pkolaczk 13y ago
        Right, I don't know much about Haskell (not actively programming in it), but I know that Haskell was not designed with OOP in mind and things like polymorphic nominal subclassing are not first-class there. There are also some things that Haskell's type system can't do e.g. the nice thing that Scala does with fold/map/reduce always returning the right type, even if it has to be a different type than the type of the source collection. I'd like to be proven wrong, Haskell is on my list of next languages to learn well ;)
        papsosouid 13y ago
        I don't even know what anything in your post means. You are correct that haskell is not an OOP language. You are very confused beyond that point.
happy_dino 13y ago
> Scala's crazy amount of syntax Could you expand on that a bit?
- lucian1900 13y ago
  First, I must say that I like the idea of the language. It has ADTs (case classes) and typeclasses (traits), a bit of type inference, can run on Android and isn't Java. It's just the baroque syntax that bothers me. It starts from this [1]. Then there's case classes, _, optional everything (forgetting = in a function def can make it mean something else), the currying syntax [2] (sometimes it needs an arbitrary _ to break ambiguity), the imports (especially renaming), arbitrary rules on whether construction needs "new" or not, etc. The fact that [3] is possible even though Scala is not an almost-no-syntax language (like Lisps and Haskell) concerns me. And it even has macros, but all of its very many language features aren't implemented as macros :( 1. http://en.wikipedia.org/wiki/Scala_(programming_language)#Syntactic_flexibility http://en.wikipedia.org/wiki/Scala_(programming_language)#Sy... 2. http://brenocon.com/scalacheat/ http://brenocon.com/scalacheat/ 3. http://blog.fogus.me/2009/03/26/baysick-a-scala-dsl-implementing-basic/ http://blog.fogus.me/2009/03/26/baysick-a-scala-dsl-implemen...
  - happy_dino 13y ago
    - [1] comes down to the idea of not having to build two separate concepts (namely, operators AND methods) with different syntax, different declaration styles, different parsing rules, ... into the language. Scala has only methods (which can have a “symbolic” name). The usual precedence rules are based on that name. - case classes: I love them. - _: The underscore has one meaning, “there is something, but I don't care about the name”. Super simple. - forgetting = in a function def can make it mean something else: I agree, it is very error-prone. As far as I know, there are some proposals to get completely rid of procedure syntax. - currying syntax: PinS has a pretty good explanation why it works that way. It is certainly not perfect, but less error-prone than alternatives. - the imports (especially renaming): Many languages have this feature and I have not seen any issues with it. - arbitrary rules on whether construction needs "new" or not: No. The rule is that you always need new to construct an instance. -[3]: You can do crazy stuff in every language. Have a look at functional code written in Java. - And it even has macros, but all of its very many language features aren't implemented as macros: No. In a sense, ALL features are implemented via macros, because the compiler API and the reflection API (macros) are pretty much the same underneath.

There are much less complex but precisely as powerful languages out there (like Haskell). Scala's crazy amount of syntax is what makes me avoid it, not unlike C++.

trailfox 13y ago

Does Haskell let me use the many Java libs that are used extensively internally in many organizations (including mine)?

lucian1900 13y ago
No, but that still doesn't excuse Scala's syntax.
- trailfox 13y ago
  We haven't had issues with Scala's syntax. Point is that Haskell isn't a viable option for most use cases.
  - deleted 13y ago
    [deleted]
virmundi 13y ago
Terrible, terrible answer if you are mostly doing functional Scala. I've got a blog post that deals with this. Tl;dr: Java libs are good along as they are thread-safe or immutable; if they're not, you're looking at horrible side-effects where there shouldn't be any. http://talesfromannoyance.blogspot.com/2012/05/why-im-looking-at-erlang-over-scala.html http://talesfromannoyance.blogspot.com/2012/05/why-im-lookin... If you want reuse, you need to look at taking those parts and wrapping them up in SOA.
- trailfox 13y ago
  For many use cases OO Scala works just fine, functional code used where it makes sense. Our goal is to integrate with existing systems, not to seek purely functional code as a goal in and of itself.
  - virmundi 13y ago
    I agree with the concept. My concern is what happens as your team grows to include others whose Scala background is more functional. There is a sense that they should be aware of the old way your code base is put together. Unfortunately things could go awry when they code new functional based code expecting functional based input. Don't get me wrong, I like Scala. You just really have to watch its dual paradigm behavior when dealing with Java code

pkolaczk 13y ago

Uhm, although I admit Haskell is a powerful language, there are quite a few things that Haskell can't express as clearly as Scala. E.g. Haskell can't express nominal subtyping.

papsosouid 13y ago
Huh? How is: Monad m => Int -> m Bool not nominal subtyping in action? Any type you create a Monad instance for will be accepted, so subtyping. You have to actually make it an instance of Monad, it can't just have the structure of a monad, so nominal.
- pkolaczk 13y ago
  Is it polymorphic?
  - papsosouid 13y ago
    Wait, are you saying you don't know anything about haskell at all? Then why are you making claims about what it can't express?
    - pkolaczk 13y ago
      Right, I don't know much about Haskell (not actively programming in it), but I know that Haskell was not designed with OOP in mind and things like polymorphic nominal subclassing are not first-class there. There are also some things that Haskell's type system can't do e.g. the nice thing that Scala does with fold/map/reduce always returning the right type, even if it has to be a different type than the type of the source collection. I'd like to be proven wrong, Haskell is on my list of next languages to learn well ;)
      - papsosouid 13y ago
        I don't even know what anything in your post means. You are correct that haskell is not an OOP language. You are very confused beyond that point.

happy_dino 13y ago

> Scala's crazy amount of syntax Could you expand on that a bit?

lucian1900 13y ago
First, I must say that I like the idea of the language. It has ADTs (case classes) and typeclasses (traits), a bit of type inference, can run on Android and isn't Java. It's just the baroque syntax that bothers me. It starts from this [1]. Then there's case classes, _, optional everything (forgetting = in a function def can make it mean something else), the currying syntax [2] (sometimes it needs an arbitrary _ to break ambiguity), the imports (especially renaming), arbitrary rules on whether construction needs "new" or not, etc. The fact that [3] is possible even though Scala is not an almost-no-syntax language (like Lisps and Haskell) concerns me. And it even has macros, but all of its very many language features aren't implemented as macros :( 1. http://en.wikipedia.org/wiki/Scala_(programming_language)#Syntactic_flexibility http://en.wikipedia.org/wiki/Scala_(programming_language)#Sy... 2. http://brenocon.com/scalacheat/ http://brenocon.com/scalacheat/ 3. http://blog.fogus.me/2009/03/26/baysick-a-scala-dsl-implementing-basic/ http://blog.fogus.me/2009/03/26/baysick-a-scala-dsl-implemen...
- happy_dino 13y ago
  - [1] comes down to the idea of not having to build two separate concepts (namely, operators AND methods) with different syntax, different declaration styles, different parsing rules, ... into the language. Scala has only methods (which can have a “symbolic” name). The usual precedence rules are based on that name. - case classes: I love them. - _: The underscore has one meaning, “there is something, but I don't care about the name”. Super simple. - forgetting = in a function def can make it mean something else: I agree, it is very error-prone. As far as I know, there are some proposals to get completely rid of procedure syntax. - currying syntax: PinS has a pretty good explanation why it works that way. It is certainly not perfect, but less error-prone than alternatives. - the imports (especially renaming): Many languages have this feature and I have not seen any issues with it. - arbitrary rules on whether construction needs "new" or not: No. The rule is that you always need new to construct an instance. -[3]: You can do crazy stuff in every language. Have a look at functional code written in Java. - And it even has macros, but all of its very many language features aren't implemented as macros: No. In a sense, ALL features are implemented via macros, because the compiler API and the reflection API (macros) are pretty much the same underneath.