Live data from Hacker News

Typelevel Scala

github.com

1–10 of 57 posts

Re: Typelevel Scala

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

Re: Typelevel Scala

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

Re: Typelevel Scala

#5
post #3

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 :)

Re: Typelevel Scala

#6
post #3

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.

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.

Re: Typelevel Scala

#7
post #3

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.

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

Re: Typelevel Scala

#8
post #3

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.

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.

Re: Typelevel Scala

#10
post #3

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.

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)?

Post reply on HN