
Typelevel Scala - milessabin
https://github.com/typelevel/scala
======
atemerev
I am not happy about it. Typelevel projects are just porting the style
familiar to Haskell programmers to Scala, and a full fork to accomodate this
style seems to be an overkill.

I know, many people are happy to go full throttle on Cats/Scalaz/whatever, but
there's already Haskell for that. Official Scala documentation never even
mentions the word "monad" (not even once!), and I think this is a good thing.

~~~
bad_user
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.

~~~
akst
> 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-
focuse...](http://www.elmbark.com/2016/03/16/mainstream-elm-user-focused-
design)

~~~
joostdevries
That Elm talk is really interesting. Tx.

When it comes to Monad et al I'm reminded of this talk by Gilad Bracha. He
points out that the function names and type names that stem from category
theory are not very good at communicating their intent in programming. (my
words) Monad could be named Flatmappable f.i. 'unit' and 'bind' can have more
intuïtive names as well.

At the moment I get the impression that as Scala is becoming a safe and
productive and widely used tool there are developers moving to more Haskell
like pastures within Scala. Perhaps because that kind of programming is
required for some specific problems. But quite likely as well because they
hope that it will make them stand out as smarter programmers.

Some people may remember the so called "Peters principle". Informally it
states that people get promoted until they've reached their level of
incompetence.

Similarly some smart developers tend to increase the complexity of their code
to keep themselves amused until they're struggling to understand it
themselves. Joosts principle. :-)

Edit: the link to the talk [https://www.infoq.com/presentations/functional-
pros-cons](https://www.infoq.com/presentations/functional-pros-cons)

~~~
akst
I actually remembering seeing it at some point, this guy is a pretty great
presenter, glad I watched it, Thanks again for the link. Now I remember I need
to go and check out small talk to see what it's he's going on about.

------
noelwelsh
This is fantastic. It's already fixing many of the issues I run into in my
day-to-day Scala programming. I hope it serves as a good test-bed for features
to make their way into the "official" compiler.

~~~
35bge57dtjku
What are those issues?

------
partycoder
Well, it's not the first time people try to steer Scala to a different
direction. Paul Phillips for instance, after many complaints on the direction
the language was going, forked Scala (but now his fork is largely abandoned).
[https://github.com/paulp/policy](https://github.com/paulp/policy)

~~~
ci5er
Was he trying to fork the language or the compiler? I thought he wanted a
better (by his metrics) compiler for the same language. Did I misunderstand
his intent way-back-when this was a thing?

~~~
partycoder
The compiler apparently.

------
srparish
Are future versions of cats going to require the typelevel scala?

~~~
davegurnell
No. I don't believe so. Think of Typelevel Scala as a tool to help people test
out improvements to Scala as a whole, not as something that is going to
deviate significantly from Lightbend Scala.

