Seems Mr. Thomas has developed yet another personality, hm?

Regards,
--
Nils Goesche
Ask not for whom the <CONTROL-G> tolls.

For that matter, I'd expect most CL-based servers to offer similar
capabilities, since it is the natural way to implement those.

One of the core assets in this is CL's very good condition system,
which allows precise reporting of errors, and cooperation between the
signalling and the handling site in handling the error (think restarts
and handlers).  Because of those, I'm much more confident in the
reliability of CL servers than servers implemented in more
impoverished languages.

Any other language/OS that offers dynamic redefinition capabilities,
multi-processing and an expressive condition system could offer
similar capabilities.

Many languages don't, either because they don't have the underlying
features to support this, or because they still live in the conceptual
world of batch-processing...

Regs, Pierre.

Regs, Pierre.

My friend is a SysAdmin, been using Perl for 8 years, and he had never even
heard of "tied variables". "SysAdmins aren't programmers! Must be a Perl 5
thing." he quotes.

I had to look them up myself, but I haven't used perl much either.

What Eriks toy did is not simply show this "tied variable" effect.

I'm guessing here, but I would imagine the that the scenario showed:

Interacting with Lisp.
Tight association between Emacs and Lisp.
The transparent abstraction possible with Lisp.
That Lisp can do "systems programming" tasks (Really!?!?? Really.)
That you never have to leave the Lisp environment to do "real work".
If things went poorly, perhaps he was able to demonstrate the actual
interactive debugging of an error.

All of this was show pretty much transparently I imagine. All of it was,
essentially, taken for granted, like GNU Readline in BASH. It just happens.

And finally, he introduced a very high level "user object" that has
awareness of not only the simple user attributes, but also of its files in
the file system.

Many systems will delete the users home directory as part of the utility to
delete a users account, but this idea is even better integrated.

That was the "aha" moment for me. *I* am not aware of ever seeing a "User
Object" that was that high of level, to include the users files as a (not
necessarily directly accesible) property of the User. That's pretty neet, I
think.

You'd like to think that scsh would have this kind of high level
abstraction, but I don't know if it does or not.

I mean, for me even if I had a Perl module that had this kind of
abstraction, I'd probably still just do it from a command line:

find / -user 123 -print | xargs chown 456

vs writing a small Perl Script to do it.

Even if everything was set up to where you can simply type:

$ perl user["will"].id = 456

And have Magic Happen, it's still not as "elegant", by perhaps the slightest
fraction, as the SETF that Erik used. I still have to stick on that "Perl"
command. (Actually, it gains elegance with the transparent use of the
associative array, but loses elegance by actually having to launch Perl.)

If I wanted to get rid of that, then I have to use a script, and that blows
the abstraction, because now I'm not in perl anymore, and lose all of its
benefits. Once it's a script, the fact that it's one line is meaningless.

With the Lisp I could potentially do something silly like:

;; Give "will" the "next" user-id
(setf (user-id (find-user "will")) (+1 (user-id (find-user :latest))))

Error: The user "will" does not exist
  1 (continue) Add user "will"
  2 Specify another user to use this time
  3 (abort) Return to level 0.
  4 Return to top loop level 0.

Anyway, with a this little toy, it helped demonstrate that it is possible
and practical to build up a lot of nice abstractions within the Lisp World
to do Neet Things. Even "Sys Admin" things. I don't think anybody uses Perl
as a shell, but you can easily use Lisp as a shell, particularly when
combined with something like Emacs. (Thus even more motivation for a good CL
based Emacs...)

So, this wasn't simply a demonstration of a "tied" variable. It helps
demonstrate a cohesive whole that a Lisp environment can become.

"Lisp -- It's not just for AI anymore."

I saw a big picture here, and I hope others did too.

Best Regards,

