Is there a reason "Is" and "Not" are capitalized but "faster" and "than" aren't, because it's just been bugging all day whenever I refresh the front page and look over the list for anything interesting.
When Haskell Is Not faster than C
191–200 of 227 posts
Re: When Haskell Is Not faster than C
#192Earlier 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…
> Notably, stateful filesystem I/O is also an area where Haskell tends to fall down.
Can you give an example? I do not understand what you mean. The filesystem is stateful, but I do not see that impeding Haskell.
Re: When Haskell Is Not faster than C
#193This reminds me that when I was interested in learning haskell I was completely put off by their "introduction" page on their homepage. It was a couple of years ago but it doesn't seem to have changed much: http://www.haskell.org/haskellwiki/Introduction It looks like a very pretentious sales pitch to me. You have quotes like "Writing large software systems that work is difficult and expensive. [...] Functional progr…
"They also give a link to a more direct (and faster) C-to-haskell version of the quicksort[1]. Hey, it's actually longer than the C version! And it uses 3 imports. And it's still slower than the original C. Oops"
that made me laugh a few years (?) ago and it still does :)
Re: When Haskell Is Not faster than C
#194Earlier quoted context omitted.
> From this, I understood that in a larger program, most programmers wouldn't be doing the kind of micro-optimizations that they do for the Benchmarks Game. The TL;DR; is wrong too. It doesn't require micro-optimizations for a large real world C program to be faster than an equivalent Haskell program. All those abstractions and laziness in Haskell add up, and you get lower performance overall compared to ANY decent C…
By the same token, the lack of higher level abstractions in C also add up in time and mental effort, and you're more likely to end up, in my experience, writing a dumber and more dangerous algorithm than you would in a language that has better safety features and more powerful abstractions.
Even without trying to optimize.
But I think the main issue is that "new" people don't realize most of their beloved languages aren't self hosted and are C compiled and/or that they're calling the C library for almost everything.
Thus, knowing C matters a whole lot. Using it is another matter, and albeit the flexibility of C makes programs a lot more efficient every single time (when you have time and skill), it's understandable to use other languages.
Still, some tasks should still be done in C instead of starting one of these countless runtime of the new language on the block. I'm slightly tired of the huge interpreted programs running extremely slower than they should these days. Even thus the hardware has gone way faster we still manage to reproduce 10y old programs that run slower than they did when we first made them.
Re: When Haskell Is Not faster than C
#195> This article is in response to an earlier one comparing Haskell and C, which made the claim that Haskell beats out C when it comes to speed. Perhaps my reading comprehension of the original post is different from Jacques' (or I'm just wrong), but I don't think that the original article made such a claim. Here's the TL;DR of the original article: > TL;DR: Conventional wisdom is wrong. Nothing can beat highly micro-o…
IMO you can make C as fast or slow as you want it to be. If you write terrible C it's going to be slower than good Haskell.
If you write common C (and by common I mean what you see in well known daemons, kernels, etc) its generally at the very least on par. That's mostly because most of the functions come from libraries that have been optimized, in both cases.
Re: When Haskell Is Not faster than C
#196Earlier quoted context omitted.
OCaml isn't purely functional, so it misses some of the most important benefits of Haskell. It's also not entirely honest (in the fact that you can do things that the type system doesn't tell you about.)
With unsafePerformIO, Haskell is also not "entirely honest"...
With `{-#LANGUAGE Safe#-}` it is.
Re: When Haskell Is Not faster than C
#197Earlier quoted context omitted.
I prefer Erlang. http://rosettacode.org/wiki/Sorting_algorithms/Quicksort#Erl... And your illustration is particularly good for showing how much more "sane" (actually, in many ways) Erlang is. And how elegantly different Python could be. J* is my own abbreviation for Java and Javascript.)
I prefer Erlang. Just out of curiosity, why is that? (With reference to the linked example, I mean.) Clearly they're in the same league, and so it's a close call. From my perspective, I like that Haskell reserved the single vertical bar for the list comprehension notation, so that it would be as close to familiar set-comprehension notation as possible. I also like how Haskell takes advantage of how the cons operator…
I think the sytnax of Erlang is much more elegant, because it was build around the fundamental idea of pattern matching as a core feature of the language.
When you have a few good ideas put together, you could get an elegant solution. When you just stuff everything inside (like Clojure) or went to extremes (like Haskell) all you got is just a mess.
Erlang syntax, however, is noisy due to all those punctuation, but it is elegant nevertheless.
map(Fun, [H|T]) -> [Fun(H)|map(Fun, T)];
map(Fun, []) -> [].
member(H, [H|T]) -> true;
member(H, [_|T] -> member(H, T);
member(H, []) -> false.
Re: When Haskell Is Not faster than C
#198Earlier quoted context omitted.
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.
The thing is, there is some truth in among the bullshit. That 'Haskell in Industry' page really does have links to non existent products or long dead projects or things that don't seem to be using Haskell at all. And even after that blog post was widely circulated 2 years ago the page remains unchanged, and people are still citing it as evidence for the widespread use of Haskell in industry.
Re: When Haskell Is Not faster than C
#199Earlier quoted context omitted.
I prefer Erlang. Just out of curiosity, why is that? (With reference to the linked example, I mean.) Clearly they're in the same league, and so it's a close call. From my perspective, I like that Haskell reserved the single vertical bar for the list comprehension notation, so that it would be as close to familiar set-comprehension notation as possible. I also like how Haskell takes advantage of how the cons operator…
I think the sytnax of Erlang is much more elegant, because it was build around the fundamental idea of pattern matching as a core feature of the language. When you have a few good ideas put together, you could get an elegant solution. When you just stuff everything inside (like Clojure) or went to extremes (like Haskell) all you got is just a mess. Erlang syntax, however, is noisy due to all those punctuation, but it…
I'm not sure I follow you. Is the pattern-matching in Haskell somehow not 'core' enough? Both qsort examples linked in this thread use pattern matching.
Re: When Haskell Is Not faster than C
#200Earlier quoted context omitted.
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.
The difference there is that Haskell actually does offer some functionality and concepts that aren't really present in most other programming languages.
Ruby, on the other hand, is pretty unremarkable. It doesn't really offer anything beyond what older languages like Perl and Python, for example, offer.