From: Tayssir John Gabbour
Subject: Re: Paul Graham's teaching style is bad
Date: 
Message-ID: <cg1us1$pqp@odbk17.prod.google.com>
Tomasz Zielonka wrote:
> There is something that bothers me in the Lisp community. Many of you
> seem to neglect the possibility that other language communities can
> have good reasons to do things the other way.
>
> Keep your minds open ;)

I respectfully submit CLAWK:
http://lemonodor.com/archives/000040.html

Lispers borrow (*cough* steal) great ideas from other languages. No
being bogged down in the aesthetics of recursion, we will use dirty
iteration early and often. And recursion too. And state machines --
people don't normally consider things like that as part of the issue,
but I think maybe they are. Prolog-in-lisp. Big ol' toolbelt garnered
from many exotic lands and cultures, working as an ensemble in one
language.


> I think that HOF approach has many advantages over macros, like this
is
> a uniform solution, without the need to introduce thousands of new
> syntaxes.

You think HOFs are great? Your wish is lisp's command, it has HOFs. Use
them in conjunction with macros; use them separately.

But many people don't like seeing the same actor over and over, hogging
the stage, and might not take too well with abstaining from a natural
use of macros to use a technique centered on HOFs. Eating the same
food, be it French, Indian or underground US fast food is not always
the best. And if you look at Timothy Budd's _Multiparadigm Programming
in Leda_, he argues that sticking to a single paradigm will inflate
complexity. That is what's happening in the imperative world. They
think they're making progress, but they're really just reinventing the
same apps with different brandnames.

(To stray from the topic a bit... McDonald's is not a good example of
US fast food. I hope foreign travellers visit a smaller fast-food chain
in the US, or at least try a large international chain like Subway's.)


> It is interesting that almost all examples of macros given in
> chapter ,,Macros: Standard Control Structures'' of upcoming Peter
> Seibel's book can be easily implemented using HOFs in a lazy
functional
> language like Haskell.

You like laziness and functional style? I believe the Series library
does this, and our books have chapters on delay/force semantics. (For
some reason you'll often find them alongside the chapters on
nondeterministic computing.)

"If you give someone Fortran, he has Fortran. If you give someone Lisp,
he has any language he pleases." -- Guy Steele


MfG,
Tayssir

--
"Jeet Kune Do favors formlessness so that it can can assume all forms
and since Jeet Kune Do has no style, it can fit in with all the styles.
As a result, Jeet Kune Do uses all ways and is bound by none and,
likewise, uses any technique or means which serves its end. In this
art, efficiency is anything that scores." -- Bruce Lee
http://www.dreamsongs.com/cgi-bin/ExtravagariaWiki/index.cgi?NontraditionalLiterature
From: Tomasz Zielonka
Subject: Re: Paul Graham's teaching style is bad
Date: 
Message-ID: <slrnciabq0.9nk.t.zielonka@zodiac.mimuw.edu.pl>
Tayssir John Gabbour wrote:
>> I think that HOF approach has many advantages over macros, like this
>> is a uniform solution, without the need to introduce thousands of new
>> syntaxes.
>
> You think HOFs are great? Your wish is lisp's command, it has HOFs. Use
> them in conjunction with macros; use them separately.

Sure, macros+HOFs are more powerful than sole HOFs. I have almost no
Lisp programming experience, but I think I get the idea of Lisp's macros
and I appreciate their flexibility.

My point is just that it's a bit dangerous to advertize Lisp by comparing
it to "other languages" in general and claiming that this or that is
so much better in Lisp than in "other languages". But on the other hand,
such an approach seems to be statistically valid if by "other
languages" you mean "other languages known by the reader" :(

Anyway, I still think Common Lisp is one of the best programming
languages around, and I hope I will finally get to know it better.

Best regards,
Tom

-- 
.signature: Too many levels of symbolic links