The fallacy here is that type classes, folds and monads are not esoteric structures within the context of Haskell, and using them to structure regular business is pretty mundane. If someone feels a sense of achievement from doing this, they're probably very new to the language. The author of the article has baked in a value judgement about the "normal" way to structure a CRUD application that precludes alternative approaches to structuring application logic.

You could just as well argue that laying out object class hierarchies and using inheritance is "[solving problems] that have nothing to do with what you’re actually trying to achieve."

Could, indeed semi-regularly do. I actively dislike solving problems with inheritance.

I also actively dislike people missing the point. The problem is not "using programming to solve problems". The problem is letting the novelty of the programming you're using to solve problems con you into thinking you're doing something more clever than you actually are.

If we're talking about things that make me smug as a Haskell developer, I'd probably say that I feel most accomplished when I figure out how to encode more invariants into the type system so that the compiler helps me make fewer errors. I still stand by Haskell as being the best language for that that's not just a university research language.

Missingthepointception!

It's almost like I didn't explicitly point to this as a phase most serious Haskell programmers grow out of right in the goddamn article.

Another way of putting this doesn't have anything to do with how clever the developer thinks they are (or how serious they are now that they no longer think they're clever)...

It's "now you have two problems" -- the original problem you wanted to solve, and the problem of working with the tool/framework/paradigm you've chosen to solve it. So, great, you're doing object/design-pattern oriented development! And then you find this starts to lead you to a place where a significant portion of your overhead is sunk into solving problems that don't seem to have much to do with the original problem domain.

I don't know Haskell well enough to pick on it. I'd love to believe it escapes that kind of problem, but I think it's only somewhat less likely than beating entropy.

Definitely, 100%.

Which people? My friends and I walk away from a game of Cards Against Humanity thinking we had a fun time coming up with stupid combinations for an hour. I can also turn the author's previous sentence around and state that there are probably many people that get too invested in elves and orcs as well.

> ... this passes once you’re more familiar with the language and are using it for real things

> ... a large enough subset of the community never reaches that stage

This is true about pretty much every programming language (and probably generalizable to most non-programming things too). The author just happened to apply it to Ruby and Haskell for some reason.

If there's a message such as "programmers should be more aware of the language's strengths and weaknesses and shouldn't feel overconfident", it's lost in the paragraphs of vague complaints.

After playing a game of CAH, I don't think any of my friends have any delusions about doing standup or writing a comedic op-ed piece for the NY Times.

And so you begin to shoehorn absolutely everything into the new magic potion you've learned. Erlang? How can I build concurrent and robust systems with it, it's dynamically typed and the syntax is scary! (Yes, people who somehow managed to learn Haskell syntax proceed to cry like babies over having to figure out some clause delimiters. The irony is enough to power the US steel industry for a year.) Mutable state and its evil becomes the next cargo cult, type systems means I no longer have to test my software, and other similar misconceptions abound.

But, I don't mind. Most tend to grow out of it eventually. You feel hardcore at first, but you're struck by humility once you learn more and more.

By the way, Cards Against Humanity is quite nice.

Right. I think, in general, PFP (pure-FP, i.e. Haskell and a few more obscure languages) sells itself as a solution to a problem and some people start believing it's the only solution to the problem, rather than one of many (and probably not the best one, at that). Not that Haskell's virtues aren't real -- they are -- but they come at significant cost, and are often available come much cheaper with other approaches. For example, referential-transparency-everywhere is just one of several solutions to the problem of mutable shared state, and, IMO at least, not among the best solutions. Even when it comes to provable correctness, which Haskell touts as a relatively unique feature (at least relative to mainstream languages) people forget -- or more likely, don't know -- that there are fully verifiable imperative languages out there (with their own serious problems -- correctness is never free), that have actually been used by the industry to write some very important, safety-critical software, and have been actually put to the test much more than Haskell.

