Hacker News new | past | comments | ask | show | jobs | submit login

In principle I agree with this. But as a relative beginner to Haskell operators and their precedence levels are a barrier.

Operators/functions like `+` have well-understood semantics but I don't see how anyone could have an intuition for what `.:` does.

On precedence, I find myself wishing my editor could show me the expression fully parenthesised so I can see if I'm not mentally parsing it correctly.




Operators/functions like `+` have well-understood semantics but I don't see how anyone could have an intuition for what `.:` does.

As with many concepts in programming, or any other field that has its own language for that matter, a lot of this comes down to experience.

If you're used to OO-friendly languages like Java or Python, you probably think of the operator (.) as looking up a field or method on an object. If you're used to FP-friendly languages like Haskell, you probably think of (.) as function composition, and it's just as familiar and everyday a sight.

To someone who is new to Haskell or broader functional programming concepts, it might not be immediately clear why ($) is useful if you already have (.), but it's something you soon use as second nature. Before long, you come across concepts like Functor, Applicable and Monad, and with them operators like (<$>), (< * >) and (>>=). The behaviours those operators represent don't even exist outside the context of the underlying abstractions, so someone who isn't familiar with the abstractions won't understand what those operators mean or why they are useful. Again, though, in Haskell these things are routine, everyday tools, just like using (++) to increment a variable in a language like C or JavaScript. That increment operation makes little sense in a functional language where mutability is not the default, and Haskell has no direct equivalent and indeed uses (++) to mean something completely different.

By the same token, to someone who uses (.) all the time for composition of two unary functions, using (.:) for composition of a unary and a binary function is only a small mental jump and makes sense.

None of this is to say you can't take things too far, but it's important to distinguish between using unnecessarily cryptic notations for no good reason (usually a bad idea) and using notations that might appear cryptic to someone who doesn't yet know the concepts but that provide a concise notation for something that is used all the time by someone who does (often a good thing).


If we teach operators to children they won't become adults biased against some operators they haven't learned.


See Silhouette's post that is parallel to the parent. These operators don't make sense until you know the underlying concepts. Teaching the whole thing to children seems ambitious enough to probably be unrealistic.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: