6 ms·
Last week he had "Learning Haskell is no harder than learning any other programming language"[1]. This week we have: > The program takes more than a few minute
by cosarara 7y ago
Last week he had "Learning Haskell is no harder than learning any other programming language"[1]. This week we have:
> The program takes more than a few minutes and quickly spikes up to more than 3 GB of memory! What's gone wrong? Well, we used the strict version of foldl (indicated by the trailing tick '); BUT it's only strict up to "Weak Head Normal Form" (WHNF), which means it'll be strict in the structure of the tuple accumulator, but not the actual values!
As easy as any other programming language!
[1] https://news.ycombinator.com/item?id=21170547 https://news.ycombinator.com/item?id=21170547
- abhir00p 7y agoI believe in the cited article the author was simply pointing out to the fact that it is easy to learn the syntax and basic semantics of the language. It is extremely hard to write high performance Haskell, same as it is hard to write high performance C. And additionally I think it is foolish to claim that "Haskell is no harder to learn than any languages". Definitely there are certain misconceptions (like you need to know category theory to learn Haskell) which needs to be debunked, but it is quite difficult to grasp the evaluation semantics of Haskell and pretending that it is easy and natural will simply shove more users away from the language.
- philzook 7y agoHuge Haskell fanboy here. True high performance, fair enough that's hard everywhere. I think it is unlikely a novice C programmer would accidentally balloon their memory like this. The simplest Haskell program that a novice might write has abysmal performance. I think it is easier to write clear, succinct code in Haskell and easier to write decently fast code in C. Neither is impossible in either.
- skocznymroczny 7y agoA monad is just a monoid in the category of endofunctors, what's the problem?
- erichocean 7y agoThis will never get old...
- Jestar342 7y agoI wish I knew enough to appreciate this joke.
- NullPrefix 7y agohttp://james-iry.blogspot.com/2009/05/brief-incomplete-and-mostly-wrong.html http://james-iry.blogspot.com/2009/05/brief-incomplete-and-m...
- KineticLensman 7y ago> 1957 - John Backus and IBM create FORTRAN. There's nothing funny about IBM or FORTRAN. It is a syntax error to write FORTRAN while not wearing a blue tie. Not the same joke, but really rather awesome.
- pcstl 7y agoYou really don't need to know more than "it's technically true, but also completely useless for anything practical".
- non-entity 7y agoI'm still a bit starstruck by mildly comical terms like zygohistomorphic prepromorphism
- chii 7y agoEvery language has their esoteric quirks. Tell me that it isn't weird to write this https://en.wikipedia.org/wiki/Duff%27s_device https://en.wikipedia.org/wiki/Duff%27s_device Tell me it isn't strange that array access is the same as pointer deref (aka a[index] is same as index[a])
- enlyth 7y ago> counting words > esoteric quirks It shouldn't be this easy to shoot yourself in the foot when doing simple tasks
- cosarara 7y agoThe Duff's device is a low level optimization that can even hurt modern processors due to branch prediction. It's a niche trick from the olden days. It is very strange on first sight that a[index] is same as index[a], but you will never see the second one used in practice. When you are learning, you can write your code using normal array access syntax and solve problems. And then, you can learn to use pointers and deref them. And then one day you might realize that x[y] is *(x+y) and thus y[x] and that it looks funny. But that will be a long time after writing `wc`.
- heavenlyblue 7y agoDoes that even work in C when sizeof x[i] > 1?
- cosarara 7y agoYes, it does. You can try it yourself with this code example: https://repl.it/repls/PutridUselessComputer https://repl.it/repls/PutridUselessComputer
- heavenlyblue 7y agoIt still made more sense to me more than foldl vd foldl’.
- 7y ago
- tirumaraiselvan 7y agoYou don't have to get into the intricacies of laziness when you are learning the language IMHO.
- cosarara 7y agoUnless you are trying to write `wc` without iterating the file 3 times, it seems.
- runeks 7y agoHow is that related to laziness?
- cosarara 7y agoThe article explains that.
- runeks 7y agoNo, laziness has nothing to do with iterating over the file multiple times. If you perform three separate operations on the same file (as the first, naive version does), you will iterate over the file three times regardless of the evaluation strategy. The high memory usage is related to the lazy evaluation of the arguments to the “go” function. When these arguments are evaluated strictly, iterating over the file three times would increase running time by a factor of three, but the memory usage would still be low (ie. roughly proportional to the file size).
- cosarara 7y agoWhat I quoted is talking about the 2nd version of the code, that tries to count without iterating three times and then encounters a laziness problem. The first version iterates three times and the reason it takes long has nothing to do with lazyness, we agree on that.
- 7y ago
- quickthrower2 7y agoWHNF is no harder to understand than JS promises IMO.
- jacobush 7y agoBut no one pretends Javascript is not batshit insane. Right?
- runeks 7y agoThe previous article spoke about learning enough Haskell to write useful programs. It didn’t speak about learning enough Haskell to do performance optimization. I don’t think there exists a language where it’s enough to learn the surface language in order to write optimized code. Also, the previous article recommends newcomers to use the “Strict” language extension, which would avoid the exploding memory usage of the second version (“simple-fold-wc”).
- xiphias2 7y agoRust is generally fast-by-default. My favourite example is the collections API, where you can do mapping/reducing/filtering operations only by inlining multiple operations and going through the collection only once. With Haskell these things are possible, but not efficient by default (the default Haskell library uses liked lists instead of vectors for example).
- roca 7y agoYou're implicitly assuming that there are only two classes of problems: ones where performance doesn't matter at all, no matter how awful, and ones where one is willing to expend unlimited amounts of wizard-level optimization effort to achieve maximum performance. On the contrary, in practice, it is important that the obvious code a programmer would write should be reasonably efficient (let's say, within an order of magnitude time and space of the optimal single-core solution). For this (very simple problem), this article makes it clear that is not true in Haskell. In contrast I believe it would be true in Rust and even Python (without having written the programs, but using BufReader::lines() and String::split() in Rust and the lines iterator and split() in Python). It's also a problem for Haskell that the first thing you do for performance is to disable one of the key features that distinguishes Haskell from other languages.
- Annatar 7y ago"I don’t think there exists a language where it’s enough to learn the surface language in order to write optimized code." Good news, there is indeed such a language: Fortran. Modern Fortran syntax is similar to Python (but without indentation restrictions) and the compiler generates wicked fast machine code.
- UserIsUnused 7y agothat has nothing to do with programing language, but with tools/libraries. Haskell is one of the simplest programming languages, but judging it by that statement is judging java for spring2 AbstractSingletonProxyFactory bean, ruby for all of rails monkey patching and magic, etc.
- antisemiotic 7y agoHow is it so? Lazy evaluation (and thus the concept of a (weak-head) normal form, and the possibilty of space leaks) is pretty fundamental to Haskell. It's also impossible to write generic folds (i.e. without adding an NFData constraint, which comes from outside the standard library) that evaluate further than WHNF. And just making all things may lead to worse performance or even non-termination in some cases, anyway.
- Tade0 7y agoI don't think he problem here is necessarily with the language. Because Haskell is not just a language - it's a whole culture and by learning it you have to adopt that culture. That's the degree of mental shift you have to go through to really understand it. Ultimately you don't become a Haskell programmer, but a Haskell person.
- nuxi 7y ago"Keep calm and curry on", eh? :)
- quickthrower2 7y agoExactly. Do people complain about skiing being “hard” compared to walking? Or cycling for that matter? Nope. (Well kids will complain about falling off their bike once or twice) Is skiing even hard? Crawling -> Walking is arguably a lot harder.
- 1ris 7y agoThat's a quirk of the standard library. I don't think you need to know this in order to have practical knowlege of the language. Today I saw somebody implementing C++'s std::is_integral in C# and the attempt to generate random values of generic type. It wasn't pretty, but stuff like this does not make C# a hard language.