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

141–150 of 227 posts

Re: When Haskell Is Not faster than C

#141

Post by microtonal »

dllthomas wrote: post #124
sparkie wrote: post #49

Earlier 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"...

That's certainly true and always be true given the mutability underlying architectures and operating systems. However, in Haskell, unsafePerformIO is normally only used when it can be shown that a function is referentially transparent. When this is not the case, a function ought to return an IO value.

The general rule is: don't use unsafePerformIO unless your name is Simon ;).

Haskell succeeded in isolating side effects to a great extend. It has its advantages, referential transparency leads to predictable and understandable code. And disadvantages - you have to keep state via argument passing (which can be hidden nicely using the State monad) and when implementing inherently mutable algorithms you usually end up using the ST monad. Still, on the outside, a function will be pure and pretty :).

Re: When Haskell Is Not faster than C

#142

Post by teamonkey »

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…

"You want to play? Great! The rules? Perhaps it's easiest if you understand category theory first..."

Re: When Haskell Is Not faster than C

#143

Post by davorak »

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…

That is not the best introduction to the programming language by means of practical examples, but it does not look like it is supposed to be either. At least from Haskell.org it links from "What is Haskell?" Which is a very different question then what can I do with Haskell.

Re: When Haskell Is Not faster than C

#144

Post by davorak »

looser wrote: post #45
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…

Probably the reason Haskell's introduction has more explanation is because for most, functional programming language is unusual. Evaluating a language by just reading the introduction is like reading the introduction of a book and saying that you didn't like it. Read it! :) It seems we are focusing too much in a possible weak point and forgeting about several strong points Haskell has.

It is linked from the main page to answer the question "What is Haskell?" It is not supposed to an example driven page at all. The title of the wiki page could be changed to fix this though. The very next link is http://tryhaskell.org/ to learn Haskell in a example driven way.

Re: When Haskell Is Not faster than C

#145

Post by dllthomas »

microtonal wrote: post #141
dllthomas wrote: post #124

Earlier quoted context omitted.

With unsafePerformIO, Haskell is also not "entirely honest"...

That's certainly true and always be true given the mutability underlying architectures and operating systems. However, in Haskell, unsafePerformIO is normally only used when it can be shown that a function is referentially transparent. When this is not the case, a function ought to return an IO value. The general rule is: don't use unsafePerformIO unless your name is Simon ;). Haskell succeeded in isolating side effe…

This is all correct, and I do think it's an important difference between Haskell and OCaml, I just didn't like the way it was phrased ("lies") because that's not really the difference. The difference is that Haskell has a place for you to document (in the type system) whether functions have certain types of effects (and if you cooperate just a little, the compiler will make sure this documentation is correct). The cost is the (conceptual) overhead of actually doing this - which is small when you know what you're building but can require some re-plumbing of a chunk of your code when things change.

This difference isn't inherently a win for Haskell - that OCaml doesn't bear the cost of significant restructuring because you find you need to do some IO based on results internal to a function several layers down is a big win in the short term. Whether it's a win in the long term, and how much the short matters versus the long, would seem to depend very much on the particular problems you're solving.

Having come to Haskell from C by way of OCaml, my personal preference is to get as much out of the type system as one can - but one should always be aware of the trade-offs.

Re: When Haskell Is Not faster than C

#146

Post by microtonal »

pjmlp wrote: post #54
jrockway wrote: post #27

Earlier quoted context omitted.

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.

This discussion is derailing. From the top-level comment:

Hopefully it would allow everyone to realize that a language is just some syntax and semantic and that a compiler is just a program like another.

Which is true. However, this glosses over the fact that it is prohibitively hard to write efficient compilers for some languages. For instance, Prolog's semantics are so far removed from our machines that it is terribly hard to make it efficient for general purpose programs.

Semantics do make some languages harder to compile to efficient machine code than others.

Re: When Haskell Is Not faster than C

#147

Post by jberryman »

revelation wrote: post #71
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…

That wiki link to an actual implementation of quicksort in Haskell is pure comedy gold (1): " Unfortunately none of the above "real" quicksorts seems to compile as given " " The program below is working very very slowly. It's probably slowsort. " " A more specific/direct translation (neither this nor the C version is polymorphic) is offered by Daniel Fischer, who reports that this version runs within 2x of the C vers…

> and it's a completely unreadable mess that is clearly a line by line copy of the C code given

I didn't find it unreadable, and I think the point was to copy the C implementation. I'm not sure what you were expecting.

In any case the unfortunate state of parts of the haskell wiki isn't a good reason to feel one way or the other about the language.

Re: When Haskell Is Not faster than C

#148

Post by sltkr »

revelation wrote: post #71
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…

That wiki link to an actual implementation of quicksort in Haskell is pure comedy gold (1): " Unfortunately none of the above "real" quicksorts seems to compile as given " " The program below is working very very slowly. It's probably slowsort. " " A more specific/direct translation (neither this nor the C version is polymorphic) is offered by Daniel Fischer, who reports that this version runs within 2x of the C vers…

To be fair, QuickSort is particularly suitable for imperative languages that allow in-place modification of arrays. For functional languages, merge sort is a much more natural solution that is simple to implement, guaranteed to be efficient, and probably reasonably fast (though still unlikely to beat a QuickSort implementation in C).

Re: When Haskell Is Not faster than C

#149

Post by fusiongyro »

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…

Many programmers find it easier to understand something by trying to explain it. Haskell has a lot of foreign concepts, so you see a lot more articles from people trying to convey their "aha!" moment. Many of these are erroneous or overly exuberant but it's just because people get excited when they first understand something new. It probably does come across as proselytization--that may even be the intent--but if it helps you cope with it, know that the majority of these articles are first impressions from beginners getting their minds blown, and most of them don't stick it out.

Re: When Haskell Is Not faster than C

#150

Post by tome »

papsosouid wrote: post #114
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 still wonder to this day why Haskell programmers want their language to be loved so much. I don't. I just talk about it so that some of the brighter people out there will try it out. This increases the pool of people for me to hire as haskell programmers that can get started right away instead of having to learn first.

Where do you work and what are you hiring for?
Post reply on HN