Hacker News Reader

Comment by wcrichton | Hacker News Reader

I also find it strongly problematic that functional languages with customizable infix operators (e.g. Haskell and OCaml) have lines of code like this:

  whileM ((<=) <$> readLeftIdx <*> readRightIdx) $ do

And, from what I've seen in a few Haskell codebases, this isn't all that uncommon. I refuse to believe that there's not a better way to express these kinds of programming patterns. I recognize that applicatives, functors, etc. have their value in creating well-engineered interfaces, but when they manifest themselves in obscure operators, it feels self-defeating.

View on HN

The example you quoted is probably the very basic of operators and idioms being used. These operators have standard meaning in terms of fmap and applicatives.

But, I agree with you that there are obscure operators scattered around the code base and I have to keep jumping away from that point to lookup what the particular operator means in that context.

the operators $, <$>, <> in haskell are like the pointer related stuff in c. Everybody knows what the difference between foo and foo is and what the arrow operator (->) does. Its just really, really common so you pick it up pretty quickly. I know its a bit overwhelming at first, but thats not because it is difficult, but because the paradigm is really different and it needs these quick but obscure operators to not drive developers insane.

While Haskell does have customizable infix operators which can be overused and abused, that line isn't a good example of the problem in my opinion. The three infix operators there ($, <$>, and <*>) are all extremely common in Haskell code and are built-in to the language.

Every competent Haskell programmer will be intimately familiar with those three operators.

The problem arises when new libraries introduce new infix operators. I find this highly annoying and almost always consider it a code-smell. So honestly we're in agreement in general, just not with that particular example. I consider those to be basically the "arithmetic operations" of function application. Considering the entire language is based on function composition and application, I don't think it's a bad thing for an economical notation to be used.

While they may be common, they're not actually built into the language. They're just regular functions.

Sure, they're library functions, but they're also specified in the haskell 2010 spec. That makes them built-in from a practical perspective.

Do you really think it would be clearer to write

    cond = do
      li <- readLeftIdx
      ri <- readRightIdx
      return (li <= ri)
    
    -- ...
    whileM cond $ do ...

Personally, I don't think it adds much clarity. It just makes the code more verbose.

As someone who doesn't know Haskell, I can understand your version. I had no idea what the other one does.

Maybe that's not a reason to avoid the more concise syntax, but a language that is more comprehensible and intuitive to people unfamiliar with it is more likely to capture mind-share.

Just because something is unfamiliar doesn't make it worse. Operators, once learned, can greatly improve readability of code.

If you had never seen +,-,%,• before, simple math statements would be inscrutable. But, once you take the (short) time to learn them you can express things much better than if you had to write `add`, `subtract`, etc everywhere.

> If you had never seen +,-,%,• before, simple math statements would be inscrutable. But, once you take the (short) time to learn them you can express things much better than if you had to write `add`, `subtract`, etc everywhere.

A point that is particularly poignant to anyone who has ever dealt with code using custom numeric types in a language that doesn't let you define custom operators (or overload operators).

Both versions are equivalent. The reason why you didn't understand the original version is that, as you say, you don't know Haskell. But, if you learnt Haskell, the original version would've been just as easily comprehensible.

But your point is nothing more than a tautology. "You understand something you chose to learn and understand"

The other version, however, is more readable to anyone who isn't a software developer by profession, but has been exposed to at least some code or even pseudo-code. It's the difference between turning people off of programming versus keeping them interested.

> But your point is nothing more than a tautology. "You understand something you chose to learn and understand"

It's not a tautology. Especially in a language like Haskell, where it's very easy to write incomprehensible programs, even to experts, by following “common sense” principles.

> The other version, however, is more readable to anyone who isn't a software developer by profession, but has been exposed to at least some code or even pseudo-code. It's the difference between turning people off of programming versus keeping them interested.

I don't want to turn anyone off, but I also don't want to make an effort to accommodate people who aren't willing to learn. If other people like programming for what it is, that's great! If they don't, well, that's okay too. To each their own.

I get that and agree with you. My point is that it's easier to evangelize for a language that is intuitive and comprehensible with only limited exposure to the language. Languages like go are a good example of this. If you've ever done any programming, you can read go code and know what it does. even if you've never written a single line of go code in your life. I'd say Elixir, a functional programming language, is also good in this regard.

Interesting. I wonder to what degree that influences language popularity.

I suggest the following plausible points:

1. Nobody is born knowing a programming language. Languages have users to the degree that they convert non-users into users.

