I am about to get my copy of Paul Graham's book (ANSI CommonLISP) and I am
very anxious.

Still , I have some questions:

FIRST:

Here in Israel , we have thousands of C\C++ programmers and so the
newspapers want ads are filled with requests for this kind of programmers ,
BUT never did I see a CLOS \ Lisp programmer want ad .!!!

If CLOS is so powerfull and (I read that) P Graham sold his software (in
CLOS) to Yahoo in 49 Million U$, How come CLOS is so obscure in the
programming community ?

SECOND:

I have Allegro CL 5.0 Lite and Lispworks Personal Edition.

None of the above can export to EXE in the Windows Environment,
Is there a program to do this (even in its demo version), As I haven't even
started programming in CLOS - I won't be going paying 600 U$ for a program
that I still do not need.  How do CLOS beginners usually start programming.
CLISP is too primitively interfaced (still).

THIRD

I program AutoLISP in an IDE called VitalLISP and I came to like the way it
works. (automatic completion of symbols names) - I once downloaded FreeLISP
and then lost the copy. I can remeber that it reminded me of VitalLISP -
Can anybody tell me where can I find the latest version that Harlquin
released ?

TIA

Nir sullam

In the above, substitute "uranium" for "CLOS", "atomic power" for "Lisp",
"coal" for "C", "oil" for "C+", and "fuel sources" for "programmers" in
the above and see if it helps you understand the answer.

Is atomic power for everyday use?  In principle it probably could be.
Look at atomic subs, for example.  Pretty small-scale use of atomic
power.  But as a practical reality, atomic power just isn't used the
same as fossil fuels.  The market is not segmented that way.  Does
that mean that coal and oil is the future and uranium the past?  Not
nearly as clear.  Observing usage stats is sometimes predictive, but
not always. The quick and easy availability of coal and oil has turned
an artificial distinction into a situation where two "would-be
competitors" appear to be different markets.

Not by necessity but more by what is now custom, Lisp tends to get used in
highly leveraged situations where other solutions don't work.  Not so much
because it has to work that way, but because people usually reach for
something quick and easy and prevalant for ordinary problems.  But C/C++
doesn't work for some sets of things because it doesn't scale well, and
since Lisp is designed to scale, it works better in really big situations.

Also, Lisp where it is used often it allows fewer people to do what
many would otherwise do.  This means you often don't see large shops
of Lisp programmers.

The analogy isn't perfect, though.  Contrary to prevailing myth, you
don't have to wear special clothing to handle Lisp.  And it isn't unhealthy
to other products living downstream.

  you're comparing a commodities market with a luxury market.  why?

| If CLOS is so powerfull and (I read that) P Graham sold his software (in
| CLOS) to Yahoo in 49 Million U$, How come CLOS is so obscure in the
| programming community?

  because it's a luxury.

  essentially, any damn fool can pretend to be a C/C++ programmer, as you
  will very quickly find out if you _place_ one of those ads and try to
  sort one or two good guys out from of the liars and incompetent fucks who
  apply for the job.  if you want to apply for jobs where the requirement
  is Common Lisp, you will equally quickly find out that you can't fool
  anyone.  likewise, you can find a job at a hamburger joint without any
  skills whatsoever, but if you want to look at how you produce equipment
  used in hamburger joints that should be simple enough that any unskilled
  person can operate it without causing himself damage or produce bad food,
  you look at the end of the market that Common Lisp is good at helping --
  you don't see many ads for hamburger joint equipment designers, either.

  with all those ads for C/C++, it means companies are _desperate_ to hire
  people who seem to know C/C++.  why do you think this is?  it's because
  C/C++ are job-creating languages.  let's take the development of the
  telephone as an example: initially, there were human operators, and all
  this worked great: but the more people wanted phones, the more people
  were required to be operators, and the companies were scrambling for
  operators, offering a lot of people work.  then better technology came to
  the rescue and released the work force tied up in operators to do other
  necessary tasks.  think of C/C++ programmers are human telephone
  operators -- the more successful they are, the more of them are needed
  (it is no accident the languages come from the biggest telephone company
  in the United States, either).  in contrast, the Common Lisp programmers
  as designers of the automated telephone switching system, and the more
  successful they are, the less investment will be in human operators.

| None of the above can export to EXE in the Windows Environment,

  you're assuming that this is what you will need to produce.  why?

| How do CLOS beginners usually start programming?

  they play with their Lisp environments, and use Emacs as their main
  interface to this environment unless they have a visual something that
  does the same.  it seems that you simply use your tools inefficiently,
  but you should investigate how to interface several powerful tools with
  eachother to make them work as one.  they don't have to come as one form
  the Single Vendor to work as one if they were designed well.  (this may
  well be very foreign to a Microsoft victim. :)

  all programming languages are not alike.  that you have found interest in
  Common Lisp sets you out from the crowd.  don't let the crowd run you
  down just because you have found something much better.  however, it is
  essential to succeeding "on your own" that you can talk to people who
  know how to do it.  the only upside of a commodities market is that lots
  of people use the commodity, and that they can talk a lot among
  themselves.  so try to find people in your community that you can talk to
  about Lisp.  posting here is a great start in this regard.

  oh, by the way, C/C++ are quite interesting languages from a marxist
  point of view, too (it being May 1 and all): they are so bad that any
  professional who wants to do interesting work needs to learn new tools
  all the time and have the employer pay for it.  the means of production
  are thus removed from the hands of the owners into the hands of the
  workers in a very new way.  if the employers were any smart, they would
  not use languages that removed _all_ their investments in their people
  this way, because it is as unhealthy for a market with disproportionate
  power in the hands of employees as it is with disproportionate power in
  the hands of employers.  shortly, therefore, smart employers will figure
  it all out and look for stable, solid languages where programmers don't
  need to be paid to acquire this week's skill set simply in order _not_ to
  quit for the job that requires it...  C/C++ are very bad for business,
  which is another reason why you see so many companies hiring: it's such a
  terrible tool that managers who used to or taught how to manage industry
  will throw people are failing projects.

  advertising is a symptom of insufficient demand or insufficient supply.
  in many ways, competition itself stems from insufficiency in solving a
  problem.  also remember that quality can never compete with quantity.
  please remember this when you use the consequences of competition as a
  measure of success: it never is.  success is when you have no competition
  and you ensure that you match the demand.  then you can go and talk to
  people with a confidence that the desperately competing people can't.  it
  is also sage advice to remain sufficiently above it all that you don't
  become a pawn in the games of the marketers.  in other words: resist the
  temptations of the mass market in any area where it matters to you.

        1) define a struct/class to hold the closure data
        2) define classes for each of the functions in the closure
        3) instantiate an object for the closure data (from [1])
        4) instantiate objects for each of the classes from [2]. Each
           of these objects need a reference to the closure object,
           passed via the constructor.

        Note that the classes defined in [1] and [2] are named
classes; in Common Lisp, there is no need to introduce classes for the
functions, and the closure itself is anonymous.

        Compare the following:
        (defun f(a)
               (cons
                  (lambda () (setq a (1+ a)))
                  (lambda () (setq a (+ a a)))))

        (setq g (f 2))
        (funcall (car g))
        (funcall (car g))
        (funcall (cdr g))
        (funcall (cdr g))
        (setq h (f 2))
        (funcall (car h))
        (funcall (car h))
        (funcall (cdr h))
        (funcall (cdr h))

        with:
class F {
public:
  friend class Car {
  public:
    Car (F& f) : a(F.a)
      {}
    int operator()()
      { return a++; }
  private:
    int& a;
  }

  friend class Cdr {
  public:
    Cdr(F& f) : a(F.a)
      {}
    int operator()()
      { return a*=2; }
  private:
    int& a;
  }

  F(aa) : a(aa), car(this), cdr(this)
    {}

private:
  int a;
  Car car;
  Cdr cdr;

  cout << h.car() << endl;
  cout << h.car() << endl;
  cout << h.cdr() << endl;
  cout << h.cdr() << endl;

just to take one point, compare lisp macros to C++ templates or
preprocessor macros.  lisp wins this contest handily.  

in C++ templates are rock stupid and can only be used if you could
have mechanically swapped out the types in your editor and stamped out
multiple copies.  the situatation for the different types must be
*exactly* the same.

lisp macros let you inspect and digest the arguments and do different
things depending on circumstances.  if an algorithm shares 99% (or 1%)
of the same stuff, you can make a macro to share what you can and
special case what you cannot.

i think macros (amongst other things) are key to scaling.

  some people see something they can hate whenever they get the chance.

| LISP was interesting, but ultimately impractical.  The left and right
| parenthesis keys wore out on my keyboard before I finished my second
| program.  Give me C++ any day.  This sensible language spreads the load
| out much more evenly across _all_ the number-keys in the top row of my
| keyboard.

  I'm truly relieved.  I actually appreciate it when the people who hate me
  are certified nut cases.

Regs, Pierre.

Footnotes:
[1]  Although I find the names a bit hypey, but I guess in these days
you have to call Lisp macros "Dynamic Compilation Optimizers" or
"Semantic Oriented Transformations" to get your point across, with all
the mainstream hype around.

If the spread of wear on the keys of your keyboard is the sole concern
in your programming, then either you are the sad victim of very shoddy
keyboards, or you have not understood what programming[1] is all about ;)

Regs, Pierre.

(Hmm, maybe I should get that saying trademarked and put on some nice
mugs.  Anyone want to pre-order?)

Footnotes:

[1] That is in the sense of system and program construction, and not
    some of the other things people currently seem to think programming
    is, or might be...

  For example the Vistor pattern, to a certain extent, IS multiple dispatch.
  You don't have to hack up some explicit representation for it.

  [  It is a matter open to debate as to how much CLOS and a dynamic
     language make those patterns "simplistic" to implement.  

     You can find one side of the debate here:

         http://www.norvig.com/design-patterns/

     I also think the GoF (Gang of Four) probably picked a set of patterns
     that include a larger set of things that C++ doesn't do well.  Since
those
     folks are one of their primary audiences, you might as well pick
patterns
     that have a high "wow, doing that was so much more painful before"
     effect. :-)
   ]

   (defun   add-n ( n )
     #'(lambda (x) (+ n  x)))

   (mapcar (add-n 2) '( 1 2 3 4))

   In C++, the mapcar equivalent could invoke a prespecified function on
   the "closure object" to each value of the num-list to the "computation".
   It would have to "know" what type of closure it is and what the "name"
   of that function is.

   In Lisp, the environment takes care of creating these sorts of "objects"
   and of throwing them away when they aren't needed anymore. Therefore,
   there is less "overhead" the user needs to worry about.  Also, the
function
   being passed is any function, closure or otherwise. There is no carefully
   orchestrated mating dance you have to go through to use them.

   It isn't that they aren't substitutable for each other... it is required
   drudgery involved.   On the flip side, closures make for awkward classes,
   too.

---

Yes, somebody actually implemented a Turing machine with them.

Then again, somebody did the same with vi macros.

If you are using X, add the following to your .Xmodmap (some unixes
have a different file like .xmodmaprc, I think):

  !!! Lisp parenthesis bindings
  !!! =========================
  keysym 9 = 9 bracketleft
  keysym 0 = 0 bracketright
  keysym bracketleft = parenleft braceleft
  keysym bracketright = parenright braceright

Then run "$ xmodmap .Xmodmap", or restart X. Manually running "$
xmodmap SOME_FILE" where SOME_FILE contains the above will always work
if you can't figure out your system's xmodmap startup file.

I've never seen newspaper ads for brain surgeons but I'm fairly
certain that a competent brain surgeon has no trouble finding a job.

And can you do things like rename the parenthesis characters
so some other character or symbol would represent them in
ordinary Lisp syntax?

If they had written some sophisticated m4 macrology[1], it might have
been more useful, and less work...  IMHO templates are just bondage &
discipline all over again.

Regs, Pierre.

Footnotes:
[1]  Not that I condone use of m4 for this purpose ;)  Today I'm more
convinced than ever, that "Thou shalt not have a macro language other
than thine language itself", or words to this effect...

This means that a macro can define arbitrary semantics to its syntax, but
it can't change the lexical nature of the language.  For an example of a
macro that defines a pretty complex syntax of its own, see LOOP.

: | LISP was interesting, but ultimately impractical.  The left and right
: | parenthesis keys wore out on my keyboard before I finished my second
: | program.  Give me C++ any day.  This sensible language spreads the load
: | out much more evenly across _all_ the number-keys in the top row of my
: | keyboard.

:   I'm truly relieved.  I actually appreciate it when the people who hate me
:   are certified nut cases.

It is actually important to me that I believe Philip was joking when he
wrote this.  Despite all the evidence to the contrary, I've managed to
convince myself that no-one in the world is that clueless.  It will
destroy my world construct if people I respect take the above comments
by Philip seriously.

Erik, please don't take him seriously.

There are lots of ways of doing this stuff in C++, none of which take
the 30 line to define that you took.  When we really want all the
generality of a closure (which we rarely do) we use a template class
that will combine any function pointer with an object pointer to make
a closure that contains both and, (since all such templates are
derived from a single root), they can be passed around like anonymous
functions.

In any case, no matter what you do, the simple mapping from a closure
is one object = one activation record.  

class f
{
    int a;
public:
    f(int _a):a(_a){}
    int operator++() { return ++a; }
    int Times2() { return a*=2; }

//when you really want all the generality of a closure

  IntClosure<f> car(g, &f::operator ++);
  IntClosure<f> cdr(g, &f::Times2);

  cout << car() << endl;
  cout << cdr() << endl;

//Note that the type isn't stuck being specific to this template
//instantiation

IntClosureBase *anyClosure = &car;

  cout << (*anyClosure)() << endl;

//but most of the time you just want functions
  cout << ++g << endl;
  cout << ++g << endl;
  cout << g.Times2() << endl;
  cout << g.Times2() << endl;

//sometimes just having the function pointers is enough
  int (f::*fn)();

  fn = &f::operator ++();
  cout << (g.*fn)() << endl;
  fn = &f::Times2();
  cout << (g.*fn)() << endl;  

class IntClosureBase
{
public:
  virtual int operator() = 0;

  virtual int operator() { return (object->*function)(); }

A macro cannot change the basic syntax of parentesis, whitespace etc.
It is still damn powerful and very, very useful.

A macro _character_ on the other hand, can change anything.

So you cannot say
(with-angle-brackets  <+ 2 <* 3 4>>)

But you _can_ say
?<+ 2 <* 3 4>>
by properly defining the meaning of "?"

For example, I have defined
?(func-name arg1 arg2)
to mean
(my-funcall #'func-name arg1 arg2)

  the evidence to the contrary is overwhelming: there is no limit to
  cluelessness, and no reason to presume cluelessness is a joke: failing to
  realize that the clueless aren't joking is how most politicians manage to
  pull their tricks on all of us.

| It will destroy my world construct if people I respect take the above
| comments by Philip seriously.

  that's harsh, but I think you should just convince yourself otherwise.

IntClosure< afunc()
{
   f g(2);

   IntClosure<f> car(g, &f::operator ++);
   return car;

I miss closures and lambda functions the most when using some of the
stl algorithms. For example:

class Person
{
  string getName();

// Find a person with the name 'John':
vector<Person*>::iterator it = find_if(
  people.begin(),
  people.end(),
  compose(
    bind2nd(equal_to<string>(), string("John")).
    mem_fun(&Person::getName)));

I would much prefer writing an anonymous function inline:

vector<Person*>::iterator it = find_if(
  people.begin(),
  people.end(),
  method(Person* p) { return p->getName() == "John"; } );

Excuse the ugly syntax.

The main problem with closure simulators in C++ is the memory
management and providing access to the local variables without having
to create a class which copies and stores them.

Having to type shift-8 and shift-9 isn't a big deal though, I
think my stiff left arm is caused by EscapeMetaAltControlShifts
- ingenious ideas for remapping emacs control combinations are
very welcome (is it possible, on a sun keyboard, to use the
caps lock as an ordinary modifier?).

--