%   it should be a major goal of every conscientious being on this planet to
%   help anybody and everybody avoid Microsoft products.  I hope Franz Inc
%   denies you the opportunity to "help these people continue to avoid Unix",
%   at least without purchasing an educational site license.
%
%   incidentally, all they will need to learn under Linux is the Emacs/Lisp
%   Interface to Allegro CL.  it's trivial for a reasonably competent system
%   administrator to set up the machines so the users will fire up Emacs and
%   Emacs will fire up Allegro CL when they log in and just land them in the
%   listener, all ready to visit Lisp files and enjoy the benefits of working
%   in a _programming_ environment instead of an end-user environment.  a
%   university that has VMS systems _must_ have reasonably competent system
%   administrators, but I wouldn't bet any money on a place that used NT.

I have to disagree with you on one point.  Linux is a better end-user
environment than NT.  For people who like pretty pictures, just look
at www.kde.org and take a gander at the screen shots.  They don't do
the product justice though.

I hope to go a long way on free software.  I even hope to make money
on it!  Mostly I hope to have fun with it.  Linux is fun.  NT isn't.

--
David Steuber (ver 1.31.1b)
http://www.david-steuber.com
To reply by e-mail, replace trashcan with david.

When the long night comes, return to the end of the beginning.
--- Kosh (???? - 2261 AD) Babylon-5

% > Is Lisp a lazy man's programming language?
%
% I'm curious if you mean lazy as a pejorative term here?
%
% I remember some Ziggy cartoon, I think it was, that said something to
% the effect of "never underestimate the power of being lazy.  you can
% bet power steering wasn't invented by an exercise freak."

The Ziggy example seems to match my usage of the word lazy here.  I
have an idea that good engineers are lazy in the sense that they will
go to great lengths to find ways of doing things with as little effort
as possible.

Generating useful programs is probably one of the more difficult tasks
that a human mind may be called upon to perform.  I certainly don't
find it easy.  It makes solving problems just that much more
satisfying.  However, for really complicated problems, my brain is
just too small.  I need to break down the problem into small enough
chunks that I can deal with them.  Not only that, I must be able to
piece the chunks back together to actually solve the original problem.
This is also a task that I find to be quite difficult.

When a program editor can show me syntax errors as I type them or find
expressions for me, that makes my job easier.  I can think more about
the program than the task of code entry.  Taken to the next level, if
a programming language supports mechanisms to state expressions in a
consistent way, I don't have to worry about syntax so much.  The
closer the language can get to the domain of the problem I want to
solve, the more likely I am to solve that problem.  For many years,
C++ was THE language for me.  I imagine I have to unlearn some of what
I learned over the years to think in Lisp rather than thinking in C++
and translating into Lisp.  If the end goal is that I can be more
productive than I was with C++, then the effort will be worth while.

% > Is Lisp a more concise way of stating a program?
%
% When you put the question this way, I  become less sure.
% I've been trained that (and I do believe that) there is no single
% uniquely best way of stating something.  There are a finite number
% of strings of a given length that are valid programs in the language.
% (I suppose you could also remove those valid program that are not useful,
% but since we're not making a precise count, that doesn't matter here.)
% The result is that whatever "concise" means, there are only a finite
% number of things that can be concise in any given language.  And if you
% believe there are an infinite number of things that can be said,
% then some things are always sacrificed by any notation.
%
% Nevertheless, I think in practice Lisp is optimizd to make the
% things people typically want to say to be not very painful.  That's
% not a theoretical claim, just a practical engineering task.  I think
% Lisp is well-engineered for conciseness in practical situations.
% But if you state it in a very general way like your question above,
% I start to worry you're making a theoretical assertion, and I'm not
% so sure.

This is why I like reading your posts.  You force me to be more
precise.  I need more of that.

What I think I mean by concise is (to use a probably worthless metric)
to express a non trivial process with a small enough number of tokens
to make the code small, but not so few as to make the tokens to
complex to understand.  Take Perl.  It can very concisely describe a
way to digest a large text file.  It has the undesirable
characteristic of being a write-only language.  I find that I have a
heck of a time reading other peoples Perl.  I tend to be more verbose
than necessary.

