can lisp do what perl does easily?

2983 views
Skip to first unread message

; ; ; h e l m e r . . .

unread,
Mar 27, 2000, 3:00:00 AM3/27/00
to
I have been slowly learning lisp over the past year and have had someone
mention to me that I should learn perl, for jobs etc.

If I learn lisp well will I be able to do what people do with perl, I
know that we are not exactly comparing apples to apples since perl is a
'scripting' language. My hear is really in to lisp, looking for lispers'
opinions.

--
; ; ; h e l m e r . . .


Sent via Deja.com http://www.deja.com/
Before you buy.

Joe Marshall

unread,
Mar 27, 2000, 3:00:00 AM3/27/00
to
; ; ; h e l m e r . . . <assem...@t-three.com> writes:

> I have been slowly learning lisp over the past year and have had someone
> mention to me that I should learn perl, for jobs etc.
>
> If I learn lisp well will I be able to do what people do with perl, I
> know that we are not exactly comparing apples to apples since perl is a
> 'scripting' language. My hear is really in to lisp, looking for lispers'
> opinions.

Depends on what you want to do with your life. The largest
`advantage' that Perl has over Lisp is the huge amount of CGI scripts
written in Perl. If you want to write and maintain scripts, it is
unlikely that you will find many written in Lisp, and if you write
scripts in Lisp, you may find it hard to get people to adopt them.

Of course, if you really want to make money scripting, then Visual
Basic is the way to go.

On the other hand, if you really like computers, and if you find Lisp
fun and entertaining, you will most likely find Perl (and VB) to be
rather dull, poorly thought out, and painful to use. You will find
that any program you write in Perl could have been written faster and
easier in Lisp, and if it had been, it would have actually worked.

But since you're already asking this in comp.lang.lisp, you already
know what you *want* to do, so just *do* it. Then figure out how to
get paid for it. You'll be happier.

--
~jrm


Espen Vestre

unread,
Mar 27, 2000, 3:00:00 AM3/27/00
to
Joe Marshall <jmar...@alum.mit.edu> writes:

> Depends on what you want to do with your life. The largest
> `advantage' that Perl has over Lisp is the huge amount of CGI scripts
> written in Perl. If you want to write and maintain scripts, it is
> unlikely that you will find many written in Lisp, and if you write
> scripts in Lisp, you may find it hard to get people to adopt them.

if you already know lisp (and thus already at least one other
language), it's nothing wrong with learning perl, though. Perl is
pretty impressing in its text-processing speed, and is a quite useful
tool as long as you don't start to write real programs with it.

Ignore the members of the perl-worshipping community who might say
otherwise and let perl do what it's good at: Quick (& dirty) scripting.
Perl is a good substitute for awk, sed and sh, but not lisp!

--
(espen)

Matt Curtin

unread,
Mar 27, 2000, 3:00:00 AM3/27/00
to
>>>>> On Mon, 27 Mar 2000 03:41:04 GMT,
>>>>> ; ; ; h e l m e r . . . <assem...@t-three.com> said:

h> If I learn lisp well will I be able to do what people do with
h> perl, I know that we are not exactly comparing apples to apples
h> since perl is a 'scripting' language.

That Perl has a reputation as a "scripting" language is irrelevant,
especially given the way that the Perl community defines "scripting":
essentially it's writing a program that you'll throw away. So you can
have C scripts and Perl programs. The issue is whether you're going
to put it into production or whether you're going to cobble the thing
together in your home directory, run it a time or two, and be done
with it.

The simple answer to your question is "yes". Both Common Lisp is a
very capable language. At the risk of being flamed by Perl's
detractors, I'll brave a pronouncement that Perl is also generally a
capable language.

Perl's primary advantage for many people is the huge library of
ready-to-use modules available from the Comprehensive Perl Archive
Network (CPAN). Those modules provide interfaces to just about every
sort of system you could ever imagine needing to talk to. Thus, in
many cases, the job of the Perl programmer is simply to work on The
Problem at hand, providing the logic and other glue to get everything
talking nicely.

Lisp also has a nice body of code available for inspection, but it
tends to be harder to find (because it isn't well centralized or
cataloged anywhere AFAIK), more academic, and otherwise focused on
areas about which people aren't presently highly excited. Add to that
the sorts of baggage that accompany many Lisp programs whose source is
available for inspection, and there are some serious burdens that
might provide some encouragement for new folks to look elsewhere.
Almost everything in CPAN is freely available, almost always under the
same conditions as Perl itself.

Some things that would help Lisp in its comparisons with Perl:
o A centralized archive of freely-usable code for doing real jobs,
especially things related to databases, various network protocols,
HTML generation and analysis, etc.
o A simple, standardized mechanism for handling GUIs portably. Tk is
the de facto standard for GUIs in Perl. It works reasonably well
and is highly portable. Unfortunately, a lot of people write code
that quickly turns into a mess when Tk is involved, and it tends to
be hard to debug. It'd be nice to learn something from these
lessons.
o Standardized support for text-whackage a la Perl's patterns (as
they're properly called, since they're actually regular exprssion
extensions). I know that CLISP offers regexp support, but not all
Lisps do it.
o Easier deployment. Some Lisps have solved this problem, but I
haven't seen any free Lisps that will let you build a system that
can be readily installed somewhere else. This is also a problem
for Perl, but Perl is pretty much everywhere that Unix is.

People who will defend Lisp on many of these counts will say "get a
good commercial environment". That's fine and dandy, but if I, as a
fan of Lisp, am not willing to plonk down some ridiculously huge
amount of money on a "good commercial environment", why should we
expect anyone to do that? I don't even know how much money we're
talking about here; several months ago, I mailed Franz to ask about
pricing. I never heard anything more than an auto-ACK.

I'm willing to live without support. I think the last time I used
vendor support for anything was in 1994, when I was a system
administrator on an AIX system rebuilding a filesystem for the first
time. I can't remember ever using any vendor support any other time.
CMU CL, as it turns out, fulfills my needs very well. I have only a
few gripes about it:
o motifd dies a lot on Solaris (maybe elsewhere, too, I don't know).
o I can crash the Lisp by throwing incredibly huge numbers at it. It
goes off into foreign-function-land to handle the bignums, and
exits immediately.
o I don't seem to be able to compile the code into any sort of useful
form for people who don't have CMU CL.

I will not share in the Perl-bashing that many Lispers enjoy, as Perl
that cannot be read is almost always the fault of the programmer, not
of Perl itself. People who are not familiar with the "Unix tools"
find Perl's syntax strange and annoying. Understanding sed, awk,
troff, C, shell, and friends, I can tell you that I find Perl's syntax
to be quite intuitive. Usually.

Nevertheless, Perl does some things very poorly, some of these being
things that Lisp does very well:
o Getting along with programs written in other languages. It's
obviously no big deal to talk to other programs over an inet or
af_unix socket, but if you need to use a library that's implemented
in something like C, it can be nasty. XS isn't pretty. Getting
complex data types between the C library and Perl can be painful.
o Perl's threads are broken. Period. OTOH, I don't see much talk of
threads in Lisp, either.
o There isn't a good Perl compiler that will let you dump bytecode
("parse trees", you'll hear them called in Perl circles) or object
code. This forces the compilation step at startup time, thus
introducing some latency that can be annoying if you've got a very
big program.
o Perl cannot (easily) be used interactively. One fakes it with the
debugger. This is kind of annoying, as I like to write code by
testing code snippets interactively and then adding them to my
source file as I go.

So whether Perl or Lisp will work better for you will depend on the
problem at hand and its criteria for success. If you know Lisp well,
you should be able to do essentially any job. If you know Perl well,
you should be able to do essentially any job. Each has its strengths
and weaknesses. It's your job as a programmer to use the strengths
and avoid the weaknesses.

--
Matt Curtin cmcu...@interhack.net http://www.interhack.net/people/cmcurtin/

Lieven Marchand

unread,
Mar 27, 2000, 3:00:00 AM3/27/00
to
; ; ; h e l m e r . . . <assem...@t-three.com> writes:

> If I learn lisp well will I be able to do what people do with perl, I
> know that we are not exactly comparing apples to apples since perl is a
> 'scripting' language. My hear is really in to lisp, looking for lispers'
> opinions.

You could learn both.

One of the advantages of perl is the huge CPAN archive that has a
solution to almost any problem of the kind "I need to talk to service
<foo> with protocol <bar>". Especially for one of a kind tasks I often
use a small perl script to get the data and write them out in a lisp
friendly format, and then I use CL to do the rest of the work. This
works especially fine for proof of concept things. When I see I use
one of these things regularly, I can always write an interface module
in CL.

--
Lieven Marchand <m...@bewoner.dma.be>
If there are aliens, they play Go. -- Lasker

Tom Breton

unread,
Mar 27, 2000, 3:00:00 AM3/27/00
to
; ; ; h e l m e r . . . <assem...@t-three.com> writes:

> I have been slowly learning lisp over the past year and have had someone
> mention to me that I should learn perl, for jobs etc.
>

> If I learn lisp well will I be able to do what people do with perl,

They each can do anything the other one does. It's just a question of
what sort of hoops you have to jump thru to make them do it.

WRT elegance, ease of use, and niceness to work with, ISTM Lisp is the
clear winner. From personal experience, when I write Perl, I am
constantly reminded of how much easier it would be to write Lisp.

WRT code base and cachet among employers, Perl is the winner, and let
me say that that's a little unfortunate.

WRT speed, it depends completely on which implementation you're using,
but that said, it's easier to get a fast, slim Perl than a fast, slim
Lisp IMO.

--
Tom Breton, http://world.std.com/~tob
Not using "gh" since 1997. http://world.std.com/~tob/ugh-free.html
Rethink some Lisp features, http://world.std.com/~tob/rethink-lisp/index.html

Tom Breton

unread,
Mar 27, 2000, 3:00:00 AM3/27/00
to
Matt Curtin <cmcu...@interhack.net> writes:

> >>>>> On Mon, 27 Mar 2000 03:41:04 GMT,
> >>>>> ; ; ; h e l m e r . . . <assem...@t-three.com> said:
>
> h> If I learn lisp well will I be able to do what people do with
> h> perl, I know that we are not exactly comparing apples to apples
> h> since perl is a 'scripting' language.

I agree very much with what Matt said. There are just a few tiny things.


>
> Some things that would help Lisp in its comparisons with Perl:
> o A centralized archive of freely-usable code for doing real jobs,
> especially things related to databases, various network protocols,
> HTML generation and analysis, etc.

Definitely. There are some beginnings of that, eg CLOCC and the
Codex.

[snip more good ones]

> o Standardized support for text-whackage a la Perl's patterns (as
> they're properly called, since they're actually regular exprssion
> extensions). I know that CLISP offers regexp support, but not all
> Lisps do it.

Now here's something I hope Lisp doesn't acquire. Too often, eg with
format strings, file paths, the loop facility, Lisp has forgotten its
own elegance and grabbed at some byzantine, syntax-heavy notation just
because other languages used it.

Lisp has (not part of the X3J13 standard) an alternative to regexes:
s-regexes, where instead of "^abc$" it's (sequence bol "abc" eol). I
know which one I prefer to work with.


> People who will defend Lisp on many of these counts will say "get a
> good commercial environment". That's fine and dandy, but if I, as a
> fan of Lisp, am not willing to plonk down some ridiculously huge
> amount of money on a "good commercial environment", why should we
> expect anyone to do that? I don't even know how much money we're
> talking about here; several months ago, I mailed Franz to ask about
> pricing. I never heard anything more than an auto-ACK.

On this ng, you're sure to get a few catcalls over that, so let me
pre-emptively say, you're absolutely rite.


> I will not share in the Perl-bashing that many Lispers enjoy, as Perl
> that cannot be read is almost always the fault of the programmer, not
> of Perl itself. People who are not familiar with the "Unix tools"
> find Perl's syntax strange and annoying. Understanding sed, awk,
> troff, C, shell, and friends, I can tell you that I find Perl's syntax
> to be quite intuitive. Usually.

Well, intuitive because familiar. But I'd keep the word "annoying".
Figuring out how many $'s are needed, whether you should change $ to
@, whether lists have flattened sublists, and so forth, sorry, all
that's a royal pain even if it saves typing a few characters. IMO of
course.

> o Perl cannot (easily) be used interactively. One fakes it with the
> debugger. This is kind of annoying, as I like to write code by
> testing code snippets interactively and then adding them to my
> source file as I go.

Ouch. I remember that now.

> So whether Perl or Lisp will work better for you will depend on the
> problem at hand and its criteria for success. If you know Lisp well,
> you should be able to do essentially any job. If you know Perl well,
> you should be able to do essentially any job. Each has its strengths
> and weaknesses. It's your job as a programmer to use the strengths
> and avoid the weaknesses.

--

Erik Winkels

unread,
Mar 28, 2000, 3:00:00 AM3/28/00
to
Matt Curtin <cmcu...@interhack.net> writes:

> Perl's primary advantage for many people is the huge library of
> ready-to-use modules available from the Comprehensive Perl Archive

> Network (CPAN). [...]


>
> Lisp also has a nice body of code available for inspection, but it
> tends to be harder to find (because it isn't well centralized or
> cataloged anywhere AFAIK),

There was a thread a few months ago about a CPAN for Lisp (CLAN).

See: http://www.deja.com/[ST_rn=ps]/viewthread.xp?AN=539647115&search=thread&svcclass=dnyr&ST=PS&CONTEXT=954196843.318832649&HIT_CONTEXT=954196843.318832649&HIT_NUM=0&recnum=%3c3811c3dd.6159887@judy%3e%231/1&group=comp.lang.lisp&frpage=getdoc.xp&back=clarinet

And especially: http://www.deja.com/[ST_rn=ps]/getdoc.xp?AN=539647115&search=thread&CONTEXT=954196843.318832649&HIT_CONTEXT=954196843.318832649&hitnum=1

Does anyone know whether anything came from that? Are there people
behind the scenes working on it?

Erik Naggum

unread,
Mar 28, 2000, 3:00:00 AM3/28/00
to
* ; ; ; h e l m e r . . . <assem...@t-three.com>

| I have been slowly learning lisp over the past year and have had someone
| mention to me that I should learn perl, for jobs etc.

the unemployed programmer had a problem. "I know", said the programmer,
"I'll just learn perl." the unemployed programmer now had two problems.

having a job is not unimportant, but if knowing perl is a requirement for
a particular job, consider another one before taking that one. this is
true even if you know perl very well. life is too long to be an expert
at harmful things, including such evilness as C++ and perl.

I once studied perl enough to read perl code and spot bugs in other
people's programs (but later gained the wisdom that this was not an
accomplishment -- spotting a bug in a perl program is like spotting the
dog that brought the fleas), but I don't write in it and I don't ever
plan to use it for anything (part of my new position is quality assurance
for the systems I'm inheriting responsibility for, and part of any
serious QA is removing perl code the same way you go over a dilapidated
building you inherit to remove chewing gum and duct tape and fix whatever
was kept together for real). also, very much unlike any other language I
have ever studied, perl has failed to stick to memory, a phenomenon that
has actually puzzled me, but I guess there are some things that are so
gross you just have to forget, or it'll destroy something with you. perl
is the first such thing I have known.

this is your brain. this is perl. this is your brain on perl. any
questions?

| If I learn lisp well will I be able to do what people do with perl[?]

no, you won't. however, there is a very important clue to be had from
this: what people do with perl is wrong. perl makes a whole lot of tasks
easy to do, but if you look closely, you will see that those tasks are
fundamentally braindamaged, and should never have been initiated. perl
is perhaps the best example I can think of for a theory I have on the
ills of optimization and the design choices people make. most people,
when faced with a problem, will not investigate the cause of the problem,
but will instead want to solve it because the problem is actually in the
way of something more important than figuring out why something suddenly
got in their way out of nowhere. if you are a programmer, you may reach
for perl at this point, and perl can remove your problem. happy, you go
on, but find another problem blocking your way, requiring more perl --
the perl programmer who veers off the road into the forest will get out
of his car and cut down each and every tree that blocks his progress,
then drive a few meters and repeat the whole process. whether he gets
where he wanted to go or not is immaterial -- a perl programmer will
happily keep moving forward and look busy. getting a perl programmer
back on the road is a managerial responsibility, and it can be very hard:
the perl programmer is very good at solving his own problems and assure
you that he's on the right track -- he looks like any other programmer
who is stuck, and this happens to all of us, but the perl programmer is
very different in one crucial capacity: the tool is causing the problems,
and unlike other programmers who discover the cause of the problem sooner
or later and try something else, perl is rewarding the programmer with a
very strong sense of control and accomplishment that a perl programmer
does _not_ try something else.

it's not that perl programmers are idiots, it's that the language rewards
idiotic behavior in a way that no other language or tool has ever done,
and on top of it, it punishes conscientiousness and quality craftsmanship
-- put simply: you can commit any dirty hack in a few minutes in perl,
but you can't write an elegant, maintainabale program that becomes an
asset to both you and your employer; you can make something work, but you
can't really figure out its complete set of failure modes and conditions
of failure. (how do you tell when a regexp has a false positive match?)

