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

111–120 of 227 posts

Re: When Haskell Is Not faster than C

#111

Post by jacquesm »

bgilroy26 wrote: post #103
pretoriusB wrote: post #76

Earlier quoted context omitted.

> It doesn't seem like you are really in disagreement. Oh, I'm very, very much in disagreement. It's not just about "preference" as if preference is arbitrary. Superficial syntactic preference IS arbitrary. Substancial syntax issues are not. Brainfuck is not just left alone because people don't "prefer" its syntax. That's reading it in reverse. People don't prefer Brainfuck's syntax because it is objectively, and for…

Preference isn't arbitrary, people make reasoned judgments to determine what tools they will use to get their work done. No one spends 40 hours a week with a language without knowing its strengths and weaknesses.

> No one spends 40 hours a week with a language without knowing its strengths and weaknesses.

I wouldn't take that bet.

Re: When Haskell Is Not faster than C

#112

Post by pohl »

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/wiki/Sorting_algorithms/Quicksort#Com...

Re: When Haskell Is Not faster than C

#113

Post by papsosouid »

jacquesm wrote: post #84
gnuvince wrote: post #80

> This article is in response to an earlier one comparing Haskell and C, which made the claim that Haskell beats out C when it comes to speed. 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: > TL;DR: Conventional wisdom is wrong. Nothing can beat highly micro-o…

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

Re: When Haskell Is Not faster than C

#114

Post by papsosouid »

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.

Re: When Haskell Is Not faster than C

#115

Post by tikhonj »

rtpg wrote: post #51
sold wrote: 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).

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 numbers--numeric literals are polymorphic, letting you add any numeric type you want and still use literals for it.

As far as I know, Go cannot do anything of the sort.

There are some other nice features of typeclasses, like the ability to have multiple types. That is, you could have a typeclass for multiplication that allowed you to multiply two numbers, two matrices or a number with a matrix. You can even have typeclasses that are recursive, allowing you to define them for an infinite amount of types: you could have a typeclass for functions of any number of arguments, for example.

I think Go interfaces do none of that as well.

Now Rust, on the other hand, actually* has typeclasses.

Re: When Haskell Is Not faster than C

#116

Post by jmount »

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…

Plus quicksort is a classic morass- by the time you harden it enough to deal with real world data you could have written a proper merge sort with similar average case performance and much better worst case guarantee. My rant on quicksort: http://www.win-vector.com/blog/2008/04/sorting-in-anger/

Re: When Haskell Is Not faster than C

#117

Post by papsosouid »

bborud wrote: post #21

If Haskell, Lisp and friends are so great for building large software systems then surely people are going to flock to them and do exactly that. And if that didn't happen, of course the proponents of these languages would sit down and try to figure out why this wasn't happening. Right?

>If Haskell, Lisp and friends are so great for building large software systems then surely people are going to flock to them and do exactly that

No, I have seen no evidence to suggest that a majority of people will do the best thing when given the option. Popularity does not correlate well with quality. Or are you seriously suggesting "Transformers 19: BANG BANG EXPLOSIONS!!1" is the pinnacle of human artistic achievement? Those who realize how good haskell is are using it. Why would we stop and try to figure out why the majority are still watching Michael Bay sequels instead?

Re: When Haskell Is Not faster than C

#119

Post by haberman »

benbataille wrote: post #6

Could everyone on HN just take a course in languages theory so we can all stop with these stupid trolls about the best languages which have been emerging for a week. 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. Nothing sacred here. Hell you can even do imperative programming in Haskell if you wish. Coding an interpret…

> So, yes, Haskell semantics encourage functional programming, C semantics imperative programming, both are Turing complete and yes GCC is currently better at optimising C code than any Haskell compiler

No. That is not why C is winning. C is winning because of fundamental differences between its semantics and Haskell's semantics that makes it possible to implement C with less overhead on actual CPUs.

If the lesson you took from your language theory course is that all Turing-complete languages are equivalent, you should ask for your money back. While it is true that they are all capable of expressing any algorithm, there are fundamental differences that deeply affect the efficiency of implementing them: http://news.ycombinator.com/item?id=5082609

Re: When Haskell Is Not faster than C

#120

Post by agumonkey »

rtpg wrote: post #46
amirmc wrote: post #29

Earlier quoted context omitted.

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 )

Funny, I've never seen that page, I always land on Inria's page( http://caml.inria.fr/ ).

Me too. Quite delighted to see ocaml having a refreshed page and active community.
Post reply on HN