In fact, one of Haskell's marketing advantages is that, after 20 years, it is still at the stage of selling the dream. Because it has hardly been used where its strengths are supposed to matter most (complex programs employing a lot of concurrency), it gets to sell its "promising initial results" without having to contend with too much disappointment, which invariably arrives once a technology has been well tested. It's the promising NBA rookie who got picked first in the draft but has never played a full quarter, getting people to say, "if only they'd get him off the bench...".

Anyway, lots of the reported production uses of Haskell are in exactly the areas it is supposed to be strong; the problem for sharing that experience is many of them are in internal proprietary systems, not publicly-available or open-source software, so external evaluators don't have the code -- or even, often, a chance to interact with the software.

Well, this isn't a very technical discussion, but I can quickly list them: for shared mutation I think the Clojure approach of transactional/atomic mutation everywhere rather than RT-everywhere is simpler; for correctness/side-effects, imperative effect systems may be easier (well, they don't quite exist other than in a very limited, experimental form, in Koka and Java 8's pluggable type systems -- but Haskell doesn't provide a very fine-grained side-effect-control either). For correctness, Esterel (which has been well proven) and its descendants, seems a lot more sophisticated in terms of proving correctness, while being more intuitive (of course, Esterel introduces a limited computation model, but so does Haskell -- or languages in the same vain -- if they are to be decidable).

> the problem for sharing that experience is many of them are in internal proprietary systems

Yes, that, too, is a problem, but the bigger problem is that uses in the industry are vanishingly rare -- and the bigger the domain challenge, the rarer still they are. For example, I don't think there exists a single case of a Haskell program that tackles complexity in such a way that implementing it in, say, Java or Clojure, is prohibitively expensive.

Among the companies listed are Facebook and Microsoft.

This list may not be long or exhaustive but it does show a number of companies who are publicly willing to say they use Haskell. It was started in January.

I can personally attest to several companies I have worked with not mentioned in the list which also use Haskell internally. Haskell is not always the bread and butter of the business software. However, it often has an extremely strong presence for developing internal tools, compilers for DSL's, and (micro)services for various tasks.

I wouldn't go there. Awk has an extremely strong presence in internal tools; Haskell has some minor presence if you squint hard enough. If the unconventional language promising to help tackle software complexity in this modern age is used as an Awk replacement (or TCL, or Perl) then what are we doing here?

The real story is that Haskell may well be an excellent first step towards the future of programming and a great breakthrough -- or it may be a dead end -- we simply don't know because it's never really been tried. Putting it in the ring with Awk or Perl -- where it's losing, BTW -- is an insult to both Haskell and Awk. Using Haskell as one more language for "small stuff" is not using it at all, because that's not what it's meant to do, and it's certainly not where it can fulfill its promise.

Ada is absolutely painful to work with as a developer (I used to work in Aerospace). But if you could get your code to compile, it stood a very good chance of just working.

I think playing around with the abstractions that Haskell offers can be very rewarding when you go back to your "regular language". It's just approachable enough that you can learn some really advanced techniques and dip your toes into category theory all through self study.

As for Ruby, I'm not proficient in it, but plenty of people have built amazing products using it and seem happy with their language of choice. Not sure why they should be bashed for poor programming when in the end, results are the only thing that matters.

> A thing I value probably at least as much as humour is good API design.

Since he's throwing a lot of rocks, I'll say his house is looking pretty glass :) Slaying imaginary orcs isn't exactly the height of comedy.

I'd be a lot more interested in hearing why the author thinks the Sequel and Sinatra APIs are good, and how they differ from more typical poor Ruby APIs, and what features of Ruby the author thinks encourages these poor APIs.

What languages or language communities encourage better practices, and what makes them different from Haskell and Ruby, and how does that tie back to the Cards Against Humanity analogy? By the end of the piece, I was left wondering what the point was to begin with.

No that's not what the video demonstrates because the people in the video are professionals.

