Destroying C with 20 lines of Haskell: wc
0xd34df00d.me
Destroying C with 20 lines of Haskell: wc
1–10 of 74 posts
Re: Destroying C with 20 lines of Haskell: wc
#2Not being great at reading Haskell, I have some questions I was hoping people here could answer:
* Does this cope with different whitespace, such as tabs?
* Does this cope with different settings of locale?
* Does this include the option of the "longest line"?
* Does this perform the character counts?
I'm pretty sure wc does all these, and that stripping them out would make it faster. If this Haskell version doesn't do that, and yet still compares against a fully-featured version of wc, the comparison hardly seems fair.
Re: Destroying C with 20 lines of Haskell: wc
#3Not being great at reading Haskell, I have some questions I was hoping people here could answer: * Does this cope with different whitespace, such as tabs? * Does this cope with different settings of locale? * Does this include the option of the "longest line"? * Does this perform the character counts? I'm pretty sure wc does all these, and that stripping them out would make it faster. If this Haskell version doesn't…
* isSpace handles tabs, but looking at a single byte at a time it won't handle all the multibyte space symbols you can have in unicode. If you read further down, they rip out the remains of unicode handling for further speed improvements.
* Looking at a single byte at a time, it presumably only handles the "C" locale :) They don't say what locale GNU wc was tested with (if it's not LANG=C, that benchmark should be re-run)
* --max-line-length? no. But I'm guessing GNU wc isn't benchmarked with that option on (can't find the invocation in the blog post though)
* data State { ws, bs, ls } keeps count of words, bytes (more honest than calling it characters) and lines.
Re: Destroying C with 20 lines of Haskell: wc
#4Not being great at reading Haskell, I have some questions I was hoping people here could answer: * Does this cope with different whitespace, such as tabs? * Does this cope with different settings of locale? * Does this include the option of the "longest line"? * Does this perform the character counts? I'm pretty sure wc does all these, and that stripping them out would make it faster. If this Haskell version doesn't…
* isSpace handles tabs, but looking at a single byte at a time it won't handle all the multibyte space symbols you can have in unicode. If you read further down, they rip out the remains of unicode handling for further speed improvements. * Looking at a single byte at a time, it presumably only handles the "C" locale :) They don't say what locale GNU wc was tested with (if it's not LANG=C, that benchmark should be re…
Thanks for the reply ...
> ... further down, they rip out the remains of unicode handling ...
Ah. Well, that makes it a little unfair, surely.
> Looking at a single byte at a time, it presumably only handles the "C" locale ...
Again.
> --max-line-length? no. But I'm guessing GNU wc isn't benchmarked with that option on
I wonder if wc does the work anyway, and only reports it if asked, or if it actually changes the code path if it's not needed.
So this entire post feels ... intellectually dishonest. personally I'm all in favour of Haskell, and I wish I had the chance to use it "in anger" rather than just doing the occasional toy thingie that I do. But this post doesn't do it or its community any favours.
Disappointing.
Re: Destroying C with 20 lines of Haskell: wc
#5This doesn't seem to be comparing anything like the same thing. Does the Haskell version really do the same thing as the C version? Does it handle all of the same error cases, providing the same quality of error messages if they occur? Does it handle localization? If not, that makes the comparison very skewed, as unhammer already pointed out. Sure, if you strip out all of the things that the people who wrote wc actually spent all that time on then you can go faster, but failing to note the differences is simply dishonest.
Re: Destroying C with 20 lines of Haskell: wc
#6Earlier quoted context omitted.
* isSpace handles tabs, but looking at a single byte at a time it won't handle all the multibyte space symbols you can have in unicode. If you read further down, they rip out the remains of unicode handling for further speed improvements. * Looking at a single byte at a time, it presumably only handles the "C" locale :) They don't say what locale GNU wc was tested with (if it's not LANG=C, that benchmark should be re…
Thanks for the reply ... > ... further down, they rip out the remains of unicode handling ... Ah. Well, that makes it a little unfair, surely. > Looking at a single byte at a time, it presumably only handles the "C" locale ... Again. > --max-line-length? no. But I'm guessing GNU wc isn't benchmarked with that option on I wonder if wc does the work anyway, and only reports it if asked, or if it actually changes the co…
Yes. "Destroying C". The whole post feels like youthful bravado untempered by experience.
Re: Destroying C with 20 lines of Haskell: wc
#7But how would Haskell version of wc compare with C version of wc running with LC_ALL=C environment variable? UTF-8 locale is much slower than C locale in coreutils, it's a well-known fact, and their Haskell version of wc is already using fixed 8-bit characters.
Re: Destroying C with 20 lines of Haskell: wc
#8This doesn't seem to be comparing anything like the same thing. Does the Haskell version really do the same thing as the C version? Does it handle all of the same error cases, providing the same quality of error messages if they occur? Does it handle localization? If not, that makes the comparison very skewed, as unhammer already pointed out. Sure, if you strip out all of the things that the people who wrote wc actua…
> This doesn't seem to be comparing anything like the same thing.
This is a fair point, and I believe this whole series of 'Beating C with foo' posts could have been better named.
But I'm of the opinion that the whole series is about showcasing various language's strengths and weaknesses, while using GNU wc as a benchmark.
From this perspective, I've learnt a bit about several languages I knew nothing about, so I rather like these articles, despite the fact that their titles might be a bit misleading.
Re: Destroying C with 20 lines of Haskell: wc
#9This doesn't seem to be comparing anything like the same thing. Does the Haskell version really do the same thing as the C version? Does it handle all of the same error cases, providing the same quality of error messages if they occur? Does it handle localization? If not, that makes the comparison very skewed, as unhammer already pointed out. Sure, if you strip out all of the things that the people who wrote wc actua…
They explicitly say in the introduction that this is a toy version, and then in the conclusion that a future post will look at a more complete substitute.
Re: Destroying C with 20 lines of Haskell: wc
#10This doesn't seem to be comparing anything like the same thing. Does the Haskell version really do the same thing as the C version? Does it handle all of the same error cases, providing the same quality of error messages if they occur? Does it handle localization? If not, that makes the comparison very skewed, as unhammer already pointed out. Sure, if you strip out all of the things that the people who wrote wc actua…
Good point. I was thinking the same thing too.
I will wait for what the next article presents, as the end of this article states:
> Stay tuned for a second part, where we will investigate shaping all this into an actual wc substitute, where different statistics can be turned on or off, all while not computing what the user hasn’t requested.