Personal tools

Talk:Introduction

From HaskellWiki

(Difference between revisions)
Jump to: navigation, search
Line 8: Line 8:
   
 
:If you want to offer "proof" that functional programming is a good idea, starting out with an invalid example pretty much wipes out your credibility. Taking the quicksort example offered, you are saying that if memory and CPU use do not matter ... but they very often do (certainly for large sort operations). Reading up on Haskell looks too much like a waste of time. Why the '''equivalent''' quicksort code in Haskell is larger than the C code requires an explanation as to why this is a good idea - and is not suitable material for the introduction. --[[User:PrestonBannister|PrestonBannister]] 01:51, 12 August 2008 (UTC)
 
:If you want to offer "proof" that functional programming is a good idea, starting out with an invalid example pretty much wipes out your credibility. Taking the quicksort example offered, you are saying that if memory and CPU use do not matter ... but they very often do (certainly for large sort operations). Reading up on Haskell looks too much like a waste of time. Why the '''equivalent''' quicksort code in Haskell is larger than the C code requires an explanation as to why this is a good idea - and is not suitable material for the introduction. --[[User:PrestonBannister|PrestonBannister]] 01:51, 12 August 2008 (UTC)
  +
  +
::The good idea here is that the algorithm becomes rather obvious when presented in Haskell. [[User:DonStewart|dons]] 04:45, 12 August 2008 (UTC)
   
 
:Change the C to mergesort? Because that really is what the Haskell code does. (Okay, sure, it's a funny 3-way, bottom-up, lazy mergesort. Still.) -- [[User:AaronDenney|AaronDenney]] 19:55, 10 July 2007 (UTC)
 
:Change the C to mergesort? Because that really is what the Haskell code does. (Okay, sure, it's a funny 3-way, bottom-up, lazy mergesort. Still.) -- [[User:AaronDenney|AaronDenney]] 19:55, 10 July 2007 (UTC)
Line 17: Line 19:
   
 
::It was in 2nd place when the article was written, since then benchmarks and programs have changed. [[User:DonStewart|dons]] 00:17, 12 December 2007 (UTC)
 
::It was in 2nd place when the article was written, since then benchmarks and programs have changed. [[User:DonStewart|dons]] 00:17, 12 December 2007 (UTC)
  +
  +
::Update, mid-2008, the rankings have stabilised with Haskell in 8th, behind C, C++, D and friends. The shootout continues to be a moving target. [[User:DonStewart|dons]] 04:45, 12 August 2008 (UTC)
   
 
''Most functional languages, and Haskell in particular, are strongly typed, eliminating a huge class of easy-to-make errors at compile time.'' This sentence confuses strong and static typing.
 
''Most functional languages, and Haskell in particular, are strongly typed, eliminating a huge class of easy-to-make errors at compile time.'' This sentence confuses strong and static typing.

Revision as of 04:45, 12 August 2008

Added the quote by Graham Klyne.

Over the years I've received numerous complaints about the quicksort example. But none of the complainers sent me anything better so it's still here. Anyone want to come up with a better example?

--John Peterson 00:39, 26 January 2006 (UTC)

Perhaps an in-place quicksort? —Ashley Y 04:24, 26 January 2006 (UTC)
If you want to offer "proof" that functional programming is a good idea, starting out with an invalid example pretty much wipes out your credibility. Taking the quicksort example offered, you are saying that if memory and CPU use do not matter ... but they very often do (certainly for large sort operations). Reading up on Haskell looks too much like a waste of time. Why the equivalent quicksort code in Haskell is larger than the C code requires an explanation as to why this is a good idea - and is not suitable material for the introduction. --PrestonBannister 01:51, 12 August 2008 (UTC)
The good idea here is that the algorithm becomes rather obvious when presented in Haskell. dons 04:45, 12 August 2008 (UTC)
Change the C to mergesort? Because that really is what the Haskell code does. (Okay, sure, it's a funny 3-way, bottom-up, lazy mergesort. Still.) -- AaronDenney 19:55, 10 July 2007 (UTC)
Eh? The defining property of quicksort is that the diving phase is elaborate (filter < and >) but that the conquer phase is simple (list concatenation). For mergesort, it's the other way round. apfeλmus 10:51, 11 December 2007 (UTC)

What is this about Haskell being in 2nd place behind C (gcc) in the computer language shootout, the link provided shows it to be 13th (and 12th on the previous benchmark, even though it does proportionally worst). You're right about functional languages doing well though: Clean, OCaml and MLton indeed occupy positions 6,9,11. --Noegenesis 12:01, 28 August 2007 (UTC)

It was in 2nd place when the article was written, since then benchmarks and programs have changed. dons 00:17, 12 December 2007 (UTC)
Update, mid-2008, the rankings have stabilised with Haskell in 8th, behind C, C++, D and friends. The shootout continues to be a moving target. dons 04:45, 12 August 2008 (UTC)

Most functional languages, and Haskell in particular, are strongly typed, eliminating a huge class of easy-to-make errors at compile time. This sentence confuses strong and static typing. MichalPalka 00:11, 2 December 2007 (UTC)