I'd like to hear from people who prefer Lisp to other languages for at
least certain types of work. I'd like to know why they prefer it to
other current languages (for the types of work where they do prefer
it) in order to determine the extent to which those reasons might
apply to me.
A programming language doesn't have to be the best at everything for
me, or even the best at the largest number of things. It just has to
be so much better than the alternatives (some of which I probably
already know) at *something* significant to me that it's worth the
effort required to add it to my "toolbox" (and maintain it).
Since I'm not sure what might be significant to me in the future, I'd
just like to know more about why Lisp lovers prefer Lisp to all the
other languages they could choose from these days, and for what
purposes.
Since I'm already studying it to some extent, I'm going to venture a
guess at one major advantage. I find the need to express every single
idea in the same nested s-expr syntax rather tedious. If there weren't
a higher purpose for it, I'd just drop Lisp for something with a more
convenient syntax, like Python or Ruby.
But it appears to me that the purpose is to enable the building of
abstractions that, since they retain the same s-expr syntax as their
components, can be built into yet higher-level abstractions, in a way
that is somehow superior to the building up of abstractions by nested
objects or just functions that call sub-functions in a procedural
language.
I haven't yet reached the point where I know how to write a macro, so
the superiority of this Lisp style of abstraction building (over
nested objects, for ex.) isn't yet clear to me, but I definitely
"feel" as though there is something powerful out there, sort of
lurking in the fog. ;-) (I started feeling this way when I saw to my
amazement in SICP how an object system could be created with 50-60
lines of code, and that was without CL's macros.)
In any case, I'd be grateful if Lisp lovers could tell me what makes
them prefer Lisp to other current languages and the circumstances in
which they do prefer it. All the Lisp tutorials brag about garbage
collection and built-in container data structures, which were big
deals in the dark ages when the tutorials were written, but hardly
argue for learning Lisp today. What makes Lisp the best *today*, and
for what?
> I'd like to hear from people who prefer Lisp to other languages for at
> least certain types of work. I'd like to know why they prefer it
See http://www.flownet.com/gat/papers/aero-03.pdf
The argument is somewhat disguised in this paper because it's targeted
towards the aerospace community (among whom "Lisp" is a four-letter word)
but hopefully you won't find it too obscured. You seem to be on the right
track. Just one comment:
> I'd just drop Lisp for something with a more
> convenient syntax, like Python or Ruby.
You will find that once you have gotten used to them, S-expressions *are*
the most convenient syntax.
No doubt Kenny Tilton will also point you to his Road to Lisp survey, but
I'm gonig to beat him to it :-)
http://www.cliki.net/The%20Road%20to%20Lisp%20Survey
E.
There are so many reasons to prefer Lisp, you could fill a newsgroup
with them. But I'll choose just one item in your post...
········@hotmail.com (Tuang) wrote in message news:<····························@posting.google.com>...
> But it appears to me that the purpose is to enable the building of
> abstractions that, since they retain the same s-expr syntax as their
> components, can be built into yet higher-level abstractions, in a way
> that is somehow superior to the building up of abstractions by nested
> objects or just functions that call sub-functions in a procedural
> language.
The syntax *is* superior to nested function calls. The main thing to
note is that C/Algol-family function calls are the same form as
s-expressions, with the parethesis moved slightly, and extra commas
inserted instead of white space. They nest just fine, because the
syntax is uniform. But any other aspect of C/Algol family languages
breaks that syntactic unity. Loops, if/thens, blocks with declarations
all start to look different. In Lisp, all those things look very
similar.
One of the beauties of s-expressions as the complete expression of
program structure is that macros can always take an arbitrary chunk of
code and assume it is an s-expression or a sequence of s-expressions.
The advantage gained by this feature is that macros are free of the
"syntax protection" and limitations of other macro languages.
Consider a typical cpp macro that incorporates multiple C statements.
Where can it be used? Well, better make sure it has balanced braces so
that one can use it as a code block. If your macro needs to be an
expression (i.e., return a value), you need some exceedingly clumsy
use of the comma operator, and extra parentheses to make sure it
works. Not to mention all the backslashes you need to put it all in
one text line. And remember to protect against multiple evaluation by
making up some unique names for temporary variables. The syntax of a
chunk of C-code is always sticking out, and you need to cover it with
a bunch of layers of wrapping if you want to put it in a container.
The chunk of Lisp code has all these smooth, curvy ends ((like)
(these)) and always fits just where you want to put it.
This is all just one example of how Lisp is designed to smoothly allow
for abstraction. Integers that don't wrap around on overflow is
another. Abstraction is the most powerful tool around for managing
complexity, and Lisp does abstraction like no other language. I can
barely stand to program in anything else.
Tuang wrote:
> I'd like to hear from people who prefer Lisp to other languages for at
> least certain types of work. I'd like to know why they prefer it to
> other current languages (for the types of work where they do prefer
> it) in order to determine the extent to which those reasons might
> apply to me.
(a) get ye to the highlight film in my sig. That leads to over a hundred
people, almost all of whom address your question directly.
(b) aside from macros, don't expect one huge gottahave. it is everything
from speed to maturity to reflection to specials to CLOS to closures to,
yes, the parentheses. for my money, if you don't have GC, go away. If
you are not almost as fast as "C", go away. If you are still working on
the language (Java and Python), go away. If you do not support multiple
inheritance, leave me alone. infix? asta la vista baby, I edit sexpr
notation and nothing else. lexical scope and closures=must have. mo
macros, no me. etc etc etc
kenny
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton <·······@nyc.rr.com> wrote in message news:<······················@twister.nyc.rr.com>...
>
> ...if you don't have GC, go away. If
> you are not almost as fast as "C", go away. If you are still working on
> the language (Java and Python), go away. If you do not support multiple
> inheritance, leave me alone. infix? asta la vista baby, I edit sexpr
> notation and nothing else. lexical scope and closures=must have. mo
> macros, no me. etc etc etc
It sounds as though you've found your soul mate of a language. ;-)
If it turns out to be my soul mate, too, we'll share. I suspect that
I'll end up less monogamous than you, though, because I come at it
from the opposite direction. I don't usually eliminate languages for
their lack of any one of a checklist of favorite features. I *add*
them to my arsenal if they give me new powers to do something that
matters to me (provided I consider them better at it than something
else I could add instead).
I've used quite a few seriously flawed programming tools because I
felt (and still feel) that they were the best tools available for some
task. It's still just a hunch, but I suspect that Lisp (in some form)
will turn out to be the best at something significant to me, too. For
most of the other tools, I knew what the "something" was before I ever
started learning them. In Lisp's case, I'm taking a bit of a leap of
faith.
From: Ray Dillinger
Subject: Re: Reasons for preferring Lisp, and for what
Date:
Message-ID: <3FA9DB70.3226EA32@sonic.net>
Tuang wrote:
>
> It sounds as though you've found your soul mate of a language. ;-)
>
> If it turns out to be my soul mate, too, we'll share. I suspect that
> I'll end up less monogamous than you, though, because I come at it
> from the opposite direction. I don't usually eliminate languages for
> their lack of any one of a checklist of favorite features. I *add*
> them to my arsenal if they give me new powers to do something that
> matters to me (provided I consider them better at it than something
> else I could add instead).
If continuing to do this is important to you, then don't learn
Lisp. If you do, and this is the criteria you use to determine
when to learn a new language, then you will never again learn
another language.
There is no language, anywhere, that gives you capabilities you
don't have in LISP.
Want OO? There's CLOS. Want DD? There's lambda syntax for named
arguments. Want Unification? There's CLIPS. Want functional?
Lisp was *born* functional. Want dynamic? Lisp macros and HOF's
will blow you away. Want fast? You can get it working first then
*add* declarations to make it fast. Want to design your own
semantics for exceptions and escape procedures? Slide on over
to another Lisp and learn about call/cc. Want Multiprocessing?
Lisp threads work as well as anybody else's and with GC they're
a lot less of a headache. Plus the more functional you make
your code (and with Lisp you *CAN* write pure functional code)
the less the threads will bind and conflict with one another. You
can have multithreaded programs in Lisp without a single mutex.
The short story is, it's all there - either in the runtime itself or
easily in reach with libraries. Nothing's left out. There's nothing
above raw hardware manipulation left for any other language to be
better at.
These days I program in C for raw hardware manipulation and Lisp
for everything else. Time was, my favorite languages were as diverse
as prolog, smalltalk, pascal, C++, APL, FORTH, .... And there are
still things that, say, FORTH does better than C. But there's nothing
above hardware manipulation that *ANYTHING* does better than Lisp.
Bear
From: Joe Marshall
Subject: Re: Reasons for preferring Lisp, and for what
Date:
Message-ID: <65hw10ri.fsf@ccs.neu.edu>
········@hotmail.com (Tuang) writes:
> I've used quite a few seriously flawed programming tools because I
> felt (and still feel) that they were the best tools available for some
> task. It's still just a hunch, but I suspect that Lisp (in some form)
> will turn out to be the best at something significant to me, too. For
> most of the other tools, I knew what the "something" was before I ever
> started learning them. In Lisp's case, I'm taking a bit of a leap of
> faith.
Lisp is the best tool for doing something when you don't know what
you're doing.
From: Kent M Pitman
Subject: Re: Reasons for preferring Lisp, and for what
Date:
Message-ID: <wkwuabdhdj.fsf@nhplace.com>
Joe Marshall <···@ccs.neu.edu> writes:
> Lisp is the best tool for doing something when you don't know what
> you're doing.
Ah, so this is the reason that we're so misunderstood... The people
who don't know what they're doing when they say they don't like us
are not using the best tool for managing their lack of understanding.
Or maybe it explains why we use Lisp--we don't know what we're doing.
Hmm. I think we gotta work on that promo material of ours, Joe. It
sounds like we, er, cranked it out with a Lisp program.
From: ·············@comcast.net
Subject: Re: Reasons for preferring Lisp, and for what
Date:
Message-ID: <vfpt1cga.fsf@comcast.net>
Kent M Pitman <······@nhplace.com> writes:
> Joe Marshall <···@ccs.neu.edu> writes:
>
>> Lisp is the best tool for doing something when you don't know what
>> you're doing.
>
> Ah, so this is the reason that we're so misunderstood... The people
> who don't know what they're doing when they say they don't like us
> are not using the best tool for managing their lack of understanding.
>
> Or maybe it explains why we use Lisp--we don't know what we're doing.
>
> Hmm. I think we gotta work on that promo material of ours, Joe. It
> sounds like we, er, cranked it out with a Lisp program.
I guess we shouldn't make that our slogan. If we dress it up with
some buzzwords, though:
``Lisp is the best tool for finding new solutions to poorly
specified problems.''
Kenny Tilton <·······@nyc.rr.com> wrote in message news:<······················@twister.nyc.rr.com>...
> Tuang wrote:
> > I'd like to hear from people who prefer Lisp to other languages for at
> > least certain types of work. I'd like to know why they prefer it to
> > other current languages (for the types of work where they do prefer
> > it) in order to determine the extent to which those reasons might
> > apply to me.
>
> (a) get ye to the highlight film in my sig. That leads to over a hundred
> people, almost all of whom address your question directly.
Okay, I just finished and, instead of "almost all", I found that
relatively few of them addressed my question directly. Instead, almost
all were emotional outbursts about how wonderful they *felt* having
found Lisp, which is an answer, but an indirect one. I'm not
belittling those quotes (and the longer articles behind them). I'm an
emotional creature, too, and a lot of the reason I program at all is
for fun, so their expressions of rapture interest me, too. I'm glad
you're collecting them, and I'm glad I read them, but they aren't
quite what I'm hoping to learn about Lisp.
I'll tell you what I mean, and this may even suggest questions you
might want to add to your survey. I've heard Perl users say pretty
much the same things about the wonders of Perl. It wasn't the
expressions of rapture that hooked me on Perl, though, it was the
ten-line code samples that did what would have taken me 200 (buggy)
lines to do with C or Java. I hadn't thought that text processing
would be important to me until I saw how easily it could be done.
Suddenly, the "need" to do it seemed to be everywhere, and Perl had a
guaranteed spot in my toolbox until something better came along.
I'm wondering if Lisp has similar areas of extraordinary power,
relative to other currently available alternatives. As I said, I think
one will be the ability to create a tremendous variety of abstractions
with surprising ease. When I saw how you could create a surprisingly
powerful (mini-)object system with a 50-60 line macro, it struck me
like the Perl code did. My reaction was that even though I already had
more powerful object systems in other languages, that wasn't the
point. Those were built-in and I had to live with them as they were.
*This* meant that I could actually invent something on a par with OOP,
customized for my own particular needs, rather than simply relying on
what the language designer provided.
I think that will turn out to be a big deal, but I'm wondering if
there are others. Other possible candidates that come to mind are the
ability to tackle algorithmically challenging problems. I haven't
really seen code that demonstrates Lisp's superiority in this respect
to other languages, but I've heard that it's true.
For what it's worth, code showing how easy it is to do certain hard
things using Lisp might be at least as persuasive as quotes showing
how much programmers love it.
········@hotmail.com (Tuang) writes:
> I'm wondering if Lisp has similar areas of extraordinary power,
> relative to other currently available alternatives. As I said, I think
> one will be the ability to create a tremendous variety of abstractions
> with surprising ease. When I saw how you could create a surprisingly
> powerful (mini-)object system with a 50-60 line macro, it struck me
> like the Perl code did. My reaction was that even though I already had
> more powerful object systems in other languages, that wasn't the
> point. Those were built-in and I had to live with them as they were.
> *This* meant that I could actually invent something on a par with OOP,
> customized for my own particular needs, rather than simply relying on
> what the language designer provided.
The mini object system in 50 LOC is a special case of one of Lisp's
most important strengths: it lets you easily create domain-specific
languages. With macros letting you easily write code transformers,
combined with dynamic typing, generic functions, and closures, you
have a great language-building toolkit. A prime example of how that
can be useful is when you have pseudo code specifying an algorithm.
Instead of implementing what the pseudocode means, implement the
pseudocode itself: make the simple translation to an s-expression
syntax, then build what you need to make the pseudocode itself
executable. Now your implementation is clear, and it's a lot easier
to get it right, too.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
In article <···············@whirlwind.OCF.Berkeley.EDU>,
···@whirlwind.OCF.Berkeley.EDU (Thomas F. Burdick) wrote:
> ········@hotmail.com (Tuang) writes:
>
> > I'm wondering if Lisp has similar areas of extraordinary power,
> > relative to other currently available alternatives. As I said, I think
> > one will be the ability to create a tremendous variety of abstractions
> > with surprising ease. When I saw how you could create a surprisingly
> > powerful (mini-)object system with a 50-60 line macro, it struck me
> > like the Perl code did. My reaction was that even though I already had
> > more powerful object systems in other languages, that wasn't the
> > point. Those were built-in and I had to live with them as they were.
> > *This* meant that I could actually invent something on a par with OOP,
> > customized for my own particular needs, rather than simply relying on
> > what the language designer provided.
>
> The mini object system in 50 LOC is a special case of one of Lisp's
> most important strengths: it lets you easily create domain-specific
> languages.
Norvig's 'Paradigms of Artificial Intelligence Programming' is
full of such examples, and the code is available on the web even
if you lack the excellent book. (I know you know this Thomas;
I'm writing here for the original poster.) Norvig concisely
defines a language for doing symbolic mathematics, from
simplifying expressions to integrating. He defines a Prolog
interpreter, a Prolog compiler, a Scheme interpreter, and a
Scheme compiler, all in an astoundingly small number of LOC.
There are other examples of Lisp's expressiveness that do
not involve domain-specific languages, e.g., defining a general
memoizing facility in a few dozen LOC. See Norvig or just
about any Lisp textbook for the details. Another example
is how the multiple inheritance and multiple dispatch of CLOS
save you from having to write lots of explicit type dispatches
within methods.
Perhaps an inverse example of Lisp's conciseness is its
penchant for providing multiple ways to realize the same
computation. (I know Larry Wallk talks about this too, but
I know nothing of Perl and find some of his linguistic
insights dubious.) There are probably ten ways to express
iteration in Lisp, especially if one includes the Appendices
of Steele's (1990) CLtL2. This may seem like a recipe for
disaster, but it really means you're (or at least I'm)
constantly surprised by the code of others. Where I might
hack a deeply nested DO form, a more functional sort
might stick purely to the mapping functions or recursion,
a LOOP aficionado might write something so explicit it
looks like cheating, and Kent Pitman might do it all with
FORMAT. In this sense, using Lisp is like speaking a
language where you constantly run into pockets of people
with intriguing dialects and compact and catchy idioms.
Sorry if that was too "emotional."
"Tuang" wrote:
> I'm wondering if Lisp has similar areas of extraordinary power,
> relative to other currently available alternatives. As I said, I think
> one will be the ability to create a tremendous variety of abstractions
> with surprising ease. When I saw how you could create a surprisingly
> powerful (mini-)object system with a 50-60 line macro, it struck me
> like the Perl code did. My reaction was that even though I already had
> more powerful object systems in other languages, that wasn't the
> point. Those were built-in and I had to live with them as they were.
> *This* meant that I could actually invent something on a par with OOP,
> customized for my own particular needs, rather than simply relying on
> what the language designer provided.
There are plenty of similar examples. A couple of weeks ago,
I posted a "pattern-matching defun" macro (giving facilities
similar to those in languages like Haskell) that was 24 lines
long and could quite easily have been shortened. Paul Graham's
"On Lisp" contains what's more or less a Prolog interpreter
in a total of about 200 lines. At http://www.muc.de/~hoelzl/tools/dbc/dbc.lisp
there's an implementation of "design by contract" (preconditions,
postconditions, class invariants, behaving correctly under
class inheritance) in 229 lines.
--
Gareth McCaughan
.sig under construc
Tuang wrote:
> Kenny Tilton <·······@nyc.rr.com> wrote in message news:<······················@twister.nyc.rr.com>...
>
>>Tuang wrote:
>>
>>>I'd like to hear from people who prefer Lisp to other languages for at
>>>least certain types of work. I'd like to know why they prefer it to
>>>other current languages (for the types of work where they do prefer
>>>it) in order to determine the extent to which those reasons might
>>>apply to me.
>>
>>(a) get ye to the highlight film in my sig. That leads to over a hundred
>>people, almost all of whom address your question directly.
>
>
> Okay, I just finished and, instead of "almost all", I found that
> relatively few of them addressed my question directly. Instead, almost
> all were emotional outbursts about how wonderful they *felt* having
> found Lisp, which is an answer, but an indirect one. I'm not
> belittling those quotes (and the longer articles behind them). I'm an
> emotional creature, too, and a lot of the reason I program at all is
> for fun, so their expressions of rapture interest me, too. I'm glad
> you're collecting them, and I'm glad I read them, but they aren't
> quite what I'm hoping to learn about Lisp.
>
> I'll tell you what I mean, and this may even suggest questions you
> might want to add to your survey. I've heard Perl users say pretty
> much the same things about the wonders of Perl.
Absofuckinglutely. And Python and Ruby. Hell, probably even Java and
C++. Get Burdick started on Fortran!
The point is, Lisp is dead, but we /also/ have newbies turning back
flips, and on top of that many of them saying, "Hey, how come CL has had
all these 'new' features since the sixties?"
You dismissed the whole survey as just unfocused emotional outpourings.
Nonsense. The highlight film reads that way in part, but many of them
are also highly specific about macros or power or, again, Lisp having
all the features other languages are now struggling to implement
(poorly). Inside in the responses you also found explicit comparisons
with other languages--that sounds pretty damn well informed, where do
you get off with this condescending emotional outburst putdown?
What you do not realize is that you took to be outbursts were -- brace
yourself -- fairly sober statements of simple fact. Of course you have
to use Lisp to know that, not just pester c.l.l.
It wasn't the
> expressions of rapture that hooked me on Perl, though,
Oh, christ, you get hooked on a language by using it. You could be on
chapter eight by now and not bothering cll.
> I'm wondering if Lisp has similar areas of extraordinary power,
No, we're all doing drugs and seeing things. Try K.
kenny
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
On 6 Nov 2003 13:18:32 -0800, ········@hotmail.com (Tuang) wrote:
>I'll tell you what I mean, and this may even suggest questions you
>might want to add to your survey. I've heard Perl users say pretty
>much the same things about the wonders of Perl. It wasn't the
>expressions of rapture that hooked me on Perl, though, it was the
>ten-line code samples that did what would have taken me 200 (buggy)
>lines to do with C or Java. I hadn't thought that text processing
>would be important to me until I saw how easily it could be done.
>Suddenly, the "need" to do it seemed to be everywhere, and Perl had a
>guaranteed spot in my toolbox until something better came along.
I'm curious about this, can you point me to some of those samples?
I'd heard a lot about how Perl makes it very easy to write quick and
dirty programs, tried it for a couple of hours, and found it strongly
reminiscent of Basic on the Vic-20 only not as convenient :( But there
must be _some_ reason so many people use it, and I'd be interested to
know what that is.
--
"Sore wa himitsu desu."
To reply by email, remove
the small snack from address.
http://www.esatclear.ie/~rwallace
················@eircom.net (Russell Wallace) wrote :
>
> I'm curious about this, can you point me to some of those samples?
>
> I'd heard a lot about how Perl makes it very easy to write quick and
> dirty programs, tried it for a couple of hours, and found it strongly
> reminiscent of Basic on the Vic-20 only not as convenient :( But there
> must be _some_ reason so many people use it, and I'd be interested to
> know what that is.
Oh, there are just lots of special operators and built-in tools.
Things like
while (<>) {
[processing code]
}
will take a whole series of files, open them one at a time, extract
each line and assign it automatically to a built-in variable so it can
be processed, then close the file and open the next one, etc.
With built-in regular expressions, you can say things like:
($symbol, $price, $volume) = /[some regex ]/
with ()'s around wherever those three data items occur in the regex,
and extract stock data out of an HTML table, for example. If the table
changes format, you can repair the extractor in seconds by just
editing the regular expression. No library needed -- regular
expressions are built in syntax usable in lots of places.
Or with a couple of lines, you can fill a hashtable with the parsed
results of any sequence of piped Unix commands you could call from the
command line. You can call the internal grep or Unix's external grep,
call an internal sort or Unix's own "sort", or mix them together, as
you prefer. OS commands in backticks act like built-in commands.
It has networking communications of pretty much all sorts in standard
libraries, so it's just as easy to parse the stock data out of a
message waiting on a POP3 server as it is to scrape it off a Web page,
which is as easy as reading it from a local file. The libraries for
doing so are standard, work the same on all platforms, and there's
plenty of example code that you can just copy and paste.
I'm not trying to promote Perl, nor am I saying that it's more
convenient than Lisp. In fact, I'd probably choose Python over Perl
these days for work that is Perl's traditional strong suit. Perl's
syntax is so impenetrable at times that I don't even want to learn the
latest features, and I certainly wouldn't build anything big with it
if I could avoid it. I was just recalling my first encounter with it
when all I could compare it to was C/C++ or early Java.
If you're really serious about wanting to know more about Perl, take a
look at the Perl Cookbook in any big bookstore and you'll see lots of
little code chunks that do useful things. If you're not a Unix
sysadmin, though, I'd have a hard time recommending Perl today.
················@eircom.net (Russell Wallace) writes:
> I'd heard a lot about how Perl makes it very easy to write quick and
> dirty programs, tried it for a couple of hours, and found it strongly
> reminiscent of Basic on the Vic-20 only not as convenient :( But there
> must be _some_ reason so many people use it, and I'd be interested to
> know what that is.
Lisp have mercy with me, for I have sinned. I once was a devoted perl
hacker for a few years until I got to the point where my perl hacks
grew into real programs and started to show their evil nature, and
then I turned to back lisp and was saved.
I still occasionally use it, but only for one-liners (*), and then it's
actually pretty useful. Whenever you need to do some grep/wc/sort-
kind of thing and it's just a little too difficult to use the basic
tools and you think awk is awkward, then perl is quite neat.
(*) well, on my firewall I have a line that's 120 characters long ;-)
--
(espen)
On 07 Nov 2003 10:16:31 +0100, Espen Vestre
<·····@*do-not-spam-me*.vestre.net> wrote:
>Lisp have mercy with me, for I have sinned. I once was a devoted perl
>hacker for a few years until I got to the point where my perl hacks
>grew into real programs and started to show their evil nature, and
>then I turned to back lisp and was saved.
^.^
>I still occasionally use it, but only for one-liners (*), and then it's
>actually pretty useful. Whenever you need to do some grep/wc/sort-
>kind of thing and it's just a little too difficult to use the basic
>tools and you think awk is awkward, then perl is quite neat.
Okay...
>(*) well, on my firewall I have a line that's 120 characters long ;-)
...so, what does it do?
--
"Sore wa himitsu desu."
To reply by email, remove
the small snack from address.
http://www.esatclear.ie/~rwallace
················@eircom.net (Russell Wallace) writes:
> >(*) well, on my firewall I have a line that's 120 characters long ;-)
>
> ...so, what does it do?
The usual cheap, boring, match-and-count stuff:
tcpdump -r /tmp/pflog.0.tmp | \
perl -ne 'if (/ > ([^:]+)/) {++$count{$1}} END {foreach $key (keys %count) {print "$count{$key} $key\n"}}' | \
sort -rn |head -40
(hey, I didn't remember right - it's only 95 characters!)
--
(espen)
From: Joel Ray Holveck
Subject: Re: Reasons for preferring Lisp, and for what
Date:
Message-ID: <877k2cqutm.fsf@thor.piquan.org>
>> Suddenly, the "need" to do it seemed to be everywhere, and Perl had a
>> guaranteed spot in my toolbox until something better came along.
> I'm curious about this, can you point me to some of those samples?
If you're carrying around a hammer, you're a lot more likely to notice
nails than screws.
At work, I use Lisp when I can, Perl when I can't, and C when I have
to. (I'm the only Lisp coder in my group, so I have to really justify
using Lisp because of the maintainability concerns.) So I think I've
got a fairly level perspective on them.
One of the biggest tools in the Perl toolbox is its hash tables. They
serve a similar, but more prominent, role in Perl than alists do in
Lisp. The equivalent of (gethash key table) is $table->{key}. Since
nested hash tables are very common in Perl, you can write
$table->{key1}{key2}{key3}, which I find more readable than (gethash
key3 (gethash key2 (gethash key1 table))).
The biggest superpower that Perl has is its string handling. String
handling in Lisp is laborious; in Perl it's fluid and natural. This
comes in strong when you're interfacing to another system. Since most
systems communicate with each other using strings, particularly in
Unix, Perl is very good at interfacing with other systems. On a
LispM, you have lots of subsystems interfacing with one another. This
is possible because they all run in the same memory space, and can
easily pass data structures around. Perl makes this sort of fluid
data-passing possible on Unix, web systems, etc.
As a concrete example, suppose (as I did in a program I recently
wrote) that you have a string with several arbitrary variable names
you need to substitute in, and a hash with their values. This can be
done in one line in Perl:
# $string holds something like:
# 'The $dimension of the $obj is $length cm.'
# %vars holds something like:
# { $dimension => length, $obj => plank, $length => 105 }
$string =~ s/\$(\S+)/$vars->{$1}/g;
Now, look at a Lisp parallel. You have a list, and you want to
substitute keywords with their values from an alist:
;; LIST holds something like:
;; (the :dimension of the :object is :value cm)
;; VARS holds something like:
;; ((:dimension . length) (:object . plank) (:value . 105))
(mapcar #'(lambda (elt)
(if (keywordp elt)
(cdr (assoc elt vars))
elt))
list)
What took one line of Perl takes five lines of Lisp. This is
atypical; normally (for me) a Lisp implementation takes about 2/3 of
the parallel Perl implementation. However, it does show how Perl can
often give a very fluid implementation. (BTW: If you think that the
Perl above looks unreadable, imagine reading that bit of Lisp if you
didn't know the language.)
Because Perl has such amazingly groovy string handling, it's great at
programs that need a lot of communication between themselves and other
programs. This covers a lot of web applications, report processing
facilities, email processors, programs that log into remote systems
and perform automated tasks, etc, etc. Programs that do a lot on
their periphery, a lot of I/O.
Lisp, on the other hand, has amazing strengths in computation. It
really pushes the envelope on what a language can provide. You can
sculpt the language to meet the task. In this area, Lisp is great at
computationally intensive programs: constraint resolution, expert
systems, semantic network processing, symbolic math, etc, etc.
Programs that do a lot in their core (as opposed to their periphery),
a lot of processing.
One thing that Perl really has going for it is CPAN, the Comprehensive
Perl Archive Network. It's a repository for lots and lots of
libraries, for all sorts of tasks. Most Perl programs would take
three to five times as long to write if they didn't borrow from CPAN.
In Lisp software houses, the coders have often built up lots of
libraries that serve a similar purpose; they're often not as extensive
as CPAN, but usually are more coherent. These days, CLiki is filling
a lot of the role that CPAN does for Perl.
Of course, trying to tell a Lisper what's great about Perl is like
trying to tell a Perl guy what's great about Lisp. There's a je ne se
quois to each language, a nature that's difficult to convey to
somebody who hasn't experienced it. (Believe me; I've had the "why
did you write this in Lisp" discussion a million times. It's
refreshing to write its mirror!) Personally, I prefer to use Lisp
most of the time, but I'd hate to catalog my music with it.
All this is not to say that Perl is without its downsides. The syntax
is inconsistent. It's easy to get lost in complex data structures
(not that I haven't seen a few CADADRs from time to time). The OOP
support is a hack and sometimes feels unnatural. There's no way to
extend the syntax, although it's sometimes possible to effect
something similar to macros by using text processing and eval.
Overall, I think that Perl and Lisp each are powerful languages on
opposite sides of a coin. My biggest project at work uses both of
them: Perl to interface to other systems, and Lisp to do the heavy
lifting.
I think that it is interesting that Larry Wall is making Perl 6 a lot
more Lisp-like. He saw a lot of cool stuff in Lisp, and wants them to
be in Perl. I'm exited about the idea; I think it may turn out to be
similar to what Python wanted to be. Wall has also been incorporating
Lispisms into his personal Perl work lately. A friend of mine came
back from a Perl conference excitedly telling me, "I found out about
this cool trick, it's called memoization..."
I know I didn't answer your question, but I hope this helps you
understand where Perl guys are coming from when they rave about Perl.
Cheers,
joelh
--
Joel Ray Holveck - ·····@piquan.org
Fourth law of programming:
Anything that can go wrong wi
sendmail: segmentation violation - core dumped
Joel Ray Holveck <·····@piquan.org> writes:
> One of the biggest tools in the Perl toolbox is its hash tables. They
> serve a similar, but more prominent, role in Perl than alists do in
> Lisp. The equivalent of (gethash key table) is $table->{key}. Since
> nested hash tables are very common in Perl, you can write
> $table->{key1}{key2}{key3}, which I find more readable than (gethash
> key3 (gethash key2 (gethash key1 table))).
(defmacro -> (table &rest keys)
(labels ((nest-next (ks)
(if (null ks)
table
(list 'gethash (first ks) (nest-next (rest ks))))))
(nest-next (reverse keys))))
(-> table key1 key2 key3)
=> (GETHASH KEY3 (GETHASH KEY2 (GETHASH KEY1 TABLE)))
> As a concrete example, suppose (as I did in a program I recently
> wrote) that you have a string with several arbitrary variable names
> you need to substitute in, and a hash with their values. This can be
> done in one line in Perl:
> # $string holds something like:
> # 'The $dimension of the $obj is $length cm.'
> # %vars holds something like:
> # { $dimension => length, $obj => plank, $length => 105 }
> $string =~ s/\$(\S+)/$vars->{$1}/g;
(defparameter *vars*
(let ((tbl (make-hash-table :test #'equal)))
(setf (-> tbl "$dimension") "length"
(-> tbl "$obj") "plank"
(-> tbl "$length") "105")
tbl))
(let (($string "The $dimension of the $obj is $length cm."))
(repl-match $string "$[a-z]+" #'(lambda (s) (-> *vars* s)) t t))
=> "The length of the plank is 105 cm."
Admittedly, repl-match is a thin wrapper for a typical regexp package.
> One thing that Perl really has going for it is CPAN, the Comprehensive
> Perl Archive Network.
Undoubtedly...
/Jon
On Fri, 07 Nov 2003 11:31:02 GMT, Joel Ray Holveck <·····@piquan.org>
wrote:
>I know I didn't answer your question, but I hope this helps you
>understand where Perl guys are coming from when they rave about Perl.
Actually that does sort of answer my question. I don't often have
occasion to do anything with Unix-style one record per line text files
and suchlike, but now I can see how Perl could be considered handy if
you do. Thanks!
--
"Sore wa himitsu desu."
To reply by email, remove
the small snack from address.
http://www.esatclear.ie/~rwallace
················@eircom.net (Russell Wallace) writes:
> On Fri, 07 Nov 2003 11:31:02 GMT, Joel Ray Holveck <·····@piquan.org>
> wrote:
>
> >I know I didn't answer your question, but I hope this helps you
> >understand where Perl guys are coming from when they rave about Perl.
>
> Actually that does sort of answer my question. I don't often have
> occasion to do anything with Unix-style one record per line text files
> and suchlike, but now I can see how Perl could be considered handy if
> you do. Thanks!
I recently (last week) reimplemented a text-bashing Perl script in
Lisp, because it grew to the point where it needed to do useful stuff
with the bashed text. The result was 2/3 the number of lines, 1/2 the
number of characters, and *much* easier to follow. Of course I used
my personal text-bashing libraries, but it's all pretty simple stuff
(no regexp library, for example).
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
················@eircom.net (Russell Wallace) wrote in message news:<·················@news.eircom.net>...
> On Fri, 07 Nov 2003 11:31:02 GMT, Joel Ray Holveck <·····@piquan.org>
> wrote:
>
> >I know I didn't answer your question, but I hope this helps you
> >understand where Perl guys are coming from when they rave about Perl.
>
> Actually that does sort of answer my question. I don't often have
> occasion to do anything with Unix-style one record per line text files
> and suchlike, but now I can see how Perl could be considered handy if
> you do. Thanks!
Actually, the built-in regex-based features let you make just about
any collection of data appear to be such a data structure, which you
can then apply the other Perl tools to. An example of this would be
fetching an HTML file from a URL, locating just the table of interest
amidst the other clutter, and parsing the lines out of the table. In
general, depending on the nature of the clutter, it would take only
another line or two to effectively turn that URL into a "Unix-style
one record per line text file". Once you see this, you start finding
useful little "databases" everywhere you look.
I think what it mostly comes down to is the ability it gives you to
take data from anywhere in any screwy format and within a few minutes
(most of which is spent studying the format of the data) have a line
or two of code that makes the data as accessible to processing as if
it were properly stored in a relational database.
On 7 Nov 2003 12:35:11 -0800, ········@hotmail.com (Tuang) wrote:
>Actually, the built-in regex-based features let you make just about
>any collection of data appear to be such a data structure, which you
>can then apply the other Perl tools to. An example of this would be
>fetching an HTML file from a URL, locating just the table of interest
>amidst the other clutter, and parsing the lines out of the table. In
>general, depending on the nature of the clutter, it would take only
>another line or two to effectively turn that URL into a "Unix-style
>one record per line text file".
Maybe. I just remember the one time I looked at Perl, I wanted to do
something simple with a text file, but it involved looking at more
than one line at a time, so I said "Perl's supposed to be good at text
files, time to try it out," and came up with the obvious idea of
slurping the file into an array, one line per element, and processing
it there.
Perl documentation [1]: You should only look at one line at a time,
otherwise it won't run fast.
Me: Great idea Einstein, if I cared about execution speed I'd write
the bloody thing in C!
Perl documentation: Well if you really really want to look at more
than one line at a time, you can do it like this: (horrible big ugly
mess of code clogged with three zillion punctuation marks).
Me: Jesus, Perl can't even handle a simple array properly? This is a
step down from Basic on the Vic-20! And people say this is a good
language for getting things done quickly??
(I ended up doing the job in Python just from the REPL, didn't even
need to bother writing a program.)
Of course, I don't think I've ever had a problem for which regular
expressions were the right solution; if one does have such problems,
Perl probably looks better.
[1] After the installer, just using the default options, broke Windows
so it wouldn't boot anymore. An easy fix, but not a good first
impression :P
--
"Sore wa himitsu desu."
To reply by email, remove
the small snack from address.
http://www.esatclear.ie/~rwallace
Russell Wallace wrote:
> Perl documentation: Well if you really really want to look at more
> than one line at a time, you can do it like this: (horrible big ugly
> mess of code clogged with three zillion punctuation marks).
The input record separator is newline by default, but it's settable.
undef $/; # slurp mode, entire file as one record
$/ = ""; # one or more blank lines separate records
$/ = $size; # fixed length records, $size contains an integer
Your one line per element problem might have worked with something like
undef $/; # slurp mode
$_ = <FILE>; # get the whole file
@lines = split("\n", $_); # split on newlines, stuff in array
Haven't actually tried it, but I think that would slurp your file into an
array, one line per element.
> Of course, I don't think I've ever had a problem for which regular
> expressions were the right solution; if one does have such problems,
> Perl probably looks better.
I grew up on a farm. I used to keep a pair of 6" Crescent pliers in my hip
pocket always. They were not the perfect tool for every job, but they were
the one indispensable tool that I used every day. Perl is like that.
I want to learn lisp. I want to learn python. I want to learn smalltalk.
But in the meantime, perl is in my hip pocket always.
--
Bud Rogers <····@netride.net> KD5SZ
On Fri, 07 Nov 2003 19:56:48 -0600, Bud Rogers wrote:
> Your one line per element problem might have worked with something like
>
> undef $/; # slurp mode
> $_ = <FILE>; # get the whole file
> @lines = split("\n", $_); # split on newlines, stuff in array
If you want to input lines into an array, it's simpler to do just
@lines = <FILE>;
because <...> in array context returns all the lines.
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
From: Joel Ray Holveck
Subject: Re: Reasons for preferring Lisp, and for what
Date:
Message-ID: <871xsi7j36.fsf@thor.piquan.org>
Can I say how weird I feel discussing Perl here?
> Your one line per element problem might have worked with something like
> undef $/; # slurp mode
> $_ = <FILE>; # get the whole file
> @lines = split("\n", $_); # split on newlines, stuff in array
@lines = <FILE> will do that fine. But since it reads the whole file
into memory, it's not recommended unless you have to. (Sorting lines:
fine. Filtering lines: not fine.)
In Perl, there's a concept of "context", which is what type of answer
you expect. (This is part of Perl's DWIMish syntax.) If you use <>
in an array context (like when you're assigning to an array), it will
read every line and return them as an array.
I'm not sure what Russell's situation was. If you have records
separated on a regexp (such as \n), then you can set $/. If you have
records that are a fixed number of lines (say, three lines each), then
you can use $rec = <>.<>.<>; or something similar. If you have
records that are a variable number of lines and require semantic
processing to tell when they're complete (say, XML) you do the same
thing as in just about any other language: read into a buffer until
you have a complete record, and then process that. If you have
records that are a fixed number of bytes, you can use sysread.
I don't know what Russell was looking at, but I'm not aware of any
idiom for reading multiple lines that involves a "horrible big ugly
mess of code clogged with three zillion punctuation marks". And Perl
can handle a simple array properly. Perhaps Russell just wasn't yet
looking past the syntax. (Sound familiar?)
joelh
--
Joel Ray Holveck - ·····@piquan.org
Fourth law of programming:
Anything that can go wrong wi
sendmail: segmentation violation - core dumped
Joel Ray Holveck <·····@piquan.org> writes:
> I don't know what Russell was looking at, but I'm not aware of any
> idiom for reading multiple lines that involves a "horrible big ugly
> mess of code clogged with three zillion punctuation marks". And Perl
> can handle a simple array properly. Perhaps Russell just wasn't yet
> looking past the syntax. (Sound familiar?)
Heh. In defence of syntax-based arguments, though: the syntax of Lisp
is sufficiently simple that emacs can indent it reliably. This is not
the case for Perl. Only one of the many criteria by which one might
assess a syntax, but an important one for me ;-)
-dan
--
http://web.metacircles.com/cirCLe_CD - Free Software Lisp/Linux distro
On Sat, 08 Nov 2003 19:43:51 +0000, Daniel Barlow <···@telent.net> wrote:
> Heh. In defence of syntax-based arguments, though: the syntax of
> Lisp is sufficiently simple that emacs can indent it reliably. This
> is not the case for Perl. Only one of the many criteria by which
> one might assess a syntax, but an important one for me ;-)
To be fair: I've seen Emacs choke on (Common) Lisp syntax a couple of
times, too. It happens more often with Perl but cperl-mode is pretty
good given the syntax nightmare that Perl is.
Edi.
Edi Weitz <···@agharta.de> writes:
> On Sat, 08 Nov 2003 19:43:51 +0000, Daniel Barlow <···@telent.net> wrote:
>
> > Heh. In defence of syntax-based arguments, though: the syntax of
> > Lisp is sufficiently simple that emacs can indent it reliably. This
> > is not the case for Perl. Only one of the many criteria by which
> > one might assess a syntax, but an important one for me ;-)
>
> To be fair: I've seen Emacs choke on (Common) Lisp syntax a couple of
> times, too. It happens more often with Perl but cperl-mode is pretty
> good given the syntax nightmare that Perl is.
>
> Edi.
Getting fed up horrid Perl syntax and emacs' mishandling of it is one
of the straws that got me looking for alternative languages, which
eventually led to Lisp.
I had started writing stuff that looked like this:
$table{lc(${$row}[0])}->{lc(${$row}[1])}->{type} = ${$row}[2];
$table{lc(${$row}[0])}->{lc(${$row}[1])}->{size} = ${$row}[3];
$table{lc(${$row}[0])}->{lc(${$row}[1])}->{seq} = ${$row}[4];
$table{lc(${$row}[0])}->{lc(${$row}[1])}->{ident} = 1;
$name1="part1_${year}_${month}";
$data1 = $$name1{$journal};
and this:
eval <<EVAL1
\$cop = \$values[$copind];
\$cop =~ s/,//g;
\$data{\$id}->{\$section}->{ALL}->{COPIES}->{\$per} += \$cop;
\$data{\$id}->{\$section}->{NMEM}->{COPIES}->{\$per} += \$cop;
if (\$acr eq 'JANAC' || \$acr eq 'APP' || \$acr eq 'JMM' || \$acr eq 'EDQ')
{
\$data{TOTAL}->{\$section}->{NMEM}->{COPIES}->{\$per} += \$cop;
\$data{TOTAL}->{\$section}->{ALL}->{COPIES}->{\$per} += \$cop;
}
EVAL1
And so on.
On 7 Nov 2003 12:35:11 -0800, ········@hotmail.com (Tuang) wrote:
> Actually, the built-in regex-based features let you make just about
> any collection of data appear to be such a data structure, which you
> can then apply the other Perl tools to. An example of this would be
> fetching an HTML file from a URL, locating just the table of
> interest amidst the other clutter, and parsing the lines out of the
> table.
The problem with Perl's (admittedly very good) regexp capabilities is
that Perl users tend to think that they can attack almost every
problem with regular expressions. (Been there, done that.)
Trying to parse HTML or XML with regular expressions is really a bad
idea. (I skimmed through an O'Reilly title about Perl and XML in a
bookstore and had to laugh when the authors presented a little
home-grown parser which consisted mostly of regexep matches.)
Edi.
Edi Weitz <···@agharta.de> wrote in message news:<··············@bird.agharta.de>...
> On 7 Nov 2003 12:35:11 -0800, ········@hotmail.com (Tuang) wrote:
>
> > Actually, the built-in regex-based features let you make just about
> > any collection of data appear to be such a data structure, which you
> > can then apply the other Perl tools to. An example of this would be
> > fetching an HTML file from a URL, locating just the table of
> > interest amidst the other clutter, and parsing the lines out of the
> > table.
>
> The problem with Perl's (admittedly very good) regexp capabilities is
> that Perl users tend to think that they can attack almost every
> problem with regular expressions. (Been there, done that.)
>
> Trying to parse HTML or XML with regular expressions is really a bad
> idea....
It depends on how you mean this. If you mean what I think you mean,
that your generic HTML or XML manipulator library should be one that
is built expressly for that purpose, based on the formal specs, I
definitely agree. Perl has such libraries.
If you're just quickly extracting some specific data from some
specific Web page for yourself, though, then regular expressions are
excellent. It doesn't matter whether it's HTML or XML or whatever.
Just find some "landmarks" in the text you can use as delimeters to
base a regex on and let it extract your data.
Clearly this isn't a scalable approach. It's for one-time tasks, not
real applications and, as you point out, Perl users are famous for
taking it too far.
On 7 Nov 2003 12:35:11 -0800, Tuang wrote:
> Actually, the built-in regex-based features let you make just about
> any collection of data appear to be such a data structure, which you
> can then apply the other Perl tools to. An example of this would be
> fetching an HTML file from a URL, locating just the table of interest
> amidst the other clutter, and parsing the lines out of the table. In
Ye-es...if only HTML were a regular language...
{Cue jwz quote}
--
Cogito ergo I'm right and you're wrong. -- Blair Houghton
(setq reply-to
(concatenate 'string "Paul Foley " "<mycroft" '(··@) "actrix.gen.nz>"))
While anyone who uses perl would hopefully just use the relevant parsing
packages from CPAN for a known file format, I note that recent perl
"reg"exes allow you to do wacky things, more than just the traditional
limited backreferencing. In particular, there are things like the
"(??{ code })" construct that allows recursion and thus matching of e.g.
arbitrarily nested parenthesis pairs.
See the "Extended Patterns" section of the perlre man page.
http://aspn.activestate.com/ASPN/docs/ActivePerl/lib/Pod/perlre.html
Joel Ray Holveck writes:
> opposite sides of a coin. My biggest project at work uses both of
> them: Perl to interface to other systems, and Lisp to do the heavy
> lifting.
If information about that system is not confidential, you might add an
entry for your company to the industry applications page at:
http://alu.cliki.net
Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
From: Joel Ray Holveck
Subject: Re: Reasons for preferring Lisp, and for what
Date:
Message-ID: <87r80j23xl.fsf@thor.piquan.org>
>> opposite sides of a coin. My biggest project at work uses both of
>> them: Perl to interface to other systems, and Lisp to do the heavy
>> lifting.
> If information about that system is not confidential, you might add an
> entry for your company to the industry applications page at:
> http://alu.cliki.net
Will do. It's not confidential, AFAIK, but I'll run it by my boss to
be sure. But it is just an internal app; no customer has ever seen
it. Do you want that?
Cheers,
joelh
--
Joel Ray Holveck - ·····@piquan.org
Fourth law of programming:
Anything that can go wrong wi
sendmail: segmentation violation - core dumped
Joel Ray Holveck writes:
[Paolo Amoroso:]
>> If information about that system is not confidential, you might add an
>> entry for your company to the industry applications page at:
>> http://alu.cliki.net
>
> Will do. It's not confidential, AFAIK, but I'll run it by my boss to
> be sure. But it is just an internal app; no customer has ever seen
> it. Do you want that?
You bet :-) I think it is important to show that Lisp is used in
industry for solving a wide range of problems, from small internal
tools to mission critical applications.
Thanks,
Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Joel Ray Holveck <·····@piquan.org> writes:
> As a concrete example, suppose (as I did in a program I recently
> wrote) that you have a string with several arbitrary variable names
> you need to substitute in, and a hash with their values. This can be
> done in one line in Perl:
> # $string holds something like:
> # 'The $dimension of the $obj is $length cm.'
> # %vars holds something like:
> # { $dimension => length, $obj => plank, $length => 105 }
> $string =~ s/\$(\S+)/$vars->{$1}/g;
>
> Now, look at a Lisp parallel. You have a list, and you want to
> substitute keywords with their values from an alist:
> ;; LIST holds something like:
> ;; (the :dimension of the :object is :value cm)
> ;; VARS holds something like:
> ;; ((:dimension . length) (:object . plank) (:value . 105))
> (mapcar #'(lambda (elt)
> (if (keywordp elt)
> (cdr (assoc elt vars))
> elt))
> list)
This is not quite fair, you are doing quite different things.
If you had used a plist, you could do this:
(defun subst-things (list plist)
(mapcar (lambda(thing)(or (getf plist thing) thing)) list))
CL-USER 53 > (subst-things '(the :dimension of the :object is :value cm)
'(:dimension length :object plank :value 105))
(THE LENGTH OF THE PLANK IS 105 CM)
What you really are showing in the perl example, is that regexp-based
substitution is quite neat. You'd have to work a little to come up
with a similar lisp solution.
(On the other hand, the example can also be used to illustrate how
quickly regexp-based solutions get it wrong, the \S+-match is not
really what you want, since you want it to work on
'The $dimension of the $obj, mentioned above, is $length cm.'
as well...)
--
(espen)
Espen Vestre <·····@*do-not-spam-me*.vestre.net> writes:
> (On the other hand, the example can also be used to illustrate how
> quickly regexp-based solutions get it wrong, the \S+-match is not
> really what you want, since you want it to work on
>
> 'The $dimension of the $obj, mentioned above, is $length cm.'
>
> as well...)
Here is a little lisp function (hacked together in a few minutes,
so don't expect too much, e.g. I haven't thought through the conse-
quences of passing through the _whole_ string several times :-)),
that generalises what the little perl hack to the rather extreme:
(defun expand-string (string)
(loop for escape = (search "#." string)
while escape
do
(multiple-value-bind (lisp-object new-pos)
(let ((*read-eval* t))
(read-from-string string nil nil :start escape))
(when (ignore-errors (eql (elt string new-pos) #\space))
(incf new-pos))
(setf string (concatenate 'string
(subseq string 0 escape)
(princ-to-string lisp-object)
(subseq string new-pos))))
finally return string))
Now:
CL-USER 75 > (expand-string "A #.*foo* bar example: (fac 10) = #.(fac 10)")
"A foobar example: (fac 10) = 3628800"
I think what this illustrates is that whatever perl idioms you're fond
of may not be immediately available in CL, but it's often a question of
writing a tiny little utility, and once you have that, you can put it
into all of your projects.
--
(espen)
From: Joel Ray Holveck
Subject: Re: Reasons for preferring Lisp, and for what
Date:
Message-ID: <87vfpv240c.fsf@thor.piquan.org>
> This is not quite fair, you are doing quite different things.
Granted, it's not a perfect parallel. I was trying to illustrate some
differences between a Perl hacker's mindset and a Lisp hacker's
mindset, not make an inherent statement about one particular task.
> What you really are showing in the perl example, is that regexp-based
> substitution is quite neat. You'd have to work a little to come up
> with a similar lisp solution.
Yup. Regexps (and regexp operators) are Perl's biggest tools, which
is close to the point I was trying to illustrate.
> (On the other hand, the example can also be used to illustrate how
> quickly regexp-based solutions get it wrong, the \S+-match is not
> really what you want, since you want it to work on
> 'The $dimension of the $obj, mentioned above, is $length cm.'
> as well...)
I intentionally handwaved that (hence the lack of punctuation in my
example; my actual production code was different). While regexps are
cool, they can also be problematic. One of the big-time Perl hackers
once said something to the effect of, "If you use a regexp to solve a
problem, you have another problem." Which is partially true.
Cheers,
joelh
--
Joel Ray Holveck - ·····@piquan.org
Fourth law of programming:
Anything that can go wrong wi
sendmail: segmentation violation - core dumped
Joel Ray Holveck <·····@piquan.org> writes:
> One of the big-time Perl hackers once said something to the effect
> of, "If you use a regexp to solve a problem, you have another
> problem." Which is partially true.
I think you mean Jamie Zawinski[1]. Who wasn't really a big time
perl hacker ... the full quote, and even more the full thread, is
very entertaining reading.
Footnotes:
[1] http://groups.google.com/groups?selm=33F0C496.370D7C45%40netscape.com&rnum=1
--
Alan Shutko <···@acm.org> - I am the rocks.
That's what we are here for... :)
From: Joel Ray Holveck
Subject: Re: Reasons for preferring Lisp, and for what
Date:
Message-ID: <87brrn1zgx.fsf@thor.piquan.org>
>> One of the big-time Perl hackers once said something to the effect
>> of, "If you use a regexp to solve a problem, you have another
>> problem." Which is partially true.
> I think you mean Jamie Zawinski[1]. Who wasn't really a big time
> perl hacker ... the full quote, and even more the full thread, is
> very entertaining reading.
Thanks for the quote. Yes, it makes a lot more sense coming from jwz.
I was thinking I'd seen it attributed to Randall Schwartz or somebody,
but that's much more of a jwz thing to say.
I read the thread, thanks for the link. Very entertaining, and gave
me some interesting things to ponder (particularly the distinction
between abstractly "good" and "useful").
Thanks,
joelh
--
Joel Ray Holveck - ·····@piquan.org
Fourth law of programming:
Anything that can go wrong wi
sendmail: segmentation violation - core dumped
Joel Ray Holveck <·····@piquan.org> writes:
> As a concrete example, suppose (as I did in a program I recently
> wrote) that you have a string with several arbitrary variable names
> you need to substitute in, and a hash with their values. This can be
> done in one line in Perl:
> # $string holds something like:
> # 'The $dimension of the $obj is $length cm.'
> # %vars holds something like:
> # { $dimension => length, $obj => plank, $length => 105 }
> $string =~ s/\$(\S+)/$vars->{$1}/g;
>
> Now, look at a Lisp parallel. You have a list, and you want to
> substitute keywords with their values from an alist:
> ;; LIST holds something like:
> ;; (the :dimension of the :object is :value cm)
> ;; VARS holds something like:
> ;; ((:dimension . length) (:object . plank) (:value . 105))
> (mapcar #'(lambda (elt)
> (if (keywordp elt)
> (cdr (assoc elt vars))
> elt))
> list)
AFAIK, nobody has ever been put in jail for programming in Lisp. Not
so with perl. Remember: my($f)=`fortune`;
On the other hand, it's a good feedback...
--
__Pascal_Bourguignon__
http://www.informatimago.com/
From: Joe Marshall
Subject: Re: Reasons for preferring Lisp, and for what
Date:
Message-ID: <1xsk10lq.fsf@ccs.neu.edu>
········@hotmail.com (Tuang) writes:
> It wasn't the expressions of rapture that hooked me on Perl, though,
> it was the ten-line code samples that did what would have taken me
> 200 (buggy) lines to do with C or Java.
It's amazing how terse buggy code can be when you write it in Perl.
Joe Marshall <···@ccs.neu.edu> writes:
> It's amazing how terse buggy code can be when you write it in Perl.
This kind of remark doesn't help us make the sell on why Lisp is
great. It tells the world that we use Lisp because we can't handle
Perl. Given that we have already told them that Lisp is great when
you don't know what you're doing, we sound like we're as dense as any
group of dunderheads ever assembled.
I write Perl, and it isn't buggy. I have even submitted Perl source
as appendices to expert declarations used in litigation.
Claiming to love Lisp, talking about how wonderful Lisp is, and then
so loudly and proudly proclaiming one's failure to master other
languages is akin to a speaker of French going on at length about the
beauty of his preferred language while also being proud that he lacks
the mastery of other languages needed to make any sort of insightful
comparison.
If this is the best that we have to offer, we deserve what we get.
Responding back to the original poster, there are a few things that I
love about Lisp.
o Lisp is flexible. I can create functions that do what I think need
to be done, and I don't need to worry much about details regarding
things I'm passing in or the type of things that I'm returning.
(The same is true of Perl.)
o The top-level. As I'm working on a function, I can test it and
play with it, getting just the right combination of functionality,
intuitiveness, and readability that I'm striving for. (The same is
true of Python.)
o Huge toolbox. Lisp is a big language. There are lots of things
available, such that I don't need to reinvent the wheel. Functions
and macros for just about everything that I'd want to do already
exist in many cases. (The same is true of C++. CPAN takes Perl
even a step beyond this, more like (La)TeX.)
o Aesthetic. Lisp is beautiful to look at, if it's well-written.
Although I do not have difficulty reading and immediately
understanding even very densely-written Perl, it seems to be Just
Code. Lisp has a more visually pleasing appearance. I have seen
C++ that looks very nice, but that sort of thing is much less
frequent.
o Power. I'm not sure if this the result of being huge and flexible
or something else, but Lisp is tremendously powerful. Although I
have written even very large programs in Perl with success, there
are times that I have run into its boundaries. I find myself
frequently wishing that languages that I'm using would be more
Lisp-like in one way or another, usually when I'm hitting the upper
bounds of what the language expects the programmer to do.
I'm reminded here of an idiom I heard when I was learning Unix long
ago. It went something like, "On most systems you're limited by
what the software can do. In Unix, you're limited only by what you
know." As I learned the shell and the zillions of commands
available to users, I came to appreciate how true that statement
is. The same kind of thing seems to be true of Lisp; as often as I
have had to abandon an approach I wanted because it was ultimately
too pessimal in the target language, I cannot think of a single
time when I have had to change my design because Lisp wouldn't do
what I wanted.
Again, in Perl, if you're hitting the upper bounds, you do have an
option, but generally that means something like writing XS code,
which isn't really a lot of fun. Perhaps if Perl were implemented
in Perl, it would be more Lispy in its extensibility, and I'd have
a little less to complain about.
Lisp isn't perfect for every job. I might go so far as to say that
Lisp isn't perfect for ANY job. But Lisp is building material; it
lets you create the language that is perfect for the job at hand. If
you don't approach it that way, though, you're likely to see Lisp as
merely another programming language, albeit one with a strange group
of adherents -- one that seems unable to articulate why it thinks the
language is so great beyond making a few snide and unfair remarks
about "the competition."
--
Matt Curtin, CISSP, IAM, INTP. Keywords: Lisp, Unix, Internet, INFOSEC.
Founder, Interhack Corporation +1 614 545 HACK http://web.interhack.com/
Author of /Developing Trust: Online Privacy and Security/ (Apress, 2001)
Matt Curtin <········@interhack.net> wrote in message news:<··············@rowlf.interhack.net>...
> Joe Marshall <···@ccs.neu.edu> writes:
>
> I have even submitted Perl source
> as appendices to expert declarations used in litigation.
Could say more about this. It sounds intriguing. What kind of litigation?
··········@hotmail.com (larry) writes:
>> I have even submitted Perl source as appendices to expert
>> declarations used in litigation.
>
> Could say more about this. It sounds intriguing. What kind of
> litigation?
In the particular case where I submitted Perl source as an appendix,
it was litigation in connection with privacy concerns. In particular,
"Blumofe v. Pharmatrak," where Plaintiffs sued on the basis that their
privacy was invaded. Pharmatrak was a provider of web reporting
services to pharmaceutical companies. The system worked through a
combination of web bugs, JavaScript and Java surreptitiously included
on the pharmaceutical companies' web sites, with the end result being
that when a user went to the pharmaceutical company web site, the
user's browser would also talk to Pharmatrak's servers.
The Court [District of Massachusetts] granted Plaintiffs discovery on
the Pharmatrak servers. My company performed that discovery and
subsequent analysis. I wrote Perl programs that went through the web
server logs looking for things like names, addresses, phone numbers,
etc., while building cookie-based dossiers of each of the users tagged
by Pharmatrak's system.
I used Perl for reading the logs because they had testified that they
used Perl for the same purpose. I would have preferred to write the
code in Common Lisp, but if I had done that, it might have opened up a
line of argumentation for opposing counsel: that in my analysis, I
used some super-duper sophisticated stuff that Defendants were not
using. The point of how easily such dossiers could be developed would
be made much better if I used the same tools that they were using in
the normal course of business.
If you want to know more about that case specifically (I doubt I left
out any significant details regarding programming languages, but if
you're interested in privacy and in particular the Electronic
Communications Privacy Act of 1986, feel free), you can see a little
announcement and a link to the decision at
http://web.interhack.com/news/n2003_ptremand.php.
We use a lot of different languages in our forensic computing
practice; sometimes the decision on which we should use is very
obvious due to the circumstances and the suitability of the tool for
the job. Sometimes, folks are using entirely the wrong tool for the
job and then we need to have our clients (the attorneys) make some
decisions about which way we should proceed -- use the same wrong tool
that litigants were using, or introduce a new tool that sorts through
the mess more quickly.
In the past few months, we've had projects use C, C++, Perl, Python,
Common Lisp, and even some crazy stuff for IBM iSeries (AS/400)
systems.
If there isn't any compelling reason otherwise, I'll use Common Lisp,
just because I can get so much done so quickly, and I have a lot more
fun writing Lisp code than, say, C.
--
Matt Curtin, CISSP, IAM, INTP. Keywords: Lisp, Unix, Internet, INFOSEC.
Founder, Interhack Corporation +1 614 545 HACK http://web.interhack.com/
Author of /Developing Trust: Online Privacy and Security/ (Apress, 2001)
Matt Curtin wrote:
> Joe Marshall <···@ccs.neu.edu> writes:
>
>> It's amazing how terse buggy code can be when you write it in Perl.
>
> This kind of remark doesn't help us make the sell on why Lisp is
> great.
Thank you. I really don't understand why so many people feel obliged to put
down perl or those who use it. It is a useful tool, one of many.
> Lisp isn't perfect for every job. I might go so far as to say that
> Lisp isn't perfect for ANY job. But Lisp is building material; it
> lets you create the language that is perfect for the job at hand. If
> you don't approach it that way, though, you're likely to see Lisp as
> merely another programming language, albeit one with a strange group
> of adherents -- one that seems unable to articulate why it thinks the
> language is so great beyond making a few snide and unfair remarks
> about "the competition."
Thank you for a thoughtful essay on what's good about lisp rather than
what's wrong with some other language.
--
Bud Rogers <····@netride.net> KD5SZ
From: Joe Marshall
Subject: Re: Reasons for preferring Lisp, and for what
Date:
Message-ID: <3ccupqby.fsf@comcast.net>
Matt Curtin <········@interhack.net> writes:
> Joe Marshall <···@ccs.neu.edu> writes:
>
>> It's amazing how terse buggy code can be when you write it in Perl.
>
> This kind of remark doesn't help us make the sell on why Lisp is
> great.
That's ok because making a sell on Lisp was not my intent there.
> It tells the world that we use Lisp because we can't handle
> Perl. Given that we have already told them that Lisp is great when
> you don't know what you're doing, we sound like we're as dense as any
> group of dunderheads ever assembled.
I made that comment, too.
> I write Perl, and it isn't buggy. I have even submitted Perl source
> as appendices to expert declarations used in litigation.
Giving Perl to lawyers just sounds like a bad idea.
> Claiming to love Lisp, talking about how wonderful Lisp is, and then
> so loudly and proudly proclaiming one's failure to master other
> languages is akin to a speaker of French going on at length about the
> beauty of his preferred language while also being proud that he lacks
> the mastery of other languages needed to make any sort of insightful
> comparison.
>
> Lisp isn't perfect for every job. I might go so far as to say that
> Lisp isn't perfect for ANY job.
That's the spirit!
> But Lisp is building material; it lets you create the language that
> is perfect for the job at hand. If you don't approach it that way,
> though, you're likely to see Lisp as merely another programming
> language, albeit one with a strange group of adherents -- one that
> seems unable to articulate why it thinks the language is so great
> beyond making a few snide and unfair remarks about "the
> competition."
Snide, yes. Unfair? No.
Perl is the *archetype* of `write-only' languages:
print((($line=join("",<>))=~s/.*\n/index($`,$&)>=$[?"":$&/ge&&$line));
($l=join("",<>))=~s/.*\n/index($`,$&)>=$[||print$&/ge;
Call me an ignorant fool, but I really don't mind saying that I cannot
understand what the above Perl code does.
--
~jrm
Joe Marshall wrote:
> Perl is the *archetype* of `write-only' languages:
>
> print((($line=join("",<>))=~s/.*\n/index($`,$&)>=$[?"":$&/ge&&$line));
>
> ($l=join("",<>))=~s/.*\n/index($`,$&)>=$[||print$&/ge;
>
> Call me an ignorant fool, but I really don't mind saying that I cannot
> understand what the above Perl code does.
I don't know what it does either. I've written a fair amount of perl. Some
of my early work wasn't very pretty. Heck, some of my recent work isn't
all that pretty. But I've never written anything like that. Nor would I.
You can write ugly, unreadable code in any language. Choosing to do so
says more about the coder than it does about the language. And choosing
the worst example you can find to illustrate a point says more about your
prejudice than it does about the point you're trying to illustrate.
--
Bud Rogers <····@netride.net> KD5SZ
Joe Marshall <·············@comcast.net> writes:
> Perl is the *archetype* of `write-only' languages:
>
> print((($line=join("",<>))=~s/.*\n/index($`,$&)>=$[?"":$&/ge&&$line));
>
> ($l=join("",<>))=~s/.*\n/index($`,$&)>=$[||print$&/ge;
>
> Call me an ignorant fool, but I really don't mind saying that I cannot
> understand what the above Perl code does.
I've no idea either. Maybe something like whatever it is this program
does?
(defun pprint-flet (stream list &rest noise)
(declare (ignore noise))
(funcall (formatter
"~:<~^~W~^ ·@_~:<·@{~:<~^~W~^~3I ································@··@{~W~^ ~_~}~:>~^ ~_~}~:>····@···@{~W~^ ~_~}~:>")
stream
list))
;-)
Cheers,
Luke
Luke Gorrie <····@bluetail.com> writes:
> Joe Marshall <·············@comcast.net> writes:
>
>> Perl is the *archetype* of `write-only' languages:
>>
>> print((($line=join("",<>))=~s/.*\n/index($`,$&)>=$[?"":$&/ge&&$line));
>>
>> ($l=join("",<>))=~s/.*\n/index($`,$&)>=$[||print$&/ge;
>>
>> Call me an ignorant fool, but I really don't mind saying that I cannot
>> understand what the above Perl code does.
>
> I've no idea either. Maybe something like whatever it is this program
> does?
>
> (defun pprint-flet (stream list &rest noise)
No, I don't think so. Clearly this pprints a flet form :-)
> (declare (ignore noise))
> (funcall (formatter
> "~:<~^~W~^ ·@_~:<·@{~:<~^~W~^~3I ································@··@{~W~^ ~_~}~:>~^ ~_~}~:>····@···@{~W~^ ~_~}~:>")
And this is a mere implementation detail :-)
Christophe
(yes, it's often easier to rewrite pprint format strings when one
discovers a bug :-)
--
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)
From: Joe Marshall
Subject: Re: Reasons for preferring Lisp, and for what
Date:
Message-ID: <ptfyo9sd.fsf@comcast.net>
Christophe Rhodes <·····@cam.ac.uk> writes:
> Luke Gorrie <····@bluetail.com> writes:
>
>> Joe Marshall <·············@comcast.net> writes:
>>
>>> Perl is the *archetype* of `write-only' languages:
>>>
>>> print((($line=join("",<>))=~s/.*\n/index($`,$&)>=$[?"":$&/ge&&$line));
>>>
>>> ($l=join("",<>))=~s/.*\n/index($`,$&)>=$[||print$&/ge;
>>>
>>> Call me an ignorant fool, but I really don't mind saying that I cannot
>>> understand what the above Perl code does.
>>
>> I've no idea either. Maybe something like whatever it is this program
>> does?
>>
>> (defun pprint-flet (stream list &rest noise)
>
> No, I don't think so. Clearly this pprints a flet form :-)
>
>> (declare (ignore noise))
>> (funcall (formatter
>> "~:<~^~W~^ ·@_~:<·@{~:<~^~W~^~3I ································@··@{~W~^ ~_~}~:>~^ ~_~}~:>····@···@{~W~^ ~_~}~:>")
>
> And this is a mere implementation detail :-)
I have to wonder why the author chose to funcall a formatter, though.
--
~jrm
<·············@comcast.net> wrote:
>Snide, yes. Unfair? No.
>
>Perl is the *archetype* of `write-only' languages:
>
> print((($line=join("",<>))=~s/.*\n/index($`,$&)>=$[?"":$&/ge&&$line));
>
> ($l=join("",<>))=~s/.*\n/index($`,$&)>=$[||print$&/ge;
And you don't consider the above examples to be unfair? :-)
>Call me an ignorant fool, but I really don't mind saying that I cannot
>understand what the above Perl code does.
Obviously the programs filter out duplicate lines from the input
(unlike uniq, the input doesn't need to be sorted). However, not being
able to see that immediately isn't really a sign of ignorance ;-) The
only reason anyone would write horrors like those is for obfuscation
(and they're not even particularily good obfuscations). Real code
would probably look more like
for my $line (<>) {
print $line unless $lines{$line}++;
}
or
print grep { !$l{$_}++ } <>;
Some might consider those examples to be write-only, but that would
IMHO be as unfair as the semi-frequent ignorant criticism of Lisp due
to s-exprs. Perl has a lot of semantic dirty laundry, but the syntax
isn't really a problem in production use.
Incidentally, I think that CL is the most natural upgrade path from
perl. Switching to some other scripting language (like Python or Ruby)
doesn't really buy you that much. Statically typed functional
languages are pretty much diametrically opposite to perl. And let's
face it, CL is going to appeal to a perl programmer a lot more than
Scheme. After all, perl is a Lisp-2... ;-)
--
Juho Snellman
Joe Marshall <·············@comcast.net> wrote:
>Matt Curtin <········@interhack.net> writes:
>
>> But Lisp is building material; it lets you create the language that
>> is perfect for the job at hand. If you don't approach it that way,
>> though, you're likely to see Lisp as merely another programming
>> language, albeit one with a strange group of adherents -- one that
>> seems unable to articulate why it thinks the language is so great
>> beyond making a few snide and unfair remarks about "the
>> competition."
>
>Snide, yes. Unfair? No.
>
>Perl is the *archetype* of `write-only' languages:
>
> print((($line=join("",<>))=~s/.*\n/index($`,$&)>=$[?"":$&/ge&&$line));
>
> ($l=join("",<>))=~s/.*\n/index($`,$&)>=$[||print$&/ge;
>
>Call me an ignorant fool, but I really don't mind saying that I cannot
>understand what the above Perl code does.
You can write unreadable (and unmaintainable) code in _any_ language.
Most even halfway sane languages let you write perfectly legible and
well maintainable code too[0]. I think it says a whole more about the
programmer than the language if he chooses to write unreadable code (for
work - things like Obfuscated $LANGUAGE contest don't count). I've
written a lot of Perl and most of my code bore more resemblance to clean
Pascal than to the often bemoaned "executable Perl linenoise". The
reason was simple: When I have to look at that code again in a few
months, I want to understand it quickly, not spend a few hours trying to
parse line noise.
And, coming from Perl (and doing Perl programming for a living for a few
years), I find Lisp interesting and, although I'm just starting to learn
the language, I already like it.
Regards,
Alex.
[0] Intercal doesn't count as a sane language.
--
"Opportunity is missed by most people because it is dressed in overalls and
looks like work." -- Thomas A. Edison
From: Christopher C. Stacy
Subject: Re: Reasons for preferring Lisp, and for what
Date:
Message-ID: <uhe1avyxu.fsf@dtpq.com>
>>>>> On Wed, 12 Nov 2003 07:29:45 +0100, Alexander Schreiber ("Alexander") writes:
Alexander> You can write unreadable (and unmaintainable) code in _any_ language.
Alexander> Most even halfway sane languages let you write perfectly legible
My favorite language prior to Lisp was APL, and we had the same
issues there: part of the education process was teaching people
how to write understandable and efficient code, what the standard
idioms were (and which ones to avoid), how to comment code, etc.
From: Joe Marshall
Subject: Re: Reasons for preferring Lisp, and for what
Date:
Message-ID: <brrhimsk.fsf@ccs.neu.edu>
···@usenet.thangorodrim.de (Alexander Schreiber) writes:
> You can write unreadable (and unmaintainable) code in _any_ language.
So I hear. The question is the *effort* involved.
> Most even halfway sane languages let you write perfectly legible and
> well maintainable code too[0]. I think it says a whole more about the
> programmer than the language if he chooses to write unreadable code (for
> work - things like Obfuscated $LANGUAGE contest don't count). I've
> written a lot of Perl and most of my code bore more resemblance to clean
> Pascal than to the often bemoaned "executable Perl linenoise".
Why is `executable Perl linenoise' so often bemoaned? No one talks
about `executable Basic linenoise' or `executable Java linenoise'.
Why do people pay any attention to what is said about Perl on
`comp.lang.lisp'? I certainly wouldn't give much credence to postings
about Lisp that I found on `comp.lang.perl'
Joe Marshall <···@ccs.neu.edu> wrote:
>···@usenet.thangorodrim.de (Alexander Schreiber) writes:
>
>> You can write unreadable (and unmaintainable) code in _any_ language.
>
>So I hear. The question is the *effort* involved.
It is, as always, a question of self discipline and proper training.
Writing line noise in Perl is IMHO actually more work than writing
readable code, but YMMV. The Perl equivalent of the obfuscated C contest
is an interesting intellectual challenge, but anyone writing production
code this way should be tarred, feathered and then shown the door.
>> Most even halfway sane languages let you write perfectly legible and
>> well maintainable code too[0]. I think it says a whole more about the
>> programmer than the language if he chooses to write unreadable code (for
>> work - things like Obfuscated $LANGUAGE contest don't count). I've
>> written a lot of Perl and most of my code bore more resemblance to clean
>> Pascal than to the often bemoaned "executable Perl linenoise".
>
>Why is `executable Perl linenoise' so often bemoaned? No one talks
>about `executable Basic linenoise' or `executable Java linenoise'.
Because Perl is one of the languages that gives you the power to write
programs that are small, look like linenoise and do something
meaningful. Perl is only a (power) tool and as with all tools the old
wisdom holds true: "A fool with a tool is still a fool".
Regards,
Alex.
--
"Opportunity is missed by most people because it is dressed in overalls and
looks like work." -- Thomas A. Edison
········@hotmail.com (Tuang) wrote in message news:<····························@posting.google.com>...
> I think that will turn out to be a big deal, but I'm wondering if
> there are others. Other possible candidates that come to mind are the
> ability to tackle algorithmically challenging problems. I haven't
> really seen code that demonstrates Lisp's superiority in this respect
> to other languages, but I've heard that it's true.
- Lisp is based on s-expressions, which do double work as a knowledge
representation language, not just a computational one. Notice the
very sharp divide between other languages and XML. Their users go
into paroxysms of joy when they can use a clunky mini-html tool to
spit out data, and some even talk about making XML computational
languages. Yet lisp users had this since forever, and in a much
cleaner way, with (read).
McCarthy (inventor of lisp) submitted such a communication language in
1975:
http://www-formal.stanford.edu/jmc/cbcl2/cbcl2.html
Further, Sowa's _Knowledge Representation_ lists other such languages
based on lisp s-expressions, and even seriously features that
prolog-in-lisp language.
- Lisp operates well on lists of objects, hence the name "list
processing language." If something's good enough to operate on once,
it's good enough to do many times. Notice how few languages give a
decent way to specify lists. Even those that do, really want you to
only work on one object at a time. Trees are out of the question in
those languages.
- Quote. And quasi-quote. Control which variables are evaluated and
which aren't. In fact, how many languages let you hold a variable?
You know, hold a value whose type is symbol. A java programmer
couldn't begin to understand what that even means.
- Common Lisp has great documentation. This actually tends to be an
enormous advantage that technical people always underestimate.
Documentation is not a commodity. I would like to include Scheme
documentation such as:
http://swiss.csail.mit.edu/classes/6.001/abelson-sussman-lectures/
because a lot of the lessons are directly applicable (such as how eval
works). Further, look at the online Common Lisp the Language 2, Kent
Pitman's chapter on conditions, which I just started reading myself.
Almost immediately, it candidly mentions how errors can come from
code, compilers, hardware... lisp books are almost uniformly
bullshit-free and nuanced.
- Safety. Have you ever done this in, say, Java:
System.out.println( "** Uh-oh, error!" );
System.out.println( "foo: " + foo );
System.out.println( "bar: " + foo ); //notice the bug on this line?
System.out.println( "---" );
In Python, it's worse:
f = open("quux.doc", 'w')
f.write(text)
f.close() #oops, shouldn't this stuff be in a try/finally block?
Welcome to the world of built-in functions and macros. We have data
normalization for databases, shouldn't we also have it for our
variables? Macros give you these powers, from the need to only type
things once to a built-in macro that opens and closes your files
safely without attention on your part.
If you have a language where you have no control of syntax, your only
hope is visual cues that warn you're in dangerous territory. Lisp
does far better -- it gives you the tools to create a forcefield, and
if you're a newbie, it gives you many prebuilt ones free of charge,
developed throughout lisp's long history.
- Disassemble. Find another language that has a built-in function
that lets you peek at the assembly language the compiler generates for
pieces of code you write. Nor will you find something like
macroexpand. Built-in education and safety.
- It is good to think in. Look at weblogs, especially those of
Microsoft employees. They may even be insightful, but their thoughts
are encumbered by the syntaxes of their languages, which present
barriers to creating new things. You see, other languages reactively
invented syntax based on their users' needs. When a new paradigm
comes up, the committee meets up and somehow kludges it into the
language. Lisp gives you the keys to the castle, syntactical freedom
without waiting for a committee to decide what is best for its flock.
Of course, you do not have complete control with lisp; you may wish it
were a lisp-1 like scheme; or desire performance guarantees. But just
pretend any other language didn't have something so simple as a for()
loop and you wanted it: Do you have the power to insert it into the
language?
I suspect this is why lisp always wishes to take over the entire
system. It is extremely expressive, and instead of one bug-ridden
RDBMS language plus a creaky statically-but-unsafe typed language,
lisp is a sufficient and good ground for these tasks as well.
- Many dynamic languages such as Python still make you play
whack-a-mole with finding the Right Way to express something. After
all, they fought TIMTOWDI with "There Should be One, and Preferably
Only One, Obvious Way to Do It." So you have two puzzles -- solve
your problem, and figure out how to do it in the sanctioned way.
> you're collecting them, and I'm glad I read them, but they aren't
> quite what I'm hoping to learn about Lisp.
That's fine. The questionnaire's real purpose is of a sounding board
for people to hear themselves think. And undo the hidden, arbitrary
assumptions people made to simply cope with other languages. Such as
why they support "integers," but you don't want to calculate
9999999999999999999999 ^ 999, even if your computer can easily hold
the answer.
I could go on, but I'm tired.
You got good rational answers, let me give a more personal answer.
········@hotmail.com (Tuang) wrote in message news:<····························@posting.google.com>...
> In any case, I'd be grateful if Lisp lovers could tell me what makes
> them prefer Lisp to other current languages and the circumstances in
> which they do prefer it. All the Lisp tutorials brag about garbage
> collection and built-in container data structures, which were big
> deals in the dark ages when the tutorials were written, but hardly
> argue for learning Lisp today. What makes Lisp the best *today*, and
> for what?
I am different from most lispers in that I don't write that much lisp
code (except when I make little accounting apps to relieve myself from
the minutia of life, or generate code for other languages using emacs
lisp), but I read obsessively about it and search for lispers'
opinions when it comes to things like representing knowledge or
whatever. The thing about it is I wonder if anyone can "get" lisp if
they don't feel bothered by other languages. For example, it is like
a nightmare when everyone says the word "integer" and you have this
sinking feeling because it feels you alone know what that word means.
Or maybe your thoughts shift to dreaming up IDEs that let you operate
on code as something other than strings, like a surgeon doesn't only
think in terms of molecules...
I think other languages are shared hallucinations. They want to
constantly say that programming is the sign of brilliance. So they
bend your mind to their shape. If you go their circuitous route, you
are rewarded with a possibly working program, and you feel like a
genius for the mental gymnastics.
But all this programming is actually boring. People who infect their
minds with syntax are incomplete human beings, who have given up
chunks of their lives in the pursuit of expressing things in someone
else's convoluted way. Programming exists to automate the tedious
aspects of life so you can get on with living.
Now I am free to learn domains without the worry that I do not possess
the techniques to realize my conceptions in code. Syntax requires a
lot of technique, just as some say it takes lots of technique to
perform martial arts by stringing a lot of inflexible katas together.
> All the Lisp tutorials brag about garbage
> collection and built-in container data structures, which were big
> deals in the dark ages when the tutorials were written, but hardly
> argue for learning Lisp today. What makes Lisp the best *today*, and
> for what?
GC, data containers, I don't care about these things. What I am angry
about is having to rewrite my mind to remove the braindamage of the
couple years I spent programming in other languages, like fortran
(77!), java, python, c, xml. I became dumber! It is like those
network protocols, where you send your mental program up a syntax
stack to write code and transmit it to the computer, and send it back
down when you want to decode and read it. Which is the machine, and
which is the programmer?
I could go on, on a less abstract level. I could say that I use
macros to document weird APIs (so I don't have to remember them) and
they give me another tool to tie things up neatly so I can go to other
parts of a system and not need to keep in mind all the ramifications
of each little thing. But really, the best argument for lisp is to
use another language. If you don't crave the empowering nature that
lets you get on with your life, you have found happiness elsewhere and
I wish you well.
········@hotmail.com (Tuang) writes:
> In any case, I'd be grateful if Lisp lovers could tell me what makes
> them prefer Lisp to other current languages and the circumstances in
> which they do prefer it. All the Lisp tutorials brag about garbage
> collection and built-in container data structures, which were big
> deals in the dark ages when the tutorials were written, but hardly
> argue for learning Lisp today. What makes Lisp the best *today*, and
> for what?
In synthesis, the most important thing that I like with Lisp is that
it is more abstract, more high-level language than others. All the
little features of Lisp move it toward this goal. So you really can
approach your problems without minding low level stuff like syntax or
type.
--
__Pascal_Bourguignon__
http://www.informatimago.com/
Tuang wrote:
> But it appears to me that the purpose is to enable the building of
> abstractions that, since they retain the same s-expr syntax as their
> components, can be built into yet higher-level abstractions, in a way
> that is somehow superior to the building up of abstractions by nested
> objects or just functions that call sub-functions in a procedural
> language.
>
> I haven't yet reached the point where I know how to write a macro, so
> the superiority of this Lisp style of abstraction building (over
> nested objects, for ex.) isn't yet clear to me, but I definitely
> "feel" as though there is something powerful out there, sort of
> lurking in the fog. ;-) (I started feeling this way when I saw to my
> amazement in SICP how an object system could be created with 50-60
> lines of code, and that was without CL's macros.)
If you want to get a more theoretical overview why Lisp is especially
powerful in the areas you mention, check out
http://www.paulgraham.com/rootsoflisp.html and
ftp://publications.ai.mit.edu/ai-publications/pdf/AIM-453.pdf
If you want to have a more practically oriented reading, get
http://www.paulgraham.com/onlisp.html
And remember: Nothing beats trying it out for yourself. ;)
Pascal
Tuang wrote:
> Since I'm already studying it to some extent, I'm going to venture a
> guess at one major advantage. I find the need to express every single
> idea in the same nested s-expr syntax rather tedious. If there weren't
> a higher purpose for it, I'd just drop Lisp for something with a more
> convenient syntax, like Python or Ruby.
But of course there is a "higher purpose". In fact, I'd say you have it
backwards: the need to express different kinds of code, data, and metadata
in completely different syntaxes is incredibly tedious. Let's see, there's
HTML, XML, SQL, scripting languages, numerous configuration file formats,
and of course all the various imperative/OO languages which all claim
advantages in particular areas but don't have extensible syntax so you're
stuck with what they give you.
Ultimately, when you really step back and look at the situation, you'll
realize that all these different syntaxes are little more than a
distraction - something which is supposed to provide convenience in certain
more or less specific situations, but which really end up causing more
problems than they solve. The important stuff - the semantics - lies behind
the syntax.
A good example of this is handling HTML or XML in Lisp or Scheme. There are
various libraries which allow you to represent HTML as S-expressions, and
convert back and forth between the two. If you actually use one of these
systems for a while, you'll find that they work a lot better than the
standard web template solutions like PHP, ASP, or JSP. S-expressions
combined with quasiquoting blows away anything that these syntax-heavy
template languages have yet managed to come up with. And notice the term
"template language" - for other languages, it was necessary to write special
new languages, complete with interpreters etc., in order to handle HTML and
XML. By contrast, Lisp behaves as though it was designed from the start
with the ability to embed HTML and XML, directly in the language.
Look at it this way: in other languages, to process something like XML you
need to read it into data structures - e.g. objects - and use an API to
traverse and access those objects. You can think of those objects as being
the "essence" of the XML data that you've read in - they should encapsulate
everything about the data, and they form part of the way you think about
that data. But most languages don't actually let you work with these
objects naturally and directly. The syntax for instantiating them tends to
be fussy - I haven't seen many examples of XML routinely being built using
large nested literal object instantiations, for example. In general, the
only capabilities you have for manipulating such objects, generating them,
outputting them, etc., are those that are built into the definitions for
those particular objects.
In Lisp, it's quite different. You have a syntax for instantiating any kind
of object concisely, naturally and directly: S-expressions. You have a
wealth of standard procedures to manipulate the abstract trees which these
S-expressions represent. Serializing them in their "natural" form - the
S-expression syntax - is a built-in capability, and their serialized form is
fully human-readable - in fact, it's the same form as you use to express
these objects in code.
What it all comes down to is realizing that code *is* data. You can't get
away from that - it's a simple fact. Once you fully absorb that, it makes
no sense to be writing code in a syntax that doesn't lend itself to easy
programmatic manipulation. It's not just about macros which generate
ordinary Lisp code - they're just a means to an end. It's about having a
flexible substrate in which you can embed and manipulate any structure,
directly and consistently, with a common set of powerful tools that don't
change just because you're dealing with a slightly different kind of data.
S-expressions are beautiful, in the sense of form following function. Focus
on the underlying forms, which exist whether or not you're expressing them
as S-expressions or in some other supposedly "convenient" syntax. The
underlying forms are the semantics of your data, which are much more
important - that's what users of your program will ultimately notice,
because it will have an impact on the functionality and flexibility of your
programs.
Anton
On Wed, 05 Nov 2003 03:48:52 +0000, Anton van Straaten wrote:
> The important stuff - the semantics - lies behind the syntax.
But Lisp ties the semantics to the syntax stronger than other languages.
In most languages the syntax is just the surface view of the program.
The semantics is independent from a particular way to present the code.
It's easy to port a written algorithm to a different language if only
it provides all the semantic means from the source language used in it.
The running program has no traces of the syntax.
Since the syntax is not an intrinsic part of the semantics, but maps to
the semantics in one direction, after you are familiar with the language
you can see through the syntax and your mind operates on the semantic
entities being denoted. The semantics is free from the syntax it was
expressed with.
The syntax is being designed with less constraints: it must be aesthetic,
concise and unambiguous, but it doesn't have to map to language objects in
an obvious way. It can use shortcuts, infix delimiters, different kinds of
parentheses, and it only affects the surface view of the program - once
you see through the syntax, the meaning is as language-independent as the
semantic entities are.
OTOH in Lisp the syntax is an intrinsic part of the language. Both in
the sense of the mapping from the sequence of characters to an abstract
tree and in the interpretation of the tree. The program manipulates the
syntax of its host language in macros, read and eval. The interpreter /
compiler becomes a part of the language, the stages of writing the program
and running the program are blurred.
You can't port a program which uses these features to a different language
without writing a Lisp interpreter. Of course you would say "why would I
want to port it?", and I answer: I also mean psychological porting - I
like to think about a program in more abstract terms, independently of the
language it's written in. The semantics should be clear and elegant, free
from syntactic peculiarities of a heavy language.
I don't believe in a single dialect of some language to be the ultimate
mean of expressing everything - it's narrowing the horizon and becoming
a slave of the language. I want many small cooperating programs which
integrate well with the environment, each written in the language most
appropriate for the task. Trying to force everybody to use a single
language will fail.
> What it all comes down to is realizing that code *is* data. You can't get
> away from that - it's a simple fact. Once you fully absorb that, it makes
> no sense to be writing code in a syntax that doesn't lend itself to easy
> programmatic manipulation.
False conclusion. You confuse writing the program and running the program.
I prefer to make the syntax easier to write by hand than to make it easier
to manipulate programmatically, because much more often I write one-stage
code than I write code which generates other code.
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Marcin 'Qrczak' Kowalczyk wrote:
> On Wed, 05 Nov 2003 03:48:52 +0000, Anton van Straaten wrote:
>
> > The important stuff - the semantics - lies behind the syntax.
>
> But Lisp ties the semantics to the syntax stronger than other languages.
This is only because, to do the things that Lisp & Scheme can do, it is
necessary for the language semantics to have a bidirectional relationship
with its own syntax, unlike the unidirectional relationship which most
languages have. Severing this link doesn't give other languages an
advantage - it's a simple loss of functionality.
> OTOH in Lisp the syntax is an intrinsic part of the language. Both in
> the sense of the mapping from the sequence of characters to an abstract
> tree and in the interpretation of the tree. The program manipulates the
> syntax of its host language in macros, read and eval. The interpreter /
> compiler becomes a part of the language, the stages of writing the program
> and running the program are blurred.
>
> You can't port a program which uses these features to a different language
> without writing a Lisp interpreter.
Again, that's a lack in the other languages, and one which leads directly to
Greenspun's Tenth Rule. The things that Lisp does are things that many
programs need to be able to do, and without it, they have to implement those
capabilities.
> Of course you would say "why would I
> want to port it?", and I answer: I also mean psychological porting - I
> like to think about a program in more abstract terms, independently of the
> language it's written in. The semantics should be clear and elegant, free
> from syntactic peculiarities of a heavy language.
That's why I use Scheme. :)
> I don't believe in a single dialect of some language to be the ultimate
> mean of expressing everything - it's narrowing the horizon and becoming
> a slave of the language. I want many small cooperating programs which
> integrate well with the environment, each written in the language most
> appropriate for the task. Trying to force everybody to use a single
> language will fail.
I agree with the latter sentence. However, the situation we have today is
many poor, underspecified languages which *claim* to be appropriate to a
task. Close examination and experience reveals that most of these languages
are only superficially appropriate to their tasks, and by focusing too
narrowly on that task, they "lose big" in other ways.
Even the typed functional languages, which tend to be syntax-heavy, have a
"domain-specific" syntax, where the domain in question is essentially a
mathematical one with a heavy emphasis on manipulating types (note the
inextricably close syntactic/semantic link here). It turns out that this
syntax isn't completely general-purpose, as evidenced by things like the
example given in a recent (cross-)post, about a Haskell implementation which
generates Haskell code as part of its implementation. This is necessary
because these languages lack a facility for syntactic abstraction.
Haskell is interesting because of all the typed functional languages, it has
tried harder (through the efforts of people such as Paul Hudak) to address
the question of developing domain-specific languages. Since Haskell lacks a
syntactic abstraction capability, DSLs in Haskell must be implemented in
terms of features such as monads, supercombinators, and the like. In some
cases, these efforts are quite impressive. But they ultimately run into the
hard limit of lack of syntactic abstraction, and end up with strange warts
in DSL syntax which, to be understood, require a deep knowledge of the
underlying language and how the DSL is implemented - or alternatively, the
memorization of seemingly arbitrary syntax rules.
The only way to fix such things is to develop a new syntax and create a new,
independent language to handle it, with its own interpreter or compiler. A
semantic gap is created between the new language and the original host
language. There's no reason for this gap, other than the fact that the host
language was insufficiently expressive to express the target language.
And yes, I said "insufficiently expressive". Macros are demonstrably
associated with expressiveness, in the sense that they provide a capability
which can only otherwise be obtained by a global transformation of a
program[1]. Languages without macros only avoid this issue by major
workarounds such as the one described in the last paragraph.
> > What it all comes down to is realizing that code *is* data. You can't
get
> > away from that - it's a simple fact. Once you fully absorb that, it
makes
> > no sense to be writing code in a syntax that doesn't lend itself to easy
> > programmatic manipulation.
>
> False conclusion. You confuse writing the program and running the program.
You fail to see the deep connection between these two activities.
Certainly, they are separate. But they are also connected - in *both*
directions, syntax <-> semantics. Every program generator and template
language ever written is hard evidence of this. But most languages only
offer one direction, syntax -> semantics. This is simply a bug, or at the
very least, an important missing feature.
Put another way, most languages implement essentially a single formal
system. The typed functional languages, with their sophisticated
definitions, can quite easily be compared to the definitions of formal
languages such as those dealt with in mathematical logic. In fact, these
languages were inspired by mathematical logic, e.g. lambda calculus. But
for the most part, other than meta-mathematical work such as Godel's, these
formal systems don't much care about the world outside a particular system -
they have no way to deal with it, nor do they need to, for the purposes in
question.
The same is not true of programming languages. Programming involves dealing
with what amounts to many semantically distinct systems. You could argue
that each such system requires its own syntax, but it really isn't clear why
that should be the case. Even if it is the case, on what basis do you
choose the syntax for a particular system? Perhaps based on popularity -
for example, we've collectively apparently chosen XML and HTML as the syntax
of choice for large classes of problem. Except that it turns out it's much
easier to process that data when expressed in Lisp syntax, with Lisp
semantics. So remind me again of the advantages of a new syntax for every
task?
> I prefer to make the syntax easier to write by hand than to make it easier
> to manipulate programmatically
The only reason that Lisp syntax is not easier to write by hand is your own
choice of what you become familiar with. How many lines of Lisp code have
you written? I've written code in many languages, and rarely have I come
across a syntax that I couldn't become familiar and comfortable with. APL
springs to mind as one of the few which I never achieved a comfort level.
Lisp is not any harder to "write by hand" (or more realistically, with an
editor).
> Because much more often I write one-stage
> code than I write code which generates other code.
Are you sure that's not just because the language you're using doesn't give
you a choice?
Anton
[1] http://www.ai.mit.edu/~gregs/ll1-discuss-archive-html/msg02197.html
Marcin 'Qrczak' Kowalczyk wrote:
> You can't port a program which uses these features to a different language
> without writing a Lisp interpreter. Of course you would say "why would I
> want to port it?", and I answer: I also mean psychological porting - I
> like to think about a program in more abstract terms, independently of the
> language it's written in.
But that's the thing. That is where your persuasive argument falls down.
Syntax does not have to be something different than the semantics; you
can also come up with a syntax which can represent abstractions in
analogous form. Lisp code conforms to the abstraction. Nothing is
getting bent into some imagined "Lisp syntax". Lisp does atoms, lists
and trees, just like Reality.
kenny
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
The lisp syntax is completely mutable if you can be bothered, the language
even makes it really pathetically easy to make new syntax because you CAN
mess with the reader, use macros and manipulate symbols as first-class
objects - look at the "loop" macro, for god's sake!
But for some reason, after people have learnt how to produce their own
crazeee syntaxes, most seem to realise that it's clearer if you just stick
to ordinary sexps for the most part, and only use special syntax in special
circumstances.
> False conclusion. You confuse writing the program and running the program.
> I prefer to make the syntax easier to write by hand than to make it easier
> to manipulate programmatically, because much more often I write one-stage
> code than I write code which generates other code.
>
Well, that's you. No-one's holding a gun to your head to make you use lisp,
anyway. Well, maybe they are, I can't see you. But I very much doubt it.
It's not like you can't decide to maintain a rigid writing/running
distinction if you want to just because you don't have to do so. Do you
feel obliged to spill coffee in your lap because a container doesn't say
not to? I don't think "confusing" writing and running is the right term -
turn it around, you're creating a false dichotomy between the two.
But anyway, I've NEVER (even before I knew lisp) seen what's "easier" about
the convoluted syntaxes in other computer languages. As far as I'm
concerned, a major thing that keeps me using sexps is the fact the syntax
IS trivially easy to write by hand and understand - No annoying mix of
infix and prefix (or very little, and introduced in a controlled fashion),
no remembering stupid precedence rules that always seem to vary from
language to language as they "fix" the perceived "deficiencies" of
eachother, and very little line noise characters (though Common Lisp is
"worse" than most lisps in that respect), and definitely no sodding
whitespace sensitivity.
Convoluted, baroque syntaxes just get in the way. Learning
yet-another-mixed-mainly-prefix-partially-infix-syntax (they all differ)
just seems pointless mental masturbation at best and an annoying chore at
worst after you've seen a few of them, you waste time learning intricate
syntax when you could be learning relevant APIs instead.
But hey, I may be more comfortable with prefix as it's the standard verb
order in my second natural language (Irish) (though I doubt it really,
because I like forth too...)
On Wed, 05 Nov 2003 14:22:43 +0000, David Golden wrote:
> The lisp syntax is completely mutable if you can be bothered, the language
> even makes it really pathetically easy to make new syntax because you CAN
> mess with the reader, use macros and manipulate symbols as first-class
> objects - look at the "loop" macro, for god's sake!
>
> But for some reason, after people have learnt how to produce their own
> crazeee syntaxes, most seem to realise that it's clearer if you just stick
> to ordinary sexps for the most part, and only use special syntax in special
> circumstances.
Maybe there are other reasons, e.g. that the syntax can't be mutated on
the lexical level in a modular way (what if different packages try to make
conflicting readtable changes?), or that significant syntax changes can't
be integrated well with the rest of the language (explicit entering into
a different syntax region and escaping to standard Lisp is acceptable only
in some cases), or that using a standard syntax for the language is more
important than its technical features, or that changing fundamental aspects
of the syntax is too hard, or that if you change the syntax too much then
other macros and eval break.
> It's not like you can't decide to maintain a rigid writing/running
> distinction if you want to just because you don't have to do so. Do you
> feel obliged to spill coffee in your lap because a container doesn't say
> not to? I don't think "confusing" writing and running is the right term -
> turn it around, you're creating a false dichotomy between the two.
When I produce a standalone executable, it does matter which side effects
are intended to happen during compilation and which happen when the
program is run. CL and some others Lisps/Schemes have eval-when (or have a
limited macro system where you can't use your own functions inside macros,
or can't be really compiled).
> But anyway, I've NEVER (even before I knew lisp) seen what's "easier"
> about the convoluted syntaxes in other computer languages.
They require much less parens, and many are less verbose.
I don't count several factors which are purely a matter of taste.
The surface syntax of Lisp is quite simple but it must still be
interpreted - the parens have different roles in different macros.
The complexity doesn't disappear, it's shifted to a different place.
Few languages have as many variants of let / let* / labels / flet / defvar
/ defparameter / defconstant / defun / set / setf / setq as CL. Usually
three syntactic constructs are enough: one for introducing variables, one
for introducing functions, and one for rebinding - the same for global and
local scope.
> Learning yet-another-mixed-mainly-prefix-partially-infix-syntax (they
> all differ) just seems pointless mental masturbation at best and an
> annoying chore at worst after you've seen a few of them, you waste time
> learning intricate syntax when you could be learning relevant APIs
> instead.
The same can be said about different Lisp or Scheme dialects (except the
"infix" part). You can't expect every language to look the same.
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Tuang wrote:
> I'd like to know why they prefer it to
> other current languages (for the types of work where they do prefer
> it) in order to determine the extent to which those reasons might
> apply to me.
It is said that one cannot understand the true meaning of the Koran without
being able to read it in its original language. Similarly, it is said that
one cannot truely appreciate a Zen koan that has been translated.
Similarly, Lisp is the only language that the true meaning and appreciation
of programming can shine through. All other languages are like a cloudy
piece of weathered plexiglass when compared with Lisp's crystal clarity.
That is why it is the destination towards which all other languages move
and it is the reason why I use it.
faa
On Wed, 05 Nov 2003 14:29:14 -0800, Frank A. Adrian wrote:
> Similarly, Lisp is the only language that the true meaning and appreciation
> of programming can shine through.
Which Lisp dialect? :-)
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Marcin 'Qrczak' Kowalczyk wrote:
> On Wed, 05 Nov 2003 14:29:14 -0800, Frank A. Adrian wrote:
>
>> Similarly, Lisp is the only language that the true meaning and
>> appreciation of programming can shine through.
>
> Which Lisp dialect? :-)
>
All of them, yet none. Such is the buddha^h^h^hlambda nature.
David Golden <············@oceanfree.net> writes:
> Marcin 'Qrczak' Kowalczyk wrote:
>
> > On Wed, 05 Nov 2003 14:29:14 -0800, Frank A. Adrian wrote:
> >
> >> Similarly, Lisp is the only language that the true meaning and
> >> appreciation of programming can shine through.
> >
> > Which Lisp dialect? :-)
> >
>
>
> All of them, yet none. Such is the buddha^h^h^hlambda nature.
Ah! The budlambda nature!
(Use control-W to delete a whole word ;-).
--
__Pascal_Bourguignon__
http://www.informatimago.com/
Pascal Bourguignon wrote:
> Ah! The budlambda nature!
Hey! Bud "Zen" Lambda was a great guy - always had an anwer for everything
(except when he didn't)! Knew the secrets of the universe, that guy did...
faa
Pascal Bourguignon wrote:
>> All of them, yet none. Such is the buddha^h^h^hlambda nature.
>
> Ah! The budlambda nature!
>
> (Use control-W to delete a whole word ;-).
>
>
Yeah. normally I'm good about that. This time,
the reason I made the mistake of ^h^h^h is because I had written
zen^h^h^hlambda, but I decided buddha/lambda was a more appropriate
correspondence, changed zen to buddha, and failed to update my ^h count.
David Golden <············@oceanfree.net> writes:
> Pascal Bourguignon wrote:
>
> >> All of them, yet none. Such is the buddha^h^h^hlambda nature.
> >
> > Ah! The budlambda nature!
> >
> > (Use control-W to delete a whole word ;-).
> >
> >
>
> Yeah. normally I'm good about that. This time,
> the reason I made the mistake of ^h^h^h is because I had written
> zen^h^h^hlambda, but I decided buddha/lambda was a more appropriate
> correspondence, changed zen to buddha, and failed to update my ^h count.
That's interesting, because that a quite frequente source of bugs,
either in prose or in programs... Sounds like we don't keep the data
structure we use to generate speech (that would be useless for vocal
speech).
--
__Pascal_Bourguignon__
http://www.informatimago.com/
Also illustrates the value of appropriate abstractions and
saying-what-you-mean. If I'd just used ^W for the joke, which was after all
a word replacement, in the first place, there would have been no bug in
just replacing "zen" by "buddha" - I wouldn't have left other state to
neglect to correct...
David Golden wrote:
> Marcin 'Qrczak' Kowalczyk wrote:
>
>> On Wed, 05 Nov 2003 14:29:14 -0800, Frank A. Adrian wrote:
>>
>>> Similarly, Lisp is the only language that the true meaning and
>>> appreciation of programming can shine through.
>>
>> Which Lisp dialect? :-)
>
> All of them, yet none. Such is the buddha^h^h^hlambda nature.
The joke I make every time this particular collocation
of ideas comes up:
A novice asked Steele, "Does Lisp have the Buddha-nature?"
Steele answered, "Lambda."
In that moment, the novice was enlightened.
:-)
--
Gareth McCaughan
.sig under construc
"Frank A. Adrian" <·······@ancar.org> wrote in message news:<···················@news.uswest.net>...
> Tuang wrote:
>
> > I'd like to know why they prefer it to
> > other current languages (for the types of work where they do prefer
> > it) in order to determine the extent to which those reasons might
> > apply to me.
>
> It is said that one cannot understand the true meaning of the Koran without
> being able to read it in its original language. Similarly, it is said that
> one cannot truely appreciate a Zen koan that has been translated.
>
> Similarly, Lisp is the only language that the true meaning and appreciation
> of programming can shine through. All other languages are like a cloudy
> piece of weathered plexiglass when compared with Lisp's crystal clarity.
> That is why it is the destination towards which all other languages move
> and it is the reason why I use it.
My very limited experience so far backs this up. I've learned a lot of
programming languages over the years, but Lisp (in this case meaning
both Scheme and CL and perhaps other close relatives) is the most
educational programming language I think I've ever learned. Lisp is
already the best language I've ever encountered for teaching me how to
think about a programming problem.
On Wed, 05 Nov 2003 14:29:14 -0800, "Frank A. Adrian"
<·······@ancar.org> wrote:
>Similarly, Lisp is the only language that the true meaning and appreciation
>of programming can shine through. All other languages are like a cloudy
>piece of weathered plexiglass when compared with Lisp's crystal clarity.
There's some truth in this; there's an important sense in which Lisp
(not specifically Common Lisp, but the core concepts thereof) is the
canonical form, and all other high-level languages [1] must be either
syntactic sugar for Lisp or failed attempts thereof [2].
[1] That excludes C and Fortran - they're designed to do something
else, and are pretty good at that.
[2] Javascript, oddly enough, is from what little I've seen of it the
best the world has ever produced in that regard. It's a damn shame
it's not implemented so as to be usable for anything other than banner
ads. In my more cynical moments I sometimes think our industry has an
unwritten agreement to botch everything it creates lest the gods
become jealous.
--
"Sore wa himitsu desu."
To reply by email, remove
the small snack from address.
http://www.esatclear.ie/~rwallace
················@eircom.net (Russell Wallace) wrote in message news:<·················@news.eircom.net>...
> In my more cynical moments I sometimes think our industry has an
> unwritten agreement to botch everything it creates lest the gods
> become jealous.
Or lest programming be seen for what it should be - something that
requires far fewer programmers, and much less time than is usual on
projects using broken languages. Couldn't have that, 'cause then lots
of programmers would be out of a job.
·······@mediaone.net (Raffael Cavallaro) writes:
> Or lest programming be seen for what it should be - something that
> requires far fewer programmers, and much less time than is usual on
> projects using broken languages. Couldn't have that, 'cause then lots
> of programmers would be out of a job.
Or the programmers would make really useful programs and hordes
of white-collar workers would be out of a job because they
suddenly had tools that worked ;-)
--
(espen)
From: Ray Dillinger
Subject: Re: Reasons for preferring Lisp, and for what
Date:
Message-ID: <3FABD6B7.7C7D537A@sonic.net>
Espen Vestre wrote:
>
> ·······@mediaone.net (Raffael Cavallaro) writes:
>
> > Or lest programming be seen for what it should be - something that
> > requires far fewer programmers, and much less time than is usual on
> > projects using broken languages. Couldn't have that, 'cause then lots
> > of programmers would be out of a job.
>
> Or the programmers would make really useful programs and hordes
> of white-collar workers would be out of a job because they
> suddenly had tools that worked ;-)
More to the point, because their bosses had tools that worked?
It seems reasonable, but it will never happen. Middle Management
seems redundant to engineers, but it isn't really. Top management
makes business decisions; they are indispensable. Engineers (or
line workers or farm hands or whatever the "end effectors" of your
company happen to be) create the products; they are indispensable.
And sales people sell the products - in most businesses, they are
also indispensable. Though some government contractors and other
monopolists have done okay without them, or without much of them,
most companies can't.
Now, if you regard the job of middle management as handling
complexity and lower-level planning, then they could clearly be
done away with if top management had better tools. But that is
not their job. Middle management is there to handhold the sales
people and engineers and make sure they understand what's needed
and keep them motivated and make it so they can work together
even with personality conflicts. Middle management is there
to give top management familiar faces and sounding boards to
work with problems on. Middle management, in short, is not about
process and managing complexity. It's about people and managing
feelings. And to the extent that the engineers, sales people,
and top management are humans with human emotions and quirks,
you need middle management to help deal with them.
The biggest problem arises when middle management are confronted
with people who are professional, self-organizing, self-starting,
dedicated, have a wide understanding of the company and its goals,
and are productive. Such people make middle management visibly
redundant, causing a conflict of interests. In such a case it
would be good for the company to get rid of the middle manager,
but the middle manager can avert this personal disaster by getting
rid of employees that are too good.
Engineers with better tools (like LISP) do not threaten middle
management, as such; it simply implies that in the future the
ratio of sales people to engineers must be increased, and
middle management, if it is shared between the two, doesn't
really care as long as there are enough employees to sustain
it. Moreover, sales people tend to require more management
than engineers. But if particular entities of middle
management are tied to engineering or sales and can't readily
move from one to the other, then you have a conflict of
interests in that better tools will make the empires of the
ones tied to engineering shrink while making the empires of
the ones tied to sales expand.
Bear
Ray Dillinger <····@sonic.net> writes:
> and are productive. Such people make middle management visibly
> redundant, causing a conflict of interests. In such a case it
> would be good for the company to get rid of the middle manager,
> but the middle manager can avert this personal disaster by getting
> rid of employees that are too good.
You're right of course. As soon as middle management reaches a
critical mass, it turns into a black hole, sucking up and destroying
any signs of creativity below and above them :-) It seems inevitable
that mid-sized to big companies always create these black holes, but
some corporations seem to be quite clever at organizing themselves in
ways carefully constructed to avoid this, e.g. by deliberately keeping
their research labs small and at a significant physical distance from
the HQ.
--
(espen)
················@eircom.net (Russell Wallace) wrote in message news:<·················@news.eircom.net>...
>
.....
>
> [2] Javascript, oddly enough, is from what little I've seen of it the
> best the world has ever produced in that regard. It's a damn shame
> it's not implemented so as to be usable for anything other than banner
> ads. In my more cynical moments I sometimes think our industry has an
> unwritten agreement to botch everything it creates lest the gods
> become jealous.
>
Well, there is Server-Side JavaScript, which has been used for much
more than
just banner ads. Too bad there is no OpenSource implementation of it
(as far as I know).
-klaus
··········@yahoo.de (Klaus Momberger) writes:
> Well, there is Server-Side JavaScript, which has been used for much
> more than just banner ads. Too bad there is no OpenSource
> implementation of it (as far as I know).
There are at least four open-source JavaScript implementations:
SpiderMonkey, Rhino (both from Netscape/Mozilla), FESI and KJS, used
in KDE and Mac OS X. At least the Mozilla stuff is used in some web
frameworks, see http://www.mozilla.org/js/projects.html. There's also
"Sun ONE Active Server Pages" (formerly ChiliSoft ASP), an ASP module
for Apache and the Sun ONE web server (formerly iPlanet) including
JScript support, but it's neither libre nor gratis.
On 07 Nov 2003 17:40:20 +0100, Henrik Motakef
<············@henrik-motakef.de> wrote:
>There are at least four open-source JavaScript implementations:
>SpiderMonkey, Rhino (both from Netscape/Mozilla), FESI and KJS, used
>in KDE and Mac OS X. At least the Mozilla stuff is used in some web
>frameworks, see http://www.mozilla.org/js/projects.html.
Ah, cool! Things have changed since last I looked then (admittedly
awhile ago); glad to see Javascript (a much better language than Java,
btw) is getting some of the recognition it deserves.
--
"Sore wa himitsu desu."
To reply by email, remove
the small snack from address.
http://www.esatclear.ie/~rwallace
················@eircom.net (Russell Wallace) writes:
> Ah, cool! Things have changed since last I looked then (admittedly
> awhile ago); glad to see Javascript (a much better language than Java,
> btw) is getting some of the recognition it deserves.
At least java has block scoping, instead of just function or global
scoping. That's a bit of syntactic sugar that's worth its weight in
gold, and without macros in JS, I can't think of a way to get its
effects without uglifying the code.
--
Alan Shutko <···@acm.org> - I am the rocks.
A victim of your vanity you see just what you want to see.