a person's behavior is shaped by the rewards and the punishment he has
received while not thinking about his own actions. few people habitually
engage in the introspection necessary to break out of this "social
programming" or decide to ignore the signals that other people send them,
so this is a powerful mechanism for programming the unthinking masses.
rewarding idiotic behavior and punishing smart behavior effectively
brainwashes people, destroying their value systems and their trust in
their own understanding and appreciation of the world they live in, but
if you're very good at it, you can create a new world for them in which
all of this makes sense.

to really destroy any useful concepts of how software is supposed to work
together, for instance, the best possible way is to ridicule the simple
and straightforward concepts inherent in Lisp's read and print syntax,
then ridicule the overly complex and entangled concepts in stuff like IDL
and CORBA, which does basically the same thing as Lisp's simple syntax,
and then hail the randomness of various programs that output junk data,
because you can easily massage the data into the randomness that some
other program accepts as input. instead of having syntax-driven data
sharing between programs, you have code-driven glue between programs, and
because you are brainwashed perl idiot, this is an improvement, mostly to
your job security. and once you start down this path, every move forward
is a lot cheaper than any actual improvements to the system that would
_obviate_ the need for more glue code. however, if you never start down
this path, you have a chance of making relevant and important changes.

that's why, if you learn Lisp and become a good programmer, you will
never want to do what people do with perl. as such a good programmer,
one in five managers will notice that you solve problems differently and
will want to hire you to clean up after the perl programmers he used to
be mortally afraid of firing, and you can push any language you want at
this point -- just make sure you can find more programmers he can hire
who know it and always keep your code well-documented and readable -- you
do _not_ want to make any other programming language appear as random as
perl to any manager. perl is already a "necessary evil", but still evil,
while other languages don't have the "necessary" label, so if you screw
up, it will hurt other programmers, too. this problem can always be
minimized by simply being good at what you do. few perl programmers are
actually good at anything but getting perl to solve their _immediate_
problems, so you have an incredible advantage if you're a good Lisper.

I'll concede, however, that it is very important to be able to understand
what perl programmers do. if you don't understand what they are talking
about, you won't understand what they are actually trying to accomplish
with all the incredibly braindamaged uses of hash tables and syntactic
sadomasochism, and you won't be able to see through their charades and
"just one more hack, and I'll be there" lies.

here's a simple rule to use on perl programmers. if a solution is clean
and complete, it will immediately look like a tremendous amount of work
to a perl programmer, which it will: writing code that does the right
thing in perl is incredibly arduous. this is the only positive use for
perl programmers. like a really bad horror movie, where the evil guys
have no redeeming qualities whatsoever and will hate anything beautiful
or good, a true perl programmer will have a strong emotional reaction to
any really good solution: there's no way he can improve on it with his
perl hackery, and the very existence of his expertise is threatened.

then there are good programmers who know and use perl for some tasks, but
more than anything else know when _not_ to use it. they are _very_ rare.

#:Erik

Pierre R. Mai

unread,
Mar 28, 2000, 3:00:00 AM3/28/00
to
Tom Breton <t...@world.std.com> writes:

> WRT speed, it depends completely on which implementation you're using,
> but that said, it's easier to get a fast, slim Perl than a fast, slim
> Lisp IMO.

Is it? I'd gamble that both CLISP and ECL/ECLS are probably both
faster and slimmer than a current 5.00x Perl. OTOH I haven't done any
benchmarks to back-up that claim (excluding that silly micro-bench on
start-up times), nor am I likely to do this in the near future, since
I'm not currently in the scripting language business...

Regs, Pierre.

--
Pierre Mai <pm...@acm.org> PGP and GPG keys at your nearest Keyserver
"One smaller motivation which, in part, stems from altruism is Microsoft-
bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]

Tom Breton

unread,
Mar 28, 2000, 3:00:00 AM3/28/00
to
pm...@acm.org (Pierre R. Mai) writes:

> Tom Breton <t...@world.std.com> writes:
>
> > WRT speed, it depends completely on which implementation you're using,
> > but that said, it's easier to get a fast, slim Perl than a fast, slim
> > Lisp IMO.
>
> Is it? I'd gamble that both CLISP and ECL/ECLS are probably both
> faster and slimmer than a current 5.00x Perl.

I've used both CLISP and Perl 5.00{4,5}, and it didn't seem that way
to me. Granted, I used them for very different projects, so Perl may
have had an advantage. The Perl system was much easier to find and
install. RedHat bundled it, so I basically just pushed a button.
CLISP has rpms too but they were so nonstandard I ended up just
building it from source.

Christopher Browne

unread,
Mar 28, 2000, 3:00:00 AM3/28/00
to
Centuries ago, Nostradamus foresaw a time when Erik Winkels would say:

>Does anyone know whether anything came from that? Are there people
>behind the scenes working on it?

Take a look at <http://sourceforge.net>, and search for Common Lisp.

Several projects should pop up...
--
Rules of the Evil Overlord #77. "I will design fortress hallways with
no alcoves or protruding structural supports which intruders could use
for cover in a firefight."
<http://www.eviloverlord.com/lists/overlord.html>
cbbr...@hex.net - - <http://www.hex.net/~cbbrowne/lisp.html>

Andrew K. Wolven

unread,
Mar 28, 2000, 3:00:00 AM3/28/00
to

Tom Breton wrote:

> Now here's something I hope Lisp doesn't acquire. Too often, eg with
> format strings, file paths, the loop facility, Lisp has forgotten its
> own elegance and grabbed at some byzantine, syntax-heavy notation just
> because other languages used it.

True, format string suck. (sheesh, might as well use shtml or something)
File paths seem to be an endless pain in the ass.
But loop is cool. I have gotten work done with it.

loopy,
AKW


William Deakin

unread,
Mar 28, 2000, 3:00:00 AM3/28/00
to
Tom Breton wrote:

> The Perl system was much easier to find and install. RedHat bundled it, so I
> basically just pushed a button. CLISP has rpms too but they were so nonstandard
> I ended up just building it from source.

Do you think that this a serious comparison between lisp and perl?

For example: Under Linux the Debian clisp and cmucl installations are as seamless
as the perl installation. Also the under Solaris 2.6 I experienced problems
installing perl whilst found the installation of cmucl and clisp binaries to be
straightforward.

Best Regards,

:) will


Tim Bradshaw

unread,
Mar 28, 2000, 3:00:00 AM3/28/00
to
* William Deakin wrote:

> For example: Under Linux the Debian clisp and cmucl installations are as seamless
> as the perl installation. Also the under Solaris 2.6 I experienced problems
> installing perl whilst found the installation of cmucl and clisp binaries to be
> straightforward.

Too right. I upgraded from perl 5.00mumble to perl 5.00(incf mumble),
half our perl stuff we got from CPAN just broke, and I haven't yet
found time to mend it. Version hell.

--tim


Espen Vestre

unread,
Mar 28, 2000, 3:00:00 AM3/28/00
to
Tim Bradshaw <t...@cley.com> writes:

> Too right. I upgraded from perl 5.00mumble to perl 5.00(incf mumble),
> half our perl stuff we got from CPAN just broke, and I haven't yet
> found time to mend it. Version hell.

How true. I think there are quite a lot of large websites who haven't
yet upgraded from 5.003, since the entire *language* changed in the
.004 and .005 versions. The result: Loads of cgi-scripts that start with
a #!/usr/bin/perl5.004 (or .005). Horryfying.

--
(espen)

Barry Margolin

unread,
Mar 28, 2000, 3:00:00 AM3/28/00
to
In article <31631935...@naggum.no>, Erik Naggum <er...@naggum.no> wrote:
>* ; ; ; h e l m e r . . . <assem...@t-three.com>
>| I have been slowly learning lisp over the past year and have had someone
>| mention to me that I should learn perl, for jobs etc.
>
> the unemployed programmer had a problem. "I know", said the programmer,
> "I'll just learn perl." the unemployed programmer now had two problems.
>
> having a job is not unimportant, but if knowing perl is a requirement for
> a particular job, consider another one before taking that one. this is
> true even if you know perl very well. life is too long to be an expert
> at harmful things, including such evilness as C++ and perl.

While it's easy to say that when you're talking about a "particular job", I
don't think it's right to be so cavalier about this. If you have a more
popular skill, it expands your choice of employers. If you're interested
in the web industry and know Perl, you can get a job just about anywhere.
If you know Lisp, job opportunities are much more scarce. It may be that
those jobs will be more interesting, since they're likely to be more
enlightened companies, but finding them may be difficult.

And if you have multiple skills (e.g. you know both Lisp *and* Perl) then
you have even more choice *and* your range of skills will make you more
attractive to all potential employers. Basically, I think programmers
should try to be familiar with all the popular languages. It's fine to
have a preference, but adaptability is an important strength. Being a
language or OS snob is not going to improve your life.

--
Barry Margolin, bar...@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

Fernando D. Mato Mira

unread,
Mar 28, 2000, 3:00:00 AM3/28/00
to
Barry Margolin wrote:

> have a preference, but adaptability is an important strength. Being a
> language or OS snob is not going to improve your life.

You can quit and start making movies ;)

--
Fernando D. Mato Mira
Real-Time SW Eng & Networking
Advanced Systems Engineering Division
CSEM
Jaquet-Droz 1 email: matomira AT acm DOT org
CH-2007 Neuchatel tel: +41 (32) 720-5157
Switzerland FAX: +41 (32) 720-5720

www.csem.ch www.vrai.com ligwww.epfl.ch/matomira.html


Tom Breton

unread,
Mar 28, 2000, 3:00:00 AM3/28/00
to

Have you tried series? I admit, I'm just starting to use it myself so
I can't say too much, but it seems as expressive as loop, and is nice
in other ways.

Tom Breton

unread,
Mar 28, 2000, 3:00:00 AM3/28/00
to
William Deakin <wi...@pindar.com> writes:

> Tom Breton wrote:
>
> > The Perl system was much easier to find and install. RedHat bundled it, so I
> > basically just pushed a button. CLISP has rpms too but they were so nonstandard
> > I ended up just building it from source.
>
> Do you think that this a serious comparison between lisp and perl?

Since it was a comparison of easy availability, yes.

> For example: Under Linux the Debian clisp and cmucl installations are as seamless
> as the perl installation. Also the under Solaris 2.6 I experienced problems
> installing perl whilst found the installation of cmucl and clisp binaries to be
> straightforward.

Obviously those systems' mileage varied.

David Hanley

unread,
Mar 28, 2000, 3:00:00 AM3/28/00
to

To answer tersley, yes, you can write hard-to-read
prroly structured code in lisp, too. It's just not
the only option. :)

dave


David Hanley

unread,
Mar 28, 2000, 3:00:00 AM3/28/00
to

"Andrew K. Wolven" wrote:

> Tom Breton wrote:
>
> > Now here's something I hope Lisp doesn't acquire. Too often, eg with
> > format strings, file paths, the loop facility, Lisp has forgotten its
> > own elegance and grabbed at some byzantine, syntax-heavy notation just
> > because other languages used it.
>
> True, format string suck. (sheesh, might as well use shtml or something)
> File paths seem to be an endless pain in the ass.
> But loop is cool. I have gotten work done with it.

Actually, I've considered writing a format-string generating macro, with
the idea of looking something like the following:

(format nil (format-string "employee " STRING " makes " (MONEY (places 6 2))
"per year")
emp-name emp-salary)
=> "employee jeff makes $50,000.00 per year"

Of course, there's so many ways to do the same thing. You could write a
print
function which takes an arbitrary number of strings and pastes them together,
and
Write functions like (MONEY..) to format data properly.

I opted to just learn (format..) a bit better. Thay ways others can
(hopefully)
read my code.

As for loop, well, I use it sometimes, but I usually feel ashamed afterwards.

dave


Kragen Sitaker

unread,
Mar 29, 2000, 3:00:00 AM3/29/00
to
Very interesting article, Erik. As always :)

In article <31631935...@naggum.no>, Erik Naggum <er...@naggum.no> wrote:

> also, very much unlike any other language I
> have ever studied, perl has failed to stick to memory, a phenomenon that
> has actually puzzled me, but I guess there are some things that are so
> gross you just have to forget, or it'll destroy something with you. perl
> is the first such thing I have known.

Perl is so large and complex that it makes Common Lisp, COBOL, and C++
look small and simple by comparison. Large and complex things are hard
to memorize.

I just refer to the manual a lot.

> it's not that perl programmers are idiots, it's that the language rewards
> idiotic behavior in a way that no other language or tool has ever done,
> and on top of it, it punishes conscientiousness and quality craftsmanship
> -- put simply: you can commit any dirty hack in a few minutes in perl,
> but you can't write an elegant, maintainabale program that becomes an
> asset to both you and your employer;

CGI.pm is a counterexample, IMHO.

Can you give some concrete examples of how Perl rewards idiotic
behavior and punishes conscientiousness? I must be so brainwashed that
it's not obvious to me.

> you can make something work, but you can't really figure out its
> complete set of failure modes and conditions of failure. (how do
> you tell when a regexp has a false positive match?)

This is a serious criticism, and one that I agree with to some extent.
I tend to think the power of Perl's hard-to-predict features outweigh
their difficulty of prediction.

I'd be interested to see some examples of short Perl snippets that had
subtle failure modes and a shorter (or quicker to read and write)
Common Lisp snippet that performed the same function, without the
subtle failure modes. I can think of a few --- there's one in perldoc
-f open. :)

> and once you start down this path [of stupid data formats], every


> move forward is a lot cheaper than any actual improvements to the
> system that would _obviate_ the need for more glue code. however,
> if you never start down this path, you have a chance of making
> relevant and important changes.

There are a lot of systems I talk to that have stupid data formats, and
it doesn't matter how much I want to fix them; I can't.

Perl is better than anything else I know at handling stupid data
formats reliably and effortlessly.

> few perl programmers are actually good at anything but getting perl
> to solve their _immediate_ problems, so you have an incredible
> advantage if you're a good Lisper.

I think you mean "are not actually good", not "are actually good".

Most Perl programmers are not skilled programmers. Perl makes it
possible for them to do things they couldn't have done by hand, and
makes it possible for them to do things more reliably and quickly than
they could have done them by hand. It does not turn them into
competent programmers.

Getting something useful out of Lisp requires that you be at least a
minimally competent programmer, so there are few Lisp programmers who
are not at least minimally competent.
--
<kra...@pobox.com> Kragen Sitaker <http://www.pobox.com/~kragen/>
The Internet stock bubble didn't burst on 1999-11-08. Hurrah!
<URL:http://www.pobox.com/~kragen/bubble.html>
The power didn't go out on 2000-01-01 either. :)

Tom Breton

unread,
Mar 29, 2000, 3:00:00 AM3/29/00
to
David Hanley <d...@ncgr.org> writes:

> "Andrew K. Wolven" wrote:
>
> > Tom Breton wrote:
> >
> > > Now here's something I hope Lisp doesn't acquire. Too often, eg with
> > > format strings, file paths, the loop facility, Lisp has forgotten its
> > > own elegance and grabbed at some byzantine, syntax-heavy notation just
> > > because other languages used it.
> >
> > True, format string suck. (sheesh, might as well use shtml or something)
> > File paths seem to be an endless pain in the ass.
> > But loop is cool. I have gotten work done with it.
>
> Actually, I've considered writing a format-string generating macro, with
> the idea of looking something like the following:
>
> (format nil (format-string "employee " STRING " makes " (MONEY (places 6 2))
> "per year")
> emp-name emp-salary)
> => "employee jeff makes $50,000.00 per year"

For my rtest package, whose formatting functions had to work for both
Common Lisp and Elisp, I just used the argument names directly, rather
than positionally. Since there was no case where I tried to use the
same format string on many instances of data, it worked out easily.

Christopher Browne

unread,
Mar 29, 2000, 3:00:00 AM3/29/00
to
Centuries ago, Nostradamus foresaw a time when Tom Breton would say:

>William Deakin <wi...@pindar.com> writes:
>
>> Tom Breton wrote:
>>
>> > The Perl system was much easier to find and install. RedHat bundled it, so I
>> > basically just pushed a button. CLISP has rpms too but they were so nonstandard
>> > I ended up just building it from source.
>>
>> Do you think that this a serious comparison between lisp and perl?
>
>Since it was a comparison of easy availability, yes.
>
>> For example: Under Linux the Debian clisp and cmucl installations are as seamless
>> as the perl installation. Also the under Solaris 2.6 I experienced problems
>> installing perl whilst found the installation of cmucl and clisp binaries to be
>> straightforward.
>
>Obviously those systems' mileage varied.

This parallels the performance benchmarks for "null scripts;" the net
results are not necessarily meaningful except for establishing minor
claims.

But.

It nicely establishes that it is *NOT* fair to say that Perl is
"simple" to configure and install whilst CL (whether in CLISP or CMUCL
incarnations) are "complex."

To the contrary, Perl is _rather_ hairy, and the problems that there
have occasionally been with Debian make it manifestly clear that this
is so. It is not clear that CL (in *any* incarnation) is more
"hairy;" I'd have no problem with the contention that all that's
"hairy" about it is peoples' _perceptions_ of the complexity of CL...
--
Why do scientists call it research when looking for something new?
cbbr...@hex.net- <http://www.ntlug.org/~cbbrowne/lisp.html>

William Deakin

unread,
Mar 29, 2000, 3:00:00 AM3/29/00
to
Tom Breton wrote:

> Will writes:
>
> > Tom Breton wrote:
> >
> > > The Perl system was much easier to find and install. RedHat bundled it, so I
> > > basically just pushed a button. CLISP has rpms too but they were so nonstandard
> > > I ended up just building it from source.
> >
> > Do you think that this a serious comparison between lisp and perl?
>
> Since it was a comparison of easy availability, yes.

If I understand you correctly, the only readily available source of perl and lisp is in
the RedHat RPM format. And more than this, this only includes RPM's that are bundled
with the RedHat distribution! My mistake.

Thanks for clearing this up,

:) will

William Deakin

unread,
Mar 29, 2000, 3:00:00 AM3/29/00
to
Christopher Browne wrote:

> It nicely establishes that it is *NOT* fair to say that Perl is "simple" to configure
> and install whilst CL (whether in CLISP or CMUCL incarnations) are "complex."

I disagree. I would say that to install and configure CL is infact easier in both the
cases of CLISP and CMUCL (more straightforward, robust, less sensitive to non-standard
Linux/Solaris installations [1]) that the comperable perl installation. Particularly
when Apache/modperl/perlDBI or any of the libraries/modules, required to get any
sensible work done, are factored in.

Cheers,

:) will

[1] I will not bore you with the hair pulling details of my `oh dear I've got an untidy
old C++ library in /usr/local/lib and a new C++ library in /usr/lib that caused dynamic
linking to fail' story.


William Deakin

unread,
Mar 29, 2000, 3:00:00 AM3/29/00
to
David Hanley wrote:

> To answer tersley,

I must have missed the posting from tersley. My newsreader is giving me
jip. Who he?

;) will


see.signature

unread,
Mar 29, 2000, 3:00:00 AM3/29/00
to
On Wed, 29 Mar 2000 10:00:31 GMT, William Deakin <wi...@pindar.com> wrote:

>If I understand you correctly, the only readily available source of perl and lisp is in
>the RedHat RPM format. And more than this, this only includes RPM's that are bundled
>with the RedHat distribution! My mistake.
>

Please also have a look at debian .deb files, which include perl, clisp,
cmucl, gcl, xlispstat and different scheme's.

Marc


--
------------------------------------------------------------------------------
email: marc dot hoffmann at users dot whh dot wau dot nl
------------------------------------------------------------------------------

William Deakin

unread,
Mar 29, 2000, 3:00:00 AM3/29/00
to
"see.signature" wrote:

> Will wrote:
>
> >If I understand you correctly, the only readily available source of perl and lisp is in
> >the RedHat RPM format. And more than this, this only includes RPM's that are bundled
> >with the RedHat distribution! My mistake.
>
> Please also have a look at debian .deb files, which include perl, clisp,
> cmucl, gcl, xlispstat and different scheme's.

Yes, (as my four-year-old nephew would say) I *know* that. I'm afraid you have misunderstood
what I was trying to say.

Sorry,

;) will


Andrew K. Wolven

unread,
Mar 29, 2000, 3:00:00 AM3/29/00
to

Tom Breton wrote:

>
> Have you tried series? I admit, I'm just starting to use it myself so
> I can't say too much, but it seems as expressive as loop, and is nice
> in other ways.

Direct translation of c code into lisp:
;;;Algorithm A1.6; page 36, The Nurbs Book
(defun horner2 (a n m u0 v0)
"Computes a point on a power basis surface."
(loop for i from 0 to n
with b = (make-array (1+ n))
do (let ((ith-row-of-a
(make-array (1+ m)
:displaced-to a
:displaced-index-offset (* (1+ m) i))))
(setf (aref b i)
(horner1 ith-row-of-a m v0)))
finally (return (horner1 b n u0))))

series equivalent:
(defun my-horner2 (reverse-A u v)
(flet ((b (series) (my-horner1 series v)))
(my-horner1 (#Mb reverse-A) u)))

These may be totally broken.
I am still dense with series. I will have to get back to you on this issue when
I have a chance to get back to this stuff in a few months.

That flet in the series example was giving me a compiler warning and was running
much slower than the c translation.

My goal is to take the algorithms in the book:
Have a 'C' version, (maybe NLib)
A direct lisp translation (as best I can) of the 'C' version,
And a series version.

That way I can race. (I still have a lot to learn about optimization, though)
;)

A Nurbs curve is a kind of series, why not have lisp s-expressions for math
expressions, right?

If I remember correctly series macroexpands to loop.

Loop is still a very useful macro, I think.
Do you like parenthesis or do you like lisp?

AKW


Raymond Toy

unread,
Mar 29, 2000, 3:00:00 AM3/29/00
to
>>>>> "Andrew" == Andrew K Wolven <awo...@redfernlane.org> writes:


Andrew> If I remember correctly series macroexpands to loop.

No. series macroexpands into a much lower level than that, consisting
of tagbody's, go's, etc.

Ray

Tim Moore

unread,
Mar 29, 2000, 3:00:00 AM3/29/00
to
On Wed, 29 Mar 2000, Kragen Sitaker wrote:

> Very interesting article, Erik. As always :)
>
> In article <31631935...@naggum.no>, Erik Naggum <er...@naggum.no> wrote:

> > also, very much unlike any other language I
> > have ever studied, perl has failed to stick to memory, a phenomenon that
> > has actually puzzled me, but I guess there are some things that are so
> > gross you just have to forget, or it'll destroy something with you. perl
> > is the first such thing I have known.
>

> Perl is so large and complex that it makes Common Lisp, COBOL, and C++
> look small and simple by comparison. Large and complex things are hard
> to memorize.
>
> I just refer to the manual a lot.

Me too, kind of like when I was programming in Common Lisp.

> > it's not that perl programmers are idiots, it's that the language rewards
> > idiotic behavior in a way that no other language or tool has ever done,
> > and on top of it, it punishes conscientiousness and quality craftsmanship
> > -- put simply: you can commit any dirty hack in a few minutes in perl,
> > but you can't write an elegant, maintainabale program that becomes an
> > asset to both you and your employer;
>

> CGI.pm is a counterexample, IMHO.

Or any other code by Lincoln Stein. The book "Writing Apache Modules with
Perl and C" was a complete revelation for me: it's a well written
exposition of a useful Perl module coupled with excellent examples of
well writen code in a clear style. Plus, it does a great job of
explaining the hairy inner workings of Apache.

> > you can make something work, but you can't really figure out its
> > complete set of failure modes and conditions of failure. (how do
> > you tell when a regexp has a false positive match?)
>

> This is a serious criticism, and one that I agree with to some extent.
> I tend to think the power of Perl's hard-to-predict features outweigh
> their difficulty of prediction.

It would seem to be an endemic problem with regular expression based
search in any language. Perhaps one can criticize Perl for encouraging
one to use regexps for everything.

> Perl is better than anything else I know at handling stupid data
> formats reliably and effortlessly.

As Kragen said, there's a lot of stupid data out there, for one reason
or another. For example: SQL databases. What a pain in the ass. But the
reality is that they are the only practical solution for reliable access
to huge amounts of data, and Perl's DBI module makes it very easy to get
data in and out of (e.g.) Oracle and do useful stuff with it. The fact
that I need to do this doesn't a priori mean that I'm eeking out a
miserable existance in some slime pit.

As I've gained more experience with Perl it strikes me that it resembles
Lisp in many ways, albeit Lisp as channeled by an awk script on acid.

Consider that perl has:
lists as a ubiquitous data structure
first class functions
closures
lexical and dynamic binding
(a weak form of) garbage collection
a reasonable package system
an object system that, even though it's a great big hack, is very flexible
eval
...

It all seems eerily familiar. So, even though I might rather be
programming in Lisp and do worry occasionally about my mortal soul, many
of the lessons I learned as a Lisp hacker are directly applicable in Perl.

Tim

David Hanley

unread,
Mar 29, 2000, 3:00:00 AM3/29/00
to

William Deakin wrote:

> David Hanley wrote:
>
> > To answer tersley,
>
> I must have missed the posting from tersley.

Understandable. It was incredibly short.

dave


Tom Breton

unread,
Mar 29, 2000, 3:00:00 AM3/29/00
to
kra...@dnaco.net (Kragen Sitaker) writes:

> Getting something useful out of Lisp requires that you be at least a
> minimally competent programmer, so there are few Lisp programmers who
> are not at least minimally competent.

I suggest that Elisp is a counterexample. Plenty of people who
otherwise don't program have written .emacs files.

Tom Breton

unread,
Mar 29, 2000, 3:00:00 AM3/29/00
to
William Deakin <wi...@pindar.com> writes:

> Tom Breton wrote:
>
> > Will writes:
> >
> > > Tom Breton wrote:
> > >
> > > > The Perl system was much easier to find and install. RedHat bundled it, so I
> > > > basically just pushed a button. CLISP has rpms too but they were so nonstandard
> > > > I ended up just building it from source.
> > >
> > > Do you think that this a serious comparison between lisp and perl?
> >
> > Since it was a comparison of easy availability, yes.
>

> If I understand you correctly, the only readily available source of perl and lisp is in
> the RedHat RPM format. And more than this, this only includes RPM's that are bundled
> with the RedHat distribution! My mistake.
>

> Thanks for clearing this up,

It's too bad that you need to employ sarcasm for this tiny point. I
merely pointed out that it's easier to get a good Perl. You obviously
hated hearing that, but I can't help that.

To answer your sarcasm, Redhat is the largest distributor of Linux.
Having push-button install there counts for a lot.

But this is getting more and more like a language war, so I probably
won't answer again.

Christopher Browne

unread,
Mar 30, 2000, 3:00:00 AM3/30/00
to
Centuries ago, Nostradamus foresaw a time when William Deakin would say:

>Christopher Browne wrote:
>
>> It nicely establishes that it is *NOT* fair to say that Perl is "simple" to configure
>> and install whilst CL (whether in CLISP or CMUCL incarnations) are "complex."
>
>I disagree. I would say that to install and configure CL is infact easier in both the
>cases of CLISP and CMUCL (more straightforward, robust, less sensitive to non-standard
>Linux/Solaris installations [1]) that the comperable perl installation. Particularly
>when Apache/modperl/perlDBI or any of the libraries/modules, required to get any
>sensible work done, are factored in.

Hum? Disagree?

I wrote, parsed into Lisp-like predicates:

(not (fair-p (simpler? (ease-of-install 'perl) (ease-of-install
'cl))))
:-)

You seem to think that I wrote the equivalent to:
(simpler? (ease-of-install 'perl) (ease-of-install 'cl))

Which is the exact *opposite* to what I said. That "not" in the
expression corresponds nicely to the "*NOT*" that is pretty prominent
in the sentence.
--
If you're sending someone some Styrofoam, what do you pack it in?
cbbr...@hex.net- <http://www.hex.net/~cbbrowne/lisp.html>

Mark-Jason Dominus

unread,
Mar 30, 2000, 3:00:00 AM3/30/00
to
In article <8btgtf$lnr$0...@216.39.145.192>,

Tim Moore <mo...@herschel.bricoworks.com> wrote:
>As I've gained more experience with Perl it strikes me that it resembles
>Lisp in many ways, albeit Lisp as channeled by an awk script on acid.
>
>Consider that perl has:
>lists as a ubiquitous data structure
>first class functions
>closures
>lexical and dynamic binding
>(a weak form of) garbage collection
>a reasonable package system
>an object system that, even though it's a great big hack, is very flexible
>eval
>...
>
>It all seems eerily familiar.

I have been slowly coming to the same realization myself over the past
two years.

Most Perl programmers seem to come out of the C world, but Perl is
actually much more like Lisp than it is like C. Somewhere near the
beginning of Norvig's `Paradigms of Artificial Intelligence
Programming', there is a list of the eight important and unusual
features of Lisp. Perl shares seven of these. (A few moments'
thought will reveal the identity of the eighth.)

