> Haskell wasn’t built on great ideas, although it has those. It was built on a culture of how ideas are treated.

> In functional programming, our proofs are not by contradiction, but by construction. If you want to teach functional programming, or preach functional programming, or just to even have productive discussions as we all build libraries and projects together, it will serve you well to learn that ethic.

> Believe in everyone, attack nobody, even the trolliest.

> If you make even the most modest (to your mind) mistake, be it in social interaction or technical detail, be quick to apologize and retract, and do so freely. What is there to lose? Only your pride. Who keeps track? Only you. What is there to gain? Integrity

> Your self-esteem doesn’t need your help. You may feel you need to prove yourself, but you don't. Other people, in general, have better things to do with their time than judge you, even when you may sometimes feel otherwise.

> Be glad that others are charting other paths! Who knows what they will bring back from those explorations.

> Every time we learn something new and want to share it, we face these issues all over again -- the desire to proclaim, to overturn received wisdom all at once -- and the worse the received wisdom, the more vehemently we want to strike out. But if we are generous listeners and attentive teachers, we not only teach better and spread more knowledge, but also learn more, and enjoy ourselves more in the process.

It's a mindset that shows tremendous respect for others, yet tremendous self-assurance. It's the faith that the best ideas will win out in the long run.

> Now, you’re a social person, and you want to go forth and share all the great things you’ve learned. And you have learned enough to distinguish some true statements from some false statements, and you want to go and slay all the false statements in the world.

I learned some Haskell recently and I'm somewhat enthusiastic about it. It's a very difficult language, I took a lot of effort to learn Haskell compared to most other languages. It's still difficult to understand other libraries and code. But personally, For me, it was worth the effort to learn and understand it.

I don't think it's worth the effort for everybody. I don't think it's fun for everybody. I don't think it's the best tool for everything. I have no desire to spread the good word.

If you start from the premise that it's the best language out there, everybody should learn it and that it is easy, you'll get into trouble.

Edit: I don't get the downvotes -- maybe I did not express myself clearly?

My reason for downvoting you was that it seems you didn't understand that this essay is a "Letter to a Young Haskell Enthusiast", it's not for everybody, it's for a young haskell enthusiast, that's the point.

Your comment seems to have no place if you think about the kind of people that essay is aimed for.

Everyone needs a periodic reminder to keep their ego in check. On the one hand it drives ambition, spurs achievement, and encourages personal development. There is almost unlimited power in the concept of self.

Me against the world. My achievements.

I think this attitude is very prevalent in programming and the tech world in general. It is manifested and reinforced by the wild popularity of startups (My idea is good and I can go it alone) and the tech visionaries (Gates, Jobs, Musk) who seem to carry the weight of the world on their shoulders.

On the other, overfeeding your ego will make you narcissistic, selfish, insecure, and hostile. You will lose your empathy for others, and ultimately, your humanity, as you start to lose sight of the big picture: progress is a process that started long before your time and that will continue unimpeded to infinity, even after your infinitesimally tiny ego is wiped from existence.

As Isaac Newston put it best: "If I have seen further it is by standing on the shoulders of giants."

"If I have not seen as far as others, it is because giants were standing on my shoulders."[1]

[1] http://en.wikiquote.org/wiki/Hal_Abelson

Newton was possibly the greatest intellect that humanity ever produced, but he was not a nice person.

Ah, the original humblebrag.

What it wants you to do, slay false statements and spread what you know, is exactly the kind of thing that goes terribly the minute you fail to figure out what is true and what is false. Very few things in computing are really black and white, but spending our time proselytizing just leads to more thinking in a black and white world, and adoption of technologies that might leads us in the completely wrong direction (Hello Spring!)

What we have to tell a young language enthusiast is that there is much insight in ideas different than our own, and that there is much to learn in looking outside of what you consider the best. Maybe there are tools that are better suited for other kinds of problems. Maybe not everyone that disagrees with you is very wrong about things and needs to be converted.

I mean, how can you even try to ask people to improve their communication skills, when you say that people that do not think programming is math is because they have the wrong notion of math?! I just don't see how you are going to convince anyone of anything with that level of condescension.

Frankly, and being a bit meaner than I should, it seems to me that the reason Haskell can't catch on is precisely that enough of its community thinks like this.

