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

151–160 of 227 posts

Re: When Haskell Is Not faster than C

#151

Post by evincarofautumn »

abraxasz wrote: post #140
Swizec wrote: post #11

Earlier quoted context omitted.

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

When I find myself using arrows, usually I realise that I got lazy and used tuples because my data model wasn’t good enough. Good code flows from good data.

But really, you should use the “tricks” when they make your code more expressive, not just because they’re cool. It’s the same in any language.

Re: When Haskell Is Not faster than C

#152

Post by Locke1689 »

TylerE wrote: post #139
Peaker wrote: post #66

Earlier quoted context omitted.

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_ operato…

Unfortunately, OCaml doesn't have enforced purity outside the IO monad. This removes one of the main benefits of Haskell, which is to force people who are terrible at functional programming to actually write code in a functional style.

Re: When Haskell Is Not faster than C

#154

Post by dschiptsov »

pohl wrote: post #112
dschiptsov wrote: post #53

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…

Lisp's homoiconicity comes with the cost of some extra syntactic weight that Haskell doesn't have to bear. (It's also nice that "lambda" is considered so important that it's given a single character in Haskell). I'm not familiar with J*, and it seems to be difficult to search for. Do you have a reference so I can go learn about it? http://rosettacode.org/wiki/Sorting_algorithms/Quicksort#Has... http://rosettacode.org…

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

Re: When Haskell Is Not faster than C

#155

Post by kevinnk »

microtonal wrote: post #129
codygman wrote: post #104

Earlier quoted context omitted.

What do you mean add two of the same things together exactly? If I'm not mistaken, what you are talking about is possible but I don't totally understand what you are saying. Could you provide an example?

The types of polymorphism are different. Haskell's parametric polymorphism is compile-time polymorphism, Go's interfaces are run-time polymorphism. If we draw a parallel to C++, Haskell's polymorphism is like templates, Go's interfaces are like abstract base classes (except that they use compile-time duck typing). For example, consider the (+) function in Haskell: (+) :: Num n -> n -> n -> n If you use an Integer as…

> If we draw a parallel to C++, Haskell's polymorphism is like templates

It's important to note that even if Haskell's classes feel like C++ templates they are actually implemented more like abstract classes. In C++ you essentially create a new function for each template instantiation. In Haskell the function is passed an additional pointer telling the function how to implement the class. Kind of like a vtable pointer except not bound to the actual object. This has performance implications, so it's an important point to remember when comparing the languages.

Re: When Haskell Is Not faster than C

#156

Post by nightski »

TylerE wrote: post #139
Peaker wrote: post #66

Earlier quoted context omitted.

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_ operato…

I actually think the main thing OCaml lacks is the separation of pure from non-pure code via the type system. I have really become addicted to the way this ends up affecting the architecture of the code, and the guarantees it provides when using code I did not write.

Re: When Haskell Is Not faster than C

#157

Post by DanWaterworth »

kevinnk wrote: post #155
microtonal wrote: post #129

Earlier quoted context omitted.

The types of polymorphism are different. Haskell's parametric polymorphism is compile-time polymorphism, Go's interfaces are run-time polymorphism. If we draw a parallel to C++, Haskell's polymorphism is like templates, Go's interfaces are like abstract base classes (except that they use compile-time duck typing). For example, consider the (+) function in Haskell: (+) :: Num n -> n -> n -> n If you use an Integer as…

> If we draw a parallel to C++, Haskell's polymorphism is like templates It's important to note that even if Haskell's classes feel like C++ templates they are actually implemented more like abstract classes. In C++ you essentially create a new function for each template instantiation. In Haskell the function is passed an additional pointer telling the function how to implement the class. Kind of like a vtable pointe…

That's a good point, however, the important aspect of typeclasses is that they're type-checked, not that they're compiled via monomorphization. Also, I believe that the way that typeclasses are compiled is at the discretion of the compiler, so actually typeclasses may be compiled in the same way as C++ templates. Another point is that monomorphisation isn't always possible, because a function could be run with an infinite number of types.

Re: When Haskell Is Not faster than C

#158

Post by tensor »

confluence wrote: post #68

The problem with fringe languages has always been the "all talk - no walk" nature they all seem to have. Stop telling me why you are so awesome. Just show me with shipped product. Until then it's just an intellectual circle jerk. Talk less. Ship more.

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 settle for the status quo.

Re: When Haskell Is Not faster than C

#159

Post by ajross »

sltkr wrote: post #148
revelation wrote: post #71

Earlier quoted context omitted.

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

To be fair, QuickSort is particularly suitable for actual computation hardware which has hardware features like numerically addressed, stateful random access memory. Imperative arrays happen to feature "in-place modification of arrays" not because it's a useful language feature but because it's a straightforward abstraction of the actual machine being programmed.

That distinction is really important, and something I think many language nerds completely fail to understand. Sure, often all that's "really" important is the abstraction of the "Human Design Space" idea being implemented, and that's a regime where high level language abstractions have lots of value.

But sometimes you want to actually direct the hardware. And there, as everywhere, it helps to use a language with the proper abstractions. C has them, Haskell doesn't. There's absolutely no shame in that!

But somehow people get fooled into thinking that somehow Haskell (or whatever language is involved in the argument, but it seems like Haskell people fall into this hole more than most) doesn't need those abstractions to be "as fast a C". And that's just insane.

Re: When Haskell Is Not faster than C

#160

Post by pekk »

dasil003 wrote: post #85
VeejayRampay wrote: post #36

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

Rubyists aren't like hippies (hippies have no taste and they dislike drama), more like hipster art critics if anything. Haskellers being compared to Jehovah's witnesses is even more wrong. They're more like scientists, maybe of the climate change variety: most of them keep their heads down with a dedication to improving the state of the art, but when they go public it's with good reason and people should listen rathe…

Haskell has not uncovered an impending disaster which everyone ignores at their own peril. It is a programming language on the same basic level as many other popular and useful programming languages.
Post reply on HN