2. Sometimes people are forced to use a language for a job (which is, I suspect, somewhat common, but less common than hiring someone who already knows the desired language). Others are forced to learn it to pass a course. Other than those cases, though, languages convert non-users into users in proportion to how much a non-user gets rewarded for the first attempts to write code in that language. This was one of the virtues of BASIC, for example. I picked up BASIC from the TRS-80 manual in an hour, and was writing code that afternoon. I got immediate feedback (we didn't call it a REPL on BASIC, but it had one). You could just read BASIC code.

But if I have to learn a mathematical notation, or a 1000-page book, in order to be able to do anything that I want to do, I have to want to learn that language more before I'm going to bother to learn that language.

Other than university people, Haskell seems to attract people who have been around the block enough times to know why they might want to learn FP, and therefore who care enough to make the effort.

Maybe I'm weird, but I make sense of code as much as possible from static information, without actually running it in my head:

(0) Type signatures (obviously).

(1) Abstraction boundaries - which implementation details are not exposed outside of a module, class, whatever.

(2) Documented preconditions, postconditions, invariants and algebraic laws.

(3) In impure languages, the scope of mutable variables and effectful procedures.

> My point is that it's easier to evangelize for a language that is intuitive and comprehensible with only limited exposure to the language.

I have to admit I don't care much for technological evangelism. I prefer to let technical merits speak for themselves. To be more precise, I'm okay with others showing me technologies I might like (“good” advertisement), but I'm not okay with others trying to convince me to like whatever they like (“bad” advertisement).

> If you've ever done any programming, you can read go code and know what it does.

That hasn't been my experience, and I've honestly tried. If you show me a heavily concurrent Go program, I can't easily tell on a first read whether the program is correct, or, if it's incorrect, where the problem might be. Just because I can run a program (in the sense of myself acting as the interpreter), it doesn't mean that I actually understand its design. :-p

> I'd say Elixir, a functional programming language, is also good in this regard.

I haven't actually tried it, but the fact it's designed to be similar to Ruby doesn't inspire much confidence on me. I don't mind Ruby's syntax, but the impossibility to make sense of Ruby code other than by trial and error is incredibly frustrating.

> Do you really think it would be clearer to write

Absolutely, anyone with programming experience can make sense of the longer (and still quite terse) version.

    whileM ((<=) <$> readLeftIdx <*> readRightIdx) $ do

is literally symbolic soup without knowing the context and language in which it is written. For example `(<=)` could be less than or equal, but then again, given all of the other operators, who knows, might pipe output into whatever's calling `whileM`.

> Absolutely, anyone with programming experience can make sense of the longer (and still quite terse) version.

Is that true? I'm skeptical.

Why is the "<-" symbol clearer to you? In particular, why did the commenter above write

    li <- readLeftIdx

instead of

    let li = readLeftIdx

I don't think anyone with programming experience could correctly answer this question unless they also have some specific Haskell experience.

What exactly does "return" do? I don't think someone without Haskell experience has any chance of answering that correctly, because it does not have the same meaning that it does in most languages. You might be able to make a reasonable guess, but you're unlikely to actually get it right.

I think once you're at the point that you can completely understand and answer these questions, the odds are high that you'll appreciate a more economical syntax for these operations.

The repetion of `<-` for both li and ri seems to imply setting the variable on the left with the value on the right.

As for return, even if the semantics of return are different in Haskell the keyword itself is quite common in programming languages. Therefore, given that it's the last statement one can assume that it returns the result of `(li <= ri)`.

If you know Haskell then the one liner is likely obvious. If not, not at all, there's a lot of domain specific knowledge required to grok what the one liner actually does. The long form version at least provides some guide posts to work off of.

I don't deny that there's value in having someone with no experience with the language be able to make some reasonable guesses about what the code does. It's hard to argue that this could ever be a bad thing.

At the same time, I think it's less valuable than it might seem. A vague, cursory understanding is enough in this case to get a gist of what's happening, but it's not enough to actually work with the code, except via luck. The intuition you describe works okay in this case, but it would fail somewhat spectacularly in other cases, for instance with the non-determinism of the list monad.

> The repetion of `<-` for both li and ri seems to imply setting the variable on the left with the value on the right. (...) one can assume that it returns the result of `(li <= ri)`.

No, that's not what it's doing. It's not imperative assignment. It's not even a `let` binding. Against popular belief, you actually need to learn a programming language to make sense of code written in it.

> If you know Haskell then the one liner is likely obvious. If not, not at all, there's a lot of domain specific knowledge required to grok what the one liner actually does.

s/Haskell/C/, s/one/hundred/g

Even if `<-` is not assigning a value, within the monadic context bind is doing just that, assigning result of the expression on the right to the variable on the left.

The point is that everyone can take a guess as to what's happening in the long form version.

> Even if `<-` is not assigning a value, within the monadic context bind is doing just that, assigning result of the expression on the right to the variable on the left.

What about monadic actions that may return less or more than one value? For instance, parsers for languages with non-deterministic grammars, that return all valid parse trees, rather than just the zeroth one.

> The point is that everyone can take a guess as to what's happening in the long form version.

And that guess would often be wrong.

My point is that a Haskell programmer would be able to make sense of either version equally easily. Chaining applicative actions using <$> and <*> is a very common idiom. If you don't know it, you don't know Haskell.

What makes an operator "obscure"? Can functions be obscure too? What makes a function "obscure"?

You don't like punctuation in your identifiers. It's a a fair objection, and a common one for people whose native language uses a small alphabet (as opposed to CJK and other languages that are ccustomed to using wide range of glyphs)

Reply on news.ycombinator.com