6 ms·

The Typelevel Scala is nothing more than a branch on which experiments can happen before pull requests are made in the main branch. The people involved have alr

The Typelevel Scala is nothing more than a branch on which experiments can happen before pull requests are made in the main branch. The people involved have already contributed fixes, like the following by Miles Sabin, which is huge and will make Scala much better: https://github.com/scala/scala/pull/5102 https://github.com/scala/scala/pull/5102 - so basically we've got here a bunch of people that are extremely productive, working for free for the betterment of our tools and you don't like it because? > Official Scala documentation never even mentions the word "monad" (not even once!), and I think this is a good thing Actually that's a huge mistake because Scala is amongst the few languages that can express the Monad as a type. In most mainstream languages monads aren't explained because those languages lack the capacity for doing it. It's no wonder that people have a hard time understanding monads without a type to look at, as that would be like describing an elephant to a blind man. Do you think you understand Iterable because of its name? No, you understand it because you've seen its interface clearly described and then you used it and learned to appreciate it. And really, the strangest things happens when you don't talk about it. You still have for comprehensions, but surprise, they don't behave like in Python, "yield" is again overloaded, having nothing to do with Python's yield or Ruby's yield, and people stumble for no good reason, because it is hard to connect what seems like syntactic sugar over iterators to an expansion using map and flatMap. Along with "computation expressions" from F# or other bullshit naming meant to not scare away the most sensitive of us, the big problem that happens is that people get confused and don't even know what to search for. Search for monads and you'll find endless articles, tutorials, books, research. Search for comprehensions and you get shit. This is basically anti-intellectualism, the same kind of attitude that made Trump popular and that encouraged Brexit. The same kind of attitude that made the Option type in Java violate the Functor laws, taking a concept and destroying its essence just because we're afraid of big words and the opinions of experts.

tome 10y ago
> This is basically anti-intellectualism, the same kind of attitude that made Trump popular and that encouraged Brexit. The same kind of attitude that made the Option type in Java violate the Functor laws Didn't really expect that, but bravo, I suppose!
atemerev 10y ago
I am not afraid of big words, I did some research on implicit parallelization with arrows. :) But Scala is a hybrid pragmatic functional language, not aspiring to some advanced type research (except in FP-OOP interop). Even typeclasses, while working, are somewhat a hack in Scala. Why not use more appropriate languages for research and leave Scala to be good where it excels?
- whateveracct 10y ago
  Scala has first-class syntactic support typeclass-constrained generics (see context bounds) so idt they are a hack at all. Lack of canonicity and runtime representation are the main differences between Haskell and Scala typeclasses.
saosebastiao 10y ago
> And really, the strangest things happens when you don't talk about it. You still have for comprehensions, but surprise, they don't behave like in Python, "yield" is again overloaded, having nothing to do with Python's yield or Ruby's yield, and people stumble for no good reason, because it is hard to connect what seems like syntactic sugar over iterators to an expansion using map and flatMap. Along with "computation expressions" from F# or other bullshit naming meant to not scare away the most sensitive of us, the big problem that happens is that people get confused and don't even know what to search for. Search for monads and you'll find endless articles, tutorials, books, research. Search for comprehensions and you get shit. I agree that Monads deserve our time and attention. Unfortunately, search for monads and you'll get thousands of articles explaining what they are in incomprehensible terminology, along with language-specific type annotations, and devoid of any practical reasons to use them over their non-monadic control flow cousins in imperative languages. They never seem to explain why you would ever need them, how they help in certain situations. Even worse, they don't tell you when they might actually be hazardous or code smell. They rarely even gloss over the challenges (like needing monad transformers if you want any sort of monadic composition), leaving you to figure that out for yourself when you start bashing your head against the walls. For all their hard-to-google non-standard terminology, the Scala and F# communities have done a far better job than Haskell at explaining Monads in a way that actually makes people want to learn and use them. And once they have learned the concepts, the elitist sounding language doesn't sound quite so intimidating anymore.
- infinity0 10y ago
  > done a far better job than Haskell at explaining Monads [..] the elitist sounding language For fucks sakes, nobody invents words like "monad" to sound elitist.
  - saosebastiao 10y ago
    http://stackoverflow.com/questions/3870088/a-monad-is-just-a-monoid-in-the-category-of-endofunctors-whats-the-issue http://stackoverflow.com/questions/3870088/a-monad-is-just-a...
akst 10y ago
> This is basically anti-intellectualism, the same kind of attitude that made Trump popular and that encouraged Brexit. > its essence just because we're afraid of big words and the opinions of experts. I think most of the distaste for terms like Monad, is a failure to communicate it's meaning to a lot of people, it reminds me a lot of Enterprise Java terminology with terms like factories, abstract/factories, Bean, ect, that provide just as much intuition into their own meanings from their names. And when you look up their meanings you get hit with even more obtuse terminology. Like for example a in a less formal discussion about programming, a term like "pure functions", can simply described as "stateless function" [1]. You don't need to automatically reach for the big words, when a more commonly understood word sufficiently communicates something. Unfortunately I'm not so sure there's such a word for monad however. In the case of Elm, it has this approach to naming things with less formal names where it can use something more comprehensible. The author of the Elm language mentions this in a talk of his [1] (just scroll to the section on being direct). I really see this more as a communication issue, not everyone in software has a duel degree in abstract mathematics & computer science, let alone a degree. [1]: http://www.elmbark.com/2016/03/16/mainstream-elm-user-focused-design http://www.elmbark.com/2016/03/16/mainstream-elm-user-focuse...
- willtim 10y ago
  The mathematical terminology that you dislike has already been well established and well defined after decades of use in many formal publications. It will probably be continued to be used for hundreds of years. In no way is "Enterprise Java Beans" analogous.
  - akst 10y ago
    > The mathematical terminology that you dislike I'm actually indifferent to the terminology, having used my fair share of Haskell/ML/Lisp, but I can see how you came to that assumption. > in many formal publications I'm aware of this, but the thing with this is not everyone in software has a computer science background, let alone an academic background. I'm a freelancer at the moment, but if I used most of this terminology in my workplace people would be giving me wtf looks. > In no way is "Enterprise Java Beans" analogous How so? All I said formal names in mathematic/computer science, give next to intuition into their actual meaning & when you look up their meaning, most of the results are riddled with more terminology. Same kind of goes for a lot of the Jagon in Java enterprise stuff, like beans/services/factories/etc. I wasn't saying their exactly the same, but more I had a similar experience when trying to familiarise myself with that stuff.

