Re: [9fans] nice quote

[Vinu Rajashekhar <vinutheraj@gmail.com>]

Write Haskell as fast as C: exploiting strictness, laziness and recursion
- http://cgi.cse.unsw.edu.au/~dons/blog/2008/05/16
>From the article

Lesson 1: To write predictably fast Haskell -- the kind that competes
with C day in and out
-- use tail recursion, and ensure all types are inferred as simple
machine types, like Int, Word,
Float or Double that simple machine representations. The performance
is there if you want it.

Lesson 2: Laziness has an overhead -- while it allows you to write new
kinds of programs
(where lists may be used as control structures), the memory traffic
that results can be a
penalty if it appears in tight inner loops. Don't rely laziness to
give you performance in your inner loops.

Lesson 3: For heavy optimisation, the C backend to GHC is still the
way to go. Later this
year a new bleeding edge native code generator will be added to GHC,
but until then,
the C backend is still an awesome weapon.

On Mon, Sep 7, 2009 at 2:24 PM, Paul
Donnelly<paul-donnelly@sbcglobal.net> wrote:
> eris.discordia@gmail.com (Eris Discordia) writes:
>
>> I whined about LISP on yet another thread. Above says precisely why I
>> did. LISP is twofold hurtful for me as a naive, below average
>> hobbyist. For one thing the language constructs do not reflect the
>> small computer primitives I was taught somewhere around the beginning
>> of my education. For another, most (simple) problems I have had to
>> deal with are far better expressible in terms of those very
>> primitives. In other words, for a person of my (low) caliber, LISP is
>> neither suited to the family of problems I encounter nor suited to the
>> machines I solve them on. Its claim to fame as the language for
>> "wizards" remains. Although, mind you, the AI paradigm LISP used to
>> represent is long deprecated (Rodney Brooks gives a good overview of
>> this deprecation, although not specifically targeting LISP, in
>> "Cambrian Intelligence: The Early History of the New AI").
>
> Consider that your introduction to Lisp may have been very poor. You're
> right that the mapping from Lisp primitives to machine primitives isn't
> as direct as that in, but Lisp doesn't represent any AI paradigm at all,
> nor a particular programming paradigm, and its name hasn't been written
> in caps for perhaps 30 years. I'm not trying to nitpick; I'm only saying
> that there are a lot of weird ideas about Lisp floating around which a
> person can hardly be blamed for picking up on, and these are the reasons
> it sounds to me like you have.
>
>> One serious question today would be: what's LISP _really_ good for?
>> That it represents a specific programming paradigm is not enough
>> justification.
>
> I think most Lispers would say it's _really_ good for anything but the
> most demanding number crunching, or perhaps A-list games
> programming. Probably you'd run into trouble in some parallel
> programming situations, for reasons more related to implementation
> support and libraries than reasons intrinsic to the language. And the
> justification would be that Lisp is an embarrassingly multiparadigm
> language, as general-purpose as they come.
>
>



--
Vinu Rajashekhar,
5th Year Dual Degree Student,
Deptt of Computer Science & Engg,
IIT Kharagpur,
India.