And I wouldn't be surprised if there were more retired left handed surgeons in their 50s living in rural Switzerland than people who understand what he's talking about.
How to reuse `readFile` `writeFile` program with this module trick?
Assuming `IO.readFile` and `IO.writeFile` is replaced by HTTP requests.
I can define `writeFile` and `readFile` in a type class and then implement the effect for HTTP variant, hiding the HTTP client beneath.
Is it just wiring it up in mixins, cabal file?
I think general conclusion is that there's no need for dependency injection, environment objects, or similar tricks if module system is rich enough.
For a long time I questioned why Python needs anything but `async def` or `def` (async should be achievable through module or `yield` usage) and `import` statements, to achieve maximal reuse, given dynamic nature of language and modules. We could ignore all object-oriented features, decorators, replace them with modules. Would be flatter and readable compared to bloated feature set.
Indeed so, but that would require a few months worth of work from the reader, unfortunately.
(I have a t-shirt with a lambda in a circle, reminiscent of the anarchist emblem, and words "no class, no state". It's definitely possible to explain to a passer-by who never studied FP what it refers to, but not in such a way that the joke remained funny. Possibly the same deal is with the bumper sticker saying "my other car is cdr".)
"Humor can be dissected, as a frog can, but the thing dies in the process and the innards are discouraging to any but the pure scientific mind." - E. B. White.
Likely never. The Half-Life has the lambda with the top crooked, neatly inscribed in a circle [1]. The anarchist version has everything straight, and with the three sticks protruding out of the circle (like the A would). The visual rhyme is obvious.
The CS understanding of "No class, no state" is just about at the edge of something Aphex Twin might care about. But the stylized A really isn't that similar to a Lambda
The problem is that this is not only about Haskell's fundamentals. It's about them being extended with backpack, an extension that very few people use.
And honestly, I don't see the point there either. I know that backpack is meant to solve some problem everybody has, but I haven't been able to fully understand what that problem is. Specifically on this article, I don't see the gain over using a type class.
In this case that’s the >>= from Maybe.Monad. As long as you satisfy the signature, it’s happy . do has nothing to do with Monads! Who lied to you?
Could have been a stronger point by using a non-monadic >>=.
I've been doing a lot of parsing lately and I find I don't need to reach all the way for monad (applicative is usually enough). But I guess that's what ApplicativeDo[1] is for.
We’ve got to be explicit now which Functor or Monad we’re importing, and you can’t have do notation for different Monads in the same module.
This is a bit rough for usability (not to mention also undermines the point above).
But overall I like the approach of trying something radically new.
ApplicativeDo can be thought of as a compile-time transformation that turns sequential code into possibly parallel* code just by analyzing the way variables are used. Once I've had that realization I really appreciated it more.
*: By "possibly parallel" I mean the blocks of code are known to be independent from each other. They could be actually executed in parallel if the Applicative instance does so.
even for someone moderately interested in FP, this one goes above my head and the only take-away I can get from it is "maybe use ocaml instead of haskell"
It's more of an experiment: what if we take this beloved feature from OCaml to port it to Haskell (backpack), and see if it can replace a different beloved Haskell feature (type classes).
I'm reasonably versed in Haskell and my response would be that it shouldn't make that much difference to you what they've written in here. I've yet to see any code in the wild using the backpack extension.
> Have you ever seen a Number grazing in the fields? Or a Functor chirping in the trees? No? That’s because they’re LIES. LIES told by the bourgeoisie to keep common folk down.
Grumbling about how typeclasses could just be normal datatypes has been an undercurrent in the Haskell world for a long time, particularly as a way to solve the orphan instances problem. However, the syntactic grease provided by typeclasses is pretty appealing, and in the end I think this may have died down because people developed engineering solutions to the orphan instances problem (mostly "don't") that mitigated the theoretical problems enough that even most Haskellers don't care anymore... but I guess a few do still somewhat, because such things never truly go away.
(And yes, I recognize the quoted sentence as being humorous and labeling the entire article as not entirely serious... my point is that it is not entirely unserious either. The idea has been kicking around seriously for a while.)
There is a really interesting interview with Simon Peyton-Jones referenced on HN yesterday.He talks a lot about why Haskell came about, and some of the thinking behind the design choices that were made.
Delightfully weird and niche article.
And I wouldn't be surprised if there were more retired left handed surgeons in their 50s living in rural Switzerland than people who understand what he's talking about.
How to reuse `readFile` `writeFile` program with this module trick?
Assuming `IO.readFile` and `IO.writeFile` is replaced by HTTP requests. I can define `writeFile` and `readFile` in a type class and then implement the effect for HTTP variant, hiding the HTTP client beneath.
Is it just wiring it up in mixins, cabal file?
I think general conclusion is that there's no need for dependency injection, environment objects, or similar tricks if module system is rich enough.
For a long time I questioned why Python needs anything but `async def` or `def` (async should be achievable through module or `yield` usage) and `import` statements, to achieve maximal reuse, given dynamic nature of language and modules. We could ignore all object-oriented features, decorators, replace them with modules. Would be flatter and readable compared to bloated feature set.
I feel like this article would be much more approachable if it didn't assume readers already know Ocaml and Haskell and their module system
Indeed so, but that would require a few months worth of work from the reader, unfortunately.
(I have a t-shirt with a lambda in a circle, reminiscent of the anarchist emblem, and words "no class, no state". It's definitely possible to explain to a passer-by who never studied FP what it refers to, but not in such a way that the joke remained funny. Possibly the same deal is with the bumper sticker saying "my other car is cdr".)
"Humor can be dissected, as a frog can, but the thing dies in the process and the innards are discouraging to any but the pure scientific mind." - E. B. White.
> a lambda in a circle
How often do people think you're a Half-Life fan instead?
Likely never. The Half-Life has the lambda with the top crooked, neatly inscribed in a circle [1]. The anarchist version has everything straight, and with the three sticks protruding out of the circle (like the A would). The visual rhyme is obvious.
[1]: https://en.wikipedia.org/wiki/Gordon_Freeman#/media/File:Gor...
[2]: https://en.wikipedia.org/wiki/Anarchist_symbolism#/media/Fil...
or Aphex Twin
The CS understanding of "No class, no state" is just about at the edge of something Aphex Twin might care about. But the stylized A really isn't that similar to a Lambda
Haskell knowledge doesn't actually help because this isn't using the (very barebones) Haskell module system, but the Backpack extension: https://www.microsoft.com/en-us/research/wp-content/uploads/...
Yeah, it’s better to not assume anything and be stuck in the basics forever, right?
It would also be a useless article. It's fine to write for an audience, if you're not in the target audience, move on.
It's okay not to know things
Yeah... meanwhile, in lesser languages, type classes is all we have.
In the 2010-2020 era, readers of Hacker News used to know how to read Haskell and had strong opinions (pro and con) of it.
That era is now over.
The problem is that this is not only about Haskell's fundamentals. It's about them being extended with backpack, an extension that very few people use.
And honestly, I don't see the point there either. I know that backpack is meant to solve some problem everybody has, but I haven't been able to fully understand what that problem is. Specifically on this article, I don't see the gain over using a type class.
Maybe in 2010, but you have an idealized view of 2020 HN.
peak FP debate was 2015/2016-ish
I've been doing a lot of parsing lately and I find I don't need to reach all the way for monad (applicative is usually enough). But I guess that's what ApplicativeDo[1] is for.
This is a bit rough for usability (not to mention also undermines the point above).But overall I like the approach of trying something radically new.
[1] https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/appl...
ApplicativeDo can be thought of as a compile-time transformation that turns sequential code into possibly parallel* code just by analyzing the way variables are used. Once I've had that realization I really appreciated it more.
*: By "possibly parallel" I mean the blocks of code are known to be independent from each other. They could be actually executed in parallel if the Applicative instance does so.
Does that mean it may or may not run the code in parallel once compiled? Doesn't seem very ergonomic to the developer if true.
Why isn't it ergonomic? You just read the documentation or source for the Applicative class in question to find out.
If the Applicative class chooses to decide randomly whether to run in parallel, that's the class's fault, not the language or the compiler's problem.
even for someone moderately interested in FP, this one goes above my head and the only take-away I can get from it is "maybe use ocaml instead of haskell"
It's more of an experiment: what if we take this beloved feature from OCaml to port it to Haskell (backpack), and see if it can replace a different beloved Haskell feature (type classes).
I'm reasonably versed in Haskell and my response would be that it shouldn't make that much difference to you what they've written in here. I've yet to see any code in the wild using the backpack extension.
I just picture Charlie from “It’s Always Sunny in Philadelphia” connecting the dots.
Orrrrr just use a lisp?
How does this compose iterators?
"Functors" "Monads" "Typeclasses" <- concepts dreamed up by the utterly deranged
This is in reference to a meme (https://knowyourmeme.com/memes/stop-doing-math) and made relevant by the first paragraph of the post.
> Have you ever seen a Number grazing in the fields? Or a Functor chirping in the trees? No? That’s because they’re LIES. LIES told by the bourgeoisie to keep common folk down.
Grumbling about how typeclasses could just be normal datatypes has been an undercurrent in the Haskell world for a long time, particularly as a way to solve the orphan instances problem. However, the syntactic grease provided by typeclasses is pretty appealing, and in the end I think this may have died down because people developed engineering solutions to the orphan instances problem (mostly "don't") that mitigated the theoretical problems enough that even most Haskellers don't care anymore... but I guess a few do still somewhat, because such things never truly go away.
(And yes, I recognize the quoted sentence as being humorous and labeling the entire article as not entirely serious... my point is that it is not entirely unserious either. The idea has been kicking around seriously for a while.)
There is a really interesting interview with Simon Peyton-Jones referenced on HN yesterday.He talks a lot about why Haskell came about, and some of the thinking behind the design choices that were made.
https://news.ycombinator.com/item?id=45242530
It's okay not to know things
"A monad is just a monoid in the category of endofunctors"
flatMap that s**!
"You just made those words up right now".
I heard it's just like a burrito.
A Burrito is a Monad:
https://williamcotton.com/articles/a-burrito-is-a-monad
Burrito's compose surprisingly well.
Unlike your 's
Fair point's's, I'll use my standard excuse of not being a native speaker. :)
"Hello I would like x<-[1,2..] apples please"
And I'll take 3 of those.