11 ms·

I find the Haskell type system much easier than the Python type system. I'd argue that Haskell actually has a pedagogy problem, because many of its proponents

I find the Haskell type system much easier than the Python type system. 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. However, you don't really have to understand any of that to get started in Haskell, and much of the blogging community has (I think wrongly) focused on explaining advanced concepts rather than making easy introductions. You don't have to deal with monads any more than you have to deal with Python's OO behavior - which is to say, for quite a while. I'd also argue that once you take in to account the sometime strange OO implementation of Python, and that Haskell has type inference for most things, Haskell is easier to understand the high level concepts in. Typeclasses and higher order functions (functions which act on functions) provide a very neat way to substitute in different types to your algorithm without having to change the whole thing, and don't even delve in to the complicated world of functors and monads.

millstone 12y ago
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.
Jare 12y ago
> 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.
lispm 12y ago
> 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.
- CHY872 12y ago
  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.
  - lispm 12y ago
    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
    - Amadiro 12y ago
      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.
Perseids 12y ago
> 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?
- Amadiro 12y ago
  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.
  - gjm11 12y ago
    > 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/ 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 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/ 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/ 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.
jgg 12y ago
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-standard-prelude-circa-1994/ 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.

millstone 12y ago

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.

Jare 12y ago

> 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.

lispm 12y ago

> 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.

CHY872 12y ago
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.
- lispm 12y ago
  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
  - Amadiro 12y ago
    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.

Perseids 12y ago

> 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?

Amadiro 12y ago
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.
- gjm11 12y ago
  > 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/ 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 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/ 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/ 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.

jgg 12y ago

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-standard-prelude-circa-1994/ 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.