Hacker News Reader

> much of the blogging community has (I think wrongly) focused on explaining advanced concepts rather than making easy introductions.

I would like to make two notes about this:

- Most of the Haskell tutorial examples are about computing pi, fibs, and other math functions or series. Which is fine, but rather obvious beyond the recursion vs iteration bit. It's not just that newcomers arrive to Haskell with an imperative mindset, it's that they (we?) come with imperative (stateful) algorithms, which of course turn out to be a nightmare to implement.

- I found those explanations about Monads, etc necessary because as soon as I wanted to do anything less obvious than calculating a function or series, it was pretty hard to figure out how to get it done. For example, adding print logs to my code to debug, or building the code to output the formatted result of my program. "Why can't I use map here?" "What is is this mapM thing?" are very real roadblocks.

Those problems are not unique to Haskell, of course, but Haskell's purity makes it much more inflexible - you can't do some part the Haskell way to learn the ropes while you do the rest imperatively to get actual, satisfying results.

You can maybe put off the theory of monads, but their machinery hits you fast and early. For example, the meet-and-greet from Learn You A Haskell:

    main = do  
        putStrLn "Hello, what's your name?"  
        name <- getLine  
        putStrLn ("Hey " ++ name ++ ", you rock!")

The monad effectively introduced a separate syntax for declaring variables, which you must use in preference to let/where, and the compiler will emit a gibberish error message if you mix them up. So you must acquire at least a working understanding of monadic syntax before you can write a trivial program.

> I'd argue that Haskell actually has a pedagogy problem, because many of its proponents are academics or mathematicians, who are comfortable with that kind of language. Talking about monads, functors, and arrows is a very natural activity for them, and clarifies rather than complicates the subject.

Btw. I am a mathematician and the only time I ever had contact with category theory was in a seminar presentation. The great majority of students at our university would be as new to functors as most of you.

But on the other hand the reason I am fascinated by Haskell are all these advanced methodologies that promise to make the act of solving a problem more manageable. To contrast that against the Python/C comparison I find that Python gets less in my way (probably even less than any other programming language I've tried) but hasn't taught me concepts that I didn't already know from C++/Java/…

So the question would be: If you don't want to learn about Monads, why would you come to Haskell in the first place?

Category theory is pretty popular IME, I've seen lots of mathematician talk about it. It seems fairly popular especially with algebraic geometrists and algebraic topologists.

OTOH I've never seen any mathematician use (perhaps with the exception of myself, depending on at what point you start counting a person as "mathematician" and at what point you consider someone to be "using haskell") haskell. I doubt the haskell community actually has any mathematicians, it's mostly just people who'd like to be mathematicians but are too lazy to get a degree.

The overlap of mathematicians who care about category theory (some logicians, algebraic geometrists, algebraic topologists, ...) and mathematicians who program (mostly mathematicians from applied disciplines, numerical methods, computational physics, ...) is pretty much zero.

You probably won't find your algebraic topology professor programming in any language anytimes soon, except LaTeX.

> The overlap of mathematicians who care about category theory [...] and mathematicians who program [...] is pretty much zero. You probably won't find your algebraic topology professor programming

Well, unless perhaps s/he has some involvement in a project like this one http://comptop.stanford.edu/ ("The overall goal of this project is to develop flexible topological methods which will allow the analysis of data which is difficult to analyze using classical linear methods"; first named person in left sidebar is an algebraic topologist).

Or this one http://www.esf.org/index.php?id=8764 ("Applied and Computational Algebraic Topology"; first named person on steering committee is an algebraic topologist).

Or this one http://munkres.us.es:8080/groups/catam/ ("Computational Applied Topology and Applied Mathematics"; directory is an algebraic topologist).

Or, turning away from algebraic topology as such to mathematics inspired by algebraic topology and involving both category theory and programming: http://homotopytypetheory.org/ ("... new program for a comprehensive, computational foundation for mathematics based on the homotopical interpretation of type theory. [...] currently being implemented with the help of the automated proof assistant Coq"; note that in practice doing nontrivial things in Coq is a matter of functional programming).

For sure there are plenty of mathematicians (in algebraic topology and elsewhere) who don't program, but I think the intersection between people interested in categories and people interesting in programming is bigger than you suggest.

I don't know how many of them are using Haskell, though.

Yeah, I'm aware that some projects that apply computer science to pure mathematics (in various forms like Kenzo/CAT, PLEX (not CPLEX, that's for applied mathematics/finance/etc), agda, coq, GAP, ...) exist, but I don't think the claim that they are very very niche with mathematicians is exaggerated.

