3 ms·

> Like dieters falling for magic 10-minute-miracle exercise gadgets, developers seem ready to fall for easy solutions to the latest crises in their field. > Ju

> Like dieters falling for magic 10-minute-miracle exercise gadgets, developers seem ready to fall for easy solutions to the latest crises in their field. > Just like "mostly secure," "mostly pure" is wishful thinking. The slightest implicit imperative effect erases all the benefits of purity, just as a single bacterium can infect a sterile wound. Taking the analogy to its logical conclusion, the only healthy diet is a 100% strict diet allowing no impure substances. Very few people can actually live this way and it's questionable whether anyone should. The author's audience is those who wish to make safe programs. He advocates modeling all effectful computations using the type system using the framework of monads. He acknowledges that there are even more expressive frameworks like separation logic systems, but that these require too much theory to be useful to the everyday developer. So the author clearly acknowledges the tradeoff between pragmatism and safety, but it's unclear why it's better to draw the line at monads rather than separation logic. Many software developers draw the line at, "seems like it should work" and most are satisfied with the type of "mostly safe, mostly functional" assurances offered by Rust. Very few go as far as to prove their programs safe in separation logic, and indeed the cost benefit is questionable for most software systems. In my earlier career, I might have read an article like this and become some sort of a monad zealot and insist that the entire codebase has to be rewritten using monads in pure functional style. In most cases, this would be a highly questionable decision. If you are writing a game, or making a web server for a dating app, an imperative style is probably the better choice.

ParetoOptimal 3y ago
If we take familiarity out of the equation, why is a web server inherently better implemented in an imperative style rather than a functional one using monads?
- markisus 3y ago
  Familiarity is part of the equation. Writing an efficient web server requires being familiar with the imperative model since the underlying specs, protocol reference implementations, and libraries are probably given in imperative style. Familiarity aside, using a monadic style introduces constraints in your code. I concede that sometimes those constraints will protect you. But for most use cases, these constraints will just produce nuisance compiler errors, forcing you to write dummy wrapper functions to coerce certain types into other types. Consider the example of a loop whose condition and body are dependent on user input and a global state variable. global max_iterations = 100 def get_messages(): iterations = 0 messages = [] while input() != 'quit' and iterations < max_iterations: messages.append(input()) iterations += 1 Writing this in monadic style requires much more finesse. The global variable must be eliminated. Then function body has to be represented as an expression of type IO[list[string]]. The loop body evidently has type (bool, int, list[string]) -> IO[(int, list[string])], and the conditional has type int -> IO[bool]. Sequencing the conditional and the body requires a recursive function and then maybe a lift operators to convince the compiler that the types work out. See https://conscientiousprogrammer.com/blog/2015/12/11/24-days-of-hackage-2015-day-11-monad-loops-avoiding-writing-recursive-functions-by-refactoring/ https://conscientiousprogrammer.com/blog/2015/12/11/24-days-...
mrkeen 3y ago
>> Just like "mostly secure," "mostly pure" is wishful thinking. The slightest implicit imperative effect erases all the benefits of purity, just as a single bacterium can infect a sterile wound. > Taking the analogy to its logical conclusion, the only healthy diet is a 100% strict diet allowing no impure substances. Very few people can actually live this way and it's questionable whether anyone should. I have a simpler one: "Mostly const". Mostly-const gives you the best of both worlds: you get the benefits of knowing it stays the same, and the practicaliy of being able to change it (despite those const zealots who demand that you shouldn't change const variables) Erik Meijer is pushing back on language designers that push self-contradictory feature: "It's OO AND functional! Best of both worlds."
jt2190 3y ago
> … [T]he author clearly acknowledges the tradeoff between pragmatism and safety, but it's unclear why it's better to draw the line at monads rather than separation logic. Probably because programmers are already writing functional code in “mostly functional” languages, and they’re not writing separation logic.

ParetoOptimal 3y ago

If we take familiarity out of the equation, why is a web server inherently better implemented in an imperative style rather than a functional one using monads?

markisus 3y ago
Familiarity is part of the equation. Writing an efficient web server requires being familiar with the imperative model since the underlying specs, protocol reference implementations, and libraries are probably given in imperative style. Familiarity aside, using a monadic style introduces constraints in your code. I concede that sometimes those constraints will protect you. But for most use cases, these constraints will just produce nuisance compiler errors, forcing you to write dummy wrapper functions to coerce certain types into other types. Consider the example of a loop whose condition and body are dependent on user input and a global state variable. global max_iterations = 100 def get_messages(): iterations = 0 messages = [] while input() != 'quit' and iterations < max_iterations: messages.append(input()) iterations += 1 Writing this in monadic style requires much more finesse. The global variable must be eliminated. Then function body has to be represented as an expression of type IO[list[string]]. The loop body evidently has type (bool, int, list[string]) -> IO[(int, list[string])], and the conditional has type int -> IO[bool]. Sequencing the conditional and the body requires a recursive function and then maybe a lift operators to convince the compiler that the types work out. See https://conscientiousprogrammer.com/blog/2015/12/11/24-days-of-hackage-2015-day-11-monad-loops-avoiding-writing-recursive-functions-by-refactoring/ https://conscientiousprogrammer.com/blog/2015/12/11/24-days-...

mrkeen 3y ago

>> Just like "mostly secure," "mostly pure" is wishful thinking. The slightest implicit imperative effect erases all the benefits of purity, just as a single bacterium can infect a sterile wound. > Taking the analogy to its logical conclusion, the only healthy diet is a 100% strict diet allowing no impure substances. Very few people can actually live this way and it's questionable whether anyone should. I have a simpler one: "Mostly const". Mostly-const gives you the best of both worlds: you get the benefits of knowing it stays the same, and the practicaliy of being able to change it (despite those const zealots who demand that you shouldn't change const variables) Erik Meijer is pushing back on language designers that push self-contradictory feature: "It's OO AND functional! Best of both worlds."

jt2190 3y ago

> … [T]he author clearly acknowledges the tradeoff between pragmatism and safety, but it's unclear why it's better to draw the line at monads rather than separation logic. Probably because programmers are already writing functional code in “mostly functional” languages, and they’re not writing separation logic.