It's about Scheme and Common Lisp. Does it make sense to learn one or
the other, or both, or just one of it?

My background: I'm an Eiffel-Programmer, and I think I know quite a bit
about C/C++ and I refuse to do programming a line of C++. So Common Lisp
seems to me a bit like C++. Is that a correct impression? Someone
compared Scheme Standard to CL standard and this was quite frightning.
Scheme comes along with around 50 pages CL with 1100 pages. So does that
means Scheme (lean and mean) CL (big and complex) but more powerful?

On other pages I read the CL is very good for prototyping and it seems
possible to add some type-checking to CL Functions. But I don't have to.
So maybe I could use CL for scritping as for larger scale programming.

I have downloaded diverse Common Lisp systems and I have the Scheme
Shell. And of course I would like to to scripting in one of the two
languages. Does it make sense to use CL for such an area or is Scheme a
better choice here?

I have started with doing some scsh-programming. And even thought I had
a hard time, the elegance of Scheme begins to shine IMO. And I have
three books around which uses Scheme so I have to admit I'm starting to
like it more and more. But a look onto CL gave let me start thinking
again. CL seems to have far more support for OO-programming and Eiffel
is an OO-languae so I migth like CL more.

It would be nice if some of you gave me your thoughts about that.

You ask an extraordinarily subjective question, but you offer enough
about yourself to answer in a way that is probably best for you.  Please
do not repeat this answer to anyone else; send them instead back to this
group and let them get their own answer based on their own needs.

Of course, my opinion is just that of one person.  Others might view
the situation differently.  Good luck making your choice.

  if you learn Scheme, you need to learn both.  if you learn Common Lisp,
  you don't need to learn Scheme.

| My background: I'm an Eiffel-Programmer, and I think I know quite a bit
| about C/C++ and I refuse to do programming a line of C++.  So Common Lisp
| seems to me a bit like C++.  Is that a correct impression?

  no.  Common Lisp is not a bit like C++.

| Someone compared Scheme Standard to CL standard and this was quite
| frightning.

  this "fear" might mean that Merriam-Webster's Third New International
  Dictionary of the English Language are frightening to a kid and that a
  1000-phrase book for tourists is the best solution to teaching kids to
  write?  I have personally looked at huge reference tomes with a sort of
  "wow! somebody did all that work and organized it for me!" attitude.  I
  also consider it frightening that anyone would sit down and actually
  attempt to design a language and yet leave so much work to its users as
  Scheme does.  the consequence is that Scheme is a much bigger language
  than Common Lisp in practice: Scheme is not a language you can use out of
  the box, so you have to know at least a few implementations and each has
  a million functions, all non-standard and slightly different in most
  ways.  in Scheme, purity rules, so every time someone sees what he
  considers to be impure, he goes off to write his own, creating yet more
  incompatible Scheme implementations and yet more unreadable Scheme code.
  irony has never been quite so strong as in the "lean and mean design" of
  Scheme.  Common Lisp has a "just do it" quality to it that I like a lot,
  especially since it's much, much harder to get a large language beautiful
  than to make a small language beautiful, and Common Lisp is beautiful.

| Scheme comes along with around 50 pages CL with 1100 pages.  So does that
| means Scheme (lean and mean) CL (big and complex) but more powerful?

  it means Scheme was designed to prove something and Common Lisp was
  designed to build something.

  scripting has to fit into a much large scheme of things (pun intended),
  and Scheme is easier to force into other schemes of things because it
  doesn't carry enough weight of its own to be a burden to anyone: in other
  words, if used for scripting, Scheme is a thin veneer of syntax on top of
  a different system's semantics.  for some, this seems to be sufficient.

| CL seems to have far more support for OO-programming and Eiffel is an
| OO-languae so I might like CL more.

  I think you should approach new languages as "a programmer", not "an
  Eiffel programmer".

So, comparing the CL standard to R5RS (the Scheme standard) is unfair
to both.  They do not cover the same material.