When Lincoln gave his address at Gettysburg, PA, he followed someone
(I forget who) that gave a speech that went on for some length.
Lincoln's speech was on the order of a couple minutes.  When he sat
down afterwards, the previous fellow was reported to say that Lincoln
had said more in his short address than the fellow did in his long
winded speech.

I hope this analogy gets across my meaning in the way I intended.

% >  Is Lisp less prone to buggy code?
%
% Well, plainly there are some bugs in programs that are due to type
% mismatches.  And plainly languages that are statically typed are
% better at that.  Lisp is a grand experiment in the belief that there
% is more to programming than type errors.  There are design errors, for
% example.  And rapid prototyping (prototype -> users -> feedback ->
% new-prototype -> users -> feedback -> ...)detects them better than the
% clasical "waterfall" model. (requirements -> design spec ->
% implementation -> users) .

By less buggy, I mean code that performs as intended by the
programmer, not necessarily what was asked for by the end user who may
not have stated any clear design requirements.  In practice, I don't
have the luxury of working with any sort of functional specification.
If asked for one, I document what my code already does :-).
Sometimes, code really is the best word to describe it too :-).

One example of a bit of code I wrote where the requirement was not
complete was, "write an ISAPI filter for Microsoft's Proxy Server to
force certain URIs to be requested only by https rather than http."
This was actually a trivial filter to write (in C++ using the SDK).
Then along comes another request:  "I need some URI to be non-secure
because Java won't work otherwise."  So I had to go back and add
functionality.  The original code wasn't written to be extended, but I
managed to fit it in.  Additional requirements got thrown at the
filter.  At that point I was working on something else.  Another
programmer undertook the task of changing the code.    This other
programmer is a good engineer, but he is used to more abstraction from
the OS.  In this case, it worked to his disadvantage and I had to
revisit my code.  In the course of doing that, I discovered latent
bugs of my own creation along with additional difficulties that the
other programmer introduced.  The worst part of the experience was
working around a badly thought out design of the ISAPI interface for
filters that Microsoft had come up with.  It was possible for my
filter to send a 302 down to the client in clear text over a secure
port.  The client doesn't like that and immediately complains and
drops the connection.

That particular code I couldn't have written in anything other than C
or C++ no matter how much I wanted too.  However, it seems that a
desirable characteristic of a general purpose programming language is
to reduce the likely hood of a programmer error.

My friend at work who dislikes Lisp used to work for AT&T.  Emacs was
his editor of choice (and still is).  He had it set to a mode that
reformatted the text of a visited file so that the code matched a
convention that someone had decided upon when they added the c-mode to
Emacs.  Or perhaps it was part of a canned .emacs file.  At any rate,
it blew up a metric that AT&T used to measure bugs in new code.  That
metric was bugs per thousand lines of new code.  The simple
reformatting fooled the metricing software into thinking there were
many more lines of new code than really existed.  Once that problem
was discovered, a new metric was devised.  My friend came up with a
metric based on tokens.  That made formatting irrelevant.

Anyway, all programming languages are made up of tokens.  I might
naively wonder if Lisp code normally has fewer bugs per million tokens
than a C program.  But that would be a bad comparison if a Lisp
program and its C equivalent wildly varied in size.  I have no idea
how to normalize the numbers in any meaningful way.

Maybe declaring that wild pointers don't happen in Lisp would be a
nice .advocacy answer.  It seems quite popular in
comp.lang.java.advocacy.

--
David Steuber (ver 1.31.1b)
http://www.david-steuber.com
To reply by e-mail, replace trashcan with david.

When the long night comes, return to the end of the beginning.
--- Kosh (???? - 2261 AD) Babylon-5

% Somebody wrote a HTTP server, so I assume somebody could write a
% browser.

In my experience, this is a case where the server is easier to write
than the client.  There is no GUI to worry about.  With GUI programs,
it seems like 90% of the code is for the GUI.  No GUI should make the
program 10% of the size of a GUI program.  I'm sure this
generalization is easy to break.

I think I am pretty well sold on Lisp.  The only thing that could
derail me is not being able to do what I want in Lisp.  Java failed me
a while back because the AWT was so buggy.  I don't forgive easily.  I
haven't done anything of consequence in Java since.

Lisp has CLOS, so I can still do OOA/D/P.

