6 ms·

Just as C++11 looks worlds different (and better) than C++ circa 1990, I imagine that the same dynamic will play out with Scala, which I tend to analogize as Ja

by jfb 12y ago

Just as C++11 looks worlds different (and better) than C++ circa 1990, I imagine that the same dynamic will play out with Scala, which I tend to analogize as Java++. Certain idiom will develop, certain language features will be deprecated but by nature of the platform will not be able to be removed; &c. I find some idiom used by the more experienced Scala devs on my team to be distasteful: I hate hate hate the semantic confusion between the Option type and sequences that leads people to map over Options (or the dual use of is/nonEmpty). I would always prefer pattern matching, or getOrElse, for instance. I think I'm just a fan of smaller languages; I certainly understand -- and commend -- Dr Odersky's approach to a pragmatic extension of a (bad) industry language, just as I appreciated Stoustroup's; but given my druthers, I'd just as soon be working in something perhaps less pragmatic but certainly smaller and less warty. If anybody knows what language that is, please tell me. Or invent it.

bkirwi 12y ago
You might prefer Kotlin?[0] It's going in the same direction as Scala, but not quite so far. By the way, I'm curious what you mean by "the semantic confusion between the Option type and sequences that leads people to map over Options". Mapping and 'flatMapping' are very general things in Scala, and apply to many types that are not collections, like Futures / Observables / etc. [0] http://kotlinlang.org/ http://kotlinlang.org/
- llemiengre 12y ago
  Honestly Kotlin has 80% of the complexity of Scala, 20% of the functionality, almost no library ecosystem and 0 stable releases. I don't know why so many people consider it a serious choice. If you want java with type inference you can use Xtend they have had many stable releases and it has excellent tool support.
- jfb 12y ago
  I think I'd be more interested in Haskell-- than Kotlin; I am not a fan of statically dispatched OO language implementations. I am (perhaps unsurprisingly, given my employer) much more a fan of Smalltalk derived languages when writing in an OO style.
  - the_af 12y ago
    Definitely try Haskell, you'll like it. But do note it's completely idiomatic in Haskell to map over Maybe (aka Option in Scala), which was your initial objection in this subthread :)
    - jfb 12y ago
      This is a case of PEBCAK, not the language design. I'll get used to it.
- jfb 12y ago
  It's unfamiliarity with the idiom that makes me uncomfortable, to be perfectly frank. I'll get used to it. I won't get used to how alien and ultimately weak Scala's support for algebraic data types is, and that's not changing. This comes down to the affordances that Odersky and the Scala team have decided to favor, which is OO flavored in a way that I don't like. I vastly prefer the ML style: data Foo = Bar s | Baz to the sealed class/case nightmare of Scala. Again, this is not a technical nit -- this is an idiomatic and personal one.
  - bad_user 12y ago
    Yeah, but the cool thing about Scala is that you get to pick the kind of polymorphism you want, depending on whether the list of Nouns will evolve versus the list of Verbs. Like, those case classes are also classes that can have polymorphic methods on them. So for example, you can do this: https://gist.github.com/alexandru/2604948978c497adc8e2 https://gist.github.com/alexandru/2604948978c497adc8e2 - instead of doing this: https://gist.github.com/alexandru/41acda9bdd694bec38b2 https://gist.github.com/alexandru/41acda9bdd694bec38b2 Which variant is better, it depends, but both versions have tradeoffs, depending on direction. Also, Scala's OOP blend with FP is best in breed. In Ocaml for example is like having 2 type-systems in the same language, whereas in Scala it's more like a turtles all the way down kind of thing which I like.
    - jfb 12y ago
      Also, Scala's OOP blend with FP is best in breed. In Ocaml for example is like having 2 type-systems in the same language, whereas in Scala it's more like a turtles all the way down kind of thing which I like. This is a perfectly reasonable stance to take; I think my Objective-C background would have me argue that it makes more sense to keep two distinct paradigms syntactically distinct, but that's a matter of taste. I haven't done anything serious with OCaml -- perhaps that's a direction I'll explore after my Haskell toy project is finished. Thanks for the replies, you've shed much light. And the OP is great, too; I'll definitely be keeping it close at hand.
  - bkirwi 12y ago
    TBH, I think that is a legitimate technical nit. Case classes end up being very useful, but they're not as principled as the ADTs that they're generally used to replace, and that shows up in a bunch of weird corner cases. It's one of the prices you pay for trying to cram this stuff into the JVM / OOP universe. Speaking to your sibling comment on Haskell and Kotlin: I also happen to think that Haskell is by far the better-designed language. I think Kotlin does a nice job of cleaning up some of the warts of Java, but I don't really want a better Java -- I just want a better language. Scala is definitely less elegant than Haskell (Haskell/Scalaz-style FP is particularly gross) but there's a large class of problems for which I really do think it's the best language / ecosystem that happens to actually exist.