This has an interesting implication, which is that Perl programmers
are not using Perl effectively. Very few come from a Lisp background,
and they don't know what to do with closures even though they have
them. They are going around writing C programs in Perl. This is not
as ineffective as writing C programs in Lisp, but nevertheless they
could be doing much better.

>many of the lessons I learned as a Lisp hacker are directly
>applicable in Perl.

Yes, just so! And in fact I'm presently at work on a book whose main
goal is to introduce those same lessons to Perl programmers.


Kragen Sitaker

unread,
Mar 30, 2000, 3:00:00 AM3/30/00
to
In article <m3g0t9b...@world.std.com>,

Tom Breton <t...@world.std.com> wrote:
>kra...@dnaco.net (Kragen Sitaker) writes:
>> Getting something useful out of Lisp requires that you be at least a
>> minimally competent programmer, so there are few Lisp programmers who
>> are not at least minimally competent.
>
>I suggest that Elisp is a counterexample. Plenty of people who
>otherwise don't program have written .emacs files.

Good point. I still think the rule usually holds, though.

William Deakin

unread,
Mar 30, 2000, 3:00:00 AM3/30/00
to
Christopher Browne wrote:

> Hum? Disagree?

Damn. I did not readwhat you posted correctly [1]

> Which is the exact *opposite* to what I said. That "not" in the
> expression corresponds nicely to the "*NOT*" that is pretty prominent
> in the sentence.

Another case of read the message carefully (I have a long history of failing exams by not
answering the questions). Anyway, if I had read the message correctly would say we were
`violent in agreement.'
Please accept my humble appologies,

:( will

[1] I think Fernando Mato Mira was correct yesterday, I *should* learn to read.

William Deakin

unread,
Mar 30, 2000, 3:00:00 AM3/30/00
to
Tom Breton wrote:

> It's too bad that you need to employ sarcasm for this tiny point.

Would you prefer me to make large points using sarcasm. Anyway what is wrong with sarcasm?

> I merely pointed out that it's easier to get a good Perl.

What you communicated was something `a good cl is hard to get/install, perl is easy' and I
think this is wrong. I don't think I was the only person who interpreted your postings as
this.

> You obviously hated hearing that, but I can't help that.

I didn't hate hearing that. Although it didn't fill me with raptorous joy either.

> Having push-button install there counts for a lot.

Are you serious? I would say that having a push-button install/upgrade that then breaks (in
subtle and mysterious ways, whos wonders are to behold) the existing installation and modules
does *not* count for a lot. Do you work using MS kit much? Lots of push-button installs
there.

> ...this is getting more and more like a language war, so I probablywon't answer again.

Fine. Whatever. I agree.

Best Regards,

:) will


Christopher Browne

unread,
Mar 30, 2000, 3:00:00 AM3/30/00
to
Centuries ago, Nostradamus foresaw a time when William Deakin would say:
>Christopher Browne wrote:
>
>> Hum? Disagree?
>
>Damn. I did not readwhat you posted correctly [1]

No biggie. Apparently I didn't joke enough about this; I thought that
recoding the expression in pseudo-Lisp would a clear joke, but apparently
it wasn't clear enough...

Making it clear:

Whilst there may be some *perceptions* out there that deploying CL is
"tough," there are graver challenges in deploying Perl.

In some cases (and Red Hat RPM's would be a good example of this), the
tremendous amount of effort going into Perl "packages" and the dearth
of effort going into Lisp equivalents has the result of it *appearing*
easier to deploy Perl. If the *tiniest* bit of additional effort went
into packages for CLISP or CMU-CL, the situation would very likely
reverse itself.

Perl is quite amazing in the amount of effort that it goes through to
"autoconf" itself to find a *huge* amount of information about the
system it is being installed on; that effort is fairly frightening...
--
I called that number and they said whom the Lord loveth he chasteneth.
cbbr...@hex.net - - <http://www.hex.net/~cbbrowne/lsf.html>

William Deakin

unread,
Mar 30, 2000, 3:00:00 AM3/30/00
to
Christopher Browne wrote:

> No biggie. Apparently I didn't joke enough about this; I thought that
> recoding the expression in pseudo-Lisp would a clear joke, but apparently
> it wasn't clear enough...

Doh! [I'm suffering from a sense of humour failier today involving a small
15-week old child at 2am, 4am, 6am...it was a relief to come to work today :]

Cheers,

:) will

Joe Marshall

unread,
Mar 30, 2000, 3:00:00 AM3/30/00
to

