The problem is people constantly try to explain it using some kind of real world comparison to make it easier to visualize (“it’s a value in a context”, “it encodes side effects”, “it’s a way to do I/O”, “it’s just flatmap”, “it’s a burrito”), when all it really is is an abstraction. A very, very general abstraction that still turns out to be really useful, which is why we gave it the cryptic name “monad” because it’s difficult to find a name for it that can be linked to something concrete simply because of how abstract it is. It really is just an interface with 2 key functions: (for a monad M)

- wrap: (x: T) => M[T] // wraps a value
- bind: (f: (y: T) => M[U], x: M[T]) => M[U] // unwraps the value in x, potentially doing something with it in the process, passes it to f which should return a wrapped value again somehow, and returns what f returns

Anything that you can possibly find a set of functions for that fits this interface and adheres to the rules described by someone else in this thread is a monad. And it’s useful because, just like any other abstraction, if you identify that this pattern can apply to your type M and you implement the interface, then suddenly a ton of operations that work for any monad will also work for your type. One example is the coroutine transformation (async/await) that is an extremely popular solution to the Node.JS “callback hell” problem that used to exist, and which we call do-notation in Haskell:

// instead of
const getPostAuthorName = foo => getPost(foo).then(post => getUser(post.authorId)).then(user => user.username)

// you can do this
const getPostAuthorName = async foo => {
  const post = await getPost(foo)
  const user = await getUser(post.authorId)
  return user.username
}

This is a transformation you can actually do with any monad. In this case Promise.resolve is an implementation of wrap, and then is an implementation of bind (more or less, it slightly degenerate due to accepting unwrapped return values from f). Sadly it was not implemented generally in JS and they only implemented the transform specifically for Promises. It’s sad because many people say they hate monads because they’re complex, but then heap praise on Promises and async/await which is just one limited implementation of a monad. You may have noticed that generators with yield syntax are very similar to async/await. That’s because it’s the exact same transformation for another specific monad, namely generators. List comprehensions are another common implementation where this transform is useful:

// instead of
const results = []
for (const x of xs) {
  for (const y of ys) {
    results.push({ x, y })
  }
}

// you could have
const results = do {
  const x = yield xs
  const y = yield ys
  return wrap({ x, y })
}

Another (slightly broken) implementation of monads and the coroutine transform people use without knowing it is “hooks” in the React framework (though they refuse to admit it in order to not confuse beginners).

Fuck… I actually just wanted to write a short reply to the parent comment and devolved into writing a Monad Tutorial…

Isn’t a monad just a monoid in the category of endofunctors?

The Codeless Code : Monolith http://thecodelesscode.com/case/143

On the topic of Monads: http://thecodelesscode.com/topics/monads (though the other one really needs you to read the rest of the site to get a better understanding of the monk Djishin and the Java Master Banzen … and remember there’s css hidden topics along with image mouse overs… in case you read the first hundred and then realize that there’s more to each one and have to go back and read them all again).

If you use JavaScript, you’ve probably seen a monad, since Promise is a monad. Unit is Promise.resolve(), bind is Promise.then(). As required, Promise.resolve(x).then(y) === y(x) (unit forms a left identity of bind), y.then(Promise.resolve) === y (unit forms a right identity of bind), and x.then(y.then(z)) === x.then(y).then(z) (bind is essentially associative).

You even have the equivalent of Haskell’s fancy do-notation (a form of syntactic sugar to save writing unit and bind all over the place) in the form of async/await. It’s just not generalized the way it is in Haskell.

That’s because PowerShell blurs the line between programming language and scripting language. By accessing the entire .NET library, of course it’s going to have more features than a basic scripting language that relies on open source utilities installed on the system.

The reasons people hate it are because they hate Microsoft, it breaks from traditional shells too far, and it’s a pain in the ass to type (verbose). To use PowerShell effectively, you almost need to write full software programs. At that point, just use C#.

As for you preferring it to Python… I think you don’t know Python. I’m trying to come up with every way possible to make PowerShell sound better than Python, and I got nothing. Maybe you don’t like whitespace? I cannot understand your point of view here. Help me out

I use both ALOT professionally. I can say I prefer Python over PowerShell anyway… Except for Windows automation, where PS is actually pretty dope. Bash is okay, I’ve seen folks write shit in it that should have been done in Python, or GoLang, or literally anything else.

That being said, I won’t go near Rust, not because it’s a bad language feature wise, but my brain hurts when I try and read Rust code.

No amount of reading will replace experience. At some point you will come to the place where you’ll be the one who know why something that sounds good won’t be and why it won’t get adopted, but if you only base your decision on the opinions of others, you’ll never really learn anything.

The 2 that I struggle with on a daily basis:

• missing discriminated unions. Third party libraries kind of sort of fill the gap, but it’s a pain point.

• a flawed async programming model. Namely, there are multiple models (for historical reasons / backwards compatibility), and the more current one (task-based) throws a wrench in your ability to effectively design interfaces, functions, delegates etc. that can be shared between synchronous and asynchronous code. Green threads would have fixed this, at the cost of some other potential issues, but it looks we’re stuck with tasks for now. Also, there is the awkwardness of needing to constantly use .ConfigureAwait(false) after every await, unless you shouldn’t (e.g. in the UI thread), and if you get it wrong you might cause a deadlock in your app but not in a console app… A bit confusing and easy to mess up.

Oh yeah?

• [ ] I am not a robot

Solve that.

Ecosystems matter, though. In fact, I think they’re the hardest part to learn for most languages.

You can try to get away from NPM, but you’ll always run across instructions on how to do a thing in NPM. Do it any other way, and you’re on your own.

You can try to write Java in a less verbose way, but the standard library will fight you before we even talk about third party libs.

Yeah. I think Forth is kind of just interesting for what it is and it fits it’s niche well. If you’re looking into Forth you probably appreciate it for what it is, and it’s a super flexible language so it can kind of be what you want it to be. It’s obviously not perfect, and it’s not the ideal fit for what most people want to do… but I guess people just don’t really expect it to be more than it is and it’s a smaller community so nobody is too vocal or angry about it. People will complain about other niche languages like lisp, ocaml, prolog, or Haskell all the time, but people don’t say much about Forth, and when somebody does talk about it it’s pretty much all praise. The Forth people are just content I guess!

Yeah, wasn’t suggesting they were. KDE uses them. Since they’re not willing to take user feedback, thought I’d mention it here.