Comment by celoyd | Hacker News Reader

Comment by celoyd | Hacker News Reader

We work in an environment where heresay [sic] and taste drive change instead of studies and models. We are stumbling in the dark.

Another way to look at it is that we’re making progress, but with lots of false starts, like most progress. Hearsay and taste are what happen when people are working with imperfect information. Probably not even Knuth has perfect information about all the studies and models that might be relevant to any nontrivial project.

The author’s point seems to be not that programmers should understand the math behind their work, but that they should do work that’s more like math. It’s true this would mean fewer bugs. But there are a lot of problems that people in the real world would rather have mostly solved by a slightly buggy dynamic program with mutation and state hiding than not solved by a formally proven program.

A lot of programming is stuff like simple CRUD web apps. I’d rather do that in Python than Haskell for the moment. If the author wants to argue that Haskell could be made friendlier without giving up its advantages, that’s an essay I would welcome.

I'm writing a bunch of webapps in Scala making heavy use of Scalaz, which is Scala's Haskell-envy library of typeclasses. The typical pattern is to compute everything as a Validation, which you can think of as the Maybe monad, except there is information attached to the failure case. It's a very nice way of coding. Everything composes and at the end of the request handling chain you just convert to a response and you're done.

It took a bit of thinking to get the basic patterns, and there is the occasional bit of head scratching to get the type right. This feels very much like algebra.

Anyway, the point is that this style of programming is both "mathematical" and practical.

For reference, Haskell's version of that is called Either.

You also sometimes use ErrorT which is a way to slap an Either on any other Monad. The T just denotes that it's a monad transformer.

Coincidentally, I agree wholeheartedly about how practical programming like this is--this sort of error handling is at once easier and more explicit than exceptions.

Why is it easier? That's just doing the monad transformation by hand instead of letting a compiler take care of that for you (in the case of EitherT and do-notation the compiler takes care of the intraprocedural transformation for you). It's rather in the same category as Node.js programmers doing CPS transform by hand.

Haskell's advantages lie in being pure. It can't be 'friendlier,' because friendly languages let you hack things up (and are impure) as opposed to the planning required to lay down some Haskell.

I find it hard to believe that Haskell could not be friendlier. And I say that as a fan of Haskell.

Someone should define "friendly" at this point.

Haskell certainly seems friendly enough to me. It catches most of my errors before I even run the program, it let me hack things relatively quickly with very little code. Yes, there is that "purity" discipline, but I mostly think like that anyway.

Now, it certainly won't be friendly to one who routinely writes code like that:

  if (foo)
    if (bar)
      do_something;
  
  if      (foo) {} // OK, do nothing
  else if (bar) {} // OK, do nothing
  else          { do_something; }

(I saw that yesterday in production code!) Those people think too procedurally to be able to understand Haskell, or even ML. You have to fix that flaw first.

(For the few who don't see the code above as utterly ridiculous, here is the better version:)

  if (foo && bar)
    do_something;
  
  if (!foo && !bar) { do_something; }

I find funny how people want languages to be "friendlier"

It is often an egocentric excuse to not lean new tools... As if programming was about making he programmer comfortable, as opposed to producing the best result possible.

Reply on news.ycombinator.com