Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> comp.databases.theory -> Re: terminology

Re: terminology

From: Marshall <marshall.spight_at_gmail.com>
Date: 19 Jun 2006 08:44:33 -0700
Message-ID: <1150731873.492870.23240@y41g2000cwy.googlegroups.com>


Tony D wrote:
> Marshall wrote:
> > Yeah, Haskell has had a significant influence on my thinking.
> > Another book on my shelf (on that I've actually read all the
> > way through) is "Haskell: the Craft of Functional Programm"
> > (Thompson.) Although I'm not a fan of monads or laziness.
>
> With that last sentence, you move to iffy territory ... especially on
> laziness. Laziness allows you to deal with infinite data structures
> with impunity, evaluating them as far as is actually needed once and
> once only. (Laziness appears in some imperative/referentially opaque
> languages like C in the limited guise of short-circuit evaluation;
> although, if your program depends on side effects you might get some
> surprises if one of your functions doesn't get evaluated...)

Yes, and seen in this light, doesn't the C "short-circuiting" && and || look like weird choices? "Let's make everything strict except for these two operators." I suppose it was a terse way to hack in explicit conditional evaluation, but it's still weird.

Thing is, though, I prefer strictness. If I want laziness, I can get it explicitly; it's not the sort of thing I want by default. This is a design choice, though; YMMV.

Since Peyton-Jones is in the air, I'll reference "Wearing the Hair Shirt" a retrospective on Haskell.

http://research.microsoft.com/~simonpj/papers/haskell-retrospective/

P-J himself says

"Laziness makes it much, much harder to reason about performance, especially space." He mentions other disadvantages too, along with the advantages.

> [ snippage ]
>
> > Although I think SML doesn't always get the credit it deserves.
>
> No, I think Standard ML is fairly well lauded; it's just that head-on
> FP fans are heading to the lazily evaluated languages now.

I agree that Haskell is gaining momentum, but do you have any actual evidence that impure FPs are losing "market share" to pure ones? ML and OCaml seem to be doing quite well. Although, let's be honest, the strong majority of commercial software is written in C++ or Java, with VB a distant third.

> > Sure it's "impure" but I think ultimately that's a real advantage.
> > It lets you be as pure as is appropriate to the task at hand.
>
> Nope; monads let you do that in a far better way. Monads allow you to
> program sequentially where required, which takes away the last need for
> side effects - I/O. Because you can't guarantee which order redexes
> will be reduced, I/O (especially O) is a bit of a gamble, so previously
> ways had to be found to specifically order these reductions, which
> usually meant some kind of imperative programming. Monads let you do
> the same thing in a more FP friendly manner. If you go to haskell.org,
> there's a couple of good presentations on there about monads, including
> one called "Tackling the Awkward Squad : monadic input/output,
> concurrency, exceptions and foreign language calls in Haskell".

Okay, I admit I haven't gotten around to reading "Tackling the Awkward Squad" even though people have been pushing me at it for years. But I dispute your use of the word "better" above. Monads have an advantage, and they have a cost; which way is the "right" way to go is a design choice.

I'm a bit turned off by the fact that monads have to be threaded thoughout your program. It seems to me to be too high a price to pay. You lose modularity.

Also: do you really need purity *everywhere* all the time or do you only need it where you need it, so to speak?

> > Functional purity increases the ability to reason about code,
> > but imperative idioms, for all their *unclean* reputation
> > (mostly deserved) allow for some impressive achievements
> > in modularity and efficiency.
>
> Actually, efficiency is nowhere near the problem it was; there are
> surprising similarities between a highly optimised environment-based
> implementation (the fSECD machines or LISP implementations) and a
> highly optimised graph reducer implementation (such as the Chalmers
> G-machine). Peyton-Jones's "Implementation of Functional Programming
> Languages" might be quite old now (1987/88) but it has a couple of
> excellent chapters on the G-machine, amongst other things. In terms of
> modularity, you don't need imperative (or rather, referentially opaque)
> languages for that - Standard ML has modules, after all. If anything,
> because you *know* you can't have random side effects, a referentially
> transparent language would be even better for modular programming.

No argument there. And I'm still planning on reading Okasaki's "Purely Functional Data Structures" one day. (But I've got a lot of type theory books to get through first, and they aren't page-turners!)

But again: I'm still of the multi-paradigm mindset.

> > There's also the scaring the horses issue you mentioned, and I think purity-or-else
> > is likely to make them whinny nervously, whereas purity
> > by default with an option to escape is much more
> > palatable.
> >
>
> But that palatable option brings with it some unpalatable side effects
> (that is a truly awful pun - sorry).
>
> >
> > > Most of the rest of it has just been fiddling with Algol-60.
> >
> > Ain't that the truth! And wasn't it "an improvement on most
> > of its successors" after all?!
> >
>
> Wasn't that Pascal ? Pascal's successes were to remove some of the
> baroque excesses of Algol-60 and (I think) introduce enumerations;
> records (of a sort) were introduced earlier (in Algol-W or Algol-65,
> depending on reference, after Wirth jumped the Algol-68 ship) and I
> think they dumped the lunacy of call-by-name there too, but there were
> still some very odd features in Pascal (variant records, anyone ?)

I believe the precise quote was:
 "Here is a language so far ahead of its time, that it was not only an improvement on its predecessors, but also on nearly all its successors."
by Tony Hoare, speaking of Algol 60.

> > Rather than Snobol I'd cite Icon, as the more developed and therefore
> > more interesting of the two. (Both by Ralph Griswold.) I've not played
> > with APL but I have read a fair bit about J and K, which derive from
> > APL, and they're quite an achivement.
> >
> Yes, although for most of us the influence has arrived indirectly. If
> only they had designed the original APL to use normal keyboards, things
> might have been so much different ...

The weird character set was a real barrier, but I think looking at J and K, and their immense power and complete lack of readability, I'd say that while the language family is a fascinating experiment, an excessive devotion to terseness is the worse problem. But I have to give them tremendous admiration, both for the incredible departure from convention toward more expressive territory, and for the courage of their conviction in completely eliminating loops.

Still, any nontrivial K program looks like line noise.

> > But the real Mother Tongue is Lisp; like Latin, every idea has
> > already been tried there; like Latin, it is worthy of respect and
> > study, though I wouldn't want to have to use it for anything.
> >
>
> Well, yes and no. The real mother tongue is of course the lambda
> calculus, and you definitely wouldn't want to program in that in the
> raw. But I have seen some excellent work done in LISP in knowledge
> engineering, and anyone who fell in love with their Symbolics
> workstation will queue up to berate you at length as to how usable they
> were (although I hated them, and called the one I did have to use the
> "Shambolics"). But you still have side effects in many implementations,
> and that's enough for me to look elsewhere. (As anyone who reads my
> posts will know, I'm not afraid of (Lots of (Irritating) (Stupid
> (Parentheses)))).

Agreed.

Marshall Received on Mon Jun 19 2006 - 10:44:33 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US