Ironically the whole monkey-see-man-do-therefore-monkey-can-do-too argument that you're espousing with the 'professional status notwithstanding' line is itself demonstrating one of the actual points of the article, namely the 'I saw someone do this on jackass once so I should be ok to hurl myself out of this window while on fire and with my junk in a snapping-turtle' idea.

Actually, it's a game about having fun with crude humor.

The video demonstrates that it's just a game that generates laughs and eases people's insecurities therefore making them more open to come up with their own humor or be more receptive to others'. I mean, just look at Laina's reactions throughout the video, she clearly represents the type of person that is obviously uncomfortable but being drawn out of their shell.

The point is that the game itself is not the point, it's the setting. Your ridiculous Jackass strawman has no bearing.

    main = putStrLn $ unlines $ map fizzer [1..100] where
        fizzer n | n % 15 == 0  = "FizzBuzz"
                 | n %  3 == 0  = "Fizz"
                 | n %  5 == 0  = "Buzz"
                 | otherwise    = show n

    import Data.Monoid (Monoid, mconcat)
    import Data.Maybe (catMaybes)

    specialcases :: (Monoid y) => [x -> Maybe y] -> x -> Either x y
    specialcases rules x = case catMaybes (map ($ x) rules) of
        [] -> Left x
        xs -> Right (mconcat xs)

    ifDivBy :: Integer -> x -> Integer -> Maybe x
    ifDivBy n x m = if m `mod` n == 0 then Just x
                                        else Nothing

    main = putStrLn $ unlines $ strings where
        strings = map (either show id) cases
        fizzer = specialcases [ifDivBy 3 "Fizz", ifDivBy 5 "Buzz"]
        cases = map fizzer [1..100]

[0] consider that 50% of people are less funny than average, and then reflect on how funny the average person is.

Assuming that average here is an arithmetic mean (which is the most common use, but how are we quantifying "funniness" to warrant such a measure?), this would only be true if we assume a symmetric distribution with no individuals at the average.

This also assumes that objective funniness is even a meaningful concept; funniness is obviously subjective, and I would suspect that people tend to voluntarily socially engage with people that they find pleasant to be around -- part of which is having compatible sense of humor. So, the people you are voluntarily associating with (i.e., the people you are like to play CAH with) are likely to be disproportionately from the upper end of the funniness distribution from your subjective perspective -- and are likely to be among the upper end of the distribution in how they perceive your funniness, as well.

Your second point is a good one - clearly, funniness is subjective. On the other hand, I don't think my argument relies on the precise quantitative definition of funniness!

You cannot meaningfully add together how funny five people are and divide it by five. However, you can put five people in order of how funny they are, and point to the middle one.

The only appropriate concept of average for ordinal data (e.g. how funny someone is) is the median, from which it follows by definition that 50% of people are less funny than average.

PS - if it is true that it "cracks you up" every time you hear "the 50% of people are above/below average fallacy", I suggest that you might be one of the 50% of people who have a below-average sense of humour ;)

I would extrapolate further and say since there is a tiny number of comedians performing any night that there is both a non-even distribution of humor and that it is weighted towards fewer people having it. Consider, if it were so common, would the rest of us be as willing to pay to hear someone else perform?

And to be fair, I don't think that would be evidence in itself. I would be curious to see actual studies into this. At least a little.

Incorrect. For the four usual kinds of measures, the following types of "averages" are generally useful:

Nominal: Mode

Ordinal: Mode, Median

Interval: Mode, Median, Arithmetic Mean

Ratio: Mode, Median, All Means (arithmetic, geometric, harmonic)

> from which it follows by definition that 50% of people are less funny than average.

Nope, that only follows by definition for ordinal data with the additional assumption that no items have equal rank.