bad_user 12y ago
> I hate hate hate the semantic confusion between the Option type and sequences Option is a Monad in Scala and could also be modeled as an Applicative Functor - which are very generic abstractions that transcend sequences. Don't let the naming scare you, you can view them as design patterns, it just so happens that people aren't familiar with them. In Scala mapping, filtering and flatMap-ing are generic and for example Scala's for-comprehensions work on all things implementing map, filter and flatMap including things that are not sequences and for good reason. And most importantly - `Option` would be completely useless without mapping, filtering or flatMap-ing on it. Because often you have to combine multiple options and what happens in practice, without an easy to use API, people would just do "Option.get" and trade a null pointer exception for a NoSuchElementException, which would defeat the purpose of using Option. The semantic confusion between an Option and a sequence is the same confusion between a sequence and a Set - none and if there is, then you need to go back to the basics. First of all, because Option really is a collection of zero or one elements and second because all of them are Monads. > I imagine that the same dynamic will play out with Scala, which I tend to analogize as Java++ I don't know what makes people say things like this. Scala is nothing like Java and I worked with C++ and with Perl too, in production. Scala has some warts in it, but such comparisons are unwarranted.
- jfb 12y ago
  Thank you, this is very helpful. I tend to think of the Option/Maybe type as signaling to the reader a SQL-like 3VL value, where the distinction between having a thing and not having a thing is not contingent on the thing-in-itself. Clearly, I need to lift my level of thinking up at least one level of abstraction. > I don't know what makes people say things like this. It's a social and not a technical analogy (although I think the technical analogy is stronger than you apparently do). C++ took an established industry language and opened the door to a whole new level of abstraction; just as you can write C in C++ (missing the whole point), you can write Java in Scala (again, missing the point). C++'s affordances to prevent this were weaker than Scala's, which means that the acceptance of Scala's idiomatic way will probably happen much faster than that of C++'s did. It wasn't intended to be a derogatory analogy; I admire modern C++, even as I am happy not to be writing it.
- 12y ago
lmm 12y ago
> Just as C++11 looks worlds different (and better) than C++ circa 1990, I imagine that the same dynamic will play out with Scala, which I tend to analogize as Java++. Certain idiom will develop, certain language features will be deprecated but by nature of the platform will not be able to be removed; &c. I think popularity (particularly with the enterprise) ossifies a language; it's too late to fix certain mistakes. Certainly this is the case for Scala already. But don't underestimate the difference between 5 years of cruft and 25 years of cruft. > I find some idiom used by the more experienced Scala devs on my team to be distasteful: I hate hate hate the semantic confusion between the Option type and sequences that leads people to map over Options That's not confusion but enlightenment. Options aren't Sequences, but both are Monads. > I think I'm just a fan of smaller languages; I certainly understand -- and commend -- Dr Odersky's approach to a pragmatic extension of a (bad) industry language, just as I appreciated Stoustroup's; but given my druthers, I'd just as soon be working in something perhaps less pragmatic but certainly smaller and less warty. You might like Idris - it looks a lot like a slimmed-down, more principled Scala with the benefits of lessons learned. Of course the price for that is that it's less mature and has a much smaller community.

by jfb 12y ago

bkirwi 12y ago

You might prefer Kotlin?[0] It's going in the same direction as Scala, but not quite so far. By the way, I'm curious what you mean by "the semantic confusion between the Option type and sequences that leads people to map over Options". Mapping and 'flatMapping' are very general things in Scala, and apply to many types that are not collections, like Futures / Observables / etc. [0] http://kotlinlang.org/ http://kotlinlang.org/

llemiengre 12y ago
Honestly Kotlin has 80% of the complexity of Scala, 20% of the functionality, almost no library ecosystem and 0 stable releases. I don't know why so many people consider it a serious choice. If you want java with type inference you can use Xtend they have had many stable releases and it has excellent tool support.
jfb 12y ago
I think I'd be more interested in Haskell-- than Kotlin; I am not a fan of statically dispatched OO language implementations. I am (perhaps unsurprisingly, given my employer) much more a fan of Smalltalk derived languages when writing in an OO style.
- the_af 12y ago
  Definitely try Haskell, you'll like it. But do note it's completely idiomatic in Haskell to map over Maybe (aka Option in Scala), which was your initial objection in this subthread :)
  - jfb 12y ago
    This is a case of PEBCAK, not the language design. I'll get used to it.
