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.
> 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
> 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)
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/
> 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
> 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
> >>>>> 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.
--
> 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).
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?
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
> 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 <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.
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>
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
> 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
> 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
> 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)
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.
> 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
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 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.
dave
"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
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. :)
> "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.
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>
> 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
> 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.
> To answer tersley,
I must have missed the posting from tersley. My newsreader is giving me
jip. Who he?
;) will
>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
------------------------------------------------------------------------------
> 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
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
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
> 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
William Deakin wrote:
> David Hanley wrote:
>
> > To answer tersley,
>
> I must have missed the posting from tersley.
Understandable. It was incredibly short.
dave
> 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 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.
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>
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.
Good point. I still think the rule usually holds, though.
> 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.
> 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
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>
> 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
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
> 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
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.