From the C-Intercal Supplement section 6:

   `A feature of INTERCAL-72 not documented in the manual was that it
    required a certain level of politesse from the programmer.  If fewer than
    1/5th of the program statements included the PLEASE qualifier, the program
    would be rejected as insufficiently polite.'

  That is not the point.  Whether he knew how to do it is irrelevant.  If
  he knew how to use "tied variables" and how to write the same thing in
  Perl, he might _still_ think the Common Lisp way of doing it was nice
  enough that he wanted to help give Common Lisp a chance, and I told the
  story of how at least one sysadmin was sufficiently impressed.  Which was
  the point of this thread, you annoying imbecile.

  Clearly, doing _anything_ to satisfy you is an utter waste of time.
  Please, return to your Dylan newsgroup.  Anyone who _wants_ to talk to
  you will know where to find you.
--
  In a fight against something, the fight has value, victory has none.
  In a fight for something, the fight is a loss, victory merely relief.

  Wow, George W. Bush is posting to comp.lang.lisp.
--
  In a fight against something, the fight has value, victory has none.
  In a fight for something, the fight is a loss, victory merely relief.

I'd like to hear how people would compare Common Lisp to something like
Jython.  From what I've read, including Peter Norvig's "Python for Lisp
Programmers" paper, something like Jython would be a very compelling
argument:

 1) it's extremely dynamic (rivals CL), including its programming
    environment
 2) can leverage the full extent of Java's rich set of libraries
 3) good for scripting, as well as for bigger applications
 4) can be compiled
*5) uses JVM, for which a lot of work is being done

Jython is also free, open-source, and supposedly as cross-platform as
Java is (FWIW), and the Python part itself is as cross platform as gcc
is.

If you read Norvig's paper, he describes using Python instead of CL in
his AI book.  I've read that book, and saw some of the examples, Python
vs. CL...and even though I'm appalled by whitespace-dependence, I don't
know that this is necessarily any more rational than how appalled people
are with parens everywhere.  But the point made about the removal of
the parens and addition of some indentation makes CL and Python look
surprisingly similar.

Also, reading the paper, you must consider that Jython has more
capabilities than the Python that Norvig was comparing to, not to mention
a compiler that (I think) compiles Jython down to JVM code.

I havn't tried Jacol (http://jacol.sourceforge.net) yet, but after
looking at its interface into CL, it's not quite that smooth.

There are many other things I do not like in Python (for example implicit
binding by assignment and indentation dependent semantics.) but this things
may be more or less a matter of taste.

But I still do not see in what way this whole stuff is on topic in this
thread? (Maybe asking this question in comp.lang.python is more
appropriate...)

ciao,
Jochen

It does not have macros, and that is legitimate.  But there are
several arguments suggesting why they don't need macros, and that they
have something that solves the same problem.  It's been explained to
me months ago...but unfortunately, I've since forgotten the details.
Someone here might be able to fill in here.

Method combination is another feature that's very specific to CLOS,
and I would argue that 99% of programs don't use it, and of the 1%
that do, at least half are probably using it wrong (or just using it
for the sake of saying they're using a non-standard method
combination).

But again, people who work with these rules more often than not
eventually find that they like the indentation rules.  Considering
that most programmers already indent their code, some of the
puctuation and delimiters we use could be viewed as redundant, and
even obfuscating the code that's already indented.

I did indeed start responding to this thread, and was gonna say
something completely different, more in-line with the original thread.
 But somehow, for whatever reason, this thread led me into something
I've been thinking about for months (Jython).  So, since FOR ME it was
THIS THREAD that led me into that direction (and again, I'm sorry I
can't justify it to the comp.lang.lisp police -- i.e. you), I figured
that changing the subject was sufficient so that people could read the
subject, and if they're not interested in it, or in the author, then
just move past it.

Since I posted a couple weeks ago wondering if "Aspect-Oriented
Programming" was anything but hype, some people have pointed me to
informative things to read on the subject.  And it's not just hype,
it's really useful.  In Lisp, we spell it "refactoring".  But in Java,
you can't refactor everything that you can in Lisp, the language
doesn't give you the facilities.  CL-style conditions and macros are a
large part of the reason we can factor things that you can't in Java,
but method combinations are another tool that really help us factor
out "Aspects".  Gregor Kiczales et al. are trying to bring this power
to users of mainstream languages; I think it'd be a big step backwards
to move from a language without the facilities you need to refactor
"Aspects".

t...@hailstorm.OCF.Berkeley.EDU (Thomas F. Burdick) wrote in message <news:xcvelgsqtz6.fsf@hailstorm.OCF.Berkeley.EDU>...

It is in no way a needless feature.  In fact, the programmable
construction of functional behavior from multiple methods specialized
on one or more argument types is definately one of my favorite aspects
of CLOS.  But just how much the vast majority of CL programmers, and
programs, use it?  Not that much.  A gray area might be when we use
another's code (e.g. vendor code) which was implemented in CL, and
which uses it.  It's hard to gauge.

Often as in "how many times I write it"?
Often as in "what proportion of executable code contains a reference"?
Often as in "what percentage of executing programs pass through it"?
Often as in "what percentage of time is spent in such a thing"?

The reason I raise this is that a major release of Symbolics Genera
was going out at one point years ago and on the day before it did, I
discovered a bug in special bindings wherein ((lambda (*foo*) *foo*)
1) did not work.  That is, a lambda combination did not do a special
bind right.  I was told by some people that lambda combinations were
not used very "often", and that the release should go ahead.  I
managed to fuss enough to get them to hold it up (to the great
irritation of some business people) because it offended my sensibilities
that a Lisp Machine should have a broken LAMBDA...  But the use of the
word "often" in the context of this story is what has led me to see
oftenness in a different way.

It seems to me that a lot of the perceptions and arguments surrounding
Lisp are out-of-date. This article is successful in explaining the
merits of Lisp in a much more contemporary context - developing
software for an web startup. It does so in a way that is
understandable to Java-fans who aren't that aware of how the same
problems can be solved using a language like Lisp.

Even more convincing are the trivia/urban-legends around ViaWeb that
Paul Graham didn't mention: that it was sold to Yahoo for $49 million
and was the work of 3 programmers, and that during negotiations with
Yahoo!, they hired a dozen programmers so that the company wouldn't
get too suspicious. These are exactly the arguments that appeal to
Linux/Java weenies like me.

Blub
I love it.

To the extent that a lot of people probably don't make use of
non-standard method combinations, Common Lisp'ers don't write a huge
amount of OOP code and don't refactor very much.  Of course some
people /do/ write OOP code, and some people do go back over their code
and refactor what they can, but you'll only find method combinations
used by those who do both.  And the thing about refactoring is that
you /don't/ leave a lot of evidence when you're done.  That's kind of
the point.  You have to see the tangled code to understand how
important it is to have that /one/ method with
my-funky-method-combination or to put that functionality in a mixin,
or have that iteration GF, or whatever.

One example - I was doing an optimization system.  I wanted users to
construct optimizations simply.  One of the trickier areas was optimization
terminations.  You can decide to terminate an optimization on many criteria
- timeout, failure to progress, "good enough" solution found, etc., or a
combination of these items.  To implement this in CLOS, I used a base
class, termination-check that had a single generic function,
evaluate.  I called this function at the end of each optimization
iteration.  To be able to combine these tests, I used a custom method
combination that passed the boolean results of all of the termination
checks to either an 'or' or 'and' function, depending on yet another
parameter` (passed in the make-instance call for the optimization).  This
allowed the user to inherit any number of these terminator checks and
combine them with either an 'and' or 'or' semantic.  Total number of lines
of code?  About 5 for the base class and about 2-3 for each termination
subclass. Add in another 3 or 4 for the combination code and it was done.  
All the user had to do was do the equivalent of (defcalss
my-simulation-class (simulation-type termination1 termination2 ,,,)),
followed by a make instance, passing the termination combination as a
parameter (and even this was macroed over so he only needed a single defsim
call).