I like what the article is trying to do, but I must admit there is something off about it. Maybe it's me, but I read between the lines something like "you and me both know Haskell is the best language, but try to be gentle with unbelievers and admit that nobody, even Haskell programmers, is perfect. Other languages have some good insights, too." which sounds a bit cultish to me, a bit like teaching a Jedi knight to be humble. A truly open-minded position would have to continually consider that maybe Haskell and its type system are not the best options at all, instead of merely adopting a humble attitude and avoiding aggressive confrontation.

Nothing wrong with believing a tool is better than others (I do!) but it makes the article sound a bit condescending...

I'm ready to admit maybe I'm wrong and there is no implied presuposition that Haskell is superior in the article :)

----

Re-reading other comments, here is something related to what I've just said. Someone quoted Newton: "If I have seen further it is by standing on the shoulders of giants."

That statement sounds humble (a "humblebrag", some other commenter called it) but carries the implication that you have, indeed, seen further. Maybe the assumption that you as a Haskeller have "seen further" sounds immediately condescending to others who think differently.

There are two ways that I can parse this comment. The first is that you mean that there are other, newer options out there that will turn out to be better than Haskell. This, almost all Haskellers would agree with: most of us have more than a passing interest in e.g. Idris, Agda, Shen, etc.

The other reading is that you mean that other established paradigms are better options (A third reading is that there is no such thing as better, but for that I'll just point you to pg's classic Blub essay). This is a good thing to consider once, but I strongly disagree with considering it continually. Once you've made the comparison, if you come to the conclusion that one tool is better than another, it doesn't make sense to continue that comparison forever. It may make sense to revisit it from time to time as you grow in your understanding of the task and the context, but at some point your posterior probability of the other tool being better must grow so low as to no longer be worth investigation. For many Haskellers, the comparison between a Haskell-like type system and dynamic typing is this kind of comparison. My posterior probability of dynamic typing being a better choice is less than one percent, so it makes no sense for me to continue reevaluating that option.

If the latter is what you mean, I can't disagree that it is a truly open-minded position, I can only point you to a quote by the inimitable Tim Minchin: "If you open your mind too much, your brain will fall out."

I'm just writting a device controller in a side project (at userland - I already have enough problems to solve - the kernel sees it as a soundboard and a USB TTY). At fist I tought "wait, great time to try some serious reactive programming in Haskell", but I gave up, C++ looks much better fit to that problem. When it's done, I'll probably write some Haskell wrapper, and use it in a functional reactive program, but Haskell is just not the language for the controller itself.

Also, another side project requires a CRUD web app, with some simple rules. It's in Python. No way I'm going to write it in Haskell. Another component is a TCP server with a complex behaviour and that I want to scale, it's in Haskell, no way I'm going to write it in Python. Another component is in VB.Net, go figure...

Maybe there is a young and mostly unkown language that is indeed best - no strings attached. But it's certainly not Haskell and I still didn't find it.

The existence of specialized domains justifies an argument that you should use specialized languages in those domains, but that is almost never what we're discussing. Java, Python, Ruby, Haskell, Clojure... none of these are languages specialized for a given domain. They're all general-purpose languages, and if you compare them as such independent from their libraries, Haskell is the best of them. That does not mean that it's the best choice for every project, but that's a completely different question.

It's the flexibility of Python that makes it great for writting CRUD applications with diverse data types, at the same time that it's the rigidity of Haskell that makes it great for writting a complex specialized server. It's the unsafety of C++ that makes it great for directly interfacing devices, but you really does not want that unsafety in any of the other examples.

None of that is a matter of maturity, it's the other way around, the available libraries are good for different tasks because the languages allow them to be. You can't just compare those languages without context.

The only possible argument against static typing comes in the form of a program that won't typecheck, but should. This is the only type of "flexibility" that Python could win at, with regard to type systems. Please, show me a practical example of such a program. I've asked a dozen people for one, and nobody has ever followed through.

The only other argument against Haskell's "flexibility" I can think of would be against purity, but that argument doesn't fly either. Any competent Haskell programmer can work easily with state, IO, etc, and I've never run into an effectful task in practice that takes meaningfully longer to do in Haskell than in Python.