[Erik's superb rant against perl elided]

Erik gets a lot of `hate mail' for his blunt and acrid remarks, but
not enough appreciation for his insightful essays like this one.

Well said, Erik. Posts like this one are a joy to read and right on
the money.

--
~jrm

Fernando D. Mato Mira

unread,
Mar 30, 2000, 3:00:00 AM3/30/00
to
"Andrew K. Wolven" wrote:

> series equivalent:
> (defun my-horner2 (reverse-A u v)
> (flet ((b (series) (my-horner1 series v)))
> (my-horner1 (#Mb reverse-A) u)))

1. While theoreticall possible, Series does not currently support high-order series

2. Series does not currently support definition of local series functions as by
flet or labels
3. When you define an optimizable series function, you should
(declare (optimizable-series-function
as appropriate
4. How did you generate reverse-A? By (scan (reverse <some-list>)) or reversing an
array?
If you plan on transducing a series into its reversed counterpart, you'll need
buffering in between.
There's no way out.

--
Fernando D. Mato Mira
Real-Time SW Eng & Networking
Advanced Systems Engineering Division
CSEM
Jaquet-Droz 1 email: matomira AT acm DOT org
CH-2007 Neuchatel tel: +41 (32) 720-5157
Switzerland FAX: +41 (32) 720-5720

www.csem.ch www.vrai.com ligwww.epfl.ch/matomira.html


Rahul Jain

unread,
Mar 30, 2000, 3:00:00 AM3/30/00
to
In article <m3g0t9b...@world.std.com> posted on Wednesday, March

29, 2000 4:40 PM, Tom Breton <t...@world.std.com> wrote:
> kra...@dnaco.net (Kragen Sitaker) writes:
>
>> Getting something useful out of Lisp requires that you be at least a
>> minimally competent programmer, so there are few Lisp programmers who
>> are not at least minimally competent.
>
> I suggest that Elisp is a counterexample. Plenty of people who
> otherwise don't program have written .emacs files.
>

Most .emacs files I've seen are not programming at all. They are simply
multiple assignments of parameters, in order to customize the emacs
environment. Of course, a programmer's .emacs file will likely contain
numerous snippets of actual code.
Note that not all emacs users are programmers... particularly not lisp
programmers.

--
-> -\-=-=-=-=-=-=-=-=-=-/^\-=-=-=<*><*>=-=-=-/^\-=-=-=-=-=-=-=-=-=-/- <-
-> -/-=-=-=-=-=-=-=-=-=/ { Rahul -<>- Jain } \=-=-=-=-=-=-=-=-=-\- <-
-> -\- "I never could get the hang of Thursdays." - HHGTTG by DNA -/- <-
-> -/- http://photino.sid.rice.edu/ -=- mailto:rahul...@usa.net -\- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
Version 11.423.999.210020101.23.50110101.042
(c)1996-2000, All rights reserved. Disclaimer available upon request.


Kragen Sitaker

unread,
Mar 31, 2000, 3:00:00 AM3/31/00
to
In article <p6RE4.1100$75.2...@ptah.visi.com>,
David Thornley <thor...@visi.com> wrote:
>I think the problem is that there are fewer underlying principles in Perl
>than in any other language I'm familiar with. Every so often, I run into
>something that makes me think that Larry Wall's breakfast must have
>disagreed with him that day.

Perl is not designed around underlying principles, I think. Unless you
count very general principles like, "There's more than one way to do
it" and "easy things should be easy, and hard things should be possible".

>I think it could be better done. The power of the features is impressive,
>but when you're using that much power in a language like Perl you're
>not likely to feel comfortably in control. To put it another way,
>Perl isn't necessarily a bad language because of this, but it could have
>been done better.

Do you think it has been done better in Lisp?

If so, where should I read about it?

If not, how would you do it better?

>>Perl is better than anything else I know at handling stupid data
>>formats reliably and effortlessly.
>

>If they fit into Perl's idea of a regular expression, which most do.
>Common Lisp is also excellent, but that's mostly because it's excellent
>at so many things.

Not everything that can be parsed with a Perl pattern should be, even
in Perl. But Perl's patterns often do 75% of the work of handling more
complex data formats. However, they cease to be reliable or
effortless, and in these situations, occasionally, they make Erik's
criticism look mild.

Hashes are a nice help, too, as are variable interpolation in strings,
pack, unpack, and sprintf.

Kragen Sitaker

unread,
Mar 31, 2000, 3:00:00 AM3/31/00
to
In article <38e2c271.72bc$1...@news.op.net>,

Mark-Jason Dominus <m...@plover.com> wrote:
>This has an interesting implication, which is that Perl programmers
>are not using Perl effectively. Very few come from a Lisp background,
>and they don't know what to do with closures even though they have
>them.

You can't do as much with them as you can in Lisp, unfortunately. In
particular, recursive or mutually recursive closures are data
structures containing circular references, which break Perl's primitive
garbage collector.

>Yes, just so! And in fact I'm presently at work on a book whose main
>goal is to introduce those same lessons to Perl programmers.

I assure you I will purchase it the day it is released :)

Kragen Sitaker

unread,
Mar 31, 2000, 3:00:00 AM3/31/00
to
In article <slrn8e6mvo....@knuth.brownes.org>,

Christopher Browne <cbbr...@hex.net> wrote:
>Perl is quite amazing in the amount of effort that it goes through to
>"autoconf" itself to find a *huge* amount of information about the
>system it is being installed on; that effort is fairly frightening...

This has a lot to do with Perl providing, as part of the language, an
interface to nearly all of the standard Unix system calls, and quite a
number that aren't very standard, as well as some other facilities like
dbm files, dynamic module loading, gethostent(), etc.

In order to do this correctly, it must (a) figure out what libraries
things are located in; (b) figure out what facilities aren't there; (c)
figure out which variants of particular facilities are present.

It also thinks it has to compile on very primitive systems lacking
things like an ANSI C compiler, a decent shell, #! support, filenames
longer than 14 characters, or ASCII. (The Configure script mentions
PDP-11 support when it's asking you about memory models.)

There are pros and cons to this approach.

Does scsh check fewer things and support as many platforms?

Still, I'm mystified by why Configure wants to know where awk, comm,
and pg are. It points to some scary makefiles.

Thom Goodsell

unread,
Mar 31, 2000, 3:00:00 AM3/31/00
to
Rahul Jain wrote:
>
> In article <m3g0t9b...@world.std.com> posted on Wednesday, March
> 29, 2000 4:40 PM, Tom Breton <t...@world.std.com> wrote:
> > I suggest that Elisp is a counterexample. Plenty of people who
> > otherwise don't program have written .emacs files.
> >
>
> Most .emacs files I've seen are not programming at all. They are simply
> multiple assignments of parameters, in order to customize the emacs
> environment. Of course, a programmer's .emacs file will likely contain
> numerous snippets of actual code.
> Note that not all emacs users are programmers... particularly not lisp
> programmers.

Agreed. I *am* a Lisp programmer, but my .emacs file has been almost
entirely cut and pasted from other people's .emacs file. The only thing
I've done is twiddle a few settings.

Thom Goodsell

Scientist t...@cra.com
Charles River Analytics (617) 491-3474 x574
Cambridge, MA, USA http://www.cra.com/

Mark-Jason Dominus

unread,
Mar 31, 2000, 3:00:00 AM3/31/00
to
In article <l2TE4.13817$3g5.1...@tw11.nn.bcandid.com>,

Kragen Sitaker <kra...@dnaco.net> wrote:
>You can't do as much with them as you can in Lisp, unfortunately. In
>particular, recursive or mutually recursive closures are data
>structures containing circular references, which break Perl's primitive
>garbage collector.

Yes, but the crappy garbage collector has an upside. People used to
say that garbage collection was impractical and inefficient. Rather
than patiently explain to them that their notion of garbage collection
was thirty years out of date, I would just point out that Perl has an
incredibly rotten garbage collector, maybe the worst possible garbage
collector, and that it is still a gigantic success. Perl's GC is so
bad that it stands as a sort of reductio ad absurdem to arguments that
say that GC is a bad choice, because it succeeds in spite of its
immense badness. ``Look,'' I would say. ``If Perl's garbage
collection is so great, imagine how much greater it would be if it
were actually state of the art.''

This argument is not as useful as it was in the past now that I can
just point at Java. I don't particularly like Java, but it may have
the beneficial effect that people finally shut up about garbage
collection.

In the 1960s there were big language wars about recursion; people
would tell you that recursion was unnecessary (because it can always
be simulated with iterative methods) and that it is inefficient. This
is true in some sense, but totally misses the value of recursion. But
you can't explain the value of recursion to a programmer who knows
only FORTRAN; you are not going to be able to get past his ignorance.
He is going to reason that FORTRAN does not have recursion, many large
projects are implemented in Fortran, and therefore recursion is
unnecessary for large projects. With the advent of C and Pascal,
industrial and commercial programming languages finally had recursion,
and I think the result is that now if you tried to promulgate a
general-purpose programming language without recursion, you would be
laughed at, and programmers who still don't understand recursion are
considered woefully ignorant, and maybe pitiful relics of the past.

I like to think that the advent of Java has had the same effect on
garbage collection. You used to see people saying the same things
about garbage collection that they said about recursion. It isn't
necessary, it is inefficient, it is only available in ivory-tower
languages that are not suited for doing real work, blah blah blah.
Nobody is going to be able to say this any more now that we have had
Java. I would not be surprised if in twenty years garbage collection
is in the mainstream the way recursion is now, and the idea of a
GC-less general-purpose programming language is laughable.

I have a fantasy that the same thing will somehow happen to closures.
I think it's appalling that people are still promulgating
general-purpose programming languages without lexical closure and
first-class functions. One of the reasons I am writing my book is to
try to help put a stop to this.

Anyway, there is some hope that Perl might someday get a better
garbage collector. Several people are talking about it, and Brad Kuhn
told me a few months ago that some guy he knew in Cincinnati was
looking into putting in the Boehm garbarge collector. Every time
someone appears on the perl developers' list with some idea that
relies on any specific GC semantics, Sarathy warns them that they
cannot do that because Perl might someday get a better garbage
collector. Certainly a lot of people would like to see the
reference counting go away.


Tim Bradshaw

unread,
Mar 31, 2000, 3:00:00 AM3/31/00
to
* Mark-Jason Dominus wrote:
> You used to see people saying the same things
> about garbage collection that they said about recursion. It isn't
> necessary, it is inefficient, it is only available in ivory-tower
> languages that are not suited for doing real work, blah blah blah.

Surely Java is near-conclusive proof of this point?

--tim

David Hanley

unread,
Mar 31, 2000, 3:00:00 AM3/31/00
to

David Thornley wrote:

> >Perl is so large and complex that it makes Common Lisp, COBOL, and C++
> >look small and simple by comparison. Large and complex things are hard
> >to memorize.
> >

> Yup. On the flip side, you can do useful things with a small part of
> the language. I've never touched the object system (it looks like
> something I'm not going to enjoy), and have ignored several other things.
> I've written some useful stuff.

That's surely true. OTOH, a large language with lots of features means
that it may be hard to read and modify someone else's code because they
did some thing with features you are not as familiar with, or interact
in some odd way.

I think that's where CL is a big win. The library is very large, but there
are just a few underlying unfying principles. It's a lot easier to undertand
a few unfamiliar function rather than unfamilar language behavioral issues.
(not contradicting you, just elaborating my ideas on this)

dave


Jonathan Coupe

unread,
Apr 3, 2000, 3:00:00 AM4/3/00
to

Tim Bradshaw <t...@cley.com> wrote in message
news:ey3r9cr...@cley.com...

I'm not pro or anti Java (it's not suitable for the work I do yet, for sure)
but the people I've spoken to who have used it for real world projects site
memory leaks as being one of the biggest project killers. It's certainly the
first GC langugae I've seen for which people actually spend money on memory
leak detection tools. (Of course this is also be a reflection of Java's
popularlity - I've certainly used Eiffel and Lisp compilers that leaked
memory.)

Jonathan

Robert Monfera

unread,
Apr 5, 2000, 3:00:00 AM4/5/00
to

Tim Moore wrote:

> As Kragen said, there's a lot of stupid data out there, for one reason
> or another. For example: SQL databases. What a pain in the ass.

SQL has quite solid fundamentals and it should not be dismissed on the
basis of its syntax - it's quite easy to generate SQL strings from
classes or query definition objects.

Robert

Frank A. Adrian

unread,
Apr 5, 2000, 3:00:00 AM4/5/00
to

Robert Monfera <mon...@fisec.com> wrote in message
news:38EB0520...@fisec.com...
>Tim Moore wrote:

Tim was right when he said that SQL databases are a pain in the ass. And I
don't think he was referring simply to syntax issues. Yes, it's easy to
generate SQL strings (having been employed to do this in the past, I can
attest to this), but why do I even need a separate language and access
methodology? The real issue is whether the RDB model was necessary. It was
a fairly neat enhancement over hierarchical data bases and allowed more
flexible slicing of data but, at its core, the RDB model is simply a
collection of objects joined on the relations between them, with optional
data slicing and transaction control thrown in. Was the construction of a
new model along with the idea of separating the objects used this model from
all other in-memory objects really a good idea? Or would work on the VM
systems in place at the time to provide persistent object spaces with
transparently maintained, use-based indices have been better? More to the
point, would it be better now? The division in access methods and identity
between in-memory and on-disk objects makes construction of software much
more difficult than if the distinction did not exist. To make it worse, the
current implementations of the RDB model revel in pushing the users' noses
into these distinctions. I believe that Henry Baker had a really good paper
a few years back on this topic (Don't hold me to this statement, because
it's a hazy recollection with no reference at this point).

faa

Philip Lijnzaad

unread,
Apr 6, 2000, 3:00:00 AM4/6/00
to
On Wed, 5 Apr 2000 23:41:49 -0700,
"Frank" == Frank A Adrian <fad...@uswest.net> writes:

Frank> why do I even need a separate language and access methodology?

for fully general and high-level ad-hoc querying, specifying the what, not
the how. For easily working with sets of things, rather than having to spell
it all out.

Frank> The real issue is whether the RDB model was necessary.

from which point of view? Is Lisp necessary?

Frank> at its core, the RDB model is simply a collection of objects

what are your objects, rows or columns? If former, certainly not, if latter,
yes (but this view is less common)

Frank> joined on the relations between them, with optional data slicing and
Frank> transaction control thrown in.

(transactions are essential to any data managemnt, whether relational or
not)

Frank> Was the construction of a new model along with the idea of separating
Frank> the objects used this model from all other in-memory objects really a
Frank> good idea?

yes, most certainly.

Frank> Or would work on the VM systems in place at the time to provide
Frank> persistent object spaces with transparently maintained, use-based
Frank> indices have been better?

?

Frank> More to the point, would it be better now?

Probably not. Look at the rather sorry state of the OODBMS field. OODBMses
have been touted as the next silver bullet for about 15 years now. They still
are a just a very small niche, for a number of reasons.

Frank> The division in access methods and identity between in-memory and
Frank> on-disk objects makes construction of software much more difficult
Frank> than if the distinction did not exist.

yes, that's true if you're talking about one application with just a little
data. If you're talking about Gigabytes worth of complex information, chances
that this data will be needed in unforseen ways are much higher. At this
point, OO database simply become too rigid. Is there an accepted notion of
what constitutes a view in OODM? Set-level manipulations? Schema evolution?
Query language? And not wholly unimportantly, are these things available in
current implementations, in an not entirely unstandardized way?

Frank> To make it worse, the current implementations of the RDB model revel
Frank> in pushing the users' noses into these distinctions.

?

Frank> I believe that Henry Baker had a really good paper a few years back on
Frank> this topic (Don't hold me to this statement, because it's a hazy
Frank> recollection with no reference at this point).

I'd be very interested in a proper reference to this, knowning Baker's high
quality writings.

Philip
--
Not getting what you want is sometimes a wonderful stroke of luck.
-----------------------------------------------------------------------------
Philip Lijnzaad, lijn...@ebi.ac.uk | European Bioinformatics Institute,rm A2-24
+44 (0)1223 49 4639 | Wellcome Trust Genome Campus, Hinxton
+44 (0)1223 49 4468 (fax) | Cambridgeshire CB10 1SD, GREAT BRITAIN
PGP fingerprint: E1 03 BF 80 94 61 B6 FC 50 3D 1F 64 40 75 FB 53

Christopher C Stacy

unread,
Apr 6, 2000, 3:00:00 AM4/6/00
to
>>>>> On 06 Apr 2000 13:06:08 +0100, Philip Lijnzaad ("Philip") writes:

Philip> yes, that's true if you're talking about one application with just a little
Philip> data. If you're talking about Gigabytes worth of complex information, chances
Philip> that this data will be needed in unforseen ways are much higher. At this
Philip> point, OO database simply become too rigid. Is there an accepted notion of
Philip> what constitutes a view in OODM? Set-level manipulations? Schema evolution?
Philip> Query language? And not wholly unimportantly, are these things available in
Philip> current implementations, in an not entirely unstandardized way?

If you are looking for a standardized interface to a standardized model
of databases, then you should stick with RDBMS and SQL for now.
This disucssion is about (relatively) new ways of doing things, and, yes,
all the concepts and issues that you mentioned are dealt with in
object-oriented database systems. (Certainly there is nothing in RDBMS
that magically solves those problems, either, and in fact I have found,
for example, schema evolution to be fairly weak in systems such as Oracle.)
I don't know why you would characterize OODBMS as only being suitable
for small or simpl applications -- it has been successfully employed
in gigabyte databases and complex applications.

Seth Gordon

unread,
Apr 6, 2000, 3:00:00 AM4/6/00
to
"Frank A. Adrian" wrote:

> I believe that Henry Baker had a really good paper

> a few years back on this topic (Don't hold me to this statement, because
> it's a hazy recollection with no reference at this point).

"Relational Databases", a letter to the _ACM Forum,_ October 15, 1991:
ftp://ftp.netcom.com/pub/hb/hbaker/letters/CACM-RelationalDatabases.html

--
perl -le"for(@w=(q[dm='r 0rJaa,u0cksthe';dc=967150;dz=~s/d/substrdm,\
(di+=dc%2?4:1)%=16,1ordi-2?'no':'Perl h'/e whiledc>>=1;printdz]))\
{s/d/chr(36)/eg;eval;}#In Windows type this all on 1 line w/o '\'s"
== seth gordon == sgo...@kenan.com == standard disclaimer ==
== documentation group, kenan systems corp., cambridge, ma ==

Frank A. Adrian

unread,
Apr 6, 2000, 3:00:00 AM4/6/00