If you go to your average mathematics department and ask a few professors there that work in logic, algtop or alggeom, I doubt you'll find any that do any programming for their research. You probably won't find that many logicians that use proof-assistants either, although those are probably the least niche category of the things listed (and they are fairly popular with the CS folks)

> However, you don't really have to understand any of that to get started in Haskell

For sure. Then you get a compiler error.

Programming Haskell without understand the type system and lambda calculus is not possible.

Edit: thanks for downvoting me. If you believe that you can program Haskell without understanding the basics of Functional Programming and without understanding the type system, then you live in an alternate reality or want to evangelize Haskell.

I'm sorry, but to be an amazing programmer in Haskell, the understanding you need of the lambda calculus is minimal.. For example, consider this function to compute the Ackermann function in the lambda calculus:

    λx. x (λf y.y f (f 1) ) (λx1 f x.f (x1 f x))

or even just addition

    λx y f x.(x f) (y f x)

none of that will even come up in Haskell.

Even the type system - you need to understand some tiny amount - you can only add ints to ints etc. The more complicated stuff, the type inference, the monads etc - can be ignored until later.

Haskell can be used without understanding - almost all programming languages can. That's why we have so many newbie bugs.

Until later? What later. An hour later?

Let's look at a few chapter titles of Real World Haskell.

Chapter 2: Types and Functions

Chapter 3: Defining types, streamlining functions

Chapter 4: Functional Programming

Chapter 6: Using Typeclasses

Chapter 14: Monads

Chapter 15: Programming with Monads

Chapter 18: Monad transformers

It's a matter of perspective -- to someone who has taken a university class on lambda calculus/on logic that had a chapter on lambda calculus (e.g. as part of a M.Sc. in mathematical logic or CS), anything in RWH would probably seem extremely basic and superficial. It doesn't even introduce most of the basic things a first chapter in a book on lambda calculus would probably introduce you to.

My degree was also heavy on FP and LP alongside many other themes.

I think the biggest issue is with those developers that never got a degree or were unfortunate to land in a degree that taught programming languages instead of programming concepts.

The pretentious view that Haskell's core is a mathematical structure familiar to mathematicians is wrong.

Haskell borrows concepts from category theory (a "field" so abstract from most math that most mathematicians don't need but a handful of its concepts) to label typeclasses, and those typeclasses don't always follow from their namesake.

Further, Haskell could exist and keep its property of referential transparency without the the 'mathematical' structures or their names. Here's a version of Haskell without monads: http://donsbot.wordpress.com/2009/01/31/reviving-the-gofer-s...

Monads, functors, arrows, etc. are more aesthetic than fundamental to the core nature of Haskell. They're just a bookish (and sometimes bureaucratic, IMO) design choice. What I mean by that, is that the language designers took a concept (referential transparency) and built an understandable structure, but beside and aside from this, made a bunch of nested, derived typeclasses of dubious value or purpose. Sometimes I look at a Haskell library and have a more academic version of the, "Why the fuck is this a class?" moment.

I'd like to comment tangentially that Haskell is almost the OOP/Java of the 2010's - the programming community claims that it makes your code "safer", and in some sense it very much does, but its features are being perverted and overhyped while its caveats are being forgotten.