People are often quick to typecast languages into some role that seems to fit. Haskell is rigid and mathematical, Python is flexible and readable, etc. These impressions rarely come close to capturing the reality, and in this case end up being downright misleading.

If I'm starting developing a web application from scratch, with zero libraries available to me, I'm picking Haskell without a shadow of a doubt.

Haskell is in the oposite extreme of that dimension.

Anyway, that has no relation to readability. Python's flexibility leads too easily to metaprogramming, for example, what's extremely powerfull, but a nightmare to read. And classifying a language as "mathematical" is borderline nonsensical - it only carries some slight meaning because people that say that normaly want to say "algebrical", in oposition to, maybe, "logic-temporal".

The characteristics of Python you just mentioned are only specific to it in cases when they are erroneous. They basically all evaluate to "Python isn't type-safe." So again, show me a program that is best represented in a non-type-safe way, and I will concede the point. If you can't, then this flexibility you're praising isn't a feature, it's a bug.

They are explicit at the official documentation, if they got there by error, they are official features now.

> They basically all evaluate to "Python isn't type-safe."

Yes, they do. They are at the opposite extreme from type-safety. That's why I used them to exemplify how it's the languages that apply better to some problems.

> So again, show me a program that is best represented in a non-type-safe way, and I will concede the point.

Well, any Django[1] CRUD would do. They are quite trivial, in there's little meaning in specifying exactly the manipulated data. Yes, Haskell has tools for displaying data at the web, and querying a database; no they are simply not as powerful when applied to that problem.

[1] In other frameworks they are about as simple, but you asked for one example.

If you'd like something more "dynamic" (i.e. type-unsafe), you can instead just define a "universal data type" for all your CRUD data. For example you could define, say

   data Any = Number Int
            | Str String
            | Map String Any
            | Date ...
            | ...

EDIT: Thus you've confined all the "fuzziness" of your data definitions to a "subsystem" of your system and you can still benefit from proper types and type checking everywhere else.

My own opinion is that sometimes you're right and your interlocutor is wrong, and sometimes this means you simply cannot avoid sounding condescending.

Here's the Lisp people. They're sure that they are at the top of the power curve (including compared to Haskell), and they can tell you exactly why. "How can you get anything done in Haskell? It doesn't even have macros."

Over here are the Haskell types (pun intended). They're sure that they are at the top of the power curve (including compared to Lisp), and they can tell you exactly why. "How can you get anything done in Lisp? It doesn't even have a decent type system."

This situation - two different languages each looking down at the other - reveals the problem in pg's Blub Paradox. The problem is this: The idea that all languages can be ranked on a one-dimensional axis called "power" is wrong.

You can see this with hardware, for instance. We know what power is in hardware - it's MIPS. But once you think a bit deeper, you might remember that your workload contains a fair amount of floating point, so you have to worry about FLOPS... and there's that one data set that doesn't fit into cache, so you have to worry about memory bandwidth... or would it be worth lower MIPS to have a bigger cache? Now "power" has at least four dimensions (MIPS, FLOPS, memory bandwidth, and cache size). Even more (but for the same reasons), it's naive to say that programming languages can be strictly ordered according to on a one-dimensional "power" axis.

So now you have to start asking "power for what"? I think this is the right question, because nobody ever writes a general computer program. We always write specific ones. We want a programming language that has the most power for that specific problem we're trying to solve.

Once you crack open that door, in walks (for example) a Fortran person, who asks, "How can you get anything done in Haskell or Lisp? They don't even have decent matrix packages!" And before you say "of course they can do matrix math", by "decent" the Fortran person meant a package that can, for example, efficiently handle a banded hermitian matrix with complex elements, and still get good answers even if it turns out to be a stiff problem. I strongly suspect that Lisp and Haskell matrix packages aren't yet up to that standard. (And if you're going to say, "Well, that's just a niche", I suspect that niche is at least as big as the entire Haskell universe.)

Then a hard-real-time embedded programmer comes through the door, and says that their world needs a language that not only doesn't garbage collect, but doesn't cons either. (That niche is probably also as big as the Haskell or Lisp universe.)

And so on.

