Brian Beckman: Don't fear the Monad

I don't know category theory, so I defer to more knowledgeable people here, but that sounds strange: "Functor it understands how to take doStuff and execute it on the value inside itself, then spit out a new Optional. You don't lose the int-ness or optional-ness." So if I map a function, that takes an int and returns a string over an array of ints, this array stops being a functor? Or is it just a Swift thing? And, as always, I urge people spend an hour of their life and get the explanation of all this from someone who knows the math but still able to explain this in plain English: [this video] To the best of my limited knowledge, it's all 100% correct.

> and apparently I'm never going to understand Haskell I found this introduction to the concepts of functional programming (functional composition) to be useful: [this video] Otherwise, it's just a different way of thinking about problems. Instead of building things structurally as an object of objects, and then creating functions that relate, transform, or describe the relationships between the object structures (like taking a pixel object, altering it's x coordinate, and returning the new pixel object with only the x coordinate altered), one has functions that can be composed with other functions to produce more complex object structures. A single base unit with a sequence of functional compositions can describe a very fancy, complex unit, with many fancy, complex characteristics. >> Monads have also been explained with a physical metaphor as assembly lines, where a conveyor belt transports data between functional units that transform it one step at a time.[2] They can also be seen as a functional design pattern to build generic types.[3] [link] Otherwise, it's syntax and semantics, which I generally find annoying, but there's always google and books. [link]

Thats me here too! >.< Yeah the hidden subtext here was my presumption in that suggestion was someone was learning monads in Haskell and has at least a basic understanding of Haskell. Sorry if those papers threw you into the deep end. Monads really were thrown into play due to trying to make a pure functional programming language useful. I found the more mathematical explanation a lot easier than any analogies involving say burritos or pipes etc... At first glance to imperative programmers I will admit all of this just looks like a bunch of navel gazing. I thought the same thing, but once you let go of thinking of computation as a series of steps and at a bit of a higher abstraction this makes a lot more sense. For a more soft introduction to the concepts this channel 9 video is probably a bit better: [this video] Another option might be to just get the haskell programming from first principles book: [link] Does a good job grounding you up to monads and gives copious amounts of reference material. Even though I already knew haskell when I read the book it helped clear up some gaps I didn't know I had. But monads are going to be really weird no matter if all you've ever seen is imperative programming. Despite the fact that you already use them and have probably discovered them without knowing you did. Much like learning stack based programming languages, sometimes the only way up is to climb off the computational hill you're familiar with to learn another way to the other hill side

As Brian Beckman explained, as an aside, in "Don't fear the Monad" [1], these two differing views were born in the '70s and split two programmers into two camps: The bottom-up people, and the top-down people: - The bottom-up people start with the hardware and only add abstractions and trade performance where necessary (fortran, c, java) - The top-down people started with perfect abstraction/logic and reduced/removed abstraction to get access to the hardware and performance where necessary (lisp, ml, haskell) I don't think the two camps may ever get along. Kind of like our version of Conservative and Liberal. (nor should they, in the true spirit of democracy?) [1] [this video]

I think there are several different axes one can split programmer culture down (which may or may not be orthogonal). Brian Beckman explained one such axis, as an aside, in "Don't fear the Monad" [1], about two differing views that born in the '70s and split two programmers into two camps: The bottom-up people, and the top-down people: - The bottom-up people start with the hardware and only add abstractions and trade performance where necessary (fortran, c, java) - The top-down people started with perfect abstraction/logic and reduced/removed abstraction to get access to the hardware and performance where necessary (lisp, ml, haskell) What is interesting these days, is that these two camps are trying to steal more and more ideas from each other [2] [1] [this video] [2] [link] (previous discussion: [link] )

I would complement it with: - Scott Wlaschin's Railway Oriented Programming (ROP): [link] and [link] - Scott Wlaschin's The "Map and Bind and Apply, Oh my!" series at [link] and its concept of an "elevated world". - And for Elixir Programmers, Zohaib Rauf's "Railway Oriented Programming in Elixir" at [link] based on Scott Wlaschin stuff. - [link] . The introductory part (7 first pages of the pdf). - Brian Beckman: Don't fear the Monad [this video] - Philip Wadler's "Monads for Functional Programming" at [link] - HN comment: [link] ROP is a good way to introduce the Either monad without ever talking about monads, functors and co. Moreover it is highly useful.

Right, I understand where I wasn't clear. You're right, that idea has won and gone mainstream so I didn't think it was worth mentioning. I was emphasizing that I thought immutable data structures were inefficient and that it was the luxury of academics to abstract away stateful changes in the name of purity. I've got a couple of other ideas that I need to do more research on (I'm watching Erik Meijer videos today) 1) Class objects with methods and data are like small programs, so I don't get why people go on and on about having data structures with functions as being superior to class objects, which are essentially data structures with associated functions. 2) Similarly, Joe Armstrong seems to hate object oriented programming but Erlang instances are essentially class objects, albeit running in their own process so they have more isolation 3) From reading Erik Meijer's Confessions of a Used Programming Language Salesman, I'm assuming that Async/Await that he help put in C# and Dart are his attempt to bring Haskell continuation monads to the imperative world 4) I'm assuming Clojure Atoms and Actors are like Haskell monads but don't know that. I watched Brian Beckman: Don't fear the Monad ( [this video] ) but couldn't make heads or tails of it. Something about functions calling first order functions and pure first order effects with stateful second order effects, or something... That was a few years ago so I will give it another chance. I'm probably wrong about these ideas but they'

Take videos like this: [this video] The guy basically goes on some pseudo-mathematical journey that has only a tangential relationship with programming. "It's easy to understand!" he claims multiple times. And it was! I understood everything he said. But I had NO idea how to apply anything he said to my application. And so it goes with virtually every article I've ever read about functional programming. The truth is out there, but it's hidden in such a dense forest of obfuscation that I'm not sure I'll ever know what a monad is. The search goes on, but I'm afraid all I'll ever discover is yet another blog post where all the functions are named f(), g() and h(), or something about prime numbers. So I suppose arrogance may be assumed from seeing this concept explained so badly so many times. It's like people who understand functional programming are gatekeepers and do such a horrible job at letting people in that it seems like we've been locked out on purpose.