4 ms·
Monads are similarly fundamental in the theory of programming/computation — when you start considering effectful computation at a deep level, monads come up pre
by Twey 3y ago
Monads are similarly fundamental in the theory of programming/computation — when you start considering effectful computation at a deep level, monads come up pretty quickly, in a way that is independent of the programming language in question. That doesn't mean they'll stand the test of time as well as calculus has — computer science has had much less time than analysis (or physics, as calculus originally was) to get to the bottom of things — but it was at the time Haskell was designed the most fundamental way of talking about these things, and still a main contender. There are other abstractions with nicer properties, like algebraic effects (which compose nicely by default and therefore don't require an equivalent of monad transformers), but they're not quite equivalent in power — whether they're ‘good enough’ to become the de facto representation of effects depends on how we end up capturing the remaining part.
Haskell doesn't impose monads on a more fundamental notion of computation that other languages expose directly, which is how I interpreted your comment; rather, other languages force a particular monad on you at the language level, whereas Haskell lets you choose your monad and even mix and match different monads that suit your program. This does introduce some complexity in exchange for the additional flexibility, and people may reasonably differ on whether that flexibility is worth it, but the complexity results from exposing something more ‘fundamental’, according to our current theories of computer science, that other languages hide from you.
- CyberDildonics 3y agowhen you start considering effectful computation at a deep level, monads come up pretty quickly You say that, but they only seem to come up when dealing with haskell.
- one-punch 3y agoMonads are there in computations that we care about, regardless of the implementing programming languages (e.g., Python, C, Assembly, Turing Machines). Just that Haskell is famous for considering Monads as a first class concept, while many programming languages do not name and reason about them (in Python, C, Assembly, etc.). This is similar to structured loops and function calls (not GOTO), which are in computations that we care about, regardless of the implementing programming languages. Some languages do not name and reason about them (e.g., Assembly, Turing Machines). While it is possible to program without raising the level of discourse, this is discouraged (considered harmful), as it lacks safety, hurts productivity (developer velocity/experience), and scales worse. > > when you start considering effectful computation at a deep level, monads come up pretty quickly > You say that, but they only seem to come up when dealing with haskell. "when you start considering structured computation at a deep level, loops and function calls come up pretty quickly" "You say that, but structured loops only seem to come up when dealing with high level languages." This situation, where a higher level programming language delivers more power (in this case, scales with better developer velocity/experience) but a lower level programmer resists, has been observed many times. Paul Graham calls this the Blub Paradox [1]. What's so great about Lisp? And if Lisp is so great, why doesn't everyone use it?... I'll begin with a shockingly controversial statement: programming languages vary in power. ... But when our hypothetical Blub programmer looks in the other direction, up the power continuum, he doesn't realize he's looking up. What he sees are merely weird languages. He probably considers them about equivalent in power to Blub, but with all this other hairy stuff thrown in as well. Blub is good enough for him, because he thinks in Blub. And using a powerful high level language is "The Secret Weapon" behind the success of Viaweb [1]. Haskell is also a secret weapon for those who know how to use it. [1]: http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html "Beating the Averages"
- CyberDildonics 3y agoI can show you the assembly language for a loop and a function call in a dozen instructions. What is the assembly language for a monad? our hypothetical Blub programmer This is all patronizing rationalization to believe that people aren't picking someone else's favorite language because they "just aren't smart enough to get it". Programming is hard enough without constantly trying to make languages themselves a silver bullet. Fancy macros, fance meta programming, 'pure mathematics' etc. never equals productivity over the long term. Library writers can get away with it, but simplicity wins overall because people can focus on making programs and making tools surrounding the language. Lisp and Haskell were influential, but that doesn't make them good tools by modern standards. They had ideas that made it into other programming languages and that's enough. They did their jobs. Haskell has major programs with controlling order of execution because it pretends it can be abstracted away. "The Secret Weapon" behind the success of Viaweb Haskell users always talk about the same handful of programs that no one would have heard about if they weren't made in haskell. Meanwhile 90% of software that people actually use is basically made in C++, python and javascript. The languages aren't perfect, but when people sit down to program they can move past the language and actually write software.
- flqn 3y agoLanguages that include Option, Promise, and Result other than Haskell beg to differ
- cryptonector 3y agoOnly because mainstream programming languages haven't caught up to Haskell. Not that they haven't tried. Java's interfaces are an application of research done on Haskell. It's just that some new ideas are harder to adapt to existing tools than others.