(defstruct point
  (x 0 :type (mod 1024))
  (y 0 :type (mod 1024)))

and then go ahead and write your program using this definition. Now
you are sure that this program will run in other CL implementations as
well.

Suppose, thet, by chance you write the same (non standard) program in
the Scheme implementation X which does support DEFSTRUCT and then try
to run it in another Scheme implementation Y, which does not.  You
have - at the very least - make sure that you can have the correct
DEFSTRUCT library installed in implementation Y.  Which of course
means that, since implementation Y already supports DEFINE-RECORD,
that your footprint starts to blow up.  You get the idea.

Some CL compilers also do a decent job at "non lethal" :) type
checking.

Hope it helps

Cheers

But now that one can do  FUN, instead of #'FUN,
(lambda ..) instead of #'(lambda ..)

((lambda ..) ..) instead of (funcall (lambda ..) ..)

what's left are warts like (funcall fun ..) and naming inconsistencies
[no real prob with the latter, just define nullp (or null?, pair? (or cons?)),
etc]

Saying (CAR NIL) (CDR NIL) are wrong is just a game of words, and whether Lisp
or Scheme is right about #f is one of the great mysteries of the universe..

If you read "The Little Schemer", only in a couple of occassions does the
ugliness show.

The package system is constantly under attack, and while some Schemes have
nice module systems (eg: MzScheme), there's no standard.

You can write beautiful code in CL. Maybe it not "perfect", but it's not so
far from that.Scheme is small, so you can get all of it quick. Get your basic
lisp style up and running.
Then look at CL. You can learn things you never dreamed of while doing
Smalltalk, Eiffel, etc. (maybe tinyclos would do too, but I'm not sure.
Certainly tinyclos is nicer, but it's the son of CLOS, after all). You'll find
several books on CLOS. Will you find _any_ for the Scheme object systems
(practically all of which cannot even touch CLOS?).

BTW, don't let _anybody_ talk you into believing that CL is to Scheme as C++
is to C, that's plainly an extremely innacurate and dangerous analogy.

Welcome to schizofrenia ;-)

I OTOH found the "one loop fits all" attitude extremely non-practical
(in effect, Eiffel was the first ever language I used, where I really
needed it's ability to automatically check variants and invariants in
loops, since I regularly made mistakes in writing those loops.  I
normally make mistakes of that sort in other languages about once in
every 5 years or so).

