> The above is roughly equivalent to this in haskell:
It's not equivalent.
> How do you avoid pollution?
Haskell has <$> and the infrastructure of HKTs to stop this infectious propagation of IO, other languages do not, and their async/await colors do not isolate side-effectful actions from the rest pure parts of your codebase.
I said roughly equivalent. Async functions pollute and represent io in the same way the io monad does.
The io monad does not isolate io from your pure code. It’s infectious just like an async function.
It’s the abstractions and ways to stop the infection that makes the code pure. You don’t even need hkts to do this. Most languages don’t have a type representing this infection. The infection propagates everywhere without anyone realizing it. The IO monad explicitly tells the developer that the infection is occurring.
I’m saying that async functions do the same thing as the io monad.
The <$> operator in Haskell is just sugar for patterns to stop the pollution from occurring. You can implement it in typescript too. It just won’t be as general as that operator is defined across functors. In typescript you would define a function across only promises.
> I’m saying that async functions do the same thing as the io monad.
> The <$> operator in Haskell is just sugar for patterns to stop the pollution from occurring.
No they don't. Async functions aren't IO actions in Haskell terms, and for the latter argument of <$>, you need referential transparency (via laziness) too, otherwise your attempt at "sugaring" your async functions will break at the first binding expression in a local scope for future processing elsewhere:
...
let arg = processData <$> ioAction
in ...
Do you want to wrap-and-call-later all of these cases into lambdas by hand? :) Show me an example of that being done in a type-safe way in typescript, and I'll point you at the layers that will break composition at the next binding.
If You want to redefine the meaning of roughly equivalent then that’s your prerogative. There’s an isomorphism I’m referring to here and if you fail to see it that’s not my problem.
As for the rest of your argument, the point is to not use async functions locally in the context of pure logic. The pattern is imperative shell, functional core.
Adding a property-changing prefix to "equivalent" makes it non-equivalent, I thought you would understand it if you were using the word "isomorphism".
> the point is to not use async functions locally in the context of pure logic. The pattern is imperative shell, functional core.
The point is that IO actions aren't `async defs`, because async defs don't have two important properties to hold eqivalence to IO actions in Haskell. I'm not sure why you're trying to cherry pick arguments to see your argument fit into the slots that don't accept coloring keywords where they don't belong to: seamless composition.
You’re just playing pedantic games. By roughly equivalent I mean isomorphic. Do you not get it? Isomorphism isn’t equivalency. Sure thanks for pointing the obvious out. Why don’t we get with the program rather than state pedantic details?
IO actions aren’t equivalent to async defs. I never said that. I said roughly equivalent which means isomorphic.
I’m not sure why you’re trying to say I’m cherry picking my argument when I am the one dictating the point here. I made the first statement and you responded to it and you started out your previous response by trying to turn the conversation to your point.
Bro I made the point. I’m not changing the point. You need to not change the topic. In the very beginning I said functional core imperative shell. That’s the point.
I guess the io monad doesn’t prevent people from writing shit code in Haskell. You’re weaving in and out of io constantly with almost everything polluted with IO. Pure functions are scattered randomly in a patchwork of compositions without delineation between purity and IO. You don’t see that there needs to be a layer between the two.
> I said roughly equivalent which means isomorphic.
"roughly equivalent" isn't the definition of isomorphic, and I hinted which properties a type system and the runtime have to support for that isomorphism to be manifested in a language implementation, which isn't there for all of the mainstream languages, unless you're willing to provide that conversion by hand.
> when I am the one dictating the point here. I made the first statement and you responded to it and you started out your previous response by trying to turn the conversation to your point.
You're simply wrong, that happens.
> In the very beginning I said functional core imperative shell. That’s the point.
That terminology only exists as a coping mechanism for those on the mainstream languages. In Haskell everything is functional composition, and `IO a` is neither exempt from it, nor is made into a special case. When you realise this I'll congratulate you on becoming less ignorant.
I’m not continuing this further. The thread has turned from discussion to conflict and we are both at fault. I’m ending it here and pray that dang doesn’t come along and flag the whole thing. Good day to you sir.
It’s eye opening if you get it. I realize this thread is childish and arrogant but that’s largely orthogonal to the epiphany you gain from grokking Haskell.
Haskell has <$> and the infrastructure of HKTs to stop this infectious propagation of IO, other languages do not, and their async/await colors do not isolate side-effectful actions from the rest pure parts of your codebase.
> Which ones? I think there's always some way to isolate, even if ugly.
Almost all of them? You need referential transparency (via laziness) too, otherwise your attempt at isolation will break at the first binding expression in a local scope for future processing elsewhere:
...
let arg = processData <$> ioAction
in ...
Do you want to wrap-and-call-later all of these cases into lambdas by hand? :)
It was fascinating to discover a similar channel from (presumably, or at least, as he claims to be) a russian lawyer who does this as a hobby, and very successfuly so: https://www.youtube.com/@adekvate/videos
> then they won't be compelled away from what actually matters – the engineering.
Maybe it is, to the extend that playing with lego blocks authorised by the lego corporation is considered engineering. That, of course, is a silly line to draw for defining the discipline.
> we all have way more fun diving deep into crafting the perfect type in Haskell
What Haskell allows you to do in practice is defining required and missing control flows (for solving your problems) as types[0], and constraining those types with rules that define your business domains the control flows must operate in. That is the actual engineering, as opposed to joining plastic bricks.
> What Haskell allows you to do in practice is defining required and missing control flows
It allows that in theory, at least, certainly. That's the whole reason for its existence. But in practice, developers become enamoured with the language and start to forget about the problem. If that weren't a problem we'd all be using Haskell, but back in the real world.
The reason we’re not all using Haskell is because like any language it has pros and cons and isn’t the best choice for every niche. Not because “developers become enamored with the language and start to forget about the problem”.
Anyway, why do Go fans always reach for the Haskell strawman in discussions like this? Most mainstream languages are not nearly as exotic as Haskell, while also not being intentionally crippled like Go. But for some reason Go fans always want to compare it to Haskell.
Even JavaScript, Python and Java are not allergic to adding modern features like iterator map/filter/etc., do you think those are esoteric ivory tower languages too?
> The reason we’re not all using Haskell is because like any language it has pros and cons and isn’t the best choice for every niche.
Exactly. Thanks for reiterating.
> Anyway, why do Go fans always reach for the Haskell strawman in discussions like this?
What's a Go fan? Someone who thinks that Go blows? That is as bizarre as becoming enamoured by a language. What leads one to have feelings about a language anyway? It is an impossible to understand concept for me.
> Even JavaScript, Python and Java are not allergic to adding modern features like iterator map/filter/etc.
In what world are patterns from the 1960s "modern"? Do you consider selt belts in cars to also be a modern feature?
> What leads one to have feelings about a language anyway?
Not a single person reading this thread believes that you are a coolly detached rational observer
Responding to an argument by not only pretending not to have an opinion, but pretending not to understand the concept of having an opinion, is a very interesting rhetorical strategy. Not sure it works
> Not a single person reading this thread believes that you are a coolly detached rational observer
All one of them?
> Responding to an argument by not only pretending not to have an opinion
The "argument" has only ever been about sharing of that which we understand as fact. One can present a case for why an apparent fact is not factual – mistakes and misinformation can, indeed, slip in – but what is fact would not rest on one's feelings towards it. The story of Go is the same whether you love it, hate it, ascribe no emotion towards it, or even if you have never heard of it before.
> but pretending not to understand the concept of having an opinion
Feeling and opinion traditionally do not imply the exact same thing – they are different words for a reason – so it is not clear if you misspoke, don't recognize a difference, or if you are trying to change the subject, but I will, for the sake of quality, assume the former. While I can understand feelings in some contexts, like feelings towards people, I have no idea why an inanimate programming language would conjure feelings? That is like developing feelings towards a grain of sand you found on the beach, which I don't understand either.
I am not about to claim nobody develops feelings for inanimate programming languages. Humans are varieitied and can do all sorts of weird and wonderful things, but that does not imply I understand it. Feel free to explain it, though. That's the beauty of not understanding something: You get to learn!
I mean, that's why I also asked last time. Surely you're not one of those anti-education types?
> Not sure it works
Okay, cool. Is this some kind of problem, or why are you mentioning it?
reply