When I think about what this would take in Python and/or Java, I shudder.  
Each user would have to write a custom termination method or you'd have to
have some sort of termination registry.  All-in-all, it would take a heck
of a lot more LOC, too.  This is one of the many places that CLOS,
multimethods and method combinations help.  The point is that you don't
understand the usefulness of these mechanisms until you do enough work in
them to really think about objects in a manner that surpasses the feeble
object models of Python, Java, and even Smalltalk.

The problem is that you really have to think differently to understand
this.  That's one of the advantages of Lisp - it causes you to think
differently about almost every aspect of programming.  And that's also one
of the disadvantages leading to Lisp's lack of popularity among the hoi
polloi - how do you explain a rainbow to a blind man?

In article <ZWzA8.38$id.43...@news.uswest.net>,

If you use Lisp lists for usages where a vector (be it C++'s
std::vector or a Lisp vector) would be more appropriate,
you lose. For stacks, it's okay, of course. For sets, you lose
too if the set begins to get larger. For trees, it's not so
good either except if it's only a binary tree with no additional
information attached to the interior nodes. Else I'd build my
tree datatype myself using defstruct or defclass.

In article <8a3667a0.0205040521.54d66...@posting.google.com>,

Common Lisp as a language does not push programmers into using OO
style the way Java does.  I've read many large programs that don't use
CLOS.  Of the ones that do, the vast majority do not require a
non-standard method combination, and often there's not a single gf
that is specialized on more than one argument.   Corba interfaces in
CL are a good example of this, as well as good examples of how CL can
(through macros) be made to deal with a different set of constraints
and semantics.

When programming is solving a general purpose problem, such as
"develop a system to find `optimal' flight itineraries, given
different cost functions", people immediately think to the most
difficult aspects of the overall problem, and if they know CL, then
they'll probably want to use CL more than anything else to do it.

However, often we have specific problems, such as interfacing with
LDAP, and we end up searching for libraries.

Jython seems to take the approach that:

 1) Python is a portable, flexible, dynamic language that can handle
the
    full range of programming goals, as well as swallowing another
    language whole, (e.g. C++, Java via CPython, JPython, Jython...)

 2) Java and its accompanying libraries contain a rich set of
functionality
    and standardization (if you consider Sun's standard as such)

 3) Compilation to JVM bytecodes makes for the smoothest integration,
and
    provides additional leverage of disproportionate Java compiler
improvement.

Since this post, I've noticed a task on the Clisp project page at
Sourceforge called "JVM compilation".  This is probably a start toward
letting CL in on Java functionality.  I'm sure that Python's libraries
and Java's libraries overlap heavily, and in such situations, I'm not
sure what programmers do, quite frankly.  I'd like to find out how
that works.

On that note, since CL's syntax is so flexible, I think that JVM
compilation, along with some macros, could probably lead to a nice
addition to any CL system.  I'm interested in hearing more ideas.

"Frank A. Adrian" <fadr...@ancar.org> wrote in message <news:bQ%A8.4257$JG4.234907@news.uswest.net>...

Let's take a scenario where we use not only method combination, but
multi-methods.  Then you have:

(define-method-combination optimization-combination ...)
(defgeneric optimize (x y)
  (:method-combination optimization-combination)
  ...)

If it's clear that your OPTIMIZE function wants to see the complete
class graph of X and Y, and the corresponding methods defined on those
class combinations, then all the power to you; you have demonstrated a
capability that CL has for an interesting and unique situation.
Bravo! (I'm clapping for you.)

What about the situation of needing an LDAP interface?  Try
implementing a (Tight)VNC viewer in CL.  Do you know what you're up
against?

The significant benefit that JVM (or another p-code system) gives is a
portable binary transport layer.

This is useful if you are running though an interpreter and do not
want to keep a compiler at the other end. The other 'use' for this is
to obfuscate code somewhat to make ripping it off harder, although JVM
disassemblers have shown that this goal is not well realised.

For lisp systems, using compressed source code is probably a better
solution.

However, CL doesn't support mobile code very well at the moment, and
improvements in this direction would be very welcome, imho.

Regards,