Hacker News Reader

Comment by mjw | Hacker News Reader

[only tangentially related to the sentiment here but:]

There is this tendency (which I can sympathise with but only to an extent) in mathematics and to an extent computer science.

"Let me solve the problem once, in as general and as abstract terms as possible. Leave the lesser minds to prove the corollaries, to apply the work. Let them take on the cognitive load of rephrasing their problems into my abstracted vocubulary in order to benefit from my vast insights and my generalised theorems."

But, crucially in software development, formal systems are designed for the human brain -- and not just individual brains but whole teams of them. Programs become as much a medium of communication between humans and other humans (of varying skillsets) as between humans and computers.

You can't escape UI work and UI considerations, I guess is the point :)

View on HN

You can’t escape UI work in math, either. The comprehensibility of the notation system is crucial to forward progress. Which makes it unfortunate that a lot of mathematical notation ends up being unnecessarily arcane, taking ideas that make perfectly clear sense graphically or intuitively and mangling them into an impenetrable tangle. And I don’t think there are enough serious challenges to bad notation: if a notation has worked for a few people trying to prove things, others too often accept it and move on.

Some of the complexity may be necessary in the name of precision, but a lot of the time it’s simply a design failure. Part of the problem may be that it doesn’t seem like mathematicians get any real training in notation design or abstraction communication. Theorem proving exercises in school almost always stress rigor over clarity of explanation: proofs in homework are always either correct or not correct, and what is tested by them is students’ comprehension of existing notation and previously developed abstractions, but there is no exercise which tests students ability to invent good new abstractions or notations.

I think this line of reasoning is why the C# team avoided the M word and introduced Linq for a range of things (sequence comprehensions, reactive programming etc) and is introducing the async syntax for more stuff in 5, even though they could all be implemented with the same more general model.

[edit] the M word is Monad

I don't think there's anything inherently wrong with monads, it's just that nobody's figured out how to explain them yet :) This is somewhat compounded by the awful name and Haskell's less than practical character. My guess is that they'll turn up in a new language in a few years and everyone will wonder what they did without them.

I would agree. Also, the LINQ interface is the monadic interface with Bind / >>= renamed to SelectMany and return renamed to ToIdentity. You can use these directly or with syntax sugar, so i would suggest that they have already turned up in a language.

Anecdotally, I think microsoft flubbed the introduction by overemphasizing LINQ to SQL. This leaving a lot of developers I know thinking it was a one trick pony and never learning (for instance) LINQ over IEnumerable. Those who have since taken time to learn the non-SQL LINQ features do wonder how the lived without them.

Don't people argue that jQuery is DOM manipulation in monads? I sure ask what I did before jQuery :)

http://importantshock.wordpress.com/2009/01/18/jquery-is-a-m...

HN discussion: http://news.ycombinator.com/item?id=439116

People argue this, but not people who know what a monad is.

Care to clarify, or do you prefer just telling people they're wrong? The linked article is on the surface convincing, but I have never touched Haskell

I've spent more time explaining monads to HN than I have anything else. It comes up at least twice a day and I am tired of writing an explanation twice a day.

Go read the Typeclassopedia.

I think there's also the issue that they're a lot less convenient without built-in syntax (or macros). Haskell's do-notation makes >> look like a newline and >>= look like an assignment. Without this syntactic sugar, monadic code rarely looks like an elegant solution.

Without this syntactic sugar, monadic code rarely looks like an elegant solution.

I'm not sure this is widely agreed-upon. Here's what a program composed of pure functions looks like:

  quux = baz . bar . foo

This is a function of one argument that filters the input through foo, then bar, then baz. Just like UNIX pipes, but backwards.

Now let's try it with monads:

    quux = baz =<< bar =<< foo

Same thing; this is a function of one argument, one that passes that argument through foo, then bar, then baz.

>>= notation is quite elegant. do notation just makes functional programing look imperative.

A monad is simply a monoid in the category of Haskell endofunctors.

Reply on news.ycombinator.com