> Can we have Exception monads? Asking for friend.
This is nonsensical. Monads define a strict set of behaviors formalized as "monad laws"[0].
Perhaps what you want is a container which adheres to monad laws capable of abstracting exceptions. Two exemplars of same are Haskell's Data.Either[1] and Scala's Either[2].
I don't think it's nonsensical, it's just another name for the same thing. E.g. in the Haskell wiki it says, "the Error monad, also called the Exception monad".
I was unaware of "Exception monad" being an industry equivalent term for Either/Error. Given no other context, desiring an "Exception monad" could be interpreted as "a type which handles raising Exception types." Which is how I did.
Was a desire to have "a type which handles raising Exception types." Until now, I was unaware of "Exception monad" being an alternate moniker for Either/Error types.
> Funnily enough, Go's generics were designed by the same guy who introduced monads to computer science.
No contributor to Go is responsible for "introducing monads to computer science", as the Monad concept is a member of (or defined by if you prefer) Category Theory[0].
As you point out, monads come from category theory, not native to computer science. Thus there had to be someone to introduce approaches to applying monads in computer science. The paper usually credited with that is: https://homepages.inf.ed.ac.uk/wadler/papers/marktoberdorf/b... Which the parent rightfully points out was written by the same person primarily responsible for the design of generics in Go: https://homepages.inf.ed.ac.uk/wadler/topics/go.html
> As you point out, monads come from category theory, not native to computer science. Thus there had to be someone to introduce approaches to applying monads in computer science.
With full respect given to Wadler and his contributions to computer science, the very paper you cite authored by Wadler declares:
The concept of a monad, which arises from category theory,
has been applied by Moggi to structure the denotational
semantics of programming languages.
Therefore, one cannot assert that a computer scientist whom identifies a predecessor's contributions such as above is, in fact, responsible for said contributions.
And with full respect also given to Moggi, introductions are only introductions if they are heard.
If we were talking about the first person to discover monads, Wadler clearly would not be he. Wadler was but a wee toddler barely sputtering out his first words when the term "monad" was coined. As we are talking about who introduced monads to computer science, the signs I see continue to point to Wadler. His work is, by all appearances, what caught the attention of the computer science community. "Monads for functional programming" is regularly cited as the seminal paper. They are strongly associated with Haskell. It would even appear from the previous comment that you only came to learn about Moggi because of Wadler making his introduction, which echos Moggi not being particularly influential socially.
If you have evidence to suggest that Moggi played a bigger role in introducing (not inventing) the concepts, I am definitely keen to learn about it.
> If we were talking about the first person to discover monads, Wadler clearly would not be he.
We are not. Remember what the OP stated, to which I originally replied:
Funnily enough, Go's generics were designed by the same guy
who introduced monads to computer science.
This is demonstrably incorrect, as Wadler did not "introduce monads to computer science" and is what I disagreed with alone.
Did Wadler take monads to new and important levels in both computer science and software engineering? Absolutely!
> It would even appear from the previous comment that you only came to learn about Moggi because of Wadler making his introduction, which echos Moggi not being particularly influential socially.
I quoted the Moggi attribution due to it being present in the paper you kindly provided. Whether Moggi has any influence socially is irrelevant as it pertains to the original thesis discussed above.
> If you have evidence to suggest that Moggi played a bigger role in introducing (not inventing) the concepts, I am definitely keen to learn about it.
Again, this is not germane to the aforementioned OP statement.
Moggi's social influence is everything as introductions can only happen in the social realm. It continues that all evidence I can find suggests that his work went unnoticed until Wadler pushed it into view. In other words, people came to learn about his work only because of Wadler making the introduction. Nobody, except where one may find it trying to be implied in https://qht.co/item?id=48304692, has suggested Wadler invented monads. The OP clearly wrote "introduced", not "invented".
In 2019 I wrote a short survey of C constructs that do not
work in C++. The point was not that C is sloppy or that C++
is superior. The point was that C++ is not a superset of C,
and that C programmers crossing the border should know
where the checkpoints are.
C++ was a superset of C 30-ish years ago. Now, as the author correctly identifies, it is not as both have taken different evolutionary paths.
30 years ago, in C89 and pre-standard C++, it was the case that `int foo()` in C is a function that accepts any parameters, and in C++ it is a function with no parameters. In C89 you have to write `int foo(void)` if you want no parameters. This counterexample to C++ being a superset of C was well-known even back then.
Another well-known counterexample is implicit conversion from void*. In C89 you can do `int* foo = malloc(100);` but in C++ it requires an explicit cast from void* to int*.
I don't believe there was ever a time, even pre-standardization, when C++ was a strict superset of C; it always had little incompatibilities here and there.
> Their usage of upsert appears different than I was used to:
> Them: Upsert = Get or Insert
I agree that their choice of labeling the proposal as "upsert" is less than ideal. However, this functionality is reminiscent of a very useful Perl capability known as autovivification[0] as described in the motivation section:
A common problem when using a Map or WeakMap is how to
handle doing an update when you're not sure if the key
already exists in the map.
> Aren’t you afraid of using a VPN and their being ramifications?
Depending on the sophistication of the VPN software being used network traffic can appear to monitors as UDP[0] packets superficially similar to what many video games produce.
Okay, but user NewCzech posting to HN in the UAE could probably be deanonymized by the UAE for posting their comment, if the government got really interested in the matter.
> ... forbidden knowledge must not be leaked to the public.
Understanding is a personal achievement and has nothing to do with "forbidden knowledge" when the source of said knowledge is both quoted above and freely available.
> That's what a good PM and developer pair should be doing, it's just that it's a lot faster for both of them now to review and work in tandem to get the feature done, because the bottleneck is the code generation.
The bottleneck is understanding, never "code generation."
Below is an an axiom which has served me well over the years. Perhaps it will for you as well.
When making software, remember that it is a snapshot of
your understanding of the problem. It states to all,
including your future-self, your approach, clarity, and
appropriateness of the solution for the problem at hand.
Choose your statements wisely.
In my opinion software is a "set of decisions". If you let the AI loose, you will get software and the AI will make decisions on your behalf. Even if you read the code once for review, you probably won't know what those decisions were, until you've familiarized yourself with the code base.
> Sometimes it is code generation, not just understanding, especially if many of the tickets are just CRUD.
If "the tickets are just CRUD", then code generation reduces to a typing exercise if and only if the requisite functionality of the "CRUD tickets" are understood by the engineer(s) delivering them.
More generally, I have yet to see engineers which understand what needs to be delivered be limited by typing speed. Conversely, I have too often observed rapid code generation lacking intrinsic understanding fail to deliver satisfactory solutions.
> If "the tickets are just CRUD", then code generation reduces to a typing exercise if and only if the requisite functionality of the "CRUD tickets" are understood by the engineer(s) delivering them.
Correct, that's basically most tickets as I had said. They truly are not complex.
This is nonsensical. Monads define a strict set of behaviors formalized as "monad laws"[0].
Perhaps what you want is a container which adheres to monad laws capable of abstracting exceptions. Two exemplars of same are Haskell's Data.Either[1] and Scala's Either[2].
0 - https://wiki.haskell.org/Monad_laws
1 - https://hackage-content.haskell.org/package/base-4.22.0.0/do...
2 - https://www.scala-lang.org/api/3.8.3/scala/util/Either.html
reply