Think of programming languages as a tree. Think of your problem as a vector. Use whatever branch of the tree gets you the furthest along the vector of your problem. In other words, the best tool for the job. It's not always Haskell. It's not always anything. Learn more than one tool.

The solution to your Lisp v. Haskell dilemma is simple: ask the people who know both. I agree with Lispers that macros are powerful, and the stuff in the book Let Over Lambda is ridiculous and awesome. I also think that macros are dangerous, and I prefer to only use them if there's no other alternative. I pick Haskell over Lisp, having used them both extensively, and I've seen far more people come to Haskell from Clojure than the other way around.

With regard to Fortran, embedded, etc, see my response to marcosdumay. Yes, those niches are sizeable and you should use the correct tool for the job. That has no bearing, though, on the question of which programming language is better.

True, but such a normalization is not unique. That is, one language or the other can come out as "more powerful", depending on the normalization chosen.

Your point about "ask those who use both" is harder to refute...

You're projecting a level of condescension onto Gershom's words that just isn't there and makes no sense within the context of the article. His point is that the "debate" about programming/mathematics is largely one of semantics and consists of well-intentioned people arguing from a different set of definitions. I'd hardly consider this to be a controversial statement, much less condescending.

... Are you sure your clearly preconceived notion about "Haskell People" didn't taint your perception?

"Every time we learn something new and want to share it, we face these issues all over again -- the desire to proclaim, to overturn received wisdom all at once -- and the worse the received wisdom, the more vehemently we want to strike out. But if we are generous listeners and attentive teachers, we not only teach better and spread more knowledge, but also learn more, and enjoy ourselves more in the process."

The article says exactly the opposite, but you're too lazy to read.

(though I can see how the endless feature-incorporating (typeclass-based) refactor cycle is particularly relevant to Haskell - come to think of it, I think many somewhat older Haskell developers could stand to take from this too)

Letter to a Young Visual Basic 6 Programmer

[...]

So how do you help them want to learn it too? You do not tell them this is a language for smart people. You do not tell them you are smart because you use this language.

[...]

I'd go so far as to say it's a good read for many humans, whether they're programmers or not.

This tactic is used a lot in evangelism talks and it doesn't work. A lot of the non-FP people listen to these talks and come away thinking, "this person is obviously really smart", and then it comes up in the discussion afterwords, so not only is it unhelpful, but it distracts from the message and perpetuates exactly the myth that we're trying to dispel. We have to calibrate to the audience's understanding of relative words like "smart".

I tried to say something like this in another comment. I am a Haskell fan, but the article sounds like evangelism -- and like with evangelism, its tactics of always-show-you're-humble will inevitably annoy a large number of people.

(This is not a caricature. People on this board - though not necessarily this thread - have come across that way to me.)

However, it is much healthier to present Haskell as simply a tool for writing better and safer code, which is frequently easier to reason about than your conventional for-loops all the way down. So everyone should try it, and say for themselves.

I may be wrong and over-generalizing here, but Haskell is a very convenient vehicle for showing off and belittling others. And honestly, who does not want to stick Haskell somewhere in their CV just to look better nowdays? Being fancy has a cost for the language. This is not an intrinsic fault of Haskell. People just need such a thing. If there were no Haskell, we would have APL, Lisp, Erlang, C++, or something like this.

You don't defuse arrogance by saying "Look, I'm not smarter than you. This is easy. Now let's talk about Monads, they're just like Tacos. I'm patient."

Better be honest and say "Look, I'm not smarter than you. This is hard. We need to start with data types, and the benefits won't be obvious until long down the road."

Having TAed intro classes at a university, I can say from experience that new students pick up functional style much quicker and are always confused by mutation until they've had a fair amount of experience with it.

    FooT w (BarF x) Baz y z a

This I disagree with. Telling someone that something is hard before you teach it to them is a self-fulfilling prophesy.

My wife is a native Russian speaker, and she is slowly teaching me Russian. I struggle when learning new languages, so it's easy for me to get discouraged when the progress seems too slow.

My wife often teaches me a few words at a time, and without fail, when she says, "This word is hard," before teaching it to me, it takes me the longest to learn those words.[0] It's like my brain, upon hearing that something is going to be hard, assumes that I'll forget it anyway, and simply turns off.[1]

