Live data from Hacker News

When Haskell Is Not faster than C

jacquesmattheij.com

131–140 of 227 posts

Re: When Haskell Is Not faster than C

#131

Earlier quoted context omitted.

> 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: The TL;DR is not representative of the whole article. It would be nice if it were but it isn't, so just reading the TL;DR is not enough, better do the short-enough;did-read version of that. Another commenter in…

The whole article didn't make such a claim either. Your hate boner is clouding your judgement. Your article is far more biased and far less useful than the original. Especially all the random off-topic nonsense like "you should totally add error checking" and "lets change the style for no reason because I want to pad the length of this".

I can't parse your comment, please rephrase.

Re: When Haskell Is Not faster than C

#133
What do you guys think I should learn next? I've been studying javascript/ruby and I would like to diversify what I can make. I don't want to rush learning new languages, but it's interesting to learn about paradigms that certain languages enforce.

What's important to me(not in order):

1) Being an omni-platform developer 2) I only know two high-level languages, so learning a low level language will benefit me. 3) I want to get into Natural Language Processing and deep neural networks/AI, machine learning etc. 4) I'm a self-taught programmer, so the amount of good resources online/amazon is a big factor. 5) I need a fucking job. 6) I like making web applications/web games, and I would like to make native applications/games as well.

Re: When Haskell Is Not faster than C

#134
post #51
post #20

Earlier quoted context omitted.

It's different. It's like you were listening to one music genre all your life and there's suddenly something new. If, say, Python was the only language with "for(each)" loops, you'd see many blog posts about that too. After I saw this, the old style of iterating by index feels so antiquated. Haskell gives the same feeling many times. It has unique features when it comes to abstraction and I feel they are the right wa…

strangely enough, I think one of the interesting features (type classes) only ended up reappearing in Go with its interfaces (granted, only in a very limited fashion).

Rust has them too, it's described in this very interesting blog post that I haven't had time to fully read yet:

http://smallcultfollowing.com/babysteps/blog/2012/04/09/rust...

"We also manage to combine traditional class-oriented OOP with Haskell’s type classes in a way that feels seamless to me."

Re: When Haskell Is Not faster than C

#135

Earlier quoted context omitted.

> 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: The TL;DR is not representative of the whole article. It would be nice if it were but it isn't, so just reading the TL;DR is not enough, better do the short-enough;did-read version of that. Another commenter in…

The whole article didn't make such a claim either. Your hate boner is clouding your judgement. Your article is far more biased and far less useful than the original. Especially all the random off-topic nonsense like "you should totally add error checking" and "lets change the style for no reason because I want to pad the length of this".

> Your hate boner is clouding your judgement.

Should be a button or T-shirt.

Re: When Haskell Is Not faster than C

#136

I ran into similar issue few years ago where lack of knowledge combined with large amount of fanboyism clouded someones mind. In a popular language comparisons site there was a threading benchmark. It was simple, just start 256 threads. Haskell beat C by far. I did strace. The C benchmark actually spawned 256 threads and the Haskell one spawned 4. The response I got was that it's a builtin feature in Haskell that it…

I've never worked on a project where my job was to create 256 threads. Instead, I would be tasked with processing lots of requests or datasets in parallel. If Haskell provides convenient and idiomatic ways to do this with lightweight threads that C does not, then C is effectively slower. If C has a commonly used and available library to implement this same approach - then maybe its faster. The whole point is we are comparing implementations of a programming task.

Re: When Haskell Is Not faster than C

#137

Earlier quoted context omitted.

I'm trying to translate what you are saying. All languages are Turing complete, so it doesn't matter? Do you program in assembly language then? I mean, if it doesn't matter....

> All languages are Turing complete, so it doesn't matter? Precisely. The whole "my language is better" argument is completely void. Syntax is mostly a matter of preference. Semantic will make the structure of your program different but in the end there is no actual difference on what you can do only on how you will do it. Once again it mostly boils down to preference. If you really need to argue about something go f…

> Note that there is no theoretical bound preventing an Haskell compiler to generate code equally fast than the one of a C compiler for any program.

And there's no theoretical bound saying that C is faster than Brainfuck. But no Brainfuck implementation will ever catch C for, say, parsing, and I'd be willing to put money on that.

This "all Turing-complete languages are on equal performance footing" is nonsense. Just because you can't write a proof that shows a result mathematically does not mean that a difference does not exist.

Re: When Haskell Is Not faster than C

#139
post #66

Earlier quoted context omitted.

What about Objective Caml? Seems to fit the bill for all those metrics as well, yet for a reason that eludes me to this day, it never quite reached the kind of "street rep" that Haskell now enjoys.

I don't know OCaml very well, but I do know that without laziness, it does not support as much high-level/reusability[1]. Also, it lacks much of the mind-expanding stuff in Haskell (The class hierarchy explained by the Typeclassopedia). AFAIK, GHC had surpassed OCaml's compilers' performance, concurrency support, etc. Compiler rewrite rules are also a very nice feature that other languages cannot immitate due to lack…

Your're showing your ignorance.

OCaml has full support for laziness. It's just default strict with optional laziness via a keyword (http://caml.inria.fr/pub/docs/manual-ocaml/libref/Lazy.html), rather than the opposite.

The only thing Caml lacks that haskell has is typeclasses, so doing non-integer math is ugly, and non-int/float math is REALLY ugly, like something out java or something, since there is _no_ operator overloading.

I suspect the main barriers to Caml gaining wider acceptance had more to do with a cultural barrier - both the documentation and error messages in English were (and mostly continue to be) fairly poor.

Caml actually did attain a measure of popularity for a while in the early 2000s - the winning ICFP content entry was in Ocaml for something like 4 years running at one point.

Re: When Haskell Is Not faster than C

#140
post #11

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…

Two things I love about Haskell. 1. It is very terse/expressive. I can look at code I haven't touched in 6 months and still understand what it's doing. Perhaps because my code is newbie code and thus somewhat simple. 2. It is the only language that brings me back to the days of Turbo Pascal when the joy of coding came from coding itself, not from building cool things. A small but vital distinction. That said, I rarel…

Maybe it is because I'm not a Haskell Guru, but although I love Haskell's terseness, it tends to make it very hard for me to read code I've written a while ago. I tend to get excited about cool Haskell features like Arrows, using them whenever I can, then I forget about them, and when I read my code 6 months later, it's like gibberish..
Post reply on HN