Idris is strict by default and has a stronger type system than Haskell that supports dependent typing and in effect forced the hand of the GHC developers and the wider Haskell community by showing laziness, one of the most unpopular aspects of Haskell, to be completely unnecessary for a modern, purely-functional language.
The strict pragma is a tacit admission that default non-strict evaluation was a mistake, and all of those who defended it here and on proggit for years should come clean and apologize for having done so, especially those who dishonestly tried to pass it off as an optimization while knowing full well that "spaceleaks" are one of the biggest performance concerns with deploying non-trivial Haskell code in production. I wrote off Haskell entirely for that very reason, and I'm not alone in having done so (search HN comments).
In fact, I would wager that if Haskell had not adopted such an unusual evaluation strategy, GHC would have required only a tenth of the manhours that have presently gone into it. Yes, you CS PhDs who secretly wish you were math PhDs wouldn't be able to write toy programs with infinite lists, but that's a small price to pay for lowering the language's skyscraper-steep learning curve and giving it predictable, easily reasoned-about performance characteristics.
Laziness helps a lot with composition, when designing an interface you can have functions with arguments that won't be used by every implementation but have no performance overhead.
Although, most of the time laziness is only useful at a single level, and that kind of laziness can be easily done in languages like C++ with a much lower overhead.
It's a bit sad that GHC has so many advanced code optimization methods but performance is still lacking.
Yes, you can write high-performance Haskell but it requires expertise or huge amount of profiling and time.
On the other hand, you can easily write faster (speed-wise) prototypes in C++ and get superior performance almost all the time.
> Yes, you can write high-performance Haskell but it requires expertise or huge amount of profiling and time.
Is there a language X that allows you to write high performance X without huge amounts of profiling and time?
> On the other hand, you can easily write faster (speed-wise) prototypes in C++ and get superior performance almost all the time.
You can't really compare development time though can you, even with C++x11? Even if so, you should probably specify the version of C++ you are referring to since they can mean very different experiences.
> Is there a language X that allows you to write high performance X without huge amounts of profiling and time?
Yeah, if high-performance is something faster than Haskell I'm already there with C++. If I understand copy/move semantics I won't get bitten by anyone, same thing with laziness in Haskell, although sometimes I stumble a bit.
Of course we're all talking about C++14. I guess everyone else is talking about GHC 8.+, at least in this thread.
> You can't really compare development time though can you, even with C++x11? Even if so, you should probably specify the version of C++ you are referring to since they can mean very different experiences.
Write a highly performant discrete optimization in Haskell using monad transformers that have overhead, laziness that has overhead, and almost everything has several levels of indirection.
Yes, I can write a prototype that is sufficiently fast, I can then profile and write a version that Haskell might never reach. And yes, it'll probably take me less time to do than to do the same with Haskell, it might be my lack of expertise, who knows, I've tried.
The Haskell community is by far the most abrasive and hostile to criticism of any programming language. You can get away with voicing trite complaints about too many parentheses in a thread on Lisp, but nearly any comment here critical of Haskell ends up at < 0.
Attempting to shutdown your critics is a great way to alienate the unconverted. "Avoid success at all costs" indeed.
Perhaps you are being shutdown because you are combining your criticism with condescension and personal attacks? Like deciding that people were being "dishonest" because they don't agree with you and argue for their opinion? Or levying insults against CS and math PhDs?
I haven't done enough Haskell to be part of the community (and to have bought into whatever hostile groupthink you think surrounds it), but I down-voted you just the same for being a complete jerk.
Indeed. There is something very familiar about the tone and content of these posts from haskeldownvot5. There was another individual that achieved a degree of infamy within the Haskell community for posting similar screeds to various forums. The claims that the Haskell community can't accept criticism, the accusations of the same 'lying' about performance, the referring to 'lazy evaluation' as though it were a carcinogen, the aspersions cast against the education of various individuals, both specific and non-specific...yes, all very familiar.
I think there's some interesting psychology at work here. haskeldownvot5 is clearly inviting downvotes by his/her choice of username as well as the contents of his/her posts, but I think haskeldownvot5 has managed to convince himself/herself that there is some cabal within the Haskell community that is responsible for the downvotes. There must be a name for the phenomenon where an individual brings things upon themselves and then uses the criticism/persecution they receive as evidence to the fact that they were right all along.
> There must be a name for the phenomenon where an individual brings things upon themselves and then uses the criticism/persecution they receive as evidence to the fact that they were right all along.
I believe that "persecution complex" is the phrase you're looking for.
It's useful to keep in mind that the canonical interpretation is "Avoid (success at all costs)", rather than "(Avoid success) at all costs".
Either way, I personally have the opposite experience: I find that the Haskell community is quite self-critical. Sure, you have the "I have seen the light and I must spread the faith" idiots that all newly-popular technologies gather, but the veterans tend to be quite critical of the failings of the language, and invested in finding ways around them (I do realise this steers dangerously close to a no true scotsman).
I'm pretty sure it has to do with comments like these:
> Yes, you CS PhDs who secretly wish you were math PhDs wouldn't be able to write toy programs with infinite lists, but that's a small price to pay for lowering the language's skyscraper-steep learning curve and giving it predictable, easily reasoned-about performance characteristics.
Instead of Evil Haskell Conspiracy shutting down your criticism.
He's right though. Real programs run on real hardware, that has inherent limitations, that have to be reflected in the programming language somehow. Law of leaky abstractions and all that.
I agree. The flip side of that is that real programs are written by real humans, who have inherent limitations, that have to be reflected in the programming language somehow. ;)
Haskell certainly leans more toward the "cater to the limitations of humans" end rather than the "cater to the limitations of the machine" end, which is already filled by a whole host of languages like C++, Ada, Rust, D and others.
I think SQL is a far leakier language than Haskell in terms of the correlation between code and performance, but it seems to have achieved a measure of success even in situations where performance is critical.
The "law" of leaky abstractions is bollocks. Haskell, Idris and the like demonstrate this quite thoroughly, by offering abstractions that you can only implement if you provide proof that your implementation satisfies the assumptions of the abstraction.
I'm broadly in agreement with a lot of haskeldownvot5's views (if not his tone); I think laziness is, with the benefit of hindsight, a mistake. But it's not a case of ivory-tower PhDs forgetting that programs run on real hardware; if anything it's the opposite, an assumption that our tools and reasoning would not be powerful enough to allow us to efficiently manage computation explicitly.
Hmm ... let's not get carried away here. The abstraction leaks in Haskell seem to me to be of an order of magnitude less significant than in, say, Python or C++, but Haskell still has them (especially around _|_ and performance).
Idris already demonstrates that you don't have to have Haskell's ⊥ issues or its space leak issues. Idris may still have some leaks (or may not; I can't think of any), but the so-called law, "All non-trivial abstractions, to some degree, are leaky", is out-and-out false.
Empathy goes a long way in programming discussions simply because for _all_ of us, we often make decisions and hold opinions regarding programming based on gut feel but far less often are honest about the origin of said opinions - falsely attributing them to some "truth" we somehow have come to know.
What I mean to say is, from my perspective, it's quite easy to see why the Haskell community exists as it does - most of the people who criticize it do not understand even the most basic fundamentals of it and simply are not qualified to have an opinion. Just as I am not qualified to have an opinion on anything to do with, for example, graphics programming, many people simply do not have the experience to have said qualification - not a judgement, simply a statement of fact.
Haskell certainly is not perfect nor is it likely the pinnacle of programming languages - however I don't know a single person in reality who believes that to be the case. However this is exactly the persona a significant number of Haskell criticisms seems to attack.
So at the end of the day, when the majority of the criticism against the language is _fundamentally wrong_ in fact and based on false assumptions, it's no surprise criticism isn't as well accepted as with other communities.
Now having said all that, after spending a good part of the last two months actually endeavoring to learn Haskell and functional programming at a practical level - I can tell you there are MANY valid criticisms to be made, and the thing is, if you read Haskell mailing lists and other online communities, you'll find that they constantly are being made and discussed rationally, the only difference is they are coming from people who are clearly familiar with the language, and the concepts they are discussing. These discussions, however, are far less interesting to any tech media because a.) they involve topics and terms few people are currently familiar with and b.) they aren't abrasive or hostile, and that simply is _boring_ to the media.
One final comment - Haskell is not hard to learn, any reasonably skilled programmer willing to step outside their comfort zone could within a month be at a place where they would be qualified to critique the language. Which is the primary reason why it is so frustrating, at least to me, that so few people actually do before writing criticisms of the language.
The strict pragma is not an admission of mistake anymore than any pragma and language extension is an admission of mistake. It's a feature, dammit. Also, note that laziness was an exploratory design deicision made 25 years ago, when functional programming in industry flat-out didn't exist, and even 25 years ago there were critics and proponents of laziness, and there were strictly evaluated alternatives, such as ML, so it's quite ridiculous to say that Idris "forced" the Haskell community in any way. I would certainly like if Idris compelled Haskell to go more swiftly towards dependent typing than it's going right now, but that's another story.
I personally prefer strict-by-default evaluation to laziness for production code, (and in turn would prefer total programming with data/codata to that if it existed in a mature language), but laziness has its own place and there are huge numbers of use cases of laziness in Haskell that have been reiterated over and over here and elsewhere. In any case, the situation doesn't warrant the degree of conceit you display.
I rather think the downvoting is based on your inflammatory style, and rather baseless accusations and speculation. I downvoted you because of that, not because I'm some Haskell fanboy who can't handle critique.
I don't see anything inflammatory about their style. They are just being straightforward and laconic.
HN down-voters (the old-timers) are such a sensitive bunch.
Students in Mizzou can yell at their professors as they throw their tantrums and no one dares bring them down to civil discourse; be laconic in a HN forum and you get downvoted for not being sensitive to old-timers' feelings.
ML is good at what it does but it doesn't offer Haskell's type system.
I won't comment on history and I see no value in unpleasantness, but I do think that knowing what we know now, and particularly in the light of Idris, the advantages of laziness are overstated and strict languages (or possibly explicit codata) are the future of programming. And if true, that puts Haskell in an awkward position.
I don't see why Haskell's in an awkward situation. Adding more strictness support to GHC is not particularly hard and it's happening already. It's far easier to add strictness to GHC than to launch a competitor production-strength pure functional language.
(On the long term, probably we'll see a brave new type-theoretical language, when much of the current research crystallizes into something tangible; but until then I don't see GHC being overshadowed by competitors. There is lots of inertia and the extant GHC infrastructure is extremely valuable. Dependent types are very important and adding them to GHC is very hard, but it's still happening, so Idris & co. will have a difficult time trying to fish in that pond)
There's a ton of useful stuff with HKTs, type families, GADTs, etc that you can't hope to achieve with ocaml's type system.
Recently, I've found myself using extensive type-level arithmetic for automatic hardware generation and verification. This requires a number of powerful type system features (type level literals, kind promotion, type functions and equality constraints a la type families, type normalization plugins) that wouldn't work at all in ocaml.
If you want proof the Haskell community is not incapable of criticizing itself, pop over to /r/haskell or something and post something like "If you were the King of Haskell and didn't have to worry about implementation effort, what would you change about Haskell?"
You'll get a hundred replies, the vast bulk of which will have some criticism of Haskell in it.
What won't happen is that the Haskell community will tell you all about how it regrets not being an imperative language and explain that if they could get away with it they'd switch everything to Java, because it would be so much easier.
Haskell is still a language going somewhere. It's one of the most interesting language communities there is, because most other languages are just re-exploring well-covered ground because they're shuffling the same basic primitives around in slightly novel combinations. Rust is also going to be increasingly interesting, I think, as they also have at least one big new primitive, and will have to discover how to use it skillfully, and probably discover other things they need as they go along.
I know this is anecdotal: at my undergrad state university (UT) the intro to programming for non-programmers (I was a liberal arts major) was (is?) Haskell. Personally, I think it's a great first language---along with Python. "Getting stuff done" Haskell has virtually no learning curve. Generally, you can introduce new (deeper) concepts as the student's & learner's run into issues on the 5th or 6th time.
I think UT's pass-rate for it's Haskell class is just as good as TAMU's intro-to-programming (which is C/++).
Is that so implausible? If you like the things that make Haskell different from other programming languages, Idris does most of the same things, only more so. It's the first language with a better type system than Haskell's to become even remotely mainstream.
I love Idris as much as the next guy, but I doubt virtually anyone is using it for production code. By contrast, there are millions upon millions of lines of Haskell code in production all over the world.
Does the bang pattern have the opposite semantics when Strict or StrictData pragmas are in use? Can one recover lazy semantics inside a Strict module? That would be convenient/confusing!
Back when I was way into Haskell, Johan Tibell was the guy I tried to be most like. I learned a lot from him not only about Haskell, but good software development practices in general, and how to work better with others. Great guy.
45 comments
[ 2.8 ms ] story [ 98.9 ms ] threadThe strict pragma is a tacit admission that default non-strict evaluation was a mistake, and all of those who defended it here and on proggit for years should come clean and apologize for having done so, especially those who dishonestly tried to pass it off as an optimization while knowing full well that "spaceleaks" are one of the biggest performance concerns with deploying non-trivial Haskell code in production. I wrote off Haskell entirely for that very reason, and I'm not alone in having done so (search HN comments).
In fact, I would wager that if Haskell had not adopted such an unusual evaluation strategy, GHC would have required only a tenth of the manhours that have presently gone into it. Yes, you CS PhDs who secretly wish you were math PhDs wouldn't be able to write toy programs with infinite lists, but that's a small price to pay for lowering the language's skyscraper-steep learning curve and giving it predictable, easily reasoned-about performance characteristics.
Although, most of the time laziness is only useful at a single level, and that kind of laziness can be easily done in languages like C++ with a much lower overhead.
It's a bit sad that GHC has so many advanced code optimization methods but performance is still lacking.
Yes, you can write high-performance Haskell but it requires expertise or huge amount of profiling and time.
On the other hand, you can easily write faster (speed-wise) prototypes in C++ and get superior performance almost all the time.
List of ways to write performant Haskell: https://news.ycombinator.com/item?id=10209798
Is there a language X that allows you to write high performance X without huge amounts of profiling and time?
> On the other hand, you can easily write faster (speed-wise) prototypes in C++ and get superior performance almost all the time.
You can't really compare development time though can you, even with C++x11? Even if so, you should probably specify the version of C++ you are referring to since they can mean very different experiences.
> List of ways to write performant Haskell: https://news.ycombinator.com/item?id=10209798
Cool!
Yeah, if high-performance is something faster than Haskell I'm already there with C++. If I understand copy/move semantics I won't get bitten by anyone, same thing with laziness in Haskell, although sometimes I stumble a bit.
Of course we're all talking about C++14. I guess everyone else is talking about GHC 8.+, at least in this thread.
> You can't really compare development time though can you, even with C++x11? Even if so, you should probably specify the version of C++ you are referring to since they can mean very different experiences.
Write a highly performant discrete optimization in Haskell using monad transformers that have overhead, laziness that has overhead, and almost everything has several levels of indirection. Yes, I can write a prototype that is sufficiently fast, I can then profile and write a version that Haskell might never reach. And yes, it'll probably take me less time to do than to do the same with Haskell, it might be my lack of expertise, who knows, I've tried.
Attempting to shutdown your critics is a great way to alienate the unconverted. "Avoid success at all costs" indeed.
I haven't done enough Haskell to be part of the community (and to have bought into whatever hostile groupthink you think surrounds it), but I down-voted you just the same for being a complete jerk.
If they knew about the dangers of spaceleaks, then they were being dishonest when advertising laziness as a benefit to performance.
> Or levying insults against CS and math PhDs?
I referred to CS PhDs who wish they were math PhDs, not math PhDs. Math PhDs neither know nor care about Haskell.
I think there's some interesting psychology at work here. haskeldownvot5 is clearly inviting downvotes by his/her choice of username as well as the contents of his/her posts, but I think haskeldownvot5 has managed to convince himself/herself that there is some cabal within the Haskell community that is responsible for the downvotes. There must be a name for the phenomenon where an individual brings things upon themselves and then uses the criticism/persecution they receive as evidence to the fact that they were right all along.
I believe that "persecution complex" is the phrase you're looking for.
Either way, I personally have the opposite experience: I find that the Haskell community is quite self-critical. Sure, you have the "I have seen the light and I must spread the faith" idiots that all newly-popular technologies gather, but the veterans tend to be quite critical of the failings of the language, and invested in finding ways around them (I do realise this steers dangerously close to a no true scotsman).
> Yes, you CS PhDs who secretly wish you were math PhDs wouldn't be able to write toy programs with infinite lists, but that's a small price to pay for lowering the language's skyscraper-steep learning curve and giving it predictable, easily reasoned-about performance characteristics.
Instead of Evil Haskell Conspiracy shutting down your criticism.
Haskell certainly leans more toward the "cater to the limitations of humans" end rather than the "cater to the limitations of the machine" end, which is already filled by a whole host of languages like C++, Ada, Rust, D and others.
I really like this distinction!
I'm broadly in agreement with a lot of haskeldownvot5's views (if not his tone); I think laziness is, with the benefit of hindsight, a mistake. But it's not a case of ivory-tower PhDs forgetting that programs run on real hardware; if anything it's the opposite, an assumption that our tools and reasoning would not be powerful enough to allow us to efficiently manage computation explicitly.
What I mean to say is, from my perspective, it's quite easy to see why the Haskell community exists as it does - most of the people who criticize it do not understand even the most basic fundamentals of it and simply are not qualified to have an opinion. Just as I am not qualified to have an opinion on anything to do with, for example, graphics programming, many people simply do not have the experience to have said qualification - not a judgement, simply a statement of fact.
Haskell certainly is not perfect nor is it likely the pinnacle of programming languages - however I don't know a single person in reality who believes that to be the case. However this is exactly the persona a significant number of Haskell criticisms seems to attack.
So at the end of the day, when the majority of the criticism against the language is _fundamentally wrong_ in fact and based on false assumptions, it's no surprise criticism isn't as well accepted as with other communities.
Now having said all that, after spending a good part of the last two months actually endeavoring to learn Haskell and functional programming at a practical level - I can tell you there are MANY valid criticisms to be made, and the thing is, if you read Haskell mailing lists and other online communities, you'll find that they constantly are being made and discussed rationally, the only difference is they are coming from people who are clearly familiar with the language, and the concepts they are discussing. These discussions, however, are far less interesting to any tech media because a.) they involve topics and terms few people are currently familiar with and b.) they aren't abrasive or hostile, and that simply is _boring_ to the media.
One final comment - Haskell is not hard to learn, any reasonably skilled programmer willing to step outside their comfort zone could within a month be at a place where they would be qualified to critique the language. Which is the primary reason why it is so frustrating, at least to me, that so few people actually do before writing criticisms of the language.
"Yeah, we know :( We're working on it though: (links to 3 proposals, one of which will become a part of ghc 8)"
1. Go generics 2. problems of node callbacks
The strict pragma is not an admission of mistake anymore than any pragma and language extension is an admission of mistake. It's a feature, dammit. Also, note that laziness was an exploratory design deicision made 25 years ago, when functional programming in industry flat-out didn't exist, and even 25 years ago there were critics and proponents of laziness, and there were strictly evaluated alternatives, such as ML, so it's quite ridiculous to say that Idris "forced" the Haskell community in any way. I would certainly like if Idris compelled Haskell to go more swiftly towards dependent typing than it's going right now, but that's another story.
I personally prefer strict-by-default evaluation to laziness for production code, (and in turn would prefer total programming with data/codata to that if it existed in a mature language), but laziness has its own place and there are huge numbers of use cases of laziness in Haskell that have been reiterated over and over here and elsewhere. In any case, the situation doesn't warrant the degree of conceit you display.
Appropriate given the response any criticism of Haskell elicits.
> strict pragma is not an admission of mistake anymore than any pragma and language extension is an admission of mistake. It's a feature, dammit.
A feature that likely wouldn't exist without Idris offering such a compelling, strict alternative to Haskell.
> I personally prefer strict-by-default evaluation to laziness for production code
So would I, which is why I wrote off the language, and why the GHC devs have had to back-peddle and add this pragma.
HN down-voters (the old-timers) are such a sensitive bunch.
Students in Mizzou can yell at their professors as they throw their tantrums and no one dares bring them down to civil discourse; be laconic in a HN forum and you get downvoted for not being sensitive to old-timers' feelings.
I won't comment on history and I see no value in unpleasantness, but I do think that knowing what we know now, and particularly in the light of Idris, the advantages of laziness are overstated and strict languages (or possibly explicit codata) are the future of programming. And if true, that puts Haskell in an awkward position.
(On the long term, probably we'll see a brave new type-theoretical language, when much of the current research crystallizes into something tangible; but until then I don't see GHC being overshadowed by competitors. There is lots of inertia and the extant GHC infrastructure is extremely valuable. Dependent types are very important and adding them to GHC is very hard, but it's still happening, so Idris & co. will have a difficult time trying to fish in that pond)
You can do most of Haskell's type trickery in OCaml though. Some things are much easier in Haskell, but other things are much harder.
- not necessary. You don't need HKTs to have >>= for your favorite monad.
- encodable in functors/first class modules trivially.
- genuinely complicated HKT.
The last point happens far less often than Haskell people believe. (It does happen occasionally, though, and it's indeed annoying when it does).
There's a ton of useful stuff with HKTs, type families, GADTs, etc that you can't hope to achieve with ocaml's type system.
Recently, I've found myself using extensive type-level arithmetic for automatic hardware generation and verification. This requires a number of powerful type system features (type level literals, kind promotion, type functions and equality constraints a la type families, type normalization plugins) that wouldn't work at all in ocaml.
You'll get a hundred replies, the vast bulk of which will have some criticism of Haskell in it.
What won't happen is that the Haskell community will tell you all about how it regrets not being an imperative language and explain that if they could get away with it they'd switch everything to Java, because it would be so much easier.
Haskell is still a language going somewhere. It's one of the most interesting language communities there is, because most other languages are just re-exploring well-covered ground because they're shuffling the same basic primitives around in slightly novel combinations. Rust is also going to be increasingly interesting, I think, as they also have at least one big new primitive, and will have to discover how to use it skillfully, and probably discover other things they need as they go along.
I think UT's pass-rate for it's Haskell class is just as good as TAMU's intro-to-programming (which is C/++).