jfb 12y ago
It's unfamiliarity with the idiom that makes me uncomfortable, to be perfectly frank. I'll get used to it. I won't get used to how alien and ultimately weak Scala's support for algebraic data types is, and that's not changing. This comes down to the affordances that Odersky and the Scala team have decided to favor, which is OO flavored in a way that I don't like. I vastly prefer the ML style: data Foo = Bar s | Baz to the sealed class/case nightmare of Scala. Again, this is not a technical nit -- this is an idiomatic and personal one.
- bad_user 12y ago
  Yeah, but the cool thing about Scala is that you get to pick the kind of polymorphism you want, depending on whether the list of Nouns will evolve versus the list of Verbs. Like, those case classes are also classes that can have polymorphic methods on them. So for example, you can do this: https://gist.github.com/alexandru/2604948978c497adc8e2 https://gist.github.com/alexandru/2604948978c497adc8e2 - instead of doing this: https://gist.github.com/alexandru/41acda9bdd694bec38b2 https://gist.github.com/alexandru/41acda9bdd694bec38b2 Which variant is better, it depends, but both versions have tradeoffs, depending on direction. Also, Scala's OOP blend with FP is best in breed. In Ocaml for example is like having 2 type-systems in the same language, whereas in Scala it's more like a turtles all the way down kind of thing which I like.
  - jfb 12y ago
    Also, Scala's OOP blend with FP is best in breed. In Ocaml for example is like having 2 type-systems in the same language, whereas in Scala it's more like a turtles all the way down kind of thing which I like. This is a perfectly reasonable stance to take; I think my Objective-C background would have me argue that it makes more sense to keep two distinct paradigms syntactically distinct, but that's a matter of taste. I haven't done anything serious with OCaml -- perhaps that's a direction I'll explore after my Haskell toy project is finished. Thanks for the replies, you've shed much light. And the OP is great, too; I'll definitely be keeping it close at hand.
- bkirwi 12y ago
  TBH, I think that is a legitimate technical nit. Case classes end up being very useful, but they're not as principled as the ADTs that they're generally used to replace, and that shows up in a bunch of weird corner cases. It's one of the prices you pay for trying to cram this stuff into the JVM / OOP universe. Speaking to your sibling comment on Haskell and Kotlin: I also happen to think that Haskell is by far the better-designed language. I think Kotlin does a nice job of cleaning up some of the warts of Java, but I don't really want a better Java -- I just want a better language. Scala is definitely less elegant than Haskell (Haskell/Scalaz-style FP is particularly gross) but there's a large class of problems for which I really do think it's the best language / ecosystem that happens to actually exist.

bad_user 12y ago

> I hate hate hate the semantic confusion between the Option type and sequences Option is a Monad in Scala and could also be modeled as an Applicative Functor - which are very generic abstractions that transcend sequences. Don't let the naming scare you, you can view them as design patterns, it just so happens that people aren't familiar with them. In Scala mapping, filtering and flatMap-ing are generic and for example Scala's for-comprehensions work on all things implementing map, filter and flatMap including things that are not sequences and for good reason. And most importantly - `Option` would be completely useless without mapping, filtering or flatMap-ing on it. Because often you have to combine multiple options and what happens in practice, without an easy to use API, people would just do "Option.get" and trade a null pointer exception for a NoSuchElementException, which would defeat the purpose of using Option. The semantic confusion between an Option and a sequence is the same confusion between a sequence and a Set - none and if there is, then you need to go back to the basics. First of all, because Option really is a collection of zero or one elements and second because all of them are Monads. > I imagine that the same dynamic will play out with Scala, which I tend to analogize as Java++ I don't know what makes people say things like this. Scala is nothing like Java and I worked with C++ and with Perl too, in production. Scala has some warts in it, but such comparisons are unwarranted.

jfb 12y ago
Thank you, this is very helpful. I tend to think of the Option/Maybe type as signaling to the reader a SQL-like 3VL value, where the distinction between having a thing and not having a thing is not contingent on the thing-in-itself. Clearly, I need to lift my level of thinking up at least one level of abstraction. > I don't know what makes people say things like this. It's a social and not a technical analogy (although I think the technical analogy is stronger than you apparently do). C++ took an established industry language and opened the door to a whole new level of abstraction; just as you can write C in C++ (missing the whole point), you can write Java in Scala (again, missing the point). C++'s affordances to prevent this were weaker than Scala's, which means that the acceptance of Scala's idiomatic way will probably happen much faster than that of C++'s did. It wasn't intended to be a derogatory analogy; I admire modern C++, even as I am happy not to be writing it.
12y ago

lmm 12y ago

> Just as C++11 looks worlds different (and better) than C++ circa 1990, I imagine that the same dynamic will play out with Scala, which I tend to analogize as Java++. Certain idiom will develop, certain language features will be deprecated but by nature of the platform will not be able to be removed; &c. I think popularity (particularly with the enterprise) ossifies a language; it's too late to fix certain mistakes. Certainly this is the case for Scala already. But don't underestimate the difference between 5 years of cruft and 25 years of cruft. > I find some idiom used by the more experienced Scala devs on my team to be distasteful: I hate hate hate the semantic confusion between the Option type and sequences that leads people to map over Options That's not confusion but enlightenment. Options aren't Sequences, but both are Monads. > I think I'm just a fan of smaller languages; I certainly understand -- and commend -- Dr Odersky's approach to a pragmatic extension of a (bad) industry language, just as I appreciated Stoustroup's; but given my druthers, I'd just as soon be working in something perhaps less pragmatic but certainly smaller and less warty. You might like Idris - it looks a lot like a slimmed-down, more principled Scala with the benefits of lessons learned. Of course the price for that is that it's less mature and has a much smaller community.