Most DSLs (at least the ones I've worked with, or made), are simply a convenience, and eventually to make the code more expressive.

Behind this fancy DSL, there is an API, the DSL itself isn't really an API, it's just a "frontend" for that API.

I'll pull a simple and shitty example out of my ass[1]:

    game = Game::CardsAgainstHumanity.new do
      fun 9000
      rounds 10

      must_involve_drinking!
    end

    game = Game::CardsAgainstHumanity.new()
    game.configuration(:fun_level, 9000)
    game.configuration(:round_count, 10)
    game.set_game_flag(:drinking, true)
    game.set_game_flag(:drinking_optional, false)

Also, one would have to go out of their way to hide the actual API behind the DSL, which is very unlikely and due to Ruby's nature, one could always expose the API anyway (through the C API, as a last resort).

Also, I'd like to add little bit of something about the Haskell part, even though I've never written one line of Haskell, but this isn't really about Haskell:

> "Look, I used a monad! And defined my own type class for custom folding of data! Isn’t that amazing?“. “What does it do?” “It’s a CRUD app”

I bet everyone did the same or something of that sort in <pick your language> when they were starting out with it, or exploring some part of it that they were previously unfamiliar with. This is excellent, actually. Why? Because they'll learn the benefits and pitfalls of that approach. They'll be wiser and better programmers tomorrow because of that.

--- [1]: No pun intended. Also, not looking for a real example out of principle, because I feel like the author was too lazy to do some research; this is just my opinion. Frankly, this feels like click-baiting.

For instance most API design is based off the standard Rails scaffold command, and an explanation about what's wrong about that would have been nice, and elevated this article from kind of a screed, into something informative and worthy of study.

I don't know Haskell but I've started trying to learn it a couple times. Haskell is close to how I think about problems, not sure how close yet, but I can tell it would be a great tool if I took the time to learn it. I'd probably learn a lot about how to think about problems if I did use it, and that's probably what happens for other people. It's such a major paradigm shift from the 'usual' methods that it's raised to an exalted status. If you try to solve problems without using state and with static types you can get to almost the same place regardless of language, it's just harder to implement. I've been working in Java 6 with a team firmly rooted in OO the last few years and often wish I had monads...

There it is, in the last paragraph. I was wondering what you are trying to say. But I guarantee you, it's not Ruby or Haskell making them like that. It's rather something intrinsic that feeds on accomplishment, however little it might seem to you. On the other hand, there's also a lot of mathematicians, bloggers and even roleplayers who display quite similar behavior.

Just imagine the pride of the young mathematicians when they prove something difficult for the first time without the help of a text book, when the professor could solve this in his sleep. Or think of the blogger that spreads the word on his latest article, when a philosopher or writer thinks it doesn't say much about anything. Or the roleplayer boasting about his skill for acting out his character, when an actual actor thinks its laughable.

Many people, irrespective of what they're doing, display this kind of behavior. So if these people annoy you so much, avoid them or help them.

Don't tell them that it's frustrating to interact with them. I guess you wouldn't have enjoyed it either if you just started out and someone would have told you that all your accomplishments until now are worth nothing and you shouldn't tell or show anybody what you are doing since it's embarrassing for the community.

Nobody is good at everything, I know a thousand things that I don't know or which I would execute terribly. But I know that I can still reduce this number. And if it takes me a whole week to write a program that is an abomination and it would've been a matter of hours for you, I'll still tell it to everybody since I'm proud of however little it is that I can accomplish.

On the other hand, I won't laugh at you and I won't tell you that it's frustrating to talk to you if you say something about the LHC or black holes or semiconductor physics when you barely have an idea about quantum field theory, general relativity and solid state phyiscs. I'll either avoid you or - what is usually the case - I'll help you understand it.

(Yes, I like Ruby, I like to poke Haskell occasionally, and I've only played Cards Against Humanity once, but it resulted in my mother-in-law combining "a girl's best friend" and "three dicks at once".)

Is there a a difficulty barrier for considering an application real? A lines of code requirement? Is it like pornography and I'll know it when I see it?

Got it.

Holy non-sequitur, Batman.