If you are getting ready to teach a difficult topic, perhaps spend a little more time beforehand trying to find good analogies and approaches. Oftentimes, a topic's difficulty melts away when a student can make an appropriate connection.

Don't confuse the difficulty of teaching a topic with the difficulty of learning it.

[0] You might argue, "Those words probably are harder." That's a fair point, but in the hours before our wedding, I managed to learn how to say, "Я знаю что я никогда не буду голодным. [I know that I will never be hungry.]" On the other hand, it took me days to learn, "карандаш [pencil]" after she told me it was a hard word.

[1] When I recognized this phenomenon I asked her to please stop telling when she expects something to be hard.

I've witnessed this a lecture: the Professor tries to sell Haskell with the dreaded quicksort one-liner. In my opinion, that's the classic show-off example where it's easy for somebody who knows Haskell but hard for somebody who doesn't. Most of the class thought "obviously this is beyond my capabilities" and tuned out.

Of course, students should also know that hard problems are overcome by effort, not intelligence. I know the effect you're talking about, but it is a good habit to consciously not try be discouraged by hard problems.

I don't think it is. I think (as is the case with functional languages and languages with non-Algol-inspired syntax generally, and Haskell falls in both groups) Haskell is harder to learn as an N+1 language than an imperative language with Algol-inspired syntax if you are a programmer whose existing familiar is with N languages that are all imperative languages with Algol-inspired syntax, for N > 0 (and this is increasingly true with increasing values of N.)

If you've got some background in functional languages without Algol-inspired syntax (e.g., Lisp) and some background in statically typed languages (even imperative, algol-inspired ones) it doesn't seem to be fundamentally that hard to learn, though.

I think that there is something of a deficiency in that there isn't a lot of good tutorial documentation (at least, that I've seen) for Haskell that is well designed either for new programmers or for experienced programmers without a background in things like category theory, but AFAICT that's not anything fundamental about the language, but more something about where it came from and who the early audience was. As Haskell seems to be getting broader attention, I expect that will improve.

Syntax differences very clearly are a source of difficulty for many people learning new languages, especially when there experience is focussed on a particular syntax style.

> the very sophisticated type system is.

I don't see any evidence that Haskell's type system makes it harder to learn from an absence of programming knowledge. Like its non-Algol syntax, it probably makes it harder for experienced programmers with habits centered around patterns learned in less expressive static type systems or un-/dynamically-typed languages.

If anything, I think the consistency of the type system and the relative lack of ceremony probably makes it easier, in some ways, than C/C++/Java family languages, where there is lots more type ceremony to learn.

Years pass and I always feel that I got rid of this "proving that I know better" motive but, every time I look back, I always see that I still acted with it and it was usually me who could do better. At the very least, I always feel that I could do better in the social area - like, communication.

I recently used (early July 2014) Haskell for a crud app with a daemon that does some web scraping/form posting where no API existed for a freelance client.

Haskell did not get in my way whatsoever. Here are some general stats about the application:

604 loc (was 1400 at one point, 900 after de-duplication, 604 after refactoring) 112 commits

The crud website and daemon program take up about 200 MB of memory IIRC on a $5 per month digital ocean droplet.

http://blog.emmacodes.com/post/55841830917/minswan

Interesting to note how two different language cultures manage to say this.

