Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

When Haskell Is Not faster than C

jacquesmattheij.com

Post reply on HN
Print view View original

181–190 of 227 posts

Re: When Haskell Is Not faster than C

#181

Post by tikhonj »

SilasX wrote: post #172
tikhonj wrote: post #115

Earlier quoted context omitted.

I think one of the most important features of typeclasses is the ability to be polymorphic on just the return type of an expression. For example, there is a typeclass called Read which comes with a function called read: read :: Read r => String -> r That is, you get a function from a String to whatever type is in the typeclass. It's the opposite of toString. This is also used in a whole bunch of other contexts like n…

I'm personally on a quest to "get" Haskell right now, but I really don't see what's so special about that or unique to Haskell. Languages have long accomplished what `read` does by simply casting/coercing the string into the desired type. In python, for example, I'd call int() on the input strings I want to turn into integers.

The point is that you use a single function for any type. So in Python you'd have to do int() or float() or customType()... In Haskell, all of these would be just `read'. The type system can figure out which instance to use for you, without having to specify it. Moreover, it's also trivial to write a function that works on any readable type, something hard (although not entirely impossible) to do in Python.

This makes it much easier to use: whenever you want to get any type from a string, you just read it. This is just like being able to print values of any type, except for parsing.

This can also be used with constants rather than functions. So maxBound is the maximum value for any bounded type. In Python, the closest you can get to that is something like float.maxBound. (Except, apparently, it's actually sys.float_info.max.)

As I mentioned, this also lets you define new numeric types that can still use the same literals. For my most recent project, I needed 18-bit words. I could do this and still write expressions like `x + 1` using the Word18 type. Moreover, it would be very easy to make my code generic over the exact type of number used--this would make it possible to use numbers of different sizes or even something more exotic like random variables. (It happens to be tricky because some of the semantics I was working with rely on having exactly 18 bits, but that's an issue with the domain and not with Haskell.)

In another language, I would either have to use the normal int type and make sure to always keep track of the overflow myself or I would have to wrap every literal in a function that turned into an 18-bit word.

So the special quality is being able to dispatch on the return type of an expression rather than on the types of the arguments. I think this is very special indeed and extremely useful. I hope this clarifies everything.

Re: When Haskell Is Not faster than C

#182

Post by sltkr »

ajross wrote: post #175
bcoates wrote: post #165

Earlier quoted context omitted.

To be fair to mergesort, it's particularly suitable for actual computation hardware too. It's mostly linear reads and writes, which almost all i/o systems heavily favor. GNU sort uses mergesort (in C).

GNU sort is designed to sort on disk though. If you actually watch it working on a giant file, you'll see it generating lots and lots of files in /tmp containing the merge lists. This is because quicksort obviously requires fast random access to the whole arrays, and (at least when it was written) /usr/bin/sort would be expected to be able to quickly sort data that can't fit in memory. So... if anything I think this…

> GNU sort is designed to sort on disk though. If you actually watch it working on a giant file, you'll see it generating lots and lots of files in /tmp containing the merge lists.

The number of files created is just an implementation detail; you could easily do everything in one file if you wanted to, or at most 2N files if you're not allowed to seek or overwrite files at all, and you want to do N-way merges.

Maybe GNU sort is just trying to avoid creating files larger than 2 GB (which is a problem on legacy file systems).

> Specifically here: sort is making up for the lack of memory by exploiting the comparatively (relative to virtual memory) fast streaming behavior of storage media.

Yes, also the fact that GNU sort can sort multi-terabyte files on 32-bit platforms, which otherwise wouldn't fit in memory. (Though systems with smaller process memory space than disk storage space are an oddity that will soon be outdated, I suppose.)

> I'm not at all sure a Haskell merge sort of the form used in GNU sort would do well at all

Well, even the on-disk sort starts by sorting chunks in-memory, which we have already established Haskell is bad at. However, the merge sorting part of the algorithm may well be I/O bound in practice, in which case Haskell should be able to do it just fine.

The only good reason I can think of why C could be faster, is that if you can merge more efficiently, you can choose a higher value of N for your N-way merge,

> stateful filesystem I/O is also an area where Haskell tends to fall down

What do you mean by this? AFAIK Haskell can read/write files just fine through the I/O monad.

Re: When Haskell Is Not faster than C

#183

Post by zem »

VeejayRampay wrote: post #36
jrockway wrote: post #26

Earlier quoted context omitted.

I'd say Haskell does one percent of the proselytising that Ruby does. You hear about it a lot on HN because people write interesting articles about it. Remember, most articles that are submitted aren't being upvoted. There's probably someone writing about how their ImmutableSet implementation for Java is the best thing ever, but it's not being upvoted because the community doesn't consider it interesting.

I am a Ruby programmer and let it be clear, the holier-than-thou attitude can indeed be pervasive in the Ruby community. Yet, most of the proselytism int the Ruby community are different shades of "Programming with this language makes me very happy, I'd like everyone to be happy as well". Of course it's not always as clear cut and there is sometimes much to be desired in terms of behavior. But that's where the Haskel…

as a rubyist who has dabbled a bit in haskell, i think the two camps are exactly the same in terms of proselytising. it's just frustrating to see people using "less-capable" languages and imagining how much happier/more productive/safer they'd be if they only adopted yours.

Re: When Haskell Is Not faster than C

#184

Post by tikhonj »

VeejayRampay wrote: post #5

I still wonder to this day why Haskell programmers want their language to be loved so much. At times it feels like that kid at the playground that spends half his time telling everyone how he's the best thing since sliced bread and cries himself to sleep at night wondering why no one will play with him and his monads. Don't get me wrong, Haskell looks like a great language with obvious qualities and I don't knock any…

I've seen far more people advocate Python than Haskell, and look at it now!

Of course, since Python is already popular and widely used, this has died down a bit since. That said, even on HN, where it seems almost everybody is using Python anyhow, I still see at least as many comments promoting Python as Haskell.

Re: When Haskell Is Not faster than C

#185

Post by SilasX »

tikhonj wrote: post #181
SilasX wrote: post #172

Earlier quoted context omitted.

I'm personally on a quest to "get" Haskell right now, but I really don't see what's so special about that or unique to Haskell. Languages have long accomplished what `read` does by simply casting/coercing the string into the desired type. In python, for example, I'd call int() on the input strings I want to turn into integers.

The point is that you use a single function for any type. So in Python you'd have to do int() or float() or customType()... In Haskell, all of these would be just `read'. The type system can figure out which instance to use for you, without having to specify it. Moreover, it's also trivial to write a function that works on any readable type, something hard (although not entirely impossible) to do in Python. This make…

That does make more sense, and I appreciate the more thorough explanation. It seems a bit ironic though, that Python makes you more specific and certain about the output type than Haskell!

Re: When Haskell Is Not faster than C

#186

Post by Sssnake »

confluence wrote: post #179
tensor wrote: post #158

Earlier quoted context omitted.

The old appeal to popularity. The only argument that is worse is the appeal to faith. An intellectual circle jerk occurs when one repeats the same old mantra without doing any actual research. There are plenty of "shipping" products in languages like Haskell. I'm no expert on Haskell, but this wasn't hard to find: http://www.haskell.org/haskellwiki/Haskell_in_industry A better tagline might be: Think more and don't s…

That page is just sad when compared to C/C++/Java. When Haskell is pushing trillions (downloads/cash/views/ads) every year - call me. Furthermore: > Bad science. The Haskell community generate an unprecedented amount of bad science, setting out to draw the conclusion that Haskell is great and using every trick in the book to make that conclusion seem feasible. In many cases, it requires quite some effort to uncover t…

>When Haskell is pushing trillions (downloads/cash/views/ads) every year - call me.

Did you not notice how many banks are on that page?

>Source: http://flyingfrogblog.blogspot.ch/

Are you seriously referencing Harrop to support your argument? You do realize he is a troll right? Not like, people disagree with him, an actual, original definition troll. He jumps from language to language as people learn to ignore him, and has gone through trolling every major functional programming language except F#, which is the one he currently says is perfect and ocaml is shit. Before that, ocaml was perfect and haskell was shit. Before that, haskell was perfect and lisp was shit. Google his name, there's literally thousands of messages from him in mailing list archives demonstrating this.

Re: When Haskell Is Not faster than C

#187

Post by Sssnake »

anon1385 wrote: post #177
tensor wrote: post #158

Earlier quoted context omitted.

The old appeal to popularity. The only argument that is worse is the appeal to faith. An intellectual circle jerk occurs when one repeats the same old mantra without doing any actual research. There are plenty of "shipping" products in languages like Haskell. I'm no expert on Haskell, but this wasn't hard to find: http://www.haskell.org/haskellwiki/Haskell_in_industry A better tagline might be: Think more and don't s…

That page has generated some heat in the past: http://flyingfrogblog.blogspot.ch/2010/05/why-is-haskell-use... (admittedly this guy seems to have some personal grievances with people in the Haskell community) I don't know how much the page has changed since this rant was written, but some of the entries seem to be the same, e.g. 'Ansemond LLC' which is a company with a single mac app that hasn't been updated since a…

>admittedly this guy seems to have some personal grievances with people in the Haskell community

No, he's a troll. He trolled lisp, then haskell, then ocaml. 2010 fell into his haskell phase, that's the entire reason for that particular pile of bullshit.

Re: When Haskell Is Not faster than C

#188

Post by confluence »

Sssnake wrote: post #186
confluence wrote: post #179

Earlier quoted context omitted.

That page is just sad when compared to C/C++/Java. When Haskell is pushing trillions (downloads/cash/views/ads) every year - call me. Furthermore: > Bad science. The Haskell community generate an unprecedented amount of bad science, setting out to draw the conclusion that Haskell is great and using every trick in the book to make that conclusion seem feasible. In many cases, it requires quite some effort to uncover t…

>When Haskell is pushing trillions (downloads/cash/views/ads) every year - call me. Did you not notice how many banks are on that page? >Source: http://flyingfrogblog.blogspot.ch/ Are you seriously referencing Harrop to support your argument? You do realize he is a troll right? Not like, people disagree with him, an actual, original definition troll. He jumps from language to language as people learn to ignore him, a…

Those banks do not have significant Haskell investment or units - so your point is void.

Re: When Haskell Is Not faster than C

#189

Post by billsix »

SilasX wrote: post #172
tikhonj wrote: post #115

Earlier quoted context omitted.

I think one of the most important features of typeclasses is the ability to be polymorphic on just the return type of an expression. For example, there is a typeclass called Read which comes with a function called read: read :: Read r => String -> r That is, you get a function from a String to whatever type is in the typeclass. It's the opposite of toString. This is also used in a whole bunch of other contexts like n…

I'm personally on a quest to "get" Haskell right now, but I really don't see what's so special about that or unique to Haskell. Languages have long accomplished what `read` does by simply casting/coercing the string into the desired type. In python, for example, I'd call int() on the input strings I want to turn into integers.

On your quest I'd recommend the following: http://www.amazon.com/gp/aw/d/0134843460 http://www.cs.yale.edu/homes/hudak/SOE/ http://book.realworldhaskell.org

Re: When Haskell Is Not faster than C

#190

Post by jacquesm »

neopallium wrote: post #164

There is a bug that causes invalid output when the input file is larger then the BLOCKLEN. Set BLOCKLEN to 4096 and run the program on the test input file [1] (compare with output file [2]), to see the problem on a smaller input file. The bug happens when read_sequence() is called with partial data saved from the last sequence, since (size == read) the first fread() will be asked for 0 bytes which causes the read loo…

That was a good catch! Serves me right for testing with the small file for correctness and testing for speed with the larger one.
Post reply on HN