Haskell Researchers Announce Discovery of Industry Programmer Who Gives a Shit
steve-yegge.blogspot.com
steve-yegge.blogspot.com
I know it's fashionable in these parts to make fun of Haskell, but it's just not funny unless the writer knows something about the language. Would you upvote these articles?
* Why C++ is More Object-Oriented Than Smalltalk
* Stupid Ivory-Tower Academics Claim "Perl Is Too Slow for Weather Simulation"
* LISP: It Would Be a Lot More Useful Without All the Parentheses
It's especially galling considering pg's various articles on language expressiveness; remember this quote, folks?
"""As long as our hypothetical Blub programmer is looking down the power continuum, he knows he's looking down. Languages less powerful than Blub are obviously less powerful, because they're missing some feature he's used to. But when our hypothetical Blub programmer looks in the other direction, up the power continuum, he doesn't realize he's looking up. What he sees are merely weird languages. He probably considers them about equivalent in power to Blub, but with all this other hairy stuff thrown in as well. Blub is good enough for him, because he thinks in Blub."""
When somebody tosses around phrases like how to subvert Haskell's type system to accomplish basic shit you can do in other languages, it's a big red flag that they've never used Haskell, and possibly have never even seen Haskell code.
If this were an article talking about how FORTRAN is never used in industry because punch cards are too expensive, it would garner a few votes before being eventually buried. Perhaps one or two quick comments about how the author is uninformed.
Ditto somebody making fun of Erlang because nobody's written a web browser in it yet, or elaborating on why Python's poor industry adoption is because of mandatory whitespace.
There's a lot of material that could go into a satire on Haskell. For example, one could mention its extant-but-completely-useless shared library support. Or how quick midnight hacks end up becoming part of the language's standard definition. Or even the absolute absurdity of a package publishing system that mandates bumping your package version every time a dependency has a new release.
But he doesn't talk about any of that; anybody who's bothered to google for "haskell" has read his material on half a dozen blogs. "Monads are hard" is right up there with "why shouldn't I just make everything global?" in the list of topics useful for juicing pagerank, but nothing more.
I was using FORTRAN, Erlang, and Python as examples of languages which are heavily used in industry, but have neither the crushing popularity of Java/C# or the pop-culture appreciation of Ruby or Javascript. It doesn't really matter how much Haskell or Erlang are used, or how many billions of dollars pass through their runtimes every day; for whatever reason, the Internet has decided they are not popular.
That wouldn't be funny. This article is funny because of the hyperbole of the usual criticisms (e.g. too academic). I think you have taken the post a bit too literally:
> "We crafted a fake satirical post lampooning Haskell as an unusable, overly complex turd -- a writing task that was emotionally difficult but conceptually trivial. Then we laced the post with deeper social subtext decrying the endemic superficiality and laziness of global industry programming culture, to make ourselves feel better. Finally, each of us upvoted the post, which was unexpectedly contentious because nobody could agree on what the reddit [OR hacker news] voting arrows actually mean."
His post is this fake satirical post, it's actually about "the endemic superficiality and laziness of global industry programming culture". So if you look a bit closer, you see he's making exactly your point: these criticisms are superficial.
Wait, what? Do you have a link for this? It sounds alarming, and I haven't heard of it.
The Haskell package versioning policy < http://www.haskell.org/haskellwiki/Package_versioning_policy > says that your package metadata should specify a minimum and maximum bound on which version of libhttp you support; this way, if a new version of libhttp is released that is backwards-incompatible, they can bump the version and every dependent package will still build correctly.
Say the author of libhttp realizes he really needs to add another parameter to a function. That might break dependents, so it's backwards-incompatible. So he bumps the version from 2.3 to 2.4.
Like a good package author, your browser's dependencies look like this:
name: webbrowser
version: 1.0
build-depends:
libhttp >= 2.3 && < 2.4
build-depends:
libhttp >= 2.3 && < 2.5
version: 1.0.0.1
And your choice is 1) do this for every package and every dependency, or 2) ignore the versioning policy, hope no dependency changes break your packages.
It sucks.
The general feeling I get from core Haskell developers is that they work in finance, medical, or other fields where every dependency has to undergo a four-month certification process before it can be used. So they don't care about this, because they just never see it.
But for somebody who just wants to publish his stuff online and let others use it, it's a goddamn nightmare.
The other day, the developer of the 'text' package bumped his version to 0.11. As far as I can tell, it doesn't actually have any significant changes. All he did was fix an obscure edge condition when a particular function is passed invalid input. Everything that could build against 0.10, will build against 0.11.
Since I followed the package versioning policy, most of my packages < http://packdeps.haskellers.com/feed/?needle=John+Millikin > are set to refuse his new version. It's not too bad now, but sooner or later a user will upgrade their 'text' and then try to install one of my packages and then they will email me asking me why I am so mean and restrictive.
Which means sometime in the next week or to, I need to sit down for a few hours and recompile all my stuff, then bump the versions, then commit and tag and sign and push and sdist and upload. And somewhere in that hour I'm going to be thinking about just removing the bounds check, and letting my users deal with whatever hell befalls them if in three years there is a real breaking change somewhere.
A package that is a bit outdated is far less worse than a package that refuses to compile, because someone felt the need to ignore the versioning policy.
Also, isn't Haskell very statically typed? To the point that you could just assume that, if a package is compatible with foo>=1.2 and compiles against some foo with a higher version number (and passes the test suite, if any), it's also compatible with this new foo? That's mostly how the rest of the world does it, and it works.
You can then depend on A.B.* in your package, meaning you get all bugfixes, but no API changes that would break your code.
And statically typed doesn't mean new versions automatically work. If you specify >= 1.2 because you tested with 1.2, and version 1.3 comes out, which doesn't work, people trying to build your package will automatically pull in 1.3, and their build will fail. Specifying 1.2.* means their builds will continue to succeed.
Serious enough to claim you found it "galling" and to paste a quote from Paul Graham that virtually all of us have probably read (including the author of the original post).
Wow, even Javier wouldn't have guessed the number would double so soon!
I don't think Steve is trying to make fun of Haskell so much as the idea of Haskell.
Especially resist the urge to criticize others for liking things you find unworthy. Your comment's criticism of the OP is appreciated. Your comment's criticism of other members for voting for the post is, well, something else entirely.
I like humour, and it seems like we share a personal preference for the kind that makes you laugh and then think hard when you realize that there's something incredibly insightful at the heart of the joke.
Alas, I'm not skilled enough to pull that off myself. All I can say about Haskell is to quote Alan Perlis: A language that does not change the way you think about programming is not worth learning. And given that, the sad observation that most "Industry Types" as stereotyped in the OP are not interested in changing the way they think about anything.
It's more than a Blub thing, it's a comfort zone thing.
In order for apps to be more interesting - making new ideas in IT appealing - businesses must be willing to re-examine their processes and change them with an eye towards better automation and some business intelligence. However, getting a single department in a business to change its processes is as monumental as changing global warming.
Of course, another issue altogether is COTS reducing the applications actually written in-house. Making intellectual investments in powerful programming languages is just not sound when a developer is simply writing "glue" code between vendor systems.
People do generally get jazzed up in IT departments when new technologies come around. Sure, there are technological curmudgeons, but very few. Enthusiasm gets dampened when it is clear that a good business case cannot be made for the new technology.
(I used "new" relative to an IT department's current environment and not in reference to age of the technology.)
I think some of these votes are purely because the author is a very recognizable name who hasn't blogged in a while.
I for one broke out into a smile when I saw a new yegge blog post.
IMO, it proves exactly the opposite; a person could never say it unless they at least tried to write some Haskell code.
Haskell's not like other languages, where you have to build up massive unreadable piles of code to get anything done. It's easier to write properly, with small functions glued together; and when you've done that, debugging is a matter of either simply reading the code, or running it in GHCI (and then reading it). Import your function, pass it input, see what comes out; when it's wrong, you know what the problem is.
Debugging with prints is for stuff that isn't pure, behavior that is outside the Haskell runtime system and thus can't be reasoned about. Which means you're using IO, which means you can take advantage of 'print' or whatever.
Haskell's not like other languages, where you have to build up massive unreadable piles of code to get anything done.
That's fanboyism. I understand you feel offended by the OP's post, but it is not a good satire unless it offends somebody, and IMO, the article is excellent in summarizing attitudes of some members of the Haskell community. ;)
(Note that this does NOT break referential transparency as long as you're not dependent on the program's debug output for correctness of the rest of the program.)
include System.IO.Unsafe (unsafePerformIO)
include Control.DeepSeq (deepseq)
(unsafePerformIO $ putStrLn "OES NOES") `deepseq` doStuff
Let me state that another way: if there is no evidence that putStrLn fails, the result of the above is identical to the result of "doStuff" alone.
(Anyhow, upvoted your comment because your statement is certainly correct, even if I claim it doesn't invalidate my initial claims about debugging :) )
Well, actually, unless you've tried using Haskell you probably don't realize the it has a type system completely different from 'other languages'.
About Blub: That's a stick you can use to beat anybody who criticizes any other language. Oh, you don't think Brainfuck has anything to offer? Hah! Go read pg's essay on blub!
Really? Before I started using it, the only things I knew about Haskell were 1) it has a weird type system 2) it uses something called 'monads' and 3) doing IO is really really hard.
#3 turned out to be false, #2 was true but not as scary as the hype, and #1 was true.
It's not surprising that non-users know about the "odd" type system; types are one of the few ways arbitrary languages can be compared, so I know the type systems of many languages I've never so much as written Hello World in.
About Blub: That's a stick you can use to beat anybody who criticizes any other language.
Not so; one can use it to criticize anybody who claims a language is bad because it is more expressive than usual.
For example, there are languages with more expressive type systems than even Haskell; if a programmer used to such language called Haskell inexpressive, it wouldn't make any sense to argue against them with Blub (regardless of whether he's correct).
It's not too different from OCaml or Clean. (Though, I do miss type classes in them.)
...and I have spent an entire weekend trying to figure out how to describe within Haskell's type system something that is trivial in scheme[2] !
[1] In particular, there's a lot that's not in the SML spec that most people want in a stdlib, and every compiler's implementation is quite different. This means once you decide to use SML/NJ, if someone else has written a library you need, but for MLton, you're just up the creek. Perhaps this also happens with resp. GHC and Hugs, but I haven't found it to be nearly as much of a problem.
[2] If you care: can I create a function that takes as its arguments another function and a list, and applies the elements of the list as arguments to the function? E.g., listApply (+) [1,2] should return 3. In scheme, assuming that you already have curried functions, this is trivial. In Haskell, it's exceedingly difficult. Consider: the approach in scheme, iterative partial applications, absolutely won't work in Haskell, since the types won't match: (+) has type (Num t) => t -> t -> t, but (+1) is (Num t) => t -> t.
It turns out it's possible either with explicit isorecursive types (and some lifting functions) or using Template Haskell. For posterity, I posted both solutions on this old StackOverflow question I found when looking at how others had handled the same problem (viz., they hadn't, generally):
http://stackoverflow.com/questions/3775446/passing-list-elem...
OCaml's standard library is also quite dismal. At the recent meeting of the OCaml consortium in Paris we suggested creating a new extended standard library. (We will reuse Core and Batteries et al, of course.)
A co-worker and I are in the procss of writing a regular expression module that doesn't suck. It will be threadsafe and use poor OCaml---the module from the standard library calls C-code to run a backtracking bytecode interpreter with lots of mutable state.
I don't see the target of this post being Haskell itself. I see it as being the Haskell community. I see the thesis as being that Haskell has an undeservedly bad reputation and that its community doesn't really do anything to help by being elitist and disconnected from industry.
(Sorry if that sounds overly political. I'm not a Bill Clinton hater or even disliker, but it's a perfect example and I just can't resist.)
The three sample article titles you offer are not even analogous to the original post. Yegge's title is a humorous re-working of the phrase "nobody gives a shit about Haskell," the subject of the article. Your suggestions are analogous to half-assed critiques of the language itself.
And again, they weren't funny. For example, instead of "LISP: It Would Be a Lot More Useful Without All the Parentheses" try something like:
* Scheme is an exotic sports car. Fast. Manual transmission. No radio.
* Emacs Lisp is a 1984 Subaru GL 4WD: "the car that's always in front of you."
* Common Lisp is Howl's Moving Castle.
None of your title suggestions match mine, because yours are true. Scheme is simple and no-frills; elisp is outdated and utilitarian. Common Lisp is...well, it's not Japanese, so he's lost me there.
But implying that Haskell is unsuited or unused for industrial purposes is absurd; most major Haskell libraries are written for companies, the main compilers are developed by companies, most papers are about solving some particular industrial problem, etc. Yegge's article might as well be about how nobody uses Erlang or Forth, it would make equally little sense.
Hell, the industry Yegge specifically calls out (finance) is known to use Haskell more than usual; Barclays, Deutsche Bank, Bank of America, and Credit Suisse especially. Barclays even released a paper detailing their experiences!
I read it as more a satirical lamentation regarding the relatively low adoption of Haskell outside of academic-leaning circles. I, for one, upvoted the article and think that the upvotes are justified. I felt that the article held literary value and espoused an interesting and humorous (if a bit brash) take on this situation.
If you google around, it would seem that most professional Haskell programmers are PhD holders, and I think the point he is trying to convey is that this is a somewhat unfortunate situation given the power and potential of the language.
I mentioned this at a talk I gave about Haskell a few years back and it’s become quite widely quoted. When a language becomes too well known, or too widely used and too successful suddenly you can’t change anything anymore. You get caught and spend ages talking about things that have nothing to do with the research side of things. Success is great, but it comes at a price. -- Simon Peyton Jones
"Anyway, I think it would be worth doing, if it could be expressed readably, but I was not able to figure out a way to do that."
There is some deep irony in monads in Perl not being readable enough for Perl.
Stop thinking about the programming language wars for one minute and reread the text again, and look at the multileveled semantic games the author is playing. I thought most here were good at that?
Doug Hofstadter would be proud.
While Steve Yegge is a good satirist, I see this post as an extended version of this joke from the "Mostly Wrong History of Programming Languages":
Haskell gets some resistance due to the complexity of using monads to control side effects. Wadler tries to appease critics by explaining that "a monad is a monoid in the category of endofunctors, what's the problem?"
That's a compliment.
http://www.theonion.com/articles/fuck-everything-were-doing-...
I'm an industry programmer (in C). I also have a bunch of packages on Hackage.
https://www.facebook.com/careers/puzzles.php (They only accept answers in languages they actually use.)
If you didn't understand it: You're not a hacker and never will be; go get your MBA.
If it upset you: You are a hacker without a sense of humor. You belong in a room without other people. Fed Ex will deliver your circuit boards tomorrow.
If you laughed once: You are an aspiring junior programmer. Keep on working hard and best wishes to you.
If you laughed more than once: You are a seasoned hacker. Nice to see you here.
If you sprayed Mountain Dew on your keyboard: You have that rare combination of understanding both bits and people. You must do great work.
If you are cutting and pasting these gems for your bulletin board: You and I must be kindred spirits. Email me. Let's do a start-up together.
http://en.wikipedia.org/wiki/Tea_Party_movement#Use_of_term_...
The implication is that TEA party constituents have no interest in actually understanding the grade-school math necessary to understand a budget.
Of course, teabagging has a risqué sexual connotation so the movement's opponents latched onto the nickname as the proponents dropped it.
The Tea Partiers are known for budget illiteracy, often suggesting impossible or mathematically absurd ideas to arrange government spending. At the lowest levels they suggest that cutting foreign aid and sex education will balance the federal budget. At the highest levels, they praise "courageous" budget plans like Paul Ryan's hand-waving and prayer plan to balance the budget by cutting taxes on the wealthiest and hoping that growth trickles down to all of us and health care costs magically stop rising. In between are the signs waving "keep the government's filthy hands off my medicare," the epitome of Tea Party campaigning this year.
So the story suggests that Tea Partiers have an aversion to basic arithmetic.
It is very rare that a supporter of the tea parties actually read any of these descriptions, since fashionable leftists primarily use such insults to signal to each other how enlightened they are. Referring to supporters of the tea party as "tea baggers" gets you +1 left-wing cred points.
Unfortunately, I live in California and frequent hacker news, so I'm the rare person who is insulted on quite a regular basis by my peers who assume I will think more highly of them for peppering such insults throughout non-political conversations (Hey, a satirical article on Haskell! Oh look, another person calling me an idiot for giving a shit about the size of the federal budget and wanting to do something about it before we go bankrupt.)
Apparently their approach was more successful than they thought.