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 . . .

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.

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!

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.

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.

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.

[snip more good ones]

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.

See: http://www.deja.com/[ST_rn=ps]/viewthread.xp?AN=539647115&search=thread&svcclass=dnyr&ST=PS&CON TEXT=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

  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.

Regs, Pierre.

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,

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.

--
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

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

(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.

In article <3163193555464...@naggum.no>, Erik Naggum  <e...@naggum.no> wrote:

I just refer to the manual a lot.

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.

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.  :)

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

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.

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."