In effect I'd be careful to distinguish between unnecessary complexity
(which should be elided, but which makes up large part of C++, where
the complexity seems necessary, but only because of underlying design
decisions which are ill matched to it's current uses), and necessary
complexity or size, which should be welcomed, since they make your
life as a programmer easier, IMHO.

Also, CL doesn't make so much of it's object-orientedness than
mainstream languages like Eiffel, C++, etc. do.  The pure OO part of
CL (i.e. CLOS) isn't fundamental to CL.  The basic idea of OO (which
most often get's lost in mainstream languages, i.e. that OO isn't
about classes or methods, anymore than astronomy is about optical
telescopes) OTOH is central to Lisp (in both CL and Scheme's guises).

Try to stop thinking in mainstream terms, it will help you avoid
confusion...

Regs, Pierre.

But nevertheless thanks for taking the time to answer.

But what I like most about Eiffel is it's idear of Design-by-Contract.
Wouldn't that s.th. what would be nice vor CL too?

Another perspective looks like this: CL is to Smalltalk as Smalltalk
is to C. Now substitute C++ for C (or Pascal for C) and Scheme for CL.
That's how I'd begin to explain it to someone totally unfamiliar with
CL and Scheme. As we zoom in closer, some details emerge. At some
point you have a clear enough picture for you to make a choice.

I would put it another way for someone familiar with other tools.
As you know Eiffel, I might substitute Eiffel for C. The problem with
all of this is that it's like saying an elephant is a bit like a
hippo. While it helps give a vague feeling for what these animals are
like, it doesn't help you choose an animal for a zoo.

No matter the base differences between Scheme and CL, nothing comes into play
when you go into the OO arena. You might not like
the `lack' of encapsulation in CLOS, but there's a different mechanism for that
in CL (packages). If you want classic OO encapsulation,
you might find that in some classic OO system for scheme, but then, classic OO is
wrong. That's the main conclusion you should come to, if you take Dylan, Cecil,
or CLOS. That's one of the main interests of your journey:

Cheers

When using a DbC system, all these are given to the system in a way
that it can understand and check.  Check on compile-time if possible,
on run-time if not.

An Eiffel person might give more detail but these are the essentials.

Replying not specifically to you, Fernando, but to some specific things
you said that triggered me to want to add some general points
in this discussion.  Your words included, semi-out-of-context, to help
understand what triggered these thoughts.

I also think a lack of political inclusivity is a wart.  We know very
little about the human brain, probably, compared to what we might
know.  But among those things we know is that it is capable of
accomodating a huge amount of what the Scheme community would call
"unaesthetic" complexity.  That is, the kinds of natural languages
people devise are full of special case and we have special brain
hardware that make our use of that quite efficient.  To build languages
that do not take good advantage of our ability to do this is to
waste our personal processor power.  All the claims that are made about
what languages are learnable or not are unscientific anecdotes
based on claims of how hard it was for teachers who had a bias toward
certain presentations or who had prsentations differing in huge ways
(not just namespace) retrospectively and unscientifically gauging reasons
and surely boiling them down to reasons that due not satisfy any definition
of science I know.  My experience is that CL is easy to teach to anyone
who has not been fed propaganda from other languages about how languages
"should be" and who does not balk merely because he/she has been
trained to balk.  Just as the whle LISP family is easy to teach to anyone
who has not been trained to balk at non-infix.  The degree to which
the aesthetics by which Lisp is often externally judged is born with
you is questionable at best.  People do have a born-in aesthetics, but
I think they often unlearn their intuitions about it when faced by a lack of
ability to articulate it and a pushy person who purports (sometimes without
foundation) who alleges to be able to articulate what they think better
than they themselves can do.  People LEARN to be bothered by two namespaces
because they are TAUGHT to think namespaces don't matter.  But namespaces
are ROUTINELY used in natural language, and people accomodate them very well.
Almost no word in any naturally arising human language has only a single
definition, and yet people do not rise in revolt at this "lack of elegance".
They resolve by context.  If you want to do SCIENCE about what is and
is not "natural", the data awaits and it does not come from languages
that are made and taught by their makers to captive audiences over a five
to twenty year span.  

Human-derived attempts to make unambiguous languages have gone
nowhere.  English, which is full of contextual nuance and blunt
construction, has won over the regularities of Latin and Greek and the
pseudo-regularities of languages like Spanish and German partly, at
least, because people don't have patience with aesthetics when they
stand in the way of practicality.  They want to ELECT practicality
when it suits their need, but they don't want to be REQUIRED
practicality.

  (defun foo (list) ... <cursor>

and you want to now access the LIST function, you can do it with only local
editing.  You can ALSO access the LIST function with only local editing.

In Scheme, the decision to bind the variable LIST is a [premature]
decision not to use the variable LIST in the program you are writing.
To access the outer variable requires rewriting the program.  This is
usually "compensated" for by not ever using the obvious names in
programs, preferring variables like "LST".  This makes programs
inelegant, too [that is, by someone elses's (my) metric, metrics of
elegance not being uniquely determined], because it doublles the size
of the local set of terms, having in effect to always choose different
names for globally defined names than local ones.

CL allows the decision about which LIST to access to be locally
administered, and the "price" (to some) or "feature" (to others) of
this is that the kind of use is case-marked.  (FUNCALL f x) identifies
the UNUSUAL (in CL) and less syntactically optimized case of calling a
variable in ordder to allow (f x) to mean a call to the thing
familiarly known as F without fear that F has been locally bound.

This is a simple trade-off.  Scheme assumes you will be passing so
many functions that you will have at least an equi-likely chance of
wanting to call a variable named F as a globally defined function
named F, and so it assumes you want to optimize this case.  Most CL
programmers I know would gag if functional args were passed around
with enough frequency to justify optimizing this case.  Likewise, as
arguments, it's not common to pass the contents of globally defined
function names in CL, so the case of passing one is pessimized
slightly in order to make it clear that (f x) is passing a local name
[you don't have to look to be sure if the binding list is on a
previous screen.  you always know x means "some local x" and that the
user would use #'x to denote a global function by this name.

BOTH languages are doing Statistics and Politics, though, not science.
That's not bad--it's what's called for; but it is not fair to say that
we have made a "political outcome" and Scheme has made a "scientific
outcome".  A maxim I've made up for myself on this is the following:
"There are no political answers, only political questions." (Something
I just this moment thought of: It follows from strong typing that this
must be true, right?  Both arms of the IF have to have the same return
type.)  Both languages are probably doing right by their user
base. Each one is aesthetic within the context of what it is trying to
promote.  Each one is political in that it has an agenda of a
programming style that it thinks is useful.  Loosely, and I'm
exaggerating slightly for visual effect, so please don't be a stickler
here: Scheme: tolerate, but don't prefer, non-functions.  Lisp:
tolerate, but don't prefer, functions.  But what really burns me is
the oft-made claim by the Scheme community that their statistical
trade-off makes so much sense that it can be referred to without
adverbial qualification as "aesthetic" as if there were no other kind
of aesthetic worth mentioning.

Regards

      end; -- faculty

The interesting points are require. In which I state clearly what I
expect n to be a positive number. And because loops will be problematic
you have the invariant part. Which must hold fo every iteration  and the
variant part which must be a decreasing number but always positive. Now
you may say that isn't a big thing. But if you have an ancestor and some
descendants the assertions are inherited too.

This assertions can be extracted from the source and give a nice
specification. And indeed you can use Eiffel for specifyin your problem.

I guess the conditions look familar to LISPERS  because you are used to
do declarative programming. That is what they are, they don't state how
s.th is done but what has to hold. But this is quite what FP-programming
is about I guess.

If that assertions does not hold an exception is risen, which you can
handle in a rescue part.

Does that example answer your question?

  this reminds me of something.  Scheme people will go out of their way to
  claim that Scheme is a Lisp.  this is like communist dictatorships which
  refer to themselves as "democracies" and people who kill doctors and bomb
  medical clinics and call themselves "pro-life", as if hijacking a nice
  word can make up for the facts.  I just wish Scheme people could be proud
  of what they have instead of being so childish and immature that they can
  only enjoy their little scheming games if they can usurp somebody else's
  terminology.

  but, hey, my first objection to GUILE was that it was a name I'd expect
  from politicians too self-loathing to be proud of what they did, and
  Schemer and Conniver have similar connotations with me¹, strengthened
  after looking at what Scheme people do when you say that Scheme should be
  good enough on its own not to need the Lisp label so it can blame Common
  Lisp for everything when it fails.  you see, "Scheme" is what they call
  their language when they succeed.  when they fail, they call it "Lisp".
  for as long as I have been watching Scheme people, they have contributed
  much more to the bad name that "Lisp" has than to the good name that they
  think "Scheme" has by unloading all their misery on the "Lisp" name.  so
  look out for people who object to Common Lisp because they once got
  burned on a Scheme project, or learned Scheme from a bad teacher who
  insisted that Scheme is the only true Lisp.  scheming bastards, indeed.

  (this article contains 240% of the RDA of cynicism.  please limit your
  intake if you feel irritated.  prolonged exposure may also cause anger.)