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

201–210 of 227 posts

Re: When Haskell Is Not faster than C

#201

Post by Peaker »

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…

Optional laziness is not good enough -- read the blog post I linked to. You can't re-use and compose existing functions from the standard library if they all tend to be strict.

Re: When Haskell Is Not faster than C

#202

Post by Peaker »

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

unsafePerformIO for an IO action that is not actually pure is considered a bug, and the compiler makes sure you can't abuse unsafePerformIO without being bitten very very hard.

Re: When Haskell Is Not faster than C

#203

Post by Peaker »

tikhonj wrote: post #115
rtpg wrote: post #51

Earlier quoted context omitted.

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

I think one of the most important features of typeclasses is the ability to be polymorphic on just the return type of an expression. For example, there is a typeclass called Read which comes with a function called read: read :: Read r => String -> r That is, you get a function from a String to whatever type is in the typeclass. It's the opposite of toString. This is also used in a whole bunch of other contexts like n…

Aren't Rust "type-classes" also limited and use single-dispatch?

Re: When Haskell Is Not faster than C

#204

Post by Peaker »

SilasX wrote: post #185
tikhonj wrote: post #181

Earlier quoted context omitted.

The point is that you use a single function for any type. So in Python you'd have to do int() or float() or customType()... In Haskell, all of these would be just `read'. The type system can figure out which instance to use for you, without having to specify it. Moreover, it's also trivial to write a function that works on any readable type, something hard (although not entirely impossible) to do in Python. This make…

That does make more sense, and I appreciate the more thorough explanation. It seems a bit ironic though, that Python makes you more specific and certain about the output type than Haskell!

It is only ironic until you realize static typing can often save you from writing code, and not just require more code.

Re: When Haskell Is Not faster than C

#205

Post by Peaker »

teamonkey wrote: post #142
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..."

I still didn't take the time to learn CT (after 4-5 years of Haskell). It might be time to do so, though, because I keep seeing the awesome things people with a CT background apply it to.

However, you can get very very far in Haskell without ever doing or touching any CT.

Re: When Haskell Is Not faster than C

#206

Post by tikhonj »

Peaker wrote: post #203
tikhonj wrote: post #115

Earlier quoted context omitted.

I think one of the most important features of typeclasses is the ability to be polymorphic on just the return type of an expression. For example, there is a typeclass called Read which comes with a function called read: read :: Read r => String -> r That is, you get a function from a String to whatever type is in the typeclass. It's the opposite of toString. This is also used in a whole bunch of other contexts like n…

Aren't Rust "type-classes" also limited and use single-dispatch?

I haven't used Rust very much yet, but my impression is that they can dispatch on the return type at the very least. So they can have a Num typeclass. Perhaps they're limited in some other ways, but it sounds like a good start.

Re: When Haskell Is Not faster than C

#207

Post by applicative »

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…

You aren't speaking to the principal point in the post Peaker links, which is accepted by Harper in the notes "As you know, in the eager world we tend to write out our own recursive functions, rather than use combinators", which is of course all any anyone cares about; with explicit recursion the user's IQ falls 50 points immediately. The whole discussion presupposes a mechanism for 'opting out' of default strictness or default laziness, which exists in many languages.

Re: When Haskell Is Not faster than C

#208

Post by dschiptsov »

pohl wrote: post #199
dschiptsov wrote: post #197

Earlier quoted context omitted.

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.

All I'm trying to say that Erlang syntax is much more intuitive and readable, being derived from Prolog.

I honestly can't see why should I use Haskell (except for being so clever) when I have Erlang, or at least one real advantage.

Re: When Haskell Is Not faster than C

#209

Post by zem »

PommeDeTerre wrote: post #200
zem wrote: post #183

Earlier quoted context omitted.

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.

in my experience, ruby has a lot of small improvements over perl and python that add up into a far nicer programming experience. it's subjective, perhaps, but i've used a lot of languages and i find that ruby hits the sweet spot for developer productivity.

Re: When Haskell Is Not faster than C

#210

Post by mwotton »

dschiptsov wrote: post #208
pohl wrote: post #199

Earlier quoted context omitted.

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.

All I'm trying to say that Erlang syntax is much more intuitive and readable, being derived from Prolog. I honestly can't see why should I use Haskell (except for being so clever ) when I have Erlang, or at least one real advantage.

well, let's look.

map f (h:t) = f h:map f t

map f [] = []

member x (h:t) = x == h || member x t

member _ [] = False

I think the only difference is that you can't match for equality directly in the pattern.

Post reply on HN