(Using it at your day job is a different proposition, of course. I'm still having arguments with my boss over the use of Scala instead of Java. Imagine if I proposed moving outside the JVM!)

I will work on easy stuff when it is necessary and stuff just needs to get done, and I recognise that a lot of work is about getting easy stuff done because value is often tied to tedium not to complexity, but to me the fun part is when value comes from making sense of the stuff that doesnt make sense currently.

At many workplaces, its awesome to be better, because -- while, yes, those kind of assignments come with it -- so does more advancement and security.

What sucks about being at the higher end of some teams is when other people come to you with trivial problems that they just can't be bothered to look into themselves. I'm happy to help people learn but I don't like being expected to do your job for you.

Joking aside, my idea is that a job isn't good for one as long as you feel you aren't learning anything but rather covering for other people. Monetary compensation is not enough for these kind of situations because the programmers I know generally are motivated not just by money but equally from the sense of accomplishment as well. It's not about "confirming that you are smarter and know more" as discussed in the article but rather the very basic feeling of getting things done.

The job should do something for you! You may be paid well, but you must feel like you're getting something out of it too; and if you have any sort of intrinsic motivation you can't expect to be satisfied with just money. It may be on you to find out what that is, there's no guarantee it will be technical in nature.

There are times when this won't be the case, though, and you'll need to grind.

This is something I always struggle against, but ends up coming to bite me sometimes.

I also believe that there could be a more general version available for either/both:

- other programming languages / paradigms;

- other fields of research

My message would be this: "It is amazing what we know or learned, but what is more amazing is the stuff we don't know yet - so be curious, not infatuated".

In some sense, it also reminds me of the xkcd comic on learning new things http://xkcd.com/1053/

Some people can be put off by your name, like when their primary interest is their product is marketing its name rather than the technical merits of the product.

I disagree, Haskell (and other functional languages) are a lot more similar to traditional maths than other languages.

For instance, I couldn't figure out State monad for the life of me, and in general how monadic calls could maintain a context "in the background". Explanations like "it's easy just follow the Kleisli arrows" weren't helping.

Finally I did the exercise of manually "inlining" every >>=, 'get' and 'modify' call in a trivial example of a StateT function calling another StateT function. And then I got it. Truckloads of closures/continuations, constant calls to re-create the monad with new information. Function calls with functions as arguments that close over the previous calling function's state.

A lot of this was specific to how StateT + Identity unwrapped; I'm sure inlining other monads would reveal different things, and unwrapping IO is impossible in GHC :). My point is, math has been a great source of Haskell's incredible expressivity, but the pedagogical focus on math threatens to mask it's greatest triumph in Haskell: making all of that boilerplate code go away with incredible precision and elegance. When you rip it open and see what >>= or 'do ... get ... modify' is doing, you feel the power.

I feel like the article suggests this, too:

The only thing you need category theory for is to take great categorical and mathematical concepts from the world and import them back to programming, and translate them along the way so that others don’t need to make the same journey you did.

At least for advanced programmers from other worlds, they need to see the guts to appreciate how amazing this stuff is.

I was introduced to programming before abstract algebra, and when I took my first algebra class the comparison to Haskell was inevitable. Actually it turned out to be quite helpful: strongly-typed functional programming can be a good supplement to learning algebra.

In maths, you often write something like let x = ...

An imperative language statement like

x = x + 1;

isn't something you see in maths, that is not a valid equation.

"Nothing is worse than active ignorance." Johann Wolfgang von Goethe

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

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

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.

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 :)

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!

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/

I'm reminded of the adage about mathematics: think deeply of simple things.

That said, I'm going to take a different tack, not because the OP is wrong, but just to explore a second orthogonal component.

As programmers, we have both a weak and a submissive tribal identity. That's a problem, and we should change it. I call it "weak" because we aren't good judges of who belongs and who doesn't. The true bad guys (and, yes, they are quite bad and we must oppose them) have been commoditizing engineering work for decades by flooding the market with low-skill, untrained, "software engineers" (ScrumDrones, CommodityJavaDevelopers, etc.) in order to reduce top talent's leverage in the market. It has created this mythology that talent and skill don't matter, and while it's completely wrong, the failures are delayed enough that the bad actors in the business can be promoted away from the problem until shit breaks.

Our fatal flaw? Instead of striking the bad actors in the business world, we attack those low-skill engineers, who might be infuriatingly incompetent, but really didn't do anything wrong. ("You're just a PHP retard, so shut the fuck up.") The true bad guys don't really care what happens to the CommodityScrumDrones, and that's the point of having them is that they're disposable. By attacking them, the unskilled pawns, we gain nothing. Sure, they're incompetent and may be anti-intellectual (or, more likely, they just don't give a shit about programming and shouldn't be programmers, but aren't stupid or bad people). But the anti-intellectualism we must fight is that of the businessmen who are driving us in to the ground.

