

Thomas Conway drtomc at gmail.com
Sat Jul 7 07:23:14 EDT 2007

On 7/7/07, Albert Y. C. Lai <trebla at vex.net> wrote:
> Non-strict (most implementations lazy): rarely useful if you ask the
> mainstream.


Of your propositions, I must say this one has the most merit, though
not exactly as stated. :-) Being non-strict does allow some nice
expressiveness, but has one teeny tiny downside - the performance
model for haskell programs is at best inscrutable. Even using the
decent profiling tools in GHC, it can be almost impossible to
understand why a non-trivial program behaves the way it does. In my
current project, we restart the server periodically because there's a
memory leak in there somewhere that I can't track down. Now, I'm not
saying that someone else might not spot it easily, but I hope you see
my point:

I can look at the source code of a C function, and I can pretty much
guess what machine code will be generated for it (issues like
instruction scheduling and register allocation aside). The same is
essentially true for C++, Lisp, Prolog, Java, Mercury, &c, &c, &c, but
not for Haskell.

I wind up using -prof -auto-all as standard GHC flags so that if error
gets called, I have a vague chance of figuring out what's going on.


> Static typing: extreme paranoia.

I've been working in a mostly Python shop this last year, and it
reinforces my belief that people who don't like strong static typing
are yahoos, not professionals interested in producing high quality
code. Maybe I just don't get the line between professionalism and
paranoia. ;-)

> Purely functional: vocal minority of edgy people.

Ever used Prolog? Compromising purity in a declarative language can
seem like a good idea in the short term, but in the long term, it
usually causes untold grief. Especially, in the case of Prolog, the
cut operator which interferes with the natural operation of
backtracking. It overflows into the operation of negation, and creates
all kinds of bother.

So I did my PhD in the Mercury group at .mu.oz.au. Mercury is a retake
on logic programing. It is pure.

In 1995 I arrived in the US for my first logic programming conference,
and on the first evening, before the conference proper began, went out
with a bunch of attendees. I got chatting with a really nice Canadian
guy, Jamie Andrews, and five minutes into the conversation, on finding
out he was a semantics researcher, asked what I thought was a terribly
witty question "So are you presenting *another* semantics for the
'cut' operator?"

"Um, well, yes, actually" was his reply.

Apart from showing what a precocious prat I was, OMG 12 years ago, it
tells you something about what happens when you ride rough-shod over
purity. It creates gainful employment for hundreds of researchers for
decades trying to put the genie back in the bottle.

ML and friends have had a much easier time of it than Prolog, I
concede, but the problem of finding practical paradigms of programming
in pure languages that combine expressiveness with clean semantics is
actually well worth the short term inconvenience. Those with good
memories will know that the use of monads to express IO took some
time, and that there were several less successful, though more-or-less
pure attempts before. There was the pair of lazy streams model; the
continuation passing model; the linear types model (deployed by Clean,
of course); and maybe others. The cool thing is that they were all
fairly painful to use, and rather than give up, the researchers kept
trying new things and came upon monads. The extra cool thing is that
monads have turned out to be really useful for a whole lot of other
things than just a way of expressing IO or even IO and mutable state
(which linear types captures).

As SPJ notes in his Hair Shirt talk, monads are not perfect, since
they are often used in ways which over-sequentialize code using them,
so we have people working on arrows, and other more sophisticated
mechanisms, which in time will probably lead to more expressive

Thomas Conway
drtomc at gmail.com

Silence is the perfectest herald of joy:

More information about the Haskell-Cafe mailing list