--
David Steuber (ver 1.31.1b)
http://www.david-steuber.com
To reply by e-mail, replace trashcan with david.

When the long night comes, return to the end of the beginning.
--- Kosh (???? - 2261 AD) Babylon-5

% >he admits to only knowing some Emacs Lisp just well enough to
% >configure Emacs to his liking.
%
% So he uses Lisp for some completely non-AI stuff and still says such
% stupid things? Disregard him.

That isn't easy to do.  He knows the internals of C++ and Unix to an
extent I would not have thought humanly possible.  He also is very
good at architectural design and analysis.  This guy is brilliant.
However, he is not infallible.  I have been able to code some
algorithms with slightly better efficiency :-).  OTOH, he has written
compilers and implemented portions of Unix.  That is far and away more
than I have done.  He also knows a lot more about features of Emacs
than everyone else at the company.

It would be like Ptolemy arguing with Feynman.  However, he is open
minded.  But he is also human.  He doesn't like Perl just because it
has such bizarre syntax.  I can understand that.  I like/hate Perl.  I
like its power, I hate the syntax.

Anyway, the issue is decided.  Not only have I chosen to give Lisp a
solid try, I have chosen to use cmucl.  I just have to get set up for
it.  I also want to try GARNET, but I have not been successful in
obtaining it.

--
David Steuber (ver 1.31.1b)
http://www.david-steuber.com
To reply by e-mail, replace trashcan with david.

When the long night comes, return to the end of the beginning.
--- Kosh (???? - 2261 AD) Babylon-5

IQ can be raised and is partly formed by training! IQ goes down when
there is no challenge for the brain for some time so ..... IS LISP
DANGEROUS FOR OUR BRAIN?

  just because he has optimized himself for one mind-set doesn't make him
  even able to claim anything about any other mind-set for which he has
  deliberately _pessimized_ himself.  the odd thing about optimization in
  one direction is that it costs much more than it could ever gain on the
  whole, but that _one_ direction of optimization has been perceived as
  valuable enough to absorb the costs.  (I'm talking about what humans do,
  not machines.)  the result is extremely hard to optimize for something
  else, which was obviously possible _before_ going to the far end of the
  one optimization direction that was chosen.

  (I used to be a C/Unix guru, and I still get called upon to give courses
  in C and presentations on the history of Unix and Unix internals and
  such, but I had gotten bored, and C++ appeared to be the future at the
  time, so I _had_ to find something else.  I had programmed toys in Lisp
  on and off since late seventies, so CMUCL became the savior of my sanity,
  and I spent three years studying and working with it before I felt I was
  sufficiently competent to write Common Lisp applications for commercial
  clients.  so I made living writing articles for newspapers and computer
  magazines, instead.  I don't know anybody who doesn't think this was a
  high prize to pay to change course, but life is too long to want to be an
  expert in C++.)

This is true for every language that I've used, so perhaps it says
something about the kind of code I write! YMMV, but I find that an editor
that does little more than matching of parens is good enough for me.
Curiously, most non-Lisp editors fail to do this.

Note: if you can write less code, then you have less code to check. No
editor will help you do this. No app wizard will, either. The best they
can do is generate some of the code for you. You still need to edit it.

You can get a version of Garnet for CMUCL at www.cons.org in the ports
directory.  It includes several patches and fixes not available in the
"stock" version of Garnet.

  Lisp is both more challenging and more rewarding than doing complex
  menial labor, which is what C/C++ is about.  aim for supreme elegance
  _and_ total efficiency at the same time, and your brain should have
  plenty to work on.  :)

Performance today is not too meaningful, as it looks like the Guile
people intend to eventually replace the SCM core with a bytecoded design.
Check the archives for the Guile mailing list for details. Meanwhile, how
fast does a script engine need to be?

  uh, I'm not sure we disagree, because your statement is not qualitatively
  comparable to the statements "Linux is a programming environment" and "NT
  is an end-user environment".  I was _not_ comparing the two, I was only
  pointing out what they are best at, almost, but not explicitly, to the
  exclusion of (focus on) the other.  I don't know any actual end-users for
  whom NT is the best choice, myself, and all the people I know who say
  they think NT is best for end-users don't know any particular person for
  which this even _might_ be true, either, but it _has_ been optimized for
  _some_ concept of "end-user", and Linux continues to be optimal for
  programmers or at least end-users-who-aren't-afraid-of-programmers.