tome 10y ago

> This is basically anti-intellectualism, the same kind of attitude that made Trump popular and that encouraged Brexit. The same kind of attitude that made the Option type in Java violate the Functor laws Didn't really expect that, but bravo, I suppose!

atemerev 10y ago

I am not afraid of big words, I did some research on implicit parallelization with arrows. :) But Scala is a hybrid pragmatic functional language, not aspiring to some advanced type research (except in FP-OOP interop). Even typeclasses, while working, are somewhat a hack in Scala. Why not use more appropriate languages for research and leave Scala to be good where it excels?

whateveracct 10y ago
Scala has first-class syntactic support typeclass-constrained generics (see context bounds) so idt they are a hack at all. Lack of canonicity and runtime representation are the main differences between Haskell and Scala typeclasses.

saosebastiao 10y ago

> And really, the strangest things happens when you don't talk about it. You still have for comprehensions, but surprise, they don't behave like in Python, "yield" is again overloaded, having nothing to do with Python's yield or Ruby's yield, and people stumble for no good reason, because it is hard to connect what seems like syntactic sugar over iterators to an expansion using map and flatMap. Along with "computation expressions" from F# or other bullshit naming meant to not scare away the most sensitive of us, the big problem that happens is that people get confused and don't even know what to search for. Search for monads and you'll find endless articles, tutorials, books, research. Search for comprehensions and you get shit. I agree that Monads deserve our time and attention. Unfortunately, search for monads and you'll get thousands of articles explaining what they are in incomprehensible terminology, along with language-specific type annotations, and devoid of any practical reasons to use them over their non-monadic control flow cousins in imperative languages. They never seem to explain why you would ever need them, how they help in certain situations. Even worse, they don't tell you when they might actually be hazardous or code smell. They rarely even gloss over the challenges (like needing monad transformers if you want any sort of monadic composition), leaving you to figure that out for yourself when you start bashing your head against the walls. For all their hard-to-google non-standard terminology, the Scala and F# communities have done a far better job than Haskell at explaining Monads in a way that actually makes people want to learn and use them. And once they have learned the concepts, the elitist sounding language doesn't sound quite so intimidating anymore.

infinity0 10y ago
> done a far better job than Haskell at explaining Monads [..] the elitist sounding language For fucks sakes, nobody invents words like "monad" to sound elitist.
- saosebastiao 10y ago
  http://stackoverflow.com/questions/3870088/a-monad-is-just-a-monoid-in-the-category-of-endofunctors-whats-the-issue http://stackoverflow.com/questions/3870088/a-monad-is-just-a...

akst 10y ago

> This is basically anti-intellectualism, the same kind of attitude that made Trump popular and that encouraged Brexit. > its essence just because we're afraid of big words and the opinions of experts. I think most of the distaste for terms like Monad, is a failure to communicate it's meaning to a lot of people, it reminds me a lot of Enterprise Java terminology with terms like factories, abstract/factories, Bean, ect, that provide just as much intuition into their own meanings from their names. And when you look up their meanings you get hit with even more obtuse terminology. Like for example a in a less formal discussion about programming, a term like "pure functions", can simply described as "stateless function" [1]. You don't need to automatically reach for the big words, when a more commonly understood word sufficiently communicates something. Unfortunately I'm not so sure there's such a word for monad however. In the case of Elm, it has this approach to naming things with less formal names where it can use something more comprehensible. The author of the Elm language mentions this in a talk of his [1] (just scroll to the section on being direct). I really see this more as a communication issue, not everyone in software has a duel degree in abstract mathematics & computer science, let alone a degree. [1]: http://www.elmbark.com/2016/03/16/mainstream-elm-user-focused-design http://www.elmbark.com/2016/03/16/mainstream-elm-user-focuse...

willtim 10y ago
The mathematical terminology that you dislike has already been well established and well defined after decades of use in many formal publications. It will probably be continued to be used for hundreds of years. In no way is "Enterprise Java Beans" analogous.
- akst 10y ago
  > The mathematical terminology that you dislike I'm actually indifferent to the terminology, having used my fair share of Haskell/ML/Lisp, but I can see how you came to that assumption. > in many formal publications I'm aware of this, but the thing with this is not everyone in software has a computer science background, let alone an academic background. I'm a freelancer at the moment, but if I used most of this terminology in my workplace people would be giving me wtf looks. > In no way is "Enterprise Java Beans" analogous How so? All I said formal names in mathematic/computer science, give next to intuition into their actual meaning & when you look up their meaning, most of the results are riddled with more terminology. Same kind of goes for a lot of the Jagon in Java enterprise stuff, like beans/services/factories/etc. I wasn't saying their exactly the same, but more I had a similar experience when trying to familiarise myself with that stuff.