Typelevel Scala | Hacker News Reader

Typelevel Scala

github.com

90 pointsmilessabin56 comments

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.

Yes, please stop trying to make Scala Haskell. And please start switching to Haskell :)

Scala has jokingly been called Hascalator [1], but not everyone who is "ready" to make the leap to Haskell can actually do it (existing work tied to JVM, dependencies on JVM libraries, etc.) or wants to do it (better ability to reason about resource usage, familiarity with tooling, etc.).

[1] https://twitter.com/yakticus/status/577663763991564288

I do write in Haskell where it is appropriate (for fun, or if I want to prototype some complex domain model). Otherwise, I am quite happy with Scala. :)

I might be missing something, but can't you just choose not to use it? For those using Scala who are interested in access to more advanced functional programming techniques, or using libraries that are written with a more "mathy" bent, this seems like a good thing. For those who'd prefer to never have to read the word "monad", just use something else.

But I am happy with Scala as it is. Why should I use something else? I, of course, know what a monad is, but I do not exactly care. For me, expressiveness is much more important than purity.

I even use vars where it is appropriate! :)

While it doesn't mention monad, for comprehensions are first-class support for them. Whether or not you can get over the use of the word. What else are you going to call F[_], bind, and point???

I guess you could just call F[_] a monoid in the category of endofunctors of F[_]...

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

> 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!

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?

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.

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

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

http://stackoverflow.com/questions/3870088/a-monad-is-just-a...

The link you provided contains two precise definitions of the term "monad" in the responses (one which includes the source of the "a monad in X is just a monoid in the category of endofunctors of X" quote). Was it your intent to support @infinity0's premise that words like "monad" are not elitist?

If so, well done!

If not, then I humbly ask why is a term such as monad qualified as elitist, yet terms such as Abstract Syntax Tree[0], Big O notation[1], and Turing complete[2] are not?

All four of these have in common precise definitions.

All four of these have in common applicability when considering the domain each address.

All four of these have in common their existence in programming even when not directly considered by those writing software.

0 - https://en.wikipedia.org/wiki/Abstract_syntax_tree

1 - https://en.wikipedia.org/wiki/Big_O_notation

2 - https://en.wikipedia.org/wiki/Turing_completeness

> If not, then I humbly ask why is a term such as monad qualified as elitist, yet terms such as Abstract Syntax Tree[0], Big O notation[1], and Turing complete[2] are not?

The preciseness of the definition has nothing to do with the perceived elitism. Plenty of precisely mathematically defined concepts, as you've illustrated, can be (and are) explained to people without ever needing a single glyph or axiom in the explanation, let alone a recursive terminology briefer.

Take the following two definitions:

1) A screw is a mechanical device that converts rotational motion to linear motion, and torque to a linear force.

2) A screw is something you use to attach stuff to walls. You use a screwdriver to mash it in there.

One is abstract yet precise. The other is non-abstract and imprecise...so imprecise that it might as well be wrong. Regardless of its cringe induction potential to the Haskell-lovers brain, only one of these definitions will hold the attention of a 4 year old and explains why they're useful and how to use them.

The simple fact of the matter is that people in general are bad at math, and even most people who think they are "good at math" have no fucking clue what category theory is...good luck holding their attention while you brief them on it. Nobody learns abstract before non-abstract, it's just not how brains work. If you give them a reason to hold on to the concept, and explain it with words they likely understand, you might get far enough to one day explain the abstract version.

My interpretation of your analogy is that if there were a resource which presented monad-related concepts in a manner a working Scala programmer is likely to relate with, as opposed to theory laden texts, then the usefulness of these concepts might be better received in general.

Fair enough. So here is a book which does precisely that:

"Functional Programming in Scala" (ISBN-13: 978-1617290657)