| I hope to go a long way on free software.  I even hope to make money
| on it!  Mostly I hope to have fun with it.  Linux is fun.  NT isn't.

  I honestly think you should forget making money on free software, and
  regard it as luck if it happens.  the very concept is basically flawed:
  masses of people will never pay for support, but they _will_ pay more for
  upgrades than for the original product, which might as well come for
  free.  quality software does not sell in volumes, and free software is
  generally high quality software.

  instead, aim for making the software you write for commercial clients
  free after a certain period.  my clients have accepted that general-
  purpose components that I build half on their time and half on my own
  time to get the desired functionality for their use, may be re-used and
  publicly released as I see fit, but no sooner than six months after the
  system has stabilized.

But many other schemes can also be compiled from C source on all
"decent" platforms.  I think RScheme, STk, Elk are all compiled from C
source.  I think they all have wrappers for system libraries too.
I'm sure there are others.

    Klaus> wrappers over system libraries. GNU people only produce the best possible
    Klaus> software, unlike non-GNU people.

Is that why CMUCL (non-GNU, from CMU folks) is the best open source
Lisp around?  Certainly beats gcl.

I've done reasonable amounts of programming (i.e. more than one or two toy
programs) in BASIC, COBOL, PL/I, C, Lisp, Perl, and assemblers for PDP-8
and Z80, I've dabbled a little in Fortran, CLU, Pascal, Tcl, and perhaps
some I've forgotten, and I'm familiar with Ada and APL.  I have likes and
dislikes, but I can see the merits of the ones I don't particularly care
for (just as I wouldn't care to drive a tractor trailer, but I can
recognize that it's good for what it's designed for).  I've also seen the
insides of a number of language implementations, so I understand what it
takes to make them work well.

For instance, occasionally people assert "Lisp isn't a good language for
programming OS kernels", which is then countered with "Tell that to the
people who designed Lisp Machines."  Yes, Lisp Machines are Lisp all the
way down, but it's not portable Common Lisp.  Lisp Machine kernels have
some of the same low-level programming needs as other kernels, so they have
objects that are like pointers in traditional system programming languages;
you start playing around with these and you can get yourself into some of
the same kinds of problems you run into in C.  And for performance reasons,
there are parts of the system that do manual memory management; there's a
library of functions for maintaining a "pool" of similar objects (it's used
heavily by the networking routines, to allocate and deallocate packet
buffers), and if you forget to return an object to the pool when you're
done with it you can get memory leaks, or you can get duplicates if you
return it prematurely.  Of course, the fact that these non-Lispy things are
embedded in a Lisp System does give them an advantage; for instance, if
you're using a pool object in such a way that it should be freed when you
return from the function, there's a WITH-xxx macro that allocates an object
from the pool and guarantees to return it when done (this prevents the
leak, but duplication is still possible if you were wrong about the object
not needing to live beyond that dynamic extent).  What this indicates is
that low-level programming often requires certain mental disciplines, which
happen to be similar to the requirements for facility in languages like C
and PL/I; that's one reason why those languages are popular for such tasks.

It was called EEL -- Epsilon Extension Language.  In fact, I just searched
for this at Altavista, and found that the product still exists, now for
Windows of course.  See <http://www.lugaru.com/extensible.html> for their
marketing blurb on EEL.  There's also a page there describing the
history/evolution of Epsilon -- it's eerily similar to the evolution of GNU
Emacs, although different features appeared at different times (e.g. the
Epsilon equivalent of ange-FTP just appeared in the latest release).

i agree ambiguity is an immesnely important aspect of language, to the
point where i think scheme in its zeal to be minimalist loses some
important "opportunities" for ambiguity by defining them to be bad.

[e.g., the whole designator concept costs very little to implement and
execute, and it saves a great deal of explicit coercion.  it can be
trivially optimized if the performance impact turns out to matter by
just doing either type inferencing or declaration processing.  it
causes a modest implementor burden and consolidates certain coercion
all in one place (perhaps even shrinking code size because of the lack
of explicit coercion) rather than distributing it.]

so don't count me in the anti-ambiguity camp, regardless of how the
ambiguity of my "forcing" anyone to be unambiguous makes  it look.