I say it is a submissive tribal identity because this divide-and-conquer game works. Dysfunctional organizations and societies usually form three classes that matter. (There are subclasses within each related to prestige factors that don't matter.) The High must keep the Middle and Low at odds with each other, lest they band together and overthrow the High.

In order to depress programmer wages and working conditions, the bad guys prevent professionalization and collective bargaining, create startup mythologies in order to make business bad actors look like real technologists, and flood the market with commodity programmers (the Low). Amazingly, the more skilled programmers (the Middle) will, driven by their disgust in sharing working conditions with the Low, actually work unreasonably hard and clean up their messes, just to out-compete them in a game that doesn't really matter (the unskilled are never fired, and the overworked are rarely promoted). When this works as designed, they turn into the Clueless layer of the MacLeod model.

We have to fight the anti-intellectualism. We've let ourselves be typecast to business subordinates rather than technologists and it's goddamn fucking disgusting. When some businessman says "languages don't matter", we have to humiliate him for his stupidity and anti-intellectualism, before he feels empowered enough to start hiring commodity engineers. We do have to fight, and we have to get nasty, and we have to crush our enemies. But we also have to stop clawing at each other over petty differences (e.g. tabs vs. spaces) and focus on the battles that matter.

But many of the top 5% are hired by software companies who depend on innovation for survival and seem to recognize the distinction between the CommodityJavaDeveloper and the PolyglotScientistEngineer (or whatever you want to call the other end of the spectrum). Either these companies will resist the pressure exerted by that ocean of lightly-trained 9-5 programmers or they will lose their edge and fail. And aren't those companies where we want to work anyway?

NOTE: I don't mean to disparage those who happen to work 9-5. Rather, I'm suggesting that the best programmers don't cease to be such when they go home at the end of the day.

Attitudes like this is exactly what the this article seems to be concerned about, if we want to generalize beyond the Haskell community.

http://www.haskell.org/haskellwiki/Heterogenous_collections

Good grief!

Lisp:

   '(123 a "bc" #(d))

   [1, "abc", 4.0]

Trading off easy heterogenous lists buys you a better type checker, more static knowledge, faster programs and so on. It also has the advantage that mapping data into the system can be done safely. The price is that self-describing data (JSON, Transit, Msgpack, ...) is more unwieldy to work with - but a little combinator library, scrap-your-boilerplate-generics, or a reflective code generator goes a long way to solve that problem:

- OCaml: Yojson.Basic.Util - Haskell: Generics, Rank2 polymorphism - Go: JSON unmarshalling

are all examples of how to handle that problem.

Extend your numeric type tower to handle whatever new numeric types I come up with in an internally consistent manner.

In haskell I have number types for things that automatically compute derivatives. I have number types for functions that go to number types so all vector spaces work like numbers as well. I have number types for arbitrary precision floating point numbers, and I can build these things on top of each other.

It is a trade-off. We give up a bit of one thing to get something else.

You can take either side of the deal. I'd argue that the weight of benefit is on the side where we don't have a magic type tower to reason about, but it is a perfectly reasonable stance to say that the thing you want is more important to you.

On the other hand, I can turn around and argue that if what I really want is an ad hoc tower of numeric types I can just make a type for that and work inside it.

data Number = Int Int | Rational Rational | Double Double | Complex (Complex Double) | ...

instance Num Number

Now I can opt into your model. Can you opt into mine?

However, it's not the case that `data Number = ...` gets you everything. In particular, it gives up on the types! :)

For example, in Typed Racket:

-> (: norm : Real Real -> Real)

-> (define (norm x y) (sqrt (+ (sqr x) (sqr y))))

-> (norm -3 12)

- : Real

12.36931687685298

We've proved that the `norm` function always produces `Real` answers, even though `sqrt` might produce complex numbers given negative inputs. The sum type you've given won't let you prove that.

In Python, not only can you "opt in" to those features (in a completely natural way) but those features already exist in the form of highly popular libraries:

NumPy - http://www.numpy.org/

SymPy - http://www.sympygamma.com/input/?i=diff%28x**2%29

mpmath - http://mpmath.org/

...and the story is similar with Common Lisp, whose generic functions dispatch on function parameter type (just like Haskell allows with type classes), allowing you to create libraries for vector arithmetic, symbolic algebra, and arbitrary precision floating point math, again in a completely natural style.

The best forms of language advocacy probably involve showing the great things you've done with a language and forgetting about comparisons to the competition. Build it, and they will come.

Great things the parent has done with the language:

https://www.youtube.com/watch?v=cefnmjtAolY

For your first problem, C doesn't help in the general case. If I got a JSON package, I don't know at compile time what the types are going to be, so I don't know how to lay out the struct.

If I don't know anything about the types, the only things I can (safely) do are put them in untyped collections or convert them to strings. I can't add them - they might not be numeric. I can't convert them to uppercase - they might not be strings. (I can do all those things if you're going to return a Maybe - and maybe that's the right approach if you got a JSON package over the wire.)

    kazinatorDiv x y = case x `divMod` y of
        (q, 0) -> Left q
        _ -> Right (x % y)

In C++, for example, I might have a “vector<unique_ptr<GameObject>>” containing instances of various subclasses of “GameObject” such as “Player” or “Enemy”. “GameObject” has some virtual member functions such as “update()” and “render()”.

In Haskell I can do exactly the same thing with a “GameObject” type class containing the “update” and “render” methods, and implement “GameObject” for my “Player” and “Enemy” types.

In Python I do a dynamic check on every value in the collection, on every iteration, to see if “update” and “render” are present and callable. It just seems wasteful because you know that information ahead of time—a non–game object should never end up in that collection, so why waste brain power and computing power considering the possibility?

There must be some advantage I’m not seeing here.

A program that compiles in Haskell can still break, consider:

  main = do 
    print $ head []

I can't see any reasonable definition of "break" for this context for which that is valid; its exactly the same kind of breakage that strong type checking reduces the incidence of in Haskell compared to dynamic languages -- runtime errors resulting from a function call not being able to complete without error for all inputs that the language will allow to be passed to it.

> Taking the head of an empty list is no more a break than dividing something by zero.

I agree; both are clearly examples of things that can cause a program to break.

So just compile and ship; no testing?

What's the longest you've maintained something?

So I don't think your observation answers the GP's point at all.

There was some computation which produced a wrong result, which was detected, handled and diagnosed.

In what development tool does this never happen?

  for x in [1.0, "abc", True]:
      print(x)

The thing is that in dynamic languages, there's one universal sum type, and every function effectively takes arguments and returns results of that type. In Haskell, you have to plan more for the specific sum types you are going to be using, which in certain situations makes some things more complicated. Of course, it also means that things that would be in documentation or approximately verified in tests can be statically verified by the compiler, so there is a trade off.

That is a reductionistic view, like saying that everything is ultimately ones and zeros. The storage place in a dynamic language, such as a variable, or array element or whatever, is not understood to have a type in that language. The machine language (or whatever) implementation kernel of that language understands that to have a type, but that's in a different language. That kernel knows that, say, if the least significant two bits of the storage location are 00, then it's a pointer to a heap object, and that kind of thing. That code must be written safely: like only if those two bits are 00 must it treat the value as a pointer, and otherwise not. This is all implementation detail, not accessible from the high level language (or not without special escape hatches). The type of the dynamic objects is their dynamic type; and when dynamic languages feature compile-time type inference, that inference works with those types, not with the fictitious "universal sum type".

Maybe, so what?

> like saying that everything is ultimately ones and zeros.

Well, except that saying everything is ultimately ones and zeros isn't (at least in this context) a useful starting point for explaining anything.

> The storage place in a dynamic language, such as a variable, or array element or whatever, is not understood to have a type in that language.

I'm not talking about storage places, I'm talking about the logical design -- a function (regardless of the features of the language) is designed to operate on some set of values and return a result from some set of values. These sets can ar the types I'm interested in -- whether they are implemented as (static) types in a language, or as tags / dynamic types, or whatever, or even if the language had no concepts of types at all (and, in most real languages, and can be true true even withHaskell, as in the head function on lists).

And to the extent that "heterogenous" collections are useful, they are useful specifically because they are not really heterogenous, even if the shared logical type to which the elements must belong is not coherently defined as a discrete "type" within the type system of the language.

    (1, "abc", 4.0)

If you know what is where in the list, then you semantically have a tuple.

If you don't know what is where in the list, then you need some way of telling things apart. At which point an ADT is frequently the right solution, isn't any sort of advanced technique, and requires very little in the way of boilerplate.