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

101–110 of 227 posts

Re: When Haskell Is Not faster than C

#101

Post by Chattered »

benbataille wrote: post #18
seanmcdirmid wrote: post #9

Earlier quoted context omitted.

I'm trying to translate what you are saying. All languages are Turing complete, so it doesn't matter? Do you program in assembly language then? I mean, if it doesn't matter....

> All languages are Turing complete, so it doesn't matter? Precisely. The whole "my language is better" argument is completely void. Syntax is mostly a matter of preference. Semantic will make the structure of your program different but in the end there is no actual difference on what you can do only on how you will do it. Once again it mostly boils down to preference. If you really need to argue about something go f…

> Syntax is mostly a matter of preference.

And to paraphrase Feynman, mathematics is mostly the invention of better syntax. One thing I'd say which distinguishes Haskellers is that they see their programming language as a piece of mathematics. A Haskell program is a bunch of equations, and the semantics are given by domain theory.

Re: When Haskell Is Not faster than C

#102

Post by mistercow »

The original article did mention that switching to use lines instead of characters would probably speed things up considerably, but argued that this makes the program harder to understand, while Haskell makes the same optimizations automatically on the character-based program.

And that's a fine point to make, but I do think it was a little misleading and handwavy. The proper thing to do would be to make the change and show the difference both in code and performance, and let the readers draw their own conclusions.

Re: When Haskell Is Not faster than C

#103

Post by bgilroy26 »

pretoriusB wrote: post #76
bgilroy26 wrote: post #75

Earlier quoted context omitted.

> No one using Brainfuck will never be as productive as Python, to take an extreme case. Isn't it a good thing then, that no one prefers using Brainfuck to using Python at work? Leaving things up to preference doesn't mean that all the choices are the same. It means that the languages and the use cases are so varied that it isn't a good idea to restrict oneself blindly to a language before evaluating the use case. It…

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

Re: When Haskell Is Not faster than C

#104

Post by codygman »

DanWaterworth wrote: post #90
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).

Go's interfaces are not like Haskell's typeclasses. Just try and write a Go interface that allows you to add two of the same things together.

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?

Re: When Haskell Is Not faster than C

#106

Post by JabavuAdams »

This is a classic pattern: when advocating for one of several competing approaches, you spend more care optimizing your favourite approach than the competitors.

Prof. Geoffrey Hinton specifically calls this out as a pitfall in research. It's better to compare your promising new approach versus another group's approach (not your own implementation thereof). This, assuming that the other group has deep knowledge in tuning their competing approach.

Re: When Haskell Is Not faster than C

#107

Post by jacquesm »

mistercow wrote: post #102

The original article did mention that switching to use lines instead of characters would probably speed things up considerably, but argued that this makes the program harder to understand, while Haskell makes the same optimizations automatically on the character-based program. And that's a fine point to make, but I do think it was a little misleading and handwavy. The proper thing to do would be to make the change an…

The 'line reader' version of the code (not shown in the article) was actually a lot easier to read than either one of these but the article was already over long. I do have that version, if anybody is interested I can add it.

Re: When Haskell Is Not faster than C

#108

Post by tsahyt »

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…

> After a couple of paragraphs brainwashing you about how good functional programming is, you finally get to some code.

Whenever I see a page about a new programming language I usually skip all the marketing speech at first and look for a code fragment to examine first. After that I'll start reading the actual text.

Re: When Haskell Is Not faster than C

#109

Post by jacquesm »

spookylukey wrote: post #92
jacquesm wrote: post #64

Earlier quoted context omitted.

From TFA: "So here is the bottom line. If you really need your code to run as fast as possible, and you are planning to spend half your development time doing profiling and optimisation, then go ahead and write it in C because no other language (except possibly Assembler) will give you the level of control you need. But if you aren't planning to do a significant amount of micro-optimisation then you don't need C. Has…

Compared to the amount of optimisation that many people typically do (i.e. zero or close to zero), it was a large amount of extra work to get that performance boost. The global re-arrangements of the way data flows through the code are more difficult than many micro-optimisations, not less, so I don't understand how you can claim. And you don't have to be an expert in C to make the claim he is making, because most pe…

> it was a large amount of extra work to get that performance boost.

Not really, actually. It took a lot of time to document the transformations, but actually doing the coding was short, much less than an hour total.

> The global re-arrangements of the way data flows through the code are more difficult than many micro-optimisations, not less, so I don't understand how you can claim.

Maybe more difficult for you, but not for me. Micro-optimizations are actually harder for me, there are infinite possibilities there, flow has really only one (or very few) 'proper' mapping(s) from problem space to solution space.

> And you don't have to be an expert in C to make the claim he is making, because most people are not experts in C, but might turn to it because "it's faster".

Every tool has its uses. If you pick C then probably you're doing so because you are convinced that you need it. You should then study how accomplished users of that tool use it, not stop at the first naive use that you come up with yourself.

> It's precisely this kind of person who needs to understand that with their level of knowledge, and the amount of effort that they might put into optimisations, Haskell can be just as good or better.

That's very well possible, again, I do not know Haskell so I can't comment on it. But I don't see any meaningful comparison between the two languages here, speed certainly isn't it and you failed to acknowledge that the article in fact did make that claim.

Re: When Haskell Is Not faster than C

#110

Post by jacquesm »

JabavuAdams wrote: post #106

This is a classic pattern: when advocating for one of several competing approaches, you spend more care optimizing your favourite approach than the competitors. Prof. Geoffrey Hinton specifically calls this out as a pitfall in research. It's better to compare your promising new approach versus another group's approach (not your own implementation thereof). This, assuming that the other group has deep knowledge in tun…

I think it's only human. The standard should be that you present your case for your 'favorite' and then put out an open challenge to supporters of the opposition to do their worst.
Post reply on HN