this post was submitted on 30 Sep 2023
101 points (91.1% liked)
Programming
17526 readers
231 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
I was about to write Haskell or Purescriot but Unison seems like the future if it ever catches on.
Haskell just seems too academic. Monads, monoids, functors, category theory, oof. Most Haskell code I've seen just uses the imperative escape hatch (aka monads) and throws the majority of it there. But the biggest problem is just getting haskell. There are like 3 different ways, and they all come with different package managers (?).
The second biggest problem are "preludes" that add a bunch of stuff to your env (at compile time?), which messes up code completion and "goto definition" stuff. It's like haskell was written by C++ programmers who thought macros were a splendid idea and threw them in.
I've wanted to learn haskell a few times, but with those kind of hurdles, it isn't a surprise that it isn't widely used and mostly copied from. A real pity, as it seems intellectually beautiful.
Those issueThose issues go away pretty quickly once you get used to it. I mentioned unison because it kind of gets rid of that history and instead makeThose issueThose issues go away pretty quickly once you get used to it. I mentioned unison because it kind of gets rid of that history and instead makes it content-addressed **GLOBALLY.
I think the dislike for Functors/Monads/Monoids etc. is super overrated. I'm not a mathematician, but christ these are beautiful abstractions coming from a background in Java and OO programming.
Functor instances are defined by one function. Once you learn the one main thing that Functors do (mapping), you'll understand them no matter the language. Monoids have 2, Monads have 2, etc. Yes all there are functions built in terms of the functions required in the typeclass definitions (or several typeclasses), but they don't need to be known to effectively use the abstractions.
I was able to easily transfer most of my Haskell knowledge to Scala at my last job in the typelevel ecosystem because of HKTs like Functors, Monads, monad comprehensions, Monoids, etc. I was the go-to guy for FP-related questions despite most of my background being in Haskell and not Scala.
Using an Iterable in Java will be different than an Iterable in any other language in at least some respects. Yes they will represent the same abstract idea, but you can't just 1:1 transfer knowledge between different Iterable implementations.
I've programmed professionally in Java, Kotlin, Scala, Ruby, Python, JS/TS, and many more in hobbyist settings, and the cleanest transition was Haskell -> Scala (omitting language transitions on the same runtime, so Java -> Kotlin or JS -> TS).
I don't dislike them, I dislike that absolutely terrible explanations given as to what they are.
"it's just a function" - oh my, never would've guessed. The name gave nothing away.
"given the definition, one can easily ascertain" - oh, it's easy, isn't it? So easy that it's not even worth mentioning.
"given $mathematicalDefinition, where $lotsOfOneLetterVariables, $conclusions" - yes yes, totally understood that.
See haskell wiki, wikipedia, top blog entry #1, top blog entry #2, stackoverflow, LearnYouAHaskell
You can't tell me those are good ways of explaining what those are to somebody with little to no mathematical interest. Maybe the concept is easy, maybe. I mean
map()is quite easy to understand, but if it were explained as badly asfmap, I guarantee you less people would use it.Most people aren't practicing teachers, so it makes sense that not all explanations are the best. Trying to get an intuitional understanding of passing by reference or passing by value in imperative languages is arguably more important than understanding how
mapworks, and yet I'd argue it's also harder to do.If you understand
map(not just lists, but futures, IOs, Options, Maybes, etc.) then you understand Functors. Yes there are laws, but mathematical laws here are just encoding our intuition. Something like Iterator in Java may not have laws, but you would expect that calling.next()doesn't modify an SQL database, though it wouldn't be a technically invalid implementation if it did. The same is not true for Functors. If youmapover a List and the act of mapping each int to its double modified a database then you wouldn't have a lawful functor. But that should make sense intuitionally without knowing the laws.People in OO land are more happy to say they "understand" something if they generally get what the abstraction is going for. Do you know all the methods for Iterator/Iterable in Java? Even if you didn't, you'd likely say you get the "point" of an Iterable. The bar for understanding things in the FP community is usually higher than just understanding the point of something.
This doesn't mean FP is more complicated. Actually it kind of means it's simpler, because it's not unreasonable for people to totally understand what Functors are for all languages that implement them. The same is not true of Iterable/Iterator. There's no way you'd have more than just an intuition about what Iterable is in a language you don't know. I don't program in Agda or Idris, but I know
Functorin those languages are the same as Functor in Scala and Haskell. Same with Monad, Monoids, etc.