In the early '70s, there was a global movement in math pedagogy that took this angle to elementary learning.
Instead of arithmetic, first graders were taught set theory. Elements and unions became the first mathematical concepts introduced to 6-year-olds.
In the US, I think they called it "New Math". Here in Finland, set theory was included in the national educational system's grand redesign. Regardless of country, set theory as elementary math seems to have gone out of fashion as quickly as it gained traction, and by the early '80s was out everywhere.
Maybe, if they had stuck with it, we would all be using Haskell now as a side effect :)
(Here's a picture of a very '70s styled Finnish math teacher doing set theory: http://1.bp.blogspot.com/-vWW22FRIdfc/TobxIw3xF3I/AAAAAAAAHa... -- "Now tell me children, what is the union of green swans and red bears?")
That's obvious if you program, though (to me). What you can do in one language, you can do faster, slower, more concise, more verbose, more symbolic, more literal, and so on, in another. You can build constructions and you can break them apart, depending on what layer of abstraction you can get to. You can call it by it's specific name and functionality, in how the part interacts in relation to the parts around it, or you can call it objects and morphisms.
I might be totally wrong, again, or using the wrong words and confusing everyone including myself (which is why I like to study formal languages, too). But I think that no matter where you start from, you will eventually find yourself in a place where you are scratching your head, confused about what you know, what you don't know, what everyone knows, and what everyone doesn't know.
Oh, and it's probably totally obvious if write proofs, believe in induction, and get very philosophical.
Does it even make sense for someone to not believe in induction? It's a perfectly valid logical rule.
using Haskell now as a side effect
Very clever.https://www.youtube.com/watch?v=Vetg7vWitTU
(In case you don't know Lehrer, he did PhD studies in math at Harvard, and taught at Harvard and MIT, often performing his songs during his lectures (or composing songs FOR his lectures.))
... and Santa Cruz! I was one course shy of taking his last course (Infinity) before he retired.
The difficulty I find with Haskell itself (setting aside FP basics that exist in many languages these days), is the math requirement. Why requirement? Well, it may be possible to use Haskell in isolation without knowing category theory and higher level math in general, but in the real world, Haskell libraries are in fact based on and assume a foundation in category theory and general understanding of higher level math (see the uber popular Lens library, Yesod, Conduit, or really any non-trivial library implemented in Haskell).
Hand wavy stuff like, "oh, you don't need to know that, it's all just simple building blocks", mixed with, "go read this paper [filled with unicode symbols that have no meaning whatsoever to someone without a background in higher level math]" creates a split message, on the one hand Haskell is simple; on the other, beyond complex.
I'd say that F#, OCaml, and Scala are all more accessible than Haskell just due to their placing less of a cognitive burden on the beginner. Learning Haskell feels like reverse engineering my mind.
Will be interesting to see how things play out, Haskell is moving fast and is clearly ultra popular here on HN, perhaps startups are already using Haskell in anger (i.e. over Rails, Play et al).
I think that this is largely a documentation issue rather than a language issue; that is, while certainly its a language issue -- a strength -- that implementing things with a strong basis in (e.g.) category theory is facilitated in Haskell, its a documentation issue that many things implemented in Haskell libraries are not explained in a manner accessible to programmers who don't have that kind of background.
Lens actually has a great tutorial in its standard documentation. You aren't required to read all the theoretical foundations. Trying to explain the logic under JS truthiness will make your head just as spinny.
But as a fair warning it's role is as a synthesizing text for first-year PhD students in pure mathematics. The author's goal is essentially to prepare students to study algebraic geometry, which is one of the most obscure areas of contemporary mathematics research. That doesn't make it any less enjoyable of a book, and it has a lot of topics that are mostly unrelated to algebraic geometry. The point is it's not an easy book by HN standards.
I suppose I should have begun by stating that CT is a new lens on the world and any reader interested in understanding it needs to have the, typically mathematics-derived, patience to really slow down and re-evaluate the way they view some friendly concepts. But I think even with that the "Socratic" rhetoric employed is helpful.
So, I totally agree but even if it's a bit off a waterfall it's not one that I feel too bad about encouraging people to jump off of.
I agree :)
I've seen "Conceptual Mathematics" recommended by several people for learning Category Theory.
I must have more than 15 hours of material that I recorded as I was piecing together what I was (and am) learning. I should put them online - I haven't done it yet because I think it drags on for too long, but maybe I should put up one or two and judge from the comments and go from there.
Mostly I gathered these ideas by first finding out that Set Theory is at the beginning of math. Then I found out how categories and types and sets are all equivalent. Then I read some papers that explained that and for that they needed to step back and give some intuition of each and how they relate to each other. I explored so many links, but the knowledge is scattered.
I will publish some of the stuff I made, now that I know there's interest, when I'm back home on Monday. If you want to know about it, send me an email (it's in my profile page) and I'll let you know.
So publish it! Please!
If you feel your math is too rusty to follow along, http://jeremykun.com/primers/ should get you started, and then just choose the topic in http://jeremykun.com/main-content/ ... or maybe the other way around :)
When I learned Haskell, I just read Learn You A Hasekell in a few days, and immediately understood the practical value of Algebraic Data Types. They simply are like the types in C,Java,etc but more general because unions can have "fields". This alone means you can represent things like Maybe without any trouble, whereas in C/Java, you'd have to use casting, explicit tagged unions, or the visitor pattern. ML has largely the exact same features as Haskell, except you have to explicitly say which module you're using, instead of the typeclass system doing it for you. Do you also "get" ML? It sounds more like you are claiming to "get" some sort of theory, rather than Haskell or ML, which are trivial, but you make it sound like you need to be somehow enlightened to understand.
The only hard part I ever found in Haskell is lazy evaluation, which to me is just another type of magic which nobody gets, just like the Java Memory Model. The other hard part of Haskell are the extensions to type classes, which make you start thinking about open research problems.
edit: Which part of the above is downvoting material? Please explain so I can avoid being downvoted in the future.
I've been plugging it a lot lately, but here's a post I wrote trying to emphasize this: http://tel.github.io/2014/07/23/types_of_data/
But then somehow I finally understood that Haskell is (trying its best to be) Math. I had a deeply mistaken idea of what math is and I thought I "hated" it and that any kind of advanced math is too hard for me. I have failed Calculus before, though I've always done well in discrete math.
It was only when I realized that math begins (or does it?) with what you have (objects, sheep, anything you want to count) and what you can do with them (group, make a set, join two sets, etc). Then I went into a reading spree about all ofthose very basic and foundational aspects of pure math (pure as in "look around you, you can count things, you can group them based on some trait, you can do operations based on groups, you can now think of those groups as the entities to focus on, you can prove certain properties about those groups, etc") and I found it amazing that so much can be known and discovered from starting with just what you see around you.
When I understood that math starts with just looking around you then I finally made peace with math, and I saw that it was good, that it was here to help me. Then I looked at Haskell again, and suddenly Void, Unit, Either, Maybe, they all made perfect sense. Maybe is a function that takes your set and gives you a new set that looks the same, but has a special entity that means "the lack of an entity in this set"; in other words, Maybe adds a zero to a type. It's simple and easy for me when I choose to see it that way. Everything is a lot more concrete and I have even drawn all these concepts and they map very well to visual ideas. So many things in Haskell are recurring themes (like adding a zero, starting things with a "one" entity, etc) that if you have a good relationship with math, many things fall into place just nicely.
But I started Haskell hating math and that has held me back so much. So my advice would be to never deny that Haskell is math, but to explain what's so awesome about math, how it gives us so much certainty even if we only assume very basic and seemingly obvious statements. I could have used some rough advice like "listen, stop whining about math, you're wrong about what you think math is, it's much more fundamental and it's a tool to help you organize any set of ideas you have, so why would you not apply that to programming?"