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

51–60 of 227 posts

Re: When Haskell Is Not faster than C

#51

Post by rtpg »

sold wrote: post #20
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…

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).

Re: When Haskell Is Not faster than C

#52

Post by simias »

amirmc wrote: post #29
simias wrote: post #8

This 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…

Curious to know what you think of http://ocaml.org , specifically the code example on the front page and the further examples it links to ( http://ocaml.org/taste.html )

Looks like what I would expect from a language introduction. Explains the syntax, shows off some features, gives you snippets of code and tells you how to feed them into a REPL. It's a good way to start and get people interested in the language I think.

Re: When Haskell Is Not faster than C

#53

Post by dschiptsov »

Perfection is achieved not when there is nothing more to add, but when there is nothing more to remove.)

When one programs a computer (in a way it suggested in TAOCP) and you know your data, your memory layout and your CPU instruction set nothing could beat it.

Of course, there are tasks so massive, that a decent compiler could save lots and lots of man hours, but it is a completely different story.

No Haskell (leave alone J* ) could beat a code by people who know what they do close to the metal.

In some languages the code could be shorter much more readable and elegant that C, but of course, it is not Haskell, or J* .

Thoughtfully crafted Common Lisp could be close to an ideal.)

Re: When Haskell Is Not faster than C

#54

Post by pjmlp »

jrockway wrote: post #27
pjmlp wrote: post #12

Earlier quoted context omitted.

It amazes me how bad developers seem to be prepared nowadays in compiler design and language theory. Back in the day we were able to understand that language and implementation are separate concepts. As well as why certain languages had a specific implementation as the default one. Now young developers seems to think language and implementation are the same thing.

Many languages go so far as to specify a virtual machine to run the compiled program, so your statement doesn't make much sense in that context. Languages, machines, libraries and implementation are all deeply interconnected. Try writing C without a stack. Try writing Java without java.lang.

You just prove my point.

Of course languages define virtual machines, or in languages like C the abstract machine model, but that is only how the developer sees the machine through the language semantics.

This does not change in any way whatsoever how the language is actually implemented.

Re: When Haskell Is Not faster than C

#55

Post by sparkie »

Peaker wrote: post #39
sharpneli wrote: post #17

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…

You could use green threads in C but you'd also need asynchronous io to work with these green threads, and an ecosystem of libraries around it. Ghc has it therefore it makes sense to use its by default green threads. In c there is no standard ecosystem around green threads therefore it is harder to write the benchmarks that way.

This misses the point on why green threads are, and can be the default behavior in Haskell. It's because the purity allows it to be.

Sure you can make "green threads" in C, but you as the programmer must be very careful how you use these threads. You can't go accessing some global state (or performing many different side-effects) from them freely - so you must design your code to be as "purely functional" as possible to make any sense of them. The problem is when you come to use somebody elses code - how do you know it doesn't cause side-effects, if say, you only have the object and header files?

You don't, so at best you could "trial and error" until you find out that they're safe enough to use in green threads, but some bug might come back to bite you in the long run.

Haskell prevents this from ever being the case, because any function which does have side-effects must clearly express the fact in it's type signature. A green thread API can therefore specify the limitations on side-effects that may occur in it.

Re: When Haskell Is Not faster than C

#56

Post by spookylukey »

This article starts by totally misrepresenting the original article (http://paulspontifications.blogspot.co.uk/2013/01/when-haske...) by saying that it said "Haskell beats out C when it comes to speed".

If you bother to read even the TLDR of the original article you 'll find it says something completely different, which makes this article pretty poor as a response.

Re: When Haskell Is Not faster than C

#57

Post by chii »

nicholassmith wrote: post #2

Nice refutation. The problem about doing language comparisons for speed is that they generally require a non-trivial example, so you have to be an excellent programmer in all the languages you've compared. Of course, language speed charts are generally as useful as PC spec charts and YouTube videos of Nürburgring laptimes when you're buying a new car.

well, what about an existing piece of software, and compare on more than just speed, but ease of maintenance (meaning, how quickly you can add features or fix a bug)?

There seems to be a myriad of window managers and web frameworks. Someone should do an unbiased comparison.

Re: When Haskell Is Not faster than C

#58

Post by [deleted] »

simias wrote: post #8

This 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…

[deleted]

Re: When Haskell Is Not faster than C

#59

Post by Wilya »

VeejayRampay wrote: post #41
Peaker wrote: post #35

Earlier quoted context omitted.

I don't think other languages have the same benefits of Haskell. They have other benefits but not Haskell's. Python/Ruby: very easy to learn and be productive quickly. C: high level of control over resources and easy to get good performance. Haskell: very good static guarantees about correctness. Relatively easy to get decent and good performance. Extremely educational and mind expanding, far more than say Lisp. Allo…

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.

The core of Objective Caml is awesome, but there is a severe lack of libraries, which is guess is in good part due to the limited number of users, and also to the limited advocacy/marketing done by them (compared to, say, Ruby or Haskell).

Re: When Haskell Is Not faster than C

#60

Post by aphexairlines »

simias wrote: post #8

This 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…

The haskell analogue to perlintro.html is http://www.haskell.org/tutorial/index.html

Some code to chew on, some features shown off: http://lambda-the-ultimate.org/node/2427

and a great writeup of what happens behind the curtain: http://research.microsoft.com/en-us/um/people/simonpj/papers...

Post reply on HN