The authors incrementally present FP concepts, including monads, in a very approachable style. I can say first hand that this book does not require a heavy mathematical background (off hand, I don't think there are any formal proofs in it).

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

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.

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

The danger of "intuitive" names and analogies is that they often don't capture the generality of the abstraction and can limit ones thinking. The mathematical terms are useful and communicate precisely and unambiguously (e.g. if someone says X is a Functor then I assume the Functor laws are satisfied). Ignoring established terminology creates insular communities and creates confusion (e.g. a C++ Functor versus a mathematical Functor, C void versus type theory void). I agree that better books and learning resources are needed, but changing names is anti-intellectualism, IMHO.

> I agree that better books and learning resources are needed, but changing names is anti-intellectualism, IMHO

To clarify I'm not suggesting changing existing names in mathematics or existing APIs, I'm just suggesting in documentation / blog posts / educational stuff we should avoid using the more intimidating terminology if a simpler term convoys the message better, especially if the terminology gets in the way of educational material doing it's intended purpose.

Maybe this wouldn't be a problem if mathematic education content was more accessible, I don't know but at the moment I really don't think it is. Like it would nice to have a nice accessible book like "Category Theory in Python/JS" or something to refer people to... But I agree, changing names is anti-intellectualism

> The danger of "intuitive" names and analogies is that they often don't capture the generality of the abstraction and can limit ones thinking

I get that, & I feel in mathematics that is important, but in writing an API having slightly dishonest names is okay. Like a name like `flatMappable` vs' `Monad` even though not all Monad's work like a flatMap, but I get what you're saying new users might think monads are just a collections API thing, but maybe if they saw it on an Optional/Error/Promise/Async/etc this wouldn't be a problem, I don't know. Maybe it's a matter of establishing a culture where the use of these names like flatMap are first demonstrated with none collection types, again I don't know. I'm really just throwing ideas out there, but I feel it's something to consider.

Oh well, hopefully things improve

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

> 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

This was my point exactly, also thanks for the link I'll have to checkout that talk :-)

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.

Well one of the confusions I think early on (or at least professed confusion on Lambda the Ultimate IIRC) is that Scala is mixed paradigm and that adds additional load for learning.

Some feel it should go full FP (what I mean by that is really discourage OOP, side effects, etc...). There is some valid arguments as Rust and Haskell might end up being an easier language to master as you can completely avoid the OOP conversation (polymorphic inheritance seems incredibly simple yet there are whole books written on how to use it.. ie patterns).

I'm curious do you prefer a more OOP imperative approach with some FP or do you prefer the opposite (FP with some slight OOP)?

OOP hate is common these days, but I always has been an OOP enthusiast. I used to write in Smalltalk, I implemented a few metaobject protocols of my own, and I think OOP had deserves its success (unfortunately, C++/Java is not really OOP... However, some principles still apply).

So, when a language appeared to combine the best ideas from FP and OOP, I happily embraced it. And I want it to stay this way.

Sometimes you really need to drop into mutation of state in perf critical paths

There are great tools for that in both Scala and Haskell.

In Scala you can use var, which is easy.

In Haskell you can write your algorithm using ST and then use it as a pure function by means of runST. The type system guarantees that all such state is local to the invocation.

Scala is a really great OO language, enabling very useful statically typed mixin compositions that you won't find in any other language. Uunfortunately, the vocal side of the community is very much anti OOP, so you don't hear about them much, but it is still there.

There are many excellent non-OO functional languages like Haskell, where functional concepts are mapped to much more elegant syntactic devices, having not much to do with OOP. There, ADTs are not expressed as "case classes", there's no need for implicits and coercions to enable type classes, and one can speak the word "monad" freely and bravely.

However, Scala is not Haskell. Scala's raison d'être is merging FP and OOP, and it excels at it. I'd like to leave it this way.

This isn't as bad as it looks. Think of it like an additional experimental scalac that is more ready to integrate into mainline scala than Dotty is.

I'm fully on board with you...I think Scalaz as a library is a virus, and it's community is toxic, and it's desperate desire to turn Scala into Haskell ends up turning an awesome ML-inspired language into a vastly inferior religious (...ahem, pure) language.

But Cats and Shapeless aren't Scalaz. They have concepts that happen to exist in Haskell, but they aren't Haskell's concepts to own any more than C owns imperative programming. If anything, Mathematics owns the concepts and Haskell happened to borrow them to make a terrible purist concept slightly more practical. It turns out that when you need the concepts (and I have, on a couple of occasions), it makes Scala slightly more practical as well.

You happen to think the most popular scala library is a virus?

We use it extensively at Verizon, and it exists just fine with 'impure' code, Akka code, or whatever else various teams decide to also pull in. Codebases that don't use Scalaz end up re-inventing it, usually in a more buggy way and at a waste of developer effort.

Reinventing is fine on your own for a learning exercise and I certainly did it a few times, but in production code, just use Scalaz. Or sure, I suppose if you want to use a copy and pasted into a new repo version of Scalaz, go for Cats. I don't even know why Shapeless is brought into the conversation, it has a much more narrow use case and I almost never reach for it.

I've also found the Scalaz community and chat room on IRC quite helpful, whereas I've had some really unpleasant interactions with Cats committers. To go around spreading FUD and promoting an alpha level library that's less than half as popular as Scalaz (according to Github stars) is just irresponsible.

Exactly. Practically every interesting scala lib (from scalatest to play to sbt) has internal implementation of functional patterns.

Sorry, but there's no way scalaz is a more popular library than Spark.

I'll be so happy when scalaz has finally gone the way of Lift.

The overlap between cats and scalaz is gigantic idk why you seem to think they are distinct? I'd bet that the overlap between the most commonly used parts of cats and scalaz is even larger.

The main thing scalaz has that cats doesn't is scalaz.concurrent.Task, and there are multiple typelevel-endorsed alternatives to it being worked on as well (in monix and fs2). Task is wonderful btw.

fwiw we use scalaz at work and haven't upgraded to cats because it isn't ready. cats just fixed a performance bug that would have destroyed us (Map union mappend was ridiculously unoptimized compared to scalaz's). We .foldMap(/* make a small Map*/) all the time and it's one of our favorite parts of scalaz. see https://github.com/typelevel/cats/issues/1290 for the bug.

The main thing that scalaz has that cats doesn't is Tony Morris.

How are Cats and Scalaz different? I haven't played with Cats lately, but last I looked it was just a reimplementation of Scalaz.

Typelevel didn't even want to fork Scalaz to begin with. That was only their plan B, plan A was to take over the community with code of conduct/social justice shenanigans, and then expel people they didn't like. The fork is just what they came up with after dibblegate failed.

This desperate rewriting of history is one if the reasons why large parts of the Scala community are happy to get rid of these nutjobs.

They need to move their lazy asses to Haskell and start fixing and implementing the tooling there instead of enjoying their free ride in Scala while constantly shitting on the language and its community.

It's not a rewriting of history. The dibblegate conflict occurred at the end of 2014.

https://groups.google.com/forum/#!topic/scalaz/9X_putSGoCY

https://groups.google.com/forum/#!searchin/scalaz/code$20of$...

Calling Tony Morris a rapist was probably the highlight of the affair: https://twitter.com/shajra/status/544712807220908032

Up until they realized they couldn't take over the community, Lars Hupel and Miles Sabin had no publicly stated plans to leave Scalaz.

Cats initial commit is early 2015.

https://github.com/typelevel/cats/commits/master?page=74

I have no idea why everyone dislikes them so much. I use Scalaz, and it's pretty great. From what I've seen Cats is nearly the same thing, I just saw no reason to switch. In what way do you believe Cats is significantly different from Scalaz, beyond the fact that you apparently dislike the people involved?

Incidentally, scalaz-streaming was also pretty nice - mathematically I liked it but it was simply not as performant as Akka streaming. I'd love to use it if it becomes fast.

I have no idea what you are even trying to argue.

Why would they create cats while they still had hope to save scalaz from its community? No need to spin some crazy conspiracy.

> you apparently dislike the people involved

LOL WTF? That guy has single-handedly destroyed more than one community already. It's not like it's some unfortunate thing that accidentally happens. It has happened before, and will keep happening until he is shown the door for good.

The rest of the scalaz community are enabling him to keep doing his toxic shit. The faster scalaz goes the way of Lift, the better.

I judge people for using scalaz. If you think it is acceptable to keep enabling him, you are a bad human being.

If you scroll up, you'll see I was replying to this:

it's desperate desire to turn Scala into Haskell ends up turning an awesome ML-inspired language into a vastly inferior religious (...ahem, pure) language. But Cats and Shapeless aren't Scalaz.

I claim that from a technical perspective they are more or less equivalent and they only forked due to a feud. So if you want to avoid Haskell-inspired constructs in Scalaz, Cats won't be much to your liking either.

Glad we are on the same page!

And if you scroll up, you'll see that this wasn't me.

I don't have issues with Haskell-inspired constructs, I have issues with Haskell-inspired behavior.

Can you let me which open source community you prefer? Clearly It's the more welcoming one.

> Official Scala documentation never even mentions the word "monad"

By coincidence, I was reading the official guide to Futures yesterday: http://docs.scala-lang.org/overviews/core/futures.html

And was (pleasantly) surprised to find that it contains the sentence "Try[T] is similar to Option[T] or Either[T, S], in that it is a monad potentially holding a value of some type" as well as a later reference to "monadic operations without side-effects".

actually without some concepts its pretty hard to not have boilerplate code. I mean OptionT and maybe OneAnd is pretty useful.

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.

What are those issues?

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

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?

The compiler apparently.

Related discussion: Policy – A fork of the Scala compiler [0]

[0] https://news.ycombinator.com/item?id=8276565

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

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.

Reply on news.ycombinator.com