Re: [tlug] Functional Programming Group Meeting

[Curt Sampson <cjs@example.com>]

On 2008-04-24 10:18 +0900 (Thu), Stephen J. Turnbull wrote:

>  > So, would you also claim that in non-lazy languages the worst case can
>  > also be surprisingly bad?
> 
> No.  It's a matter of what people are used to.

Hm. Ok, I'm having trouble buying this one, but I'm willing to listen.

So, first of all, are you saying that this is just a temporal thing, and
at the moment Haskell is bad because people aren't generally acquainted
with the appropriate idioms for using it, or are you saying that this is
true for all time?

If you mean just for the moment, well, then I guess you'll agree with me
eventually.

If not, how do Haskell's features compare to other things that in the
past were considered odd research features that people didn't know
how to use, such as non-global variables, a long time ago, or first
order functions, to some degree even now. Or features that were once
considered not usable in what we now call "enterprise systems," such as
garbage collection.

I sincerely think that twenty years or so from now, a dececent static
type system will be in the same category as automatically managed
memory; you'll still use languages without it from time to time,
but most everyone will feel the pain of living without it, and most
won't live without it unless they have to. And quite possibly having
a complete program as one huge, messy, sequenced chunk instead of
explicitly declaring your sequencing only where you need it will be seen
to be as odd as writing your program as one giant object would seem
today. (Though honestly, I'm not sure I should hold my breath on that
one.)

> And what do you do if you need that same search tree for 1000
> searches?

Err...you missed the point here, I think. It's equally easy in any
language to use it for one or 1000 searches. But what if the tree
is huge? What you do do? You write some fairly painful code to do
partial generation of it, or just write what you would anyway in a lazy
language.

> No, it's not the same at all.  When TOOWTDI[1] is an imperative, "that
> way is efficient" is also imperative.

What's with the whole performance thing, anyway? Is it somehow better
that in Ruby you're guaranteed always to get bad performance, with no
recourse?

So, ok. Show me anything in Ruby, or even Python or perl, that's at
all hard to do faster with ghc.

Personally, I think Haskell is more often easier to optimize than
harder, compared to other languages. I know of no other language where
big-O analysis is expressed so clearly and directly.

cjs
-- 
Curt Sampson       <cjs@example.com>        +81 90 7737 2974   
Mobile sites and software consulting: http://www.starling-software.com