Lisp or Smalltalk: Suicide Mission, Part II

[d***@runbox.com]

I've refactored my question in an attempt to better focus the
responses. Specifically, I've made it a first person question to take
out some of the team and mentor issues and added some more detail about
project(s), etc:

I'm trying to decide between learning Lisp and Smalltalk.

I'm primarily interested in insights from people who have worked with
both.

I'm not a programmer, but wish to become one.

I will learn only one of the languages (at this point in time.)
Philosophically, I'm not interested in becoming a 'language collector,'
a computer scientist, or developing a 'hobby' - but I am VERY
interested in getting real work done by writing my own applications.
Ideally, I therefore want the one language I choose to learn to be able
to handle anything I intend to do now or in the future.

Since I'm focused on real-world productivity, if I can get 90% of the
benefit of something with only 50% of the complexity, and still achieve
my goals, then that is a GOOD tradeoff for me.

Someone (Avi?) once wrote that Lisp is multi-paradigm while Smalltalk
is not, but that since the one paradigm Smalltalk uses is so powerful,
you can get almost all of the benefits without all the attendant
complexity. That appeals to me. On the other hand, the power of Lisp
is seductive.

I do not have a full understanding of the benefits and downsides of
multi-methods, encapsulation, call-cc, etc. (To reiterate: I'm not
a programmer.) I have a very basic understanding of what they all
mean, but not a practical understanding that would keep me from
shooting my own feet off with unnecessary complexity or creating
debugging nightmares.

I realize that this stuff gets into language holy war debate territory
over language design, but I'm trying to understand what I'm getting
myself into with Lisp and Smalltalk - and which is best suited for my
specific goals. I realize that more powerful and flexible features
also tend to have greater costs if you misuse them (like weapons),
but...?

I guess I'm operating under the assumption that Smalltalk is better
for modeling standard business processes (all objects, all the time),
while Lisp is better for the more computationally/algorithmically
intense stuff like NLP.

So, given the strengths of each, which is the better choice for someone
who wants to be able to accomplish the tasks stated below with the
shortest learning curve and least complexity? Which is going to offer
the most productivity for someone that is programming mainly, say,
accounting systems, but with some NLP/AI stuff thrown in every once in
awhile?

I'm interested in the idea (from Andreas and Wade) of creating a DSL
using Lisp or Smalltalk that would allow me to farm work out to my team
of business analysts. But I'm not sure if that is practical for this
situation?

If I'm trying to look on the bright side, I can note (as Espen does),
that my systems analysts are not biased or coming in with preconceived
ideas about language syntax, etc. This makes me wonder which is a
better first language for them (and myself)...Smalltalk because it is
simpler, or Lisp because I don't want to 'hardwire their brains'
with doing everything one certain way...?

[d***@runbox.com]

90% of what I intend to do now and in the future is write web
applications that perform regular business processes (groupware, loan
processing, accounting, etc.), but I also want to be able to write
desktop applications (w/ GUI) using the chosen language. Boring stuff
to a computer scientist, probably, but I'm a former business
professor who became a business drone.

Smalltalk probably has the advantage for these types of apps, yes?

One of the applications will be doing natural language processing on
RSS feeds, Bloomberg terminal feeds, and Usenet postings, etc.

[For everyone who is so interested: It is essentially an application
to combat fraud in the equities markets, and based on govt. funded
research completed while I was at university studying to be a
pointy-haired boss. The primary focus is on fraudulent trade patterns,
but the NLP component would be used to find instances of stock kiting
and shilling that run afoul of investment laws. It would also be used
to find hidden risks in investment syndicates, whether formal or
informal. For example: The failure of the LTCM hedge fund was such a
huge risk to our economic system, in part, because so many of the
investment banks that cleared the LTCM trades were parroting the LTCM
trades. The banks were in awe of the Nobel-prize winning guys that
worked for LTCM..."they're brilliant, so if I do the exact same
thing, I'll look brilliant too!" The risks for the economic system
increased exponentially because of the domino effect of everyone
throwing their weight behind the same trades. One unforeseen
circumstance and everyone gets wiped out...then they had to be bailed
out by the government because it would drag the economy down the
toilet, otherwise. Your tax dollars at work.]

The NLP stuff just needs to be completed overnight, I guess in a
batch-type format...not simultaneously. I'm very interested in
learning more about what Bulent Murtezaoflu was saying about various
approaches and hardware requirements for this type of task.

I'm also interested in creating (relatively simple) expert and
agent-based systems for our company. Lisp probably has the advantage
for these types of apps, yes?

[d***@runbox.com]

I want to take not only the language features into account, but also
the existing tools, frameworks and code libraries that would help or
hinder my productivity.

I think continuation-based web tools make web development easier, so
I'm trying to compare and contrast the benefits of UnCommon Web and
Seaside. Seaside seems to be a more complete framework, and to have
more lucid documentation. I also know a few companies that are
confident enough with Seaside to use it for production systems now,
while I know very little about UCW. I don't fully understand all the
issues with either, though.

Emacs scares me (there, I said it!) Smalltalk seems to have the more
productive environment...but Lisp seems to have more open-source code
available.

I'm developing and deploying on OS X, with FreeBSD as a possible
deployment option in the distant future. I work with a university
part-time, and I have access to a few racks of XServes...I know almost
nothing about Unix beyond the very basics, though, so the pretty OS X
interfaces provide me some comfort :-)

I'm mainly looking at SBCL or LW for Lisp implementations, or VW as
the Smalltalk implementation. [I prefer to avoid any type of
royalty/runtime scenario, if possible, and (as I said) I'm working on
OS X. These implementations also work with the various frameworks and
libraries I'm interested in so far. I have no problem paying for
commercial tools if they help me get the job done.]

[d***@runbox.com]

Er...All of my post text made it to the c.l.s list, but some of it
seems to be missing on c.l.l.?

[Peter Seibel]

Post by d***@runbox.com
I'm developing and deploying on OS X, with FreeBSD as a possible
deployment option in the distant future. I work with a university
part-time, and I have access to a few racks of XServes...I know
almost nothing about Unix beyond the very basics, though, so the
pretty OS X interfaces provide me some comfort :-)
I'm mainly looking at SBCL or LW for Lisp implementations, or VW as
the Smalltalk implementation. [I prefer to avoid any type of
royalty/runtime scenario, if possible, and (as I said) I'm working on
OS X. These implementations also work with the various frameworks and
libraries I'm interested in so far. I have no problem paying for
commercial tools if they help me get the job done.]

If you're going to be using OS X you should consider OpenMCL, an
excellent open-source Common Lisp implementation.

-Peter

[d***@runbox.com]

Thanks for that suggestion, Peter, but one of the reasons I was looking
at the other implementations to start with is their multi-platform
capability. Down the road, though, I do intend to look at both MCL and
OpenMCL.

[Wade Humeniuk]

Post by d***@runbox.com
[For everyone who is so interested: It is essentially an application
to combat fraud in the equities markets, and based on govt. funded
research completed while I was at university studying to be a
pointy-haired boss. The primary focus is on fraudulent trade patterns,
but the NLP component would be used to find instances of stock kiting
and shilling that run afoul of investment laws. It would also be used
to find hidden risks in investment syndicates, whether formal or
informal. For example: The failure of the LTCM hedge fund was such a
huge risk to our economic system, in part, because so many of the
investment banks that cleared the LTCM trades were parroting the LTCM
trades. The banks were in awe of the Nobel-prize winning guys that
worked for LTCM..."they're brilliant, so if I do the exact same
thing, I'll look brilliant too!" The risks for the economic system
increased exponentially because of the domino effect of everyone
throwing their weight behind the same trades. One unforeseen
circumstance and everyone gets wiped out...then they had to be bailed
out by the government because it would drag the economy down the
toilet, otherwise. Your tax dollars at work.]

You mean something like the product from Xanalys (which used to
own LispWorks) and is written in Common Lisp?

http://www.xanalys.com/

http://www.xanalys.com/solutions/financial.html

Wade

[d***@runbox.com]

It is a different focus area within the same problem domain, I
guess...their product seems to focus on account data,etc. within
individual companies, which is great at finding embezzlement and that
sort of thing, whereas this product would focus more on a meta-market
level where you don't have account information disclosed. It focuses
more on trade clearing, financial instruments/derivative correlations,
volume patterns, etc.

But, yes, I had no doubt that Lisp was suited for this type of problem
- I'm just trying to figure out if Smalltalk is, as well, and if
Smalltalk would offer a lower complexity curve, etc.

[Wade Humeniuk]

Post by d***@runbox.com
But, yes, I had no doubt that Lisp was suited for this type of problem
- I'm just trying to figure out if Smalltalk is, as well, and if
Smalltalk would offer a lower complexity curve, etc.

Just to switch the topic back to Domain Specific Languages. Perhaps
you would like to briefly explore what a Lisp-like DSL would like
for your specific language. If you would/could post some very
specific statement from your model, say, a description of fraud
then I could take a stab of transforming that into a Lisp DSL
version. Then you can see how it might be done and what it may
look like.

It the meantime you might visit the site:

http://www.lisperati.com/casting.html

It is a light hearted look at Lisp and maybe why it is
considered to be so good.

Wade

[Friedrich Dominicus]

Post by d***@runbox.com
90% of what I intend to do now and in the future is write web
applications that perform regular business processes (groupware, loan
processing, accounting, etc.), but I also want to be able to write
desktop applications (w/ GUI) using the chosen language. Boring stuff
to a computer scientist, probably, but I'm a former business
professor who became a business drone.
Smalltalk probably has the advantage for these types of apps, yes?

I don'f feel so. Both can be used without troubles int those
areas. Some Smalltalks and some Common Lisp implementation even allow
you to run the same stuff on different platforms. I suggest you simply
check out some Smalltalk and some Lisp, read some code and write some
code and *then* might have an impression of what you like or dislike
and can tell your preferences.

Regards
Friedrich

[Thomas Gagne]

As far as expert systems go there are probably packages you can get that are
compatible with both languages. For Smalltalk you might consider visiting
<http://www.lcdi-tech.com/>. I understand Rich Cooperman has done this kind
of thing multiple times and might be able to help.

[Paolo Amoroso]

Post by d***@runbox.com
[For everyone who is so interested: It is essentially an application
to combat fraud in the equities markets, and based on govt. funded

At the 1998 "40th Anniversary of Lisp" conference, David Lamkins gave
a talk about a validation model written in Lisp for a
telecommunications fraud detection system used by RBOCs.

Post by d***@runbox.com
I'm also interested in creating (relatively simple) expert and
agent-based systems for our company. Lisp probably has the advantage
for these types of apps, yes?

I got several expert systems used books from Amazon at bargain prices.
As for using Lisp, you may check Lisa by David Young:

Lisa - Intelligent Software Agents for Common Lisp
http://lisa.sourceforge.net/

It was influenced by the popular CLIPS and JESS systems. The CVS
version supports uncertain reasoning via certainty factors.


Paolo

[Isaac Gouy]

Post by d***@runbox.com
90% of what I intend to do now and in the future is write web
applications that perform regular business processes (groupware, loan
processing, accounting, etc.), but I also want to be able to write
desktop applications (w/ GUI) using the chosen language. Boring stuff
to a computer scientist, probably, but I'm a former business
professor who became a business drone.

1) Are you trying to develop a proof-of-concept system, or are you
trying to commercialize a proven concept?

2) Where are the risks? Identify the risks and then choose technology
to address the risks.

When 90% is boring web app stuff, would it make sense to use some
boring commodity tool? WebObjects! PHP!

Why do you also want to write desktop GUI apps? Why wouldn't that
functionality be usable as a web-app? Reduce scope, reduce risk.

How much of that stuff can you get open-source or buy?
Stop this being a suicide mission - understand and manage risk.

3) afaict there's no particular reason the "NLP stuff" needs to be
written in the same language as the 90% web stuff. Seems possible that
you'll want to work on the NLP stuff in an very exploratory way; seems
likely that a lot of the web stuff could be "just another web app".

4) As you're a business professor turned business drone, is learning to
program a good use of your skills?
(At best you'll be a novice programmer, at worst you'll be a really bad
programmer with the authority to enforce really bad design decisions.)
best wishes, Isaac

[Rahul Jain]

Post by Isaac Gouy
When 90% is boring web app stuff, would it make sense to use some
boring commodity tool? WebObjects! PHP!

Or use a powerful language and the web app stuff becomes less than 10%,
because you've abstracted HTML nonsensicalities to reasonable
content-focused operators.

[Rahul Jain]

The failure of the LTCM hedge fund was such a huge risk to our
economic system, in part, because so many of the investment banks that
cleared the LTCM trades were parroting the LTCM trades.

Ah, I assumed it was just the sheer amount of money they were managing,
which supported my idea that the investors started pulling their money
out because they didn't realize that they were basically unexposed to
interest-rate risk, but were exposed to liquidity risk. As I understand
it, it was the fact that people got scared and started pulling their
money out that caused them to lose their money. Seems there was more to
this situation that I realized. Yikes...

[Niall Ross]

Dear Rahul,

Post by Rahul Jain

The failure of the LTCM hedge fund was such a huge risk to our
economic system, in part, because so many of the investment banks that
cleared the LTCM trades were parroting the LTCM trades.

Ah, I assumed it was just the sheer amount of money they were managing,
which supported my idea that the investors started pulling their money
out because they didn't realize that they were basically unexposed to
interest-rate risk, but were exposed to liquidity risk. As I understand
it, it was the fact that people got scared and started pulling their
money out that caused them to lose their money. Seems there was more to
this situation that I realized. Yikes...

FWIW, my analysis is that LTCM were managing risk by moving risk, while
under the impression they were managing risk by reducing it. A noddy and
big ears example of doing this would by a system for winning at casino by
- bet a point on black
- whenever black loses, double your bet
The formula 2^n+1 = 2^n + 2^n-1 + ... + 1 ensures that every time black wins
you will be one point up, whereupon you begin again. If you have infinite
money to start with, this system does ensure a (pointless) finite addition
to it. For gamblers with finite money, it moves risk from moderate risk
associated with moderately probable events to massive risk associated with
less probable events - in this case, a run of reds sufficient to break the
investor.

With much subtler maths, but arguably not that much more subtle philosophy,
LTCM eliminated risk from the everyday fluctuations of the markets,
delivering steady gains to their investors for some years, at the cost of
accepting massive risk in relation to improbable sequences of events, such
as Russia defaulting on her loans at the same time as a far eastern
collapse, etc. At the point they went under, they had obligations of $3
billion and their system told them that they had simply to assume further
obligations of $100 billion to keep their book level. Similarly, my
hypothetical gambler might tell the casino that if they would only increase
his credit limit by 2^n+1, all would be well. There comes a point at which
reality calls a halt. So while I daresay some at LTCM would argue that

Post by Rahul Jain
... it was the fact that people got scared and started pulling their
money out that caused them to lose their money ...

I think that would only show their continuing misunderstanding of their true
situation.

Yours faithfully
Niall Ross

[Peter Seibel]

Post by d***@runbox.com
I'm trying to decide between learning Lisp and Smalltalk.
I'm primarily interested in insights from people who have worked
with both.

I haven't ever used Smalltalk in anger but I've read about it quite a
bit and spent a year pair-programming (in Java) with an ex-Smalltalker
and got to hear all his rants about why it kicks Java's butt (which it
does). So I think I'm reasonably well qualified to say this: Both
Smalltalk and Common Lisp are miles ahead of the next other likely
choices so you can't really go too far wrong no matter which you
choose. Learn either one. Someday learn the other one and then you'll
understand the first one better.

-Peter

[Pascal Costanza]

Post by d***@runbox.com
I've refactored my question in an attempt to better focus the
responses. Specifically, I've made it a first person question to take
out some of the team and mentor issues and added some more detail about
I'm trying to decide between learning Lisp and Smalltalk.
I'm primarily interested in insights from people who have worked with
both.
I'm not a programmer, but wish to become one.
I will learn only one of the languages (at this point in time.)
Philosophically, I'm not interested in becoming a 'language collector,'
a computer scientist, or developing a 'hobby' - but I am VERY
interested in getting real work done by writing my own applications.
Ideally, I therefore want the one language I choose to learn to be able
to handle anything I intend to do now or in the future.

"If you give someone Fortran, he has Fortran. If you give someone Lisp,
he has any language he pleases." - Guy Steele

Post by d***@runbox.com
Someone (Avi?) once wrote that Lisp is multi-paradigm while Smalltalk
is not, but that since the one paradigm Smalltalk uses is so powerful,
you can get almost all of the benefits without all the attendant
complexity. That appeals to me. On the other hand, the power of Lisp
is seductive.

You have to be careful how these statements are worded. Just because a
language is multi-paradigm does'nt mean it's flexible. Just because a
language is object-oriented doesn't mean it's simple. Just because a
language is statically typed doesn't mean it's safe. And so on.

Such technical attributions are just there to give you a very rough
description of the characteristics of a language. But no matter what
characteristics a language has it can still be a shitty language.

This means that the question whether a language is actually _good_ or
not cannot be answered in such terms. The art of language design lies in
the way how to take a number of features and combine them into a usable
whole. Just like in good art you cannot pinpoint why something is
actually well-designed. And just like in the arts it's all _also_ a
matter of taste.

Your question roughly sounds like this: "I will only learn one musical
instrument, and I want to be able to play all kinds of music on it.
Which one will help me to play beautiful music."

All we can say is that a Casio sythesizer for 100$ will probably not cut
it. Whether you will prefer a violin or a piano (or something else?) is
something that you have to decide on your own.

Post by d***@runbox.com
If I'm trying to look on the bright side, I can note (as Espen does),
that my systems analysts are not biased or coming in with preconceived
ideas about language syntax, etc. This makes me wonder which is a
better first language for them (and myself)...Smalltalk because it is
simpler, or Lisp because I don't want to 'hardwire their brains'
with doing everything one certain way...?

Try the piano and see whether you like it or not. ;)



Pascal

[Jonathan Bartlett]

Post by d***@runbox.com
I will learn only one of the languages (at this point in time.)
Philosophically, I'm not interested in becoming a 'language collector,'
a computer scientist, or developing a 'hobby' - but I am VERY
interested in getting real work done by writing my own applications.

This is shooting for disaster. Race car drivers can usually know enough
about the car itself that they could build it from scratch if they
wanted to. If you are wanting to become a programmer but don't want to
invest the time to truly learn how it works, I forsee disastrous
problems continually popping up in your work that each take weeks to solve.

Post by d***@runbox.com
Ideally, I therefore want the one language I choose to learn to be able
to handle anything I intend to do now or in the future.

There isn't one. Lisp is probably closest. However, the best
environment to program in without learning real programming is probably
Delphi.

Post by d***@runbox.com
Someone (Avi?) once wrote that Lisp is multi-paradigm while Smalltalk
is not, but that since the one paradigm Smalltalk uses is so powerful,
you can get almost all of the benefits without all the attendant
complexity. That appeals to me. On the other hand, the power of Lisp
is seductive.

I would disagree with this assessment on nearly all counts.

Post by d***@runbox.com
I do not have a full understanding of the benefits and downsides of
multi-methods, encapsulation, call-cc, etc. (To reiterate: I'm not
a programmer.) I have a very basic understanding of what they all
mean, but not a practical understanding that would keep me from
shooting my own feet off with unnecessary complexity or creating
debugging nightmares.

The main issue is that when you develop complex software, you need tools
to handle the complexity. I think such evaluations by someone who is
not yet a programmer is not useful. I would suggest you become a
programmer, try a few languages, and then make that evaluation. It's
tough enough to explain such things to to people who are new
programmers, explaining them to a non-programmer is simply a waste of
time. After you've pushed out some code, you will be in a much better
position to understand.

Post by d***@runbox.com
I realize that this stuff gets into language holy war debate territory
over language design, but I'm trying to understand what I'm getting
myself into with Lisp and Smalltalk - and which is best suited for my
specific goals.

Then learn both and _then_ choose.

Post by d***@runbox.com
I guess I'm operating under the assumption that Smalltalk is better
for modeling standard business processes (all objects, all the time),
while Lisp is better for the more computationally/algorithmically
intense stuff like NLP.

Nope. Lisp is better for managed complexity. Smalltalk is better for
GUI-based projects. However, both are better than most other languages
for most projects. However, I would probably use Python instead of
Smalltalk, since it is newer (but based on smalltalk), has some import
of Lisp features, and has a larger user community (yes, that _is_ a factor).

Post by d***@runbox.com
So, given the strengths of each, which is the better choice for someone
who wants to be able to accomplish the tasks stated below with the
shortest learning curve and least complexity? Which is going to offer
the most productivity for someone that is programming mainly, say,
accounting systems, but with some NLP/AI stuff thrown in every once in
awhile?

You're planning on doing AI but don't want to bother with computer
science?!?!?!?

I really suggest you start programming _first_, and then worry about
everything else.

Jon
----
Learn to program using Linux assembly language
http://www.cafeshops.com/bartlettpublish.8640017

[Alan Knight]

It not only gets into language war territory, it pretty much defines it.
But you don't seem to have any Smalltalk responses, and it's lunchtime...

My personal recommendation would be Smalltalk, but that's pretty
predictable, as I work for a commercial Smalltalk vendor. But I'd also
agree with most of the people here that either is a quite reasonable
choice. The two have a gret deal in common. People have done lots of
business modelling in LISP. People have done lots of computational
linguistics in Smalltalk. (There was one I ran into called Lingomotors
doing it fairly recently, in the context of search engines, but I think
they went under in the great post-dot-com bust)

A couple of my reasons for picking Smalltalk would be
- simplicity. Not so much at the language level, though I do think
Smalltalk's OOP mechanisms are simpler than LISP's. But more that
simplicity is a fundamental aesthetic in the Smalltalk world.
- syntax. We're completely into language war territory here, but one of
the things I like a lot about Smalltalk is that (if written well, and
there are a couple of exceptions, but still...) Smalltalk code
transliterates very well into English. Better, to my mind, than anything
using a function call notation, which includes not only LISP, but most of
the "normal" syntax languages.

As an aside, one of the things that I like about Smalltalk (I think this
holds true for LISP as well) is the lack of a need for domain-specific
languages. Because the language is so extensible, you end up creating
what is in effect a domain-specific language, it's just that it's still
part of the main language. See, e.g.
http://www.martinfowler.com/bliki/DomainSpecificLanguage.html

I agree that Seaside is pretty cool, but I don't know the LISP equivalent
to compare.

As a caveat, I'd note that VisualWorks GUI currently, rather, um, stinks
on OS X. This is something we're working on, and there's a workaround
using the Mac's X11 support, but fixing it properly is requiring a fairly
thorough rewrite of that layer to better integrate with the Mac
facilities. Real soon now.

Post by d***@runbox.com
I've refactored my question in an attempt to better focus the
responses. Specifically, I've made it a first person question to take
out some of the team and mentor issues and added some more detail about
I'm trying to decide between learning Lisp and Smalltalk.
I'm primarily interested in insights from people who have worked with
both.
I'm not a programmer, but wish to become one.
I will learn only one of the languages (at this point in time.)
Philosophically, I'm not interested in becoming a 'language collector,'
a computer scientist, or developing a 'hobby' - but I am VERY
interested in getting real work done by writing my own applications.
Ideally, I therefore want the one language I choose to learn to be able
to handle anything I intend to do now or in the future.
Since I'm focused on real-world productivity, if I can get 90% of the
benefit of something with only 50% of the complexity, and still achieve
my goals, then that is a GOOD tradeoff for me.
Someone (Avi?) once wrote that Lisp is multi-paradigm while Smalltalk
is not, but that since the one paradigm Smalltalk uses is so powerful,
you can get almost all of the benefits without all the attendant
complexity. That appeals to me. On the other hand, the power of Lisp
is seductive.
I do not have a full understanding of the benefits and downsides of
multi-methods, encapsulation, call-cc, etc. (To reiterate: I'm not
a programmer.) I have a very basic understanding of what they all
mean, but not a practical understanding that would keep me from
shooting my own feet off with unnecessary complexity or creating
debugging nightmares.
I realize that this stuff gets into language holy war debate territory
over language design, but I'm trying to understand what I'm getting
myself into with Lisp and Smalltalk - and which is best suited for my
specific goals. I realize that more powerful and flexible features
also tend to have greater costs if you misuse them (like weapons),
but...?
I guess I'm operating under the assumption that Smalltalk is better
for modeling standard business processes (all objects, all the time),
while Lisp is better for the more computationally/algorithmically
intense stuff like NLP.
So, given the strengths of each, which is the better choice for someone
who wants to be able to accomplish the tasks stated below with the
shortest learning curve and least complexity? Which is going to offer
the most productivity for someone that is programming mainly, say,
accounting systems, but with some NLP/AI stuff thrown in every once in
awhile?
I'm interested in the idea (from Andreas and Wade) of creating a DSL
using Lisp or Smalltalk that would allow me to farm work out to my team
of business analysts. But I'm not sure if that is practical for this
situation?
If I'm trying to look on the bright side, I can note (as Espen does),
that my systems analysts are not biased or coming in with preconceived
ideas about language syntax, etc. This makes me wonder which is a
better first language for them (and myself)...Smalltalk because it is
simpler, or Lisp because I don't want to 'hardwire their brains'
with doing everything one certain way...?

[Wade Humeniuk]

Post by Alan Knight
A couple of my reasons for picking Smalltalk would be
- simplicity. Not so much at the language level, though I do think
Smalltalk's OOP mechanisms are simpler than LISP's. But more that
simplicity is a fundamental aesthetic in the Smalltalk world.

I am curious. In this particular case the application is supposed
to help find fraud and other dangerous financial activities. The people
involved are devious, intelligent, deliberately inconsistent and
constantly change tactics. Is it even possible to model this type
of behaviour with OO techniques? An extremely messy situation
handled by a simple system?

Wade

[Hans-Martin Mosner]

Wade Humeniuk <whumeniu+anti+***@telus.net> wrote:
...

Post by Wade Humeniuk
I am curious. In this particular case the application is supposed
to help find fraud and other dangerous financial activities. The people
involved are devious, intelligent, deliberately inconsistent and
constantly change tactics. Is it even possible to model this type
of behaviour with OO techniques? An extremely messy situation
handled by a simple system?

The question is not whether the analysis system is simple (it probably
should not be) but whether the programming system is simple to work with.
This covers both initial design and implementation of the algorithms as
well as debugging and maintenance. And a programming system which
throws its own complexity into the game just makes the game harder. So
simple is better here.

That said, of course the analysis system will not be simple. It will
probably consist of several stages of natural language processing,
pattern matching, rule evaluation and whatever. The goal should be to
make the system transparent in all of these stages. When the object
model of the application matches the mental model of the analysts most
closely, they have a chance of understanding why their application
behaves as it does and not as it should. Every layer of abstraction and
indirection and overgeneralization makes it more difficult.

Cheers,
Hans-Martin

[d***@runbox.com]

Thank you!

That goes to the heart of the matter of what I've been trying to say.
Very lucid.

Quoted text:
"The question is not whether the analysis system is simple (it probably
should not be) but whether the programming system is simple to work
with.
This covers both initial design and implementation of the algorithms as
well as debugging and maintenance. And a programming system which
throws its own complexity into the game just makes the game harder. So
simple is better here."

[Christopher C. Stacy]

Post by Wade Humeniuk
I am curious. In this particular case the application is supposed
to help find fraud and other dangerous financial activities. The people
involved are devious, intelligent, deliberately inconsistent and
constantly change tactics. Is it even possible to model this type
of behaviour with OO techniques? An extremely messy situation
handled by a simple system?

Fraud detection is not simple, but it was one of the most popular
and successful application areas for Lisp in the 1980s (for phone
companies, credit cards, etc.) I don't know if stock fraud is
really the same kind of thing, though. I guess they're going to
look for patterns in corporate accounting across multiple entities.

[d***@runbox.com]

Great point ;-)

But if I can get a great productivity advantage by using Smalltalk to
model the more standardized components of the software (accounting,
groupware, etc.), then perhaps I can use Lisp (and mentors) to help me
with the AI/NLP components down the road...and maybe I can even use
Smalltalk to model these behaviors by then?

I intend to start with the less challenging parts of my problem domain
first, so that I can learn on simpler concepts. The simpler concepts
are obviously the regular business software type stuff, not the AI/NLP
stuff.

I realize that someone said that Lisp is just as well suited for the
regular business stuff as is Smalltalk, but it doesn't seem to be, at
least from the outset to a complete newbie.
You get into modeling real world "objects" very quickly in Smalltalk -
it is a nice, consistent abstraction - whereas the idea of modeling a
groupware or workflow system in Lisp using O-O seems light years beyond
me. And I've read the same amount about both languages! Making a
calculator seems like it would be easier to do in Lisp versus
Smalltalk, but that's about it at this point in my education.

People don't really seem to program "off-the-rack," common business
software in Lisp. But they do in Smalltalk. If they are equally
capable at this task, why is that? Is it just a philosophical
difference or a historical one or what?

[Marc Battyani]

Post by d***@runbox.com
I realize that someone said that Lisp is just as well suited for the
regular business stuff as is Smalltalk, but it doesn't seem to be, at
least from the outset to a complete newbie.
You get into modeling real world "objects" very quickly in Smalltalk -
it is a nice, consistent abstraction - whereas the idea of modeling a
groupware or workflow system in Lisp using O-O seems light years beyond
me.

I'm doing exactly that for banks: web based/groupware/workflow/document
generation/risk analysis/etc.
I also write traceability software mostly for medical/biological firms and
robot driving/data acquisition for ultrasound testing in steel factories.
All this is done 100% in Common Lisp and several big consulting companies
have admitted that they could not have written it in Java even with 20 times
more man days. :) (In particular they couldn't figure how to do the
simultaneous views update in HTML browsers and the instantaneous
transmission of changed data in HTML interfaces)

Post by d***@runbox.com
And I've read the same amount about both languages! Making a
calculator seems like it would be easier to do in Lisp versus
Smalltalk, but that's about it at this point in my education.
People don't really seem to program "off-the-rack," common business
software in Lisp. But they do in Smalltalk. If they are equally
capable at this task, why is that? Is it just a philosophical
difference or a historical one or what?

It's just that it's not published. Not enough time for that. My web site has
been outdated for several years and I can't even find enough time to publish
the new versions of cl-pdf and cl-typesetting :(

Marc

[d***@runbox.com]

Marc Battyani wrote:

"I'm doing exactly that for banks: web
based/groupware/workflow/document
generation/risk analysis/etc. I also write traceability software
mostly for medical/biological firms and robot driving/data acquisition
for ultrasound testing in steel factories. All this is done 100% in
Common Lisp and several big consulting companies have admitted that
they could not have written it in Java even with 20 times more man
days. :)"

So, let me understand this...you are creating all sorts of beautiful
music, but you only use one instrument?!!! (Just kidding.)

That is very good to know that someone is using Lisp for that sort of
thing, but based on your contributions to the community, I think you're
a very advanced Lisp wizard ;-)

Do you think someone just starting out can understand how to start
modeling workflow/groupware software in Lisp? Again, it seems that in
Smalltalk you start modeling real world objects right off the bat...it
has the simple abstraction. I wouldn't be able to do anything
successfully in Smalltalk yet, of course, but I do understand HOW it
would work - whereas with Lisp I can't imagine where to begin. Does
it start coming together when you get into CLOS stuff, or...?

Mark Battyani wrote:

"(In particular they couldn't figure how to do the simultaneous views
update in HTML browsers and the instantaneous transmission of changed
data in HTML interfaces)"

This intrigues me. I'm not 100% sure what you mean, but I recently
asked a question about (draggable portlets and) avoiding roundtrips to
the server for HTML UIs on c.l.s. - does your solution rely on
Javascript or...?

Thanks,
Sergei

[Pascal Bourguignon]

Post by d***@runbox.com
Do you think someone just starting out can understand how to start
modeling workflow/groupware software in Lisp?

Modeling is not done in Lisp or in Smalltalk. Implementation is.
Modeling is done in UML with Objecteering, Rational or ArgoUML.

Post by d***@runbox.com
Again, it seems that in
Smalltalk you start modeling real world objects right off the bat...it
has the simple abstraction. I wouldn't be able to do anything
successfully in Smalltalk yet, of course, but I do understand HOW it
would work - whereas with Lisp I can't imagine where to begin. Does
it start coming together when you get into CLOS stuff, or...?

What difference in modeling do you see between:

PjbObject subclass: invoiceLine
instanceVariableNames: 'description currency amountHt vatRate
amountVat amountTtc'
classVariableNames: ''
poolDictionaries: ''
category: 'Invoice Frameword'!

PjbObject subclass: invoice
instanceVariableNames: 'date issuerFiscalId invoiceNumber
payerFiscalId title currency
lines totalHt totalVat totalTtc'
classVariableNames: 'allInvoices'
poolDictionaries: ''
category: 'Invoice Frameword'!

and

(defclass* invoice-line pjb-object
(description currency amount-ht vat-rate amount-vat amount-ttc))

(defclass* invoice pjb-object
(date issuer-fiscal-id invoice-number payer-fiscal-id title currency
lines total-ht total-vat total-ttc)
(all-invoices))

(*) ?


I believe now is the time to stop talking and start learning these
programming languages.





[*] Assuming this language-dumbing-down macro:

(defmacro defclass* (name super &optional inst-attr clas-attr)
`(defclass ,name (,super)
,(append
(mapcar (lambda (attr)
`(,attr :initarg ,(intern (string attr) "KEYWORD")
:accessor ,attr))
inst-attr)
(mapcar (lambda (attr)
`(,attr :initarg ,(intern (string attr) "KEYWORD")
:accessor ,attr :allocation :class))
clas-attr))))

If you wanted to, you could even write:

;; PjbObject subclass: invoiceLine
;; instanceVariableNames: 'description currency amountHt vatRate
;; amountVat amountTtc'
;; classVariableNames: ''
;; poolDictionaries: ''
;; category: 'Invoice Frameword'!


(subclass pjb-object invoice-line
:instance-variable-names: (description currency amount-ht vat-rate
amount-vat amount-ttc))

(subclass pjb-object invoice
:instance-variable-names (date issuer-fiscal-id invoice-number
payer-fiscal-id title currency
lines total-ht total-vat total-ttc)
:class-variable-names (all-invoices))

with this macro:

(defmacro subclass (super name &key instance-variable-names
class-variable-names)
`(defclass ,name (,super)
,(append
(mapcar (lambda (attr)
`(,attr :initarg ,(intern (string attr) "KEYWORD")
:accessor ,attr))
instance-variable-names)
(mapcar (lambda (attr)
`(,attr :initarg ,(intern (string attr) "KEYWORD")
:accessor ,attr :allocation :class))
class-variable-names))))

Note that these macros can easily be written by experienced Lisp
programmers, but can still be used by domain specialists.

[Niall Ross]

Dear Pascal,

Post by Pascal Bourguignon

Post by d***@runbox.com
Do you think someone just starting out can understand how to start
modeling workflow/groupware software in Lisp?

Modeling is not done in Lisp or in Smalltalk. Implementation is.
Modeling is done in UML with Objecteering, Rational or ArgoUML.
...

I could not disagree more strongly. If your models are not executable, they
will not help you discover what is wrong with your first ideas; they will
merely delay the moment when you start learning that, wasting valuable
opportunity cost. If they are executable, why are you wasting time coding
in a modelling language instead of in the implementation language? If the
implementation language obstructs understanding instead of helping you gain
it, then you should not have chosen it. The whole point of choosing
Smalltalk (my recommendation) or Lisp (a much better choice than almost any
other) is to avoid that problem.

In an agile methods approach (which I strongly recommend), you express your
opinions of what should happen in tests, then let the code teach you. _If_
any part of your system will impose a tax on refactoring _then_
configure-controlled up-front modelling may be prudent. (So, for example,
if you planned to build distinct parts of the system in Smalltalk and Lisp
and knew that it would organisationally or otherwise non-trivial to move
small chuncks of behaviour between the two then it would be worth investing
time modelling that interface.) Where refactoring is easy, keep your
up-front non-executable artefacts lightweight, express your ideas as tests,
get to code quickly, and expect to _discover_ the right answer, not just
implement it.

I've been down the UML route (as user and as researcher) and have come back,
satisfied that it is not the way. It is just a tax on refactoring.

Yours faithfully
Niall Ross

[Thomas Gagne]

<snip>

Post by Pascal Bourguignon
Modeling is not done in Lisp or in Smalltalk. Implementation is.
Modeling is done in UML with Objecteering, Rational or ArgoUML.

Modeling is done all the time in the Smalltalk IDE. It's so easy to build and
play with objects there's little need wasting time drawing pictures you can't
play with in UML.
<snip>

Post by Pascal Bourguignon
PjbObject subclass: invoiceLine
instanceVariableNames: 'description currency amountHt vatRate
amountVat amountTtc'
classVariableNames: ''
poolDictionaries: ''
category: 'Invoice Frameword'!
PjbObject subclass: invoice
instanceVariableNames: 'date issuerFiscalId invoiceNumber
payerFiscalId title currency
lines totalHt totalVat totalTtc'
classVariableNames: 'allInvoices'
poolDictionaries: ''
category: 'Invoice Frameword'!

That's a pretty unfair code example. Though it is Smalltalk code it is not
what programmers write to create a subclass.

Wwhy be so generous? Why not use opcodes for the code above as a Smalltalk
example and suggest devmail must write those directly?

[Marc Battyani]

Post by Pascal Bourguignon

Post by d***@runbox.com
Do you think someone just starting out can understand how to start
modeling workflow/groupware software in Lisp?

Modeling is not done in Lisp or in Smalltalk. Implementation is.
Modeling is done in UML with Objecteering, Rational or ArgoUML.

Using UML is the best way to spend time and money to insure your project
will never be successful.
I use exactly the opposite method: I just model objects as CLOS classes
within my framework and then the framework draws lots of nice object
diagrams so that even the UML zealots are pleased. For a banking technical
groupware/workflow application the generated documentation has 1400 pages.
(The doc generation is done with cl-typegraph and cl-typesetting). If we had
to write it before writing the application, the application would not even
have been started!

The reality is that before they would have finished to draw these UML
drawings I have finished the data part of the real application with all the
user interfaces and database backing. So they can already play with the
objects ;-)

Marc

[Friedrich Dominicus]

Post by Pascal Bourguignon

Post by d***@runbox.com
Do you think someone just starting out can understand how to start
modeling workflow/groupware software in Lisp?

Modeling is not done in Lisp or in Smalltalk. Implementation is.
Modeling is done in UML with Objecteering, Rational or ArgoUML.

And if you want to live forever try snake oil....

Regards
Friedrich

[Paolo Amoroso]

Post by d***@runbox.com
Do you think someone just starting out can understand how to start
modeling workflow/groupware software in Lisp? Again, it seems that in
Smalltalk you start modeling real world objects right off the bat...it

For some thoughts on how Lispers approach design issues, you may check
this blog entry by Daniel Barlow on protocol-oriented programming:

http://ww.telent.net/diary/2004/8/#30.47349


Paolo

[Rahul Jain]

Post by d***@runbox.com
So, let me understand this...you are creating all sorts of beautiful
music, but you only use one instrument?!!! (Just kidding.)

The key here is that Lisp is not just one instrument. It is a one-man
band, Mark II. A kit of a few commonly-used instruments as well as a set
of tools for creating new ones.

[Marc Battyani]

Post by d***@runbox.com
So, let me understand this...you are creating all sorts of beautiful
music, but you only use one instrument?!!! (Just kidding.)

Well, remember that Lisp is the programmable programming language. So first
you create your instruments and then you just drive them :)

Post by d***@runbox.com
Do you think someone just starting out can understand how to start
modeling workflow/groupware software in Lisp? Again, it seems that in
Smalltalk you start modeling real world objects right off the bat...it
has the simple abstraction. I wouldn't be able to do anything
successfully in Smalltalk yet, of course, but I do understand HOW it
would work - whereas with Lisp I can't imagine where to begin. Does
it start coming together when you get into CLOS stuff, or...?

CLOS is a superset of the usual object paradigm so you can do at least as
well. Things like HTML generation are quite nicely embeddable in Common
Lisp. That why they are so many of them ;-)
The only problem I would see to start with Lisp in your case would be to
have too much choice. There is no pre-made integrated solution. You have to
make your own.

Post by d***@runbox.com
"(In particular they couldn't figure how to do the simultaneous views
update in HTML browsers and the instantaneous transmission of changed
data in HTML interfaces)"
This intrigues me. I'm not 100% sure what you mean, but I recently
asked a question about (draggable portlets and) avoiding roundtrips to
the server for HTML UIs on c.l.s. - does your solution rely on
Javascript or...?

Yes, JavaScript/DHTML on the browser side. I don't have any submit buttons.
The views reflect the status of the objects and are updated when needed. The
object modifications and user actions are immediately sent to the server.

Marc

[BR]

You have to make your own.

A blessing and a curse.

[Paolo Amoroso]

Post by d***@runbox.com
People don't really seem to program "off-the-rack," common business
software in Lisp. But they do in Smalltalk. If they are equally

You may get an idea of how Lisp is used by checking this page:

Industry Application
http://lisp.tech.coop/Industry%20Application

Other relevant pages:

Success Stories
http://lisp.tech.coop/Success%20Stories

Evaluate Lisp
http://lisp.tech.coop/Evaluate%20Lisp


Paolo

[Alan Knight]

Post by Wade Humeniuk

Post by Alan Knight
A couple of my reasons for picking Smalltalk would be
- simplicity. Not so much at the language level, though I do think
Smalltalk's OOP mechanisms are simpler than LISP's. But more that
simplicity is a fundamental aesthetic in the Smalltalk world.

I am curious. In this particular case the application is supposed
to help find fraud and other dangerous financial activities. The
people involved are devious, intelligent, deliberately inconsistent
and constantly change tactics. Is it even possible to model this type
of behaviour with OO techniques? An extremely messy situation
handled by a simple system?
Wade

An interesting premise. One example would be that people do large-scale
trading of complex derivatives using Smalltalk, a domain which has many
(some might say eerily many) similarities.

For a technical description, see e.g.
http://www.whysmalltalk.com/events/nfrESUG2004report.pdf (Note that this
is a large PDF describing an entire conference, the description in
question starts on page 33) or for more buzzword-oriented
http://secure.cwheroes.org/briefingroom_2004/pdf_frame/index.asp?id=4909

[Rahul Jain]

Post by Alan Knight
- simplicity. Not so much at the language level, though I do think
Smalltalk's OOP mechanisms are simpler than LISP's. But more that
simplicity is a fundamental aesthetic in the Smalltalk world.

Depends on if you find "1" simpler than "all". In Lisp, OOP is
consistent with non-OOP in the way you interact with it. (Of course,
you'd need non-dispatched functions in smalltalk to use that, but you
can always pretend that a class is a namespace... oh wait it really is
one... and it's a scope, too... Now... how exactly do I inherit from the
namespace of some class and the type of another, but the scope of
neither?) Also, the various arguments to OOP functions
(generic-funcitons) are consistent with each other.

The extra available complexities (declarative and programmatic method
combination, multiple inheritance, slot merging, powerful MOP, etc) are
only there if you choose to use them, but are already there for you when
you need to use them. Writing a method-combination system for Smalltalk
probably isn't that simple. :)

[Wade Humeniuk]

Just thought I would point you to a few more links of
useful and unusual Lisp software.

Loom: http://www.isi.edu/isd/LOOM/
Screamer: http://www.cis.upenn.edu/~screamer-tools/screamer-intro.html

and though not directly Lisp related, a book:

Artificial Intelligence: A Modern Approach

http://aima.cs.berkeley.edu/

by Peter Norvig

http://www.norvig.com/


Wade

[d***@runbox.com]

I do intend to read books, read code, and write some code to try to get
a better feel for the languages. I never thought the code itself was
going to be a huge stumbling block...I thought the programming
environments and other practical issues were going to be the stumbling
block. The freaking editors scare me more than the code...finding out
that my chosen implementation of a language won't handle something
because of threading support, or OS issues, or " unforeseen X" scares
me more than the code. Feeling like I've wasted years of my life
learning something I will never use scares me...I've done that enought
already ;-)

I am TRYING to manage risk. In part, by speaking to a community of
users instead of just the people selling the tools.

I also thought the learning curve and my business timeframe might be an
issue, so I was trying to get a feel for which
language/environment/community was quicker to get up to speed and
productive with given my problem domain. If I know that someone else
has already tackled a similar problem using X language implementation
on a similar platform, then that encourages me to use that toolset.
Then I can focus on learning that toolset and completing my tasks at
hand, and maybe learn the other language in the future.

When I said I didn't want to be a computer scientist, I only meant that
I'm not interested in learning languages primarily for the intellectual
challenge or for a full-time career as in academia...I AM very willing
to learn the theory and skills that are necessary to be a proficient
programmer and to achieve my practical goals. I don't think you should
have to learn several instruments to play in a band...learning one
instrument allows you to learn quite a bit about music theory in
general, at least enough to start performing. Then, if you choose, you
can learn other instruments - and you have a bit of a headstart in
every one you learn after the first.

And, no, I'm sure that learning to program is not the "best" use of my
time or talents. I will never be a great programmer, or probably even
a decent one. But I've founded and sold three profitable software
companies (I had the idea, financed the idea, marketed the idea, and
sold the company - without ever coding a single line) - and I envied
the programmers the entire time. I guess I would like to be able to
give breath to some of my ideas myself, instead of just handing off the
concepts and blueprints and waiting on someone else to hand me a
"close, but not quite right" instance of my ideas. The communication
overhead is very frustrating. I want to craft my ideas into software
form myself.

I was particularly curious about the strengths and weaknesses of the
two web frameworks I mentioned, because - being a noob - I would like
to have some positive reinforcement as I'm learning to code. Getting
things to work properly is good reinforcement, whereas finding the hard
way that something is not production-ready is not good reinforcement.

I was trying to solicit pointers that might save me problems in the
future, given what I DO know about my goals now.

Knowing that Cincom VW support on OS X is not perfect yet but that
progress is being made is something that is worth knowing now. Knowing
that Smalltalk is or is not good at NLP is worth knowing now (!?)
Knowing that there are people who are using Smalltalk for rules engines
and have exiting code libraries is worth knowing now (thanks for the
pointer, Thomas.)

Links to existing software in CL that focus on similar problem domains
are a good thing (thanks, Wade and Paolo.)

I've just received an order of Lisp books (PAIP, Ansi Common Lisp,
Common Lisp: Gentle Introduction to Symbolic Computation, and Winston &
Horn) and Smalltalk books (On to Smalltalk, Smalltalk with Style, An
introduction to OO Programming and Smalltalk, Dolphin Smalltalk
Handbook, Smalltalk by Example, Smalltalk and OO, Chamond Liu's book,
etc.)

I'm going to order a few more (Peter Seibel's book, On Lisp when the
new edition comes out, etc.)

BTW, I paid less for ALL of the Smalltalk books off of Amazon and ebay
for less than I paid for ONE of the Lisp books ;-)

I tend to do better reading hardcopies of books versus (free) online
versions, so I went ahead and bought quite a few. But I appreciate the
authors who have allowed their work to be put online for the benefit of
all.

[Isaac Gouy]

Post by d***@runbox.com
And, no, I'm sure that learning to program is not the "best" use
of my time or talents. I will never be a great programmer, or
probably even a decent one. But I've founded and sold three
profitable software companies (I had the idea, financed the idea,
marketed the idea, and sold the company - without ever coding a
single line) - and I envied the programmers the entire time. I
guess I would like to be able to give breath to some of my ideas
myself, instead of just handing off the concepts and blueprints and
waiting on someone else to hand me a "close, but not quite right"
instance of my ideas. The communication overhead is very frustrating.
I want to craft my ideas into software form myself.

Humbly suggest that you have a well-proven method for bringing your
ideas to fruition and you should stick to it.

On those previous projects would you have hired a lead-programmer who
had no previous experience programming?

[Pascal Bourguignon]

Post by d***@runbox.com
[...]
The freaking editors scare me more than the code...

Editors is a solved problem: just use an emacs. If something is
missing or molesting, just write some lisp. (Is there any emacs with
Smalltalk as scripting language?)

Post by d***@runbox.com
[...]
BTW, I paid less for ALL of the Smalltalk books off of Amazon and ebay
for less than I paid for ONE of the Lisp books ;-)
[...]

[d***@runbox.com]

Is there a (mature) version of Emacs that allows you to write
extensions using CL instead of Elisp? I read something once about
Climacs or something (?), but I don't think it was ready for use.

Which Emacs-like editor is more user-friendly for people who don't come
from a Unix background? Can you get by just using the LW editors, or
is their a disadvantage to doing that?

[Pascal Bourguignon]

Post by d***@runbox.com
Is there a (mature) version of Emacs that allows you to write
extensions using CL instead of Elisp? I read something once about
Climacs or something (?), but I don't think it was ready for use.

There's Hemlock that's available with cmucl (and PortableHemlock which
should work on some other implementations).
http://www.cliki.net/CL-Emacs

climacs development just started a few months ago.

An alternative could be using emacs with emacs-cl:
http://www.cliki.net/emacs-cl
http://www.lisp.se/emacs-cl/

Post by d***@runbox.com
Which Emacs-like editor is more user-friendly for people who don't come
from a Unix background? Can you get by just using the LW editors, or
is their a disadvantage to doing that?

[John Thingstad]

Post by d***@runbox.com
Is there a (mature) version of Emacs that allows you to write
extensions using CL instead of Elisp? I read something once about
Climacs or something (?), but I don't think it was ready for use.
Which Emacs-like editor is more user-friendly for people who don't come
from a Unix background? Can you get by just using the LW editors, or
is their a disadvantage to doing that?

LispWorks IED editor is based on the functionality of emacs and
is fully customizabe in common lisp.

[Paolo Amoroso]

Post by d***@runbox.com
Is there a (mature) version of Emacs that allows you to write
extensions using CL instead of Elisp? I read something once about
Climacs or something (?), but I don't think it was ready for use.

The most promising, Common Lisp based Emacs-like editor is probably
Climacs:

http://common-lisp.net/project/climacs/

but it's indeed not ready for wide use.


Paolo

[drewc]

***@runbox.com wrote:
[snip]

Post by d***@runbox.com
I was particularly curious about the strengths and weaknesses of the
two web frameworks I mentioned, because - being a noob - I would like
to have some positive reinforcement as I'm learning to code. Getting
things to work properly is good reinforcement, whereas finding the hard
way that something is not production-ready is not good reinforcement.

I use UCW and common lisp to program data-driven web-based business
applications for our members. I've delivered using it, and find it the
quickest way to create reliable web apps with working back buttons :).

If you have any specific questions or want to see some code, feel free
to contact me (drew at tech.coop).

I've never used seaside in production (can't stand the smalltalk
syntax), but it was the first and is probably a great product.

You made a great comment earlier in the thread about musical
instruments. In keeping with that metaphor, Lisp is the language you are
going to want to learn. Lisp is like the piano. In learning lisp you
will learn a lot about programming languages in general, and the skills
and concepts you discover will be easly to translate to a new language.

Once you can play the piano, you have a good idea how music works, and
it's easy to pick up another instument. Find a C, and go from there.

Smalltalk is much more specialized. lets call it a guitar. Great
instrument, quite popular in it's day. It only has 6 strings (the piano
has 88), but those 6 strings can be played in many ways. Once you know
the guitar, the lute, bass, or dulcimer is not that hard, but your
knowlege is very specialized. You'd have problems with vibes or
harpsicord because you'd contantly be trying to relate to the guitar
rather then the music.

So, my suggestion would be piano (I play them both). Once you know Lisp,
every other language is just subset.

drewc

Post by d***@runbox.com
I was trying to solicit pointers that might save me problems in the
future, given what I DO know about my goals now.
Knowing that Cincom VW support on OS X is not perfect yet but that
progress is being made is something that is worth knowing now. Knowing
that Smalltalk is or is not good at NLP is worth knowing now (!?)
Knowing that there are people who are using Smalltalk for rules engines
and have exiting code libraries is worth knowing now (thanks for the
pointer, Thomas.)
Links to existing software in CL that focus on similar problem domains
are a good thing (thanks, Wade and Paolo.)
I've just received an order of Lisp books (PAIP, Ansi Common Lisp,
Common Lisp: Gentle Introduction to Symbolic Computation, and Winston &
Horn) and Smalltalk books (On to Smalltalk, Smalltalk with Style, An
introduction to OO Programming and Smalltalk, Dolphin Smalltalk
Handbook, Smalltalk by Example, Smalltalk and OO, Chamond Liu's book,
etc.)
I'm going to order a few more (Peter Seibel's book, On Lisp when the
new edition comes out, etc.)
BTW, I paid less for ALL of the Smalltalk books off of Amazon and ebay
for less than I paid for ONE of the Lisp books ;-)
I tend to do better reading hardcopies of books versus (free) online
versions, so I went ahead and bought quite a few. But I appreciate the
authors who have allowed their work to be put online for the benefit of
all.

[Niall Ross]

Post by d***@runbox.com
...
I've just received an order of Lisp books (PAIP, Ansi Common Lisp,
Common Lisp: Gentle Introduction to Symbolic Computation, and Winston &
Horn) and Smalltalk books (On to Smalltalk, Smalltalk with Style, An
introduction to OO Programming and Smalltalk, Dolphin Smalltalk
Handbook, Smalltalk by Example, Smalltalk and OO, Chamond Liu's book,
etc.)
...

If the 'etc.' does not already include Kent Beck's 'Smalltalk Best Practice
Patterns' then it should.

Yours faithfully
Niall Ross

[Ted Bracht]

Post by Niall Ross

Post by d***@runbox.com
...
I've just received an order of Lisp books (PAIP, Ansi Common Lisp,
Common Lisp: Gentle Introduction to Symbolic Computation, and Winston &
Horn) and Smalltalk books (On to Smalltalk, Smalltalk with Style, An
introduction to OO Programming and Smalltalk, Dolphin Smalltalk
Handbook, Smalltalk by Example, Smalltalk and OO, Chamond Liu's book,
etc.)
...

If the 'etc.' does not already include Kent Beck's 'Smalltalk Best Practice
Patterns' then it should.
Yours faithfully
Niall Ross

I also strongly suggest "Structure and Interpretation of Computer
Programs by Abelson et all <http://mitpress.mit.edu/sicp/>, not only one
of the best books to learn to program, it also gives you a good flavour
of Lisp (well, Scheme to be precise)

Ted

[d***@runbox.com]

I do not have it yet, but intend to get it...I've been outbid on ebay a
few times ;-)

Thank you.

- Sergei

[Chris Uppal]

Post by d***@runbox.com
I do intend to read books

[...]

Post by d***@runbox.com
I've just received an order of Lisp books (PAIP, Ansi Common Lisp,
Common Lisp: Gentle Introduction to Symbolic Computation, and Winston &
Horn) and Smalltalk books (On to Smalltalk, Smalltalk with Style, An
introduction to OO Programming and Smalltalk, Dolphin Smalltalk
Handbook, Smalltalk by Example, Smalltalk and OO, Chamond Liu's book,
etc.)

Read Chamond Liu's book first (of the Smalltalk ones anyway).

IMO, its one of the best books on OO programming that I've ever read. The
nearest thing the Smalltalk world has to "The Structure and Interpretation of
Computer Programs" (which you didn't mention amongst your Lispy books -- I
/trust/ that's because you've already read it ;-).

-- chris

[Tayssir John Gabbour]

Post by Chris Uppal

Post by d***@runbox.com
I do intend to read books

[...]

Post by d***@runbox.com
I've just received an order of Lisp books (PAIP, Ansi Common Lisp,
Common Lisp: Gentle Introduction to Symbolic Computation, and
Winston & Horn) and Smalltalk books (On to Smalltalk, Smalltalk
with Style, An introduction to OO Programming and Smalltalk,
Dolphin Smalltalk Handbook, Smalltalk by Example, Smalltalk and
OO, Chamond Liu's book, etc.)

Read Chamond Liu's book first (of the Smalltalk ones anyway).
IMO, its one of the best books on OO programming that I've ever
read. The nearest thing the Smalltalk world has to "The Structure
and Interpretation of Computer Programs" (which you didn't
mention amongst your Lispy books -- I /trust/ that's because
you've already read it ;-).

Unfortunately, people often claim that SICP is a recipe for short-term
confusion if you're really wanting to learn Common Lisp. (And I agree.)
It teaches a Scheme dialect which has no macros -- the only mention of
them is in one rather negative footnote. Among other issues.

It should be rather inexpensive to print out Practical Common Lisp at a
copyshop, and I think it has the best explanation of many things.
http://www.gigamonkeys.com/book/

One might also find Casting Spels in Lisp entertaining and thoughtful.
http://www.lisperati.com/casting.html

MfG,
Tayssir

[Edi Weitz]

Post by Tayssir John Gabbour
It should be rather inexpensive to print out Practical Common Lisp
at a copyshop, and I think it has the best explanation of many
things. http://www.gigamonkeys.com/book/

It should also be rather inexpensive to wait a couple of weeks and buy
it. I think that giving advice to steal the book instead of buying it
is really a disservice to the (already rather small) Lisp book market.

Cheers,
Edi.

[Tayssir John Gabbour]

On 22 Jan 2005 09:01:04 -0800, "Tayssir John Gabbour"

Post by Tayssir John Gabbour
It should be rather inexpensive to print out Practical Common Lisp
at a copyshop, and I think it has the best explanation of many
things. http://www.gigamonkeys.com/book/

It should also be rather inexpensive to wait a couple of weeks and
buy it. I think that giving advice to steal the book instead of
buying it is really a disservice to the (already rather small) Lisp
book market.

I had a feeling someone might call my suggestion "advice to steal." The
original poster already mentioned his difficulty reading things on the
web.

- I've preordered despite being able to print it out myself. I assumed
it would help him be more successful in his endeavor, which could only
have the effect of possibly widening the Lisp book market.

- The PDF availability and lack of warnings led me to believe that
Peter had a liberal view of this sort of thing.

- It's not likely to be available very soon. It took forever to obtain
Hackers & Painters after it was released. (I recall it took a while for
Amazon.com to ship.) Having it lie around work would provide
entertaining reading and keep one's eyes peeled at the bookstore.

- For businesses, it's pretty demoralizing to have a ghetto copy when
one can buy it; it looks bad, feels bad, and if they use Lisp, they'll
feel really disrespectful. This was covered in Steve McConnell's Code
Complete.

Now, if I get the impression from Peter that I was in error, I'll
certainly retract my statement.


MfG,
Tayssir

[Peter Seibel]

Post by Tayssir John Gabbour

On 22 Jan 2005 09:01:04 -0800, "Tayssir John Gabbour"

Post by Tayssir John Gabbour
It should be rather inexpensive to print out Practical Common Lisp
at a copyshop, and I think it has the best explanation of many
things. http://www.gigamonkeys.com/book/

It should also be rather inexpensive to wait a couple of weeks and
buy it. I think that giving advice to steal the book instead of
buying it is really a disservice to the (already rather small) Lisp
book market.

I had a feeling someone might call my suggestion "advice to steal."
The original poster already mentioned his difficulty reading things
on the web.

I appreciate both Tayssir's and Edi's advice to the OP. On the one
hand, he can't buy it yet and I'd rather he read it than not, even if
that means printing it out. On the other, of course I'd hope that if
he does read it and likes it he'll buy it when it becomes available in
print either because he wants a nicely bound printed copy or because
he recognizes that it's worth supporting the authors and the
publishers that made it possible for the book to exist. And if he
reads it and doesn't like it, I hope he'll pass his samizdat copy on
to someone who is interested in Lisp so maybe they'll read it, like
it, and, eventually, buy it. This is, of course, my opinion and may or
may not reflect how Apress feels about it.

-Peter

[d***@runbox.com]

Peter,

I've already pre-ordered (multiple copies) via Amazon...which I'd
thought I'd already mentioned (?) So I don't think there is a reason
for anyone to debate...

Although I don't like reading things online, it doesn't take me long to
realize that something is worth purchasing. Your book is very
interesting, whether I ever use Lisp in a commercial setting or not.
Thanks,

- Sergei

[lin8080]

Post by Tayssir John Gabbour

On 22 Jan 2005 09:01:04 -0800, "Tayssir John Gabbour"

Post by Tayssir John Gabbour
It should be rather inexpensive to print out Practical Common Lisp
at a copyshop, and I think it has the best explanation of many
things. http://www.gigamonkeys.com/book/

It should also be rather inexpensive to wait a couple of weeks and
buy it. I think that giving advice to steal the book instead of
buying it is really a disservice to the (already rather small) Lisp
book market.

I had a feeling someone might call my suggestion "advice to steal." The
original poster already mentioned his difficulty reading things on the
web.

Ahja-
You can also take a text2speak program, burning a CD and listen to that
while sitting in your car waiting to drive on, hm?

stefan

[Trent Buck]

Post by lin8080

Post by Tayssir John Gabbour
The original poster already mentioned his difficulty reading things
on the web.

You can also take a text2speak program, burning a CD and listen to that
while sitting in your car waiting to drive on, hm?

I have done this in the past (read books via TTS). It doesn't work for
technical manuals because

- You don't read them at a constant pace (unlike fiction).

- You don't read them linearly -- you flip to the glossary and
appendices, you refer back to earlier passages, you skip examples or
re-read them.

Also, neither code / algorithms nor diagrams translate to speech well.

(The best material for TTS is short fiction; stuff like Lovecraft.)

One thing you *can* do is get a PostScript or PDF book printed by your
local PSP (print service provider). I paid AU$35 to have On Lisp
printed last week. Compared to cloth or card, ring binding isn't great,
but it's easier to handle than the original PostScript file.

Another thing I often do for HTML books is to open them in w3m-el (read:
emacs), and pipe individual paragraphs to TTS with the M-S-| chord.
This works well at home, but it's not portable.

[Rainer Joswig]

Post by Tayssir John Gabbour

Post by Chris Uppal

Post by d***@runbox.com
I do intend to read books

[...]

Post by d***@runbox.com
I've just received an order of Lisp books (PAIP, Ansi Common Lisp,
Common Lisp: Gentle Introduction to Symbolic Computation, and
Winston & Horn) and Smalltalk books (On to Smalltalk, Smalltalk
with Style, An introduction to OO Programming and Smalltalk,
Dolphin Smalltalk Handbook, Smalltalk by Example, Smalltalk and
OO, Chamond Liu's book, etc.)

Read Chamond Liu's book first (of the Smalltalk ones anyway).
IMO, its one of the best books on OO programming that I've ever
read. The nearest thing the Smalltalk world has to "The Structure
and Interpretation of Computer Programs" (which you didn't
mention amongst your Lispy books -- I /trust/ that's because
you've already read it ;-).

Unfortunately, people often claim that SICP is a recipe for short-term
confusion if you're really wanting to learn Common Lisp. (And I agree.)
It teaches a Scheme dialect which has no macros -- the only mention of
them is in one rather negative footnote. Among other issues.

I wouldn't recommend SICP for learning Common Lisp. Actually
SICP isn't about learning a programming language. It is about
learning to develop software. For that purpose it uses
a kind of Scheme as a vehicle. Some Scheme that you can
learn in a very short time - but then the fun begins.

Not using macros is a good thing. It just brings confusion
and hard to debug code to students.

If you do know a bit of Common Lisp, then you will find it useful to
read SICP to get basic knowledge of recursion, iteration,
higher-order functions, symbolic programming, queues, constraints,
logic programming, implementing Scheme, and much more.

Post by Tayssir John Gabbour
It should be rather inexpensive to print out Practical Common Lisp at a
copyshop, and I think it has the best explanation of many things.
http://www.gigamonkeys.com/book/
One might also find Casting Spels in Lisp entertaining and thoughtful.
http://www.lisperati.com/casting.html
MfG,
Tayssir

[Alain Picard]

Post by Tayssir John Gabbour
Unfortunately, people often claim that SICP is a recipe for short-term
confusion if you're really wanting to learn Common Lisp. (And I agree.)

Maybe so. But it's still a marvellous as a book which teaches _programming_.
I certainly don't think there's anything difficult about reading it on it's
own terms and applying said learnings to CL (or SmallTalk, Python, etc. for
that matter).

I'd recommend reading it to any would-be programmer, irrespective of
their final choice of language.

[Tayssir John Gabbour]

Post by Alain Picard

Post by Tayssir John Gabbour
Unfortunately, people often claim that SICP is a recipe for
short-term confusion if you're really wanting to learn Common
Lisp. (And I agree.)

Maybe so. But it's still a marvellous as a book which teaches
_programming_. I certainly don't think there's anything difficult
about reading it on it's own terms and applying said learnings to
CL (or SmallTalk, Python, etc. for that matter).
I'd recommend reading it to any would-be programmer, irrespective of
their final choice of language.

My ambivalence with SICP comes from our b0rken computing culture. Had
computing proceeded well, with community-built things like the
condition system and CLOS+MOP being fairly commonplace, I'd agree that
SICP's a beautiful little minimalistic text.

However, in the really piteous way things are, people use SICP as a
Great Book. A flaming sword in the dark. But it's not, with any
universality. As with any skillful book or entertainment, some people
like it immensely, and I just happen not to be in that group. It's
simply a riff on what one can do with a minimum of well-chosen tools.
Insightful for being a simplification.

It doesn't seriously talk about errorhandling or many other things. And
parens are silly without code-is-data, which is only considered near
the end -- in a section about building your own interpreter, which is
about as interesting to me as becoming a machinist to learn how to
build a lathe.

I dunno. Depressing subject, except the walls of the modern world are
noticeably being chipped away.


MfG,
Tayssir

[Rahul Jain]

"The Structure and Interpretation of Computer Programs" (which you
didn't mention amongst your Lispy books -- I /trust/ that's because
you've already read it ;-).

He's got PAIP, which is SICP for Lisp, both in terms of language and in
terms of motivation.

[Chris Uppal]

Post by Rahul Jain

"The Structure and Interpretation of Computer Programs" (which you
didn't mention amongst your Lispy books -- I /trust/ that's because
you've already read it ;-).

He's got PAIP, which is SICP for Lisp, both in terms of language and in
terms of motivation.

PAIP ?

I realize that there's probably a more explicit ref. somewhere in this large
(and /far/ too excitable) thread-group, but I can't find it looking back. TIA

(BTW, for anyone who cares, I never meant to suggest that SICP was a book
/about/ lisp, only that it was a good book about programming, and /relevant
to/, and indeed a good advert for, lispy languages.)

-- chris

[Bulent Murtezaoglu]

[...]
CU> PAIP ? [...]

http://www.norvig.com/paip.html

(Google does know it, it turns out. It also knows SICP and CLHS. I also
checked SICM: it has one link above it).

cheers,

BM

[Chris Uppal]

Post by Bulent Murtezaoglu
http://www.norvig.com/paip.html

Thanks.

-- chris

[Rahul Jain]

Getting a bit off the original subject, so I'll change the subject line.

Post by Chris Uppal
(BTW, for anyone who cares, I never meant to suggest that SICP was a book
/about/ lisp, only that it was a good book about programming, and /relevant
to/, and indeed a good advert for, lispy languages.)

SICP is a good book about programming for certain goals, to which scheme
is aligned. PAIP is a good book about programming for certain other
goals, to which lisp is aligned. There is definitely some overlap in the
problems and there is a little overlap in the solutions, but there is
quite a bit of scope where they differ.

E.g., the Y combinator is a cool thing to know about and a cool thing to
put in answers to usenet requests for homework answers and definitely
something to show you just how to get turing-completeness using just the
lambda calculus. But it's hardly a way to write efficient code. SICP is
about learning about opening your mind to the strange corners that exist
in computing. PAIP is about opening your computer to the strange corners
that exist in your mind.

[Will Hartung]

Post by d***@runbox.com
Since I'm focused on real-world productivity, if I can get 90% of the
benefit of something with only 50% of the complexity, and still achieve
my goals, then that is a GOOD tradeoff for me.

Answer: Neither.

You don't want to be a programmer, programming isn't your goal, and you just
want to Get Things Done.

Then go learn Java or C#/VB.

If you're happy with the Windows platform, C#/VB. If you're not, then Java.

What you want to do is basically what everyone else wants to do: Glue Stuff
together that does what you want. In order to achieve that, you need a lot
of Stuff available to glue togther. Java/C#/VB has a lot of Stuff in terms
of free and commercial libraries, frameworks, and applications that you can
Glue together to Get Things Done.

You don't need the ability to easily craft Stuff from mere bits and build
them up into modern wonders, plus you simply don't have the experience to
pull it off in the short term. Rather you need to bolt Stuff that other
folks have crafted from mere bits and bend them to your will.

While Smalltalk and Lisp are wonderful langauges and have great
environments, they're not as good in the assembling bits together department
simply because they lack the wide array of parts to bolt together. They're
great as a raw material, but you want more finished goods.

Java/C#/VB have a LOT of finished goods.

Any productivity gains that Lisp or Smalltalk may give can't beat the
productivity of using something that's already written.

So, off you go then. I'll look for your: Java or C#: Sucide Mission, Pt III
cross post on c.l.j.p where we can discuss the finer points of that
decision.

Seriously. This is the BMW/Mercedes debate for guy who's looking for a
truck. You need to go to the GM/Ford dealers.

Regards,

Will Hartung
(***@msoft.com)

[Thomas Gagne]

Will Hartung wrote:
<snip>

Post by Will Hartung
So, off you go then. I'll look for your: Java or C#: Sucide Mission, Pt III
cross post on c.l.j.p where we can discuss the finer points of that
decision.

Don't you mean c.l.j.a?

[d***@runbox.com]

Thanks for that suggestion. I think you're probably right from a
business and financial perspective :-(

<BUT>

I don't like Java (or C#...or Microsoft...)

If I'm going to fail miserably, I at least want to enjoy myself on the
way down - and to be able to look at myself in the mirror.

[Darin Johnson]

Post by d***@runbox.com
Philosophically, I'm not interested in becoming a 'language collector,'
a computer scientist, or developing a 'hobby' - but I am VERY
interested in getting real work done by writing my own applications.

Now the question is, will everyone else working on the project feel
the same way?

The reason I ask is that your statement here (and your requirements
elsewhere) lead me to think of the analogy: "I want to build my own
house, but I don't want to learn much carpentry or be an electrician."
In other words, professional programming is a _profession_. You
wouldn't want to write your own legal contracts would you? Believe
me, all of the programs I've seen that had a comment "I learned how to
program while building this" were pretty dismal. Learning all about
arithmetic and compound interest doesn't turn somebody into good
financial accountant; similarly learning the languages and tools for
programming doesn't make a good programmer.

I'm just going to gripe here for a moment, and see if I can shrug off
a few decades of baggage. I see this attitude all over that
programming is easy. Further, they may think that because they're
experts in what they do and they understand the problem that needs to
be solved that they also be able to write good programs to do so.
This just isn't true. What inevitably results is something that only
barely works and is impossible to maintain (think about the
stereotypical brilliant scientist who churns out abysmal Fortran).
Barely working programs that can't be maintained is ok in a hobby, but
disasterous for business. What does work though is if the experts
work alongside the professional programmers, rather than thinking that
they can save a few bucks and do it themselves.

Further this attitude is much more frustrating when the people in
charge of writing paychecks and hiring people have it. Things like
Visual Basic have encouraged this by having managers suddenly think
"wow, I just wrote a program, this isn't nearly as hard as my staff
told me it was."

[d***@runbox.com]

Darin,

I don't think programming is easy, and I've admitted I will probably
never be a very good programmer. I'm not wanting to learn programming
to save some money...I'm definitely losing money in the short-term by
trying to learn to program. And I don't mean, in any way, to demean or
diminish the work or skills of professional programmers. I'm also not
trying to entirely supplant them on this or any other project. And,
again, I AM willing to learn...it is the "thinking like a programmer"
part of the equation that most fascinates me. But productivity is my
primary goal, and I think that bridging some of the communication gap
between programmers, systems analysts, and domain experts will lead to
increased productivity. I DO think that since I understand the problem
domain better than our programmers and system analysts that I can
contribute something to the development process.

I'm just wanting to be able to participate in a part of the process
which I've always been left out of, and to do that I need to learn to
program. As an amateur. Within the framework of a commercial
enterprise. It can't be a bad thing that I'm wanting to better
understand something I'm responsible for managing, can it? Would you
rather I be forcing .NET down everyone's throat because our Microsoft
rep says it's cool and I don't understand anything about it?

That being said, I'm not sure I can help you shrug off any baggage with
my history:
I do write my own law contracts (I went back to school for a law
degree, because I felt "professional" full-time practising attorneys
were a hindrance to the entrepreneurial process) I did build my own
house (twice), the first won an award for environmental design and the
second is a log home that I sold for a nice profit. I got certified as
a CPA, just so I would be more proficient in the operation of our
business. At this point, I've never performed surgery on myself, but
I'm not ruling that out for the future ;-)

[d***@runbox.com]

"At this point, I've never performed surgery on myself, but I'm not
ruling that out for the future ;-) "

No lobotomy jokes, please.

[Arie van Wingerden]

Hi,

it might very well be interesting for you to read "The Road To Lisp" of a
lot of people on http://alu.cliki.net/The%20Road%20to%20Lisp%20Survey

There, a lot of individuals kind of explain why they chose Lisp in the end.
Maybe it can help you with your choice ;-)

Met vriendelijke groet / with kind regards,
Arie van Wingerden

"Lisp is a language for doing what you've been told is impossible"
--- Kent Pitman

Post by d***@runbox.com
I've refactored my question in an attempt to better focus the
responses. Specifically, I've made it a first person question to take
out some of the team and mentor issues and added some more detail about
I'm trying to decide between learning Lisp and Smalltalk.
I'm primarily interested in insights from people who have worked with
both.
I'm not a programmer, but wish to become one.
I will learn only one of the languages (at this point in time.)
Philosophically, I'm not interested in becoming a 'language collector,'
a computer scientist, or developing a 'hobby' - but I am VERY
interested in getting real work done by writing my own applications.
Ideally, I therefore want the one language I choose to learn to be able
to handle anything I intend to do now or in the future.
Since I'm focused on real-world productivity, if I can get 90% of the
benefit of something with only 50% of the complexity, and still achieve
my goals, then that is a GOOD tradeoff for me.
Someone (Avi?) once wrote that Lisp is multi-paradigm while Smalltalk
is not, but that since the one paradigm Smalltalk uses is so powerful,
you can get almost all of the benefits without all the attendant
complexity. That appeals to me. On the other hand, the power of Lisp
is seductive.
I do not have a full understanding of the benefits and downsides of
multi-methods, encapsulation, call-cc, etc. (To reiterate: I'm not
a programmer.) I have a very basic understanding of what they all
mean, but not a practical understanding that would keep me from
shooting my own feet off with unnecessary complexity or creating
debugging nightmares.
I realize that this stuff gets into language holy war debate territory
over language design, but I'm trying to understand what I'm getting
myself into with Lisp and Smalltalk - and which is best suited for my
specific goals. I realize that more powerful and flexible features
also tend to have greater costs if you misuse them (like weapons),
but...?
I guess I'm operating under the assumption that Smalltalk is better
for modeling standard business processes (all objects, all the time),
while Lisp is better for the more computationally/algorithmically
intense stuff like NLP.
So, given the strengths of each, which is the better choice for someone
who wants to be able to accomplish the tasks stated below with the
shortest learning curve and least complexity? Which is going to offer
the most productivity for someone that is programming mainly, say,
accounting systems, but with some NLP/AI stuff thrown in every once in
awhile?
I'm interested in the idea (from Andreas and Wade) of creating a DSL
using Lisp or Smalltalk that would allow me to farm work out to my team
of business analysts. But I'm not sure if that is practical for this
situation?
If I'm trying to look on the bright side, I can note (as Espen does),
that my systems analysts are not biased or coming in with preconceived
ideas about language syntax, etc. This makes me wonder which is a
better first language for them (and myself)...Smalltalk because it is
simpler, or Lisp because I don't want to 'hardwire their brains'
with doing everything one certain way...?

[d***@runbox.com]

Wow...coincidence. I was actually browsing TRTL while you posted that
suggestion!
I wish TRTL was more easily searched, though...

Thank you.

- Sergei

[drewc]

Post by d***@runbox.com
Wow...coincidence. I was actually browsing TRTL while you posted that
suggestion!
I wish TRTL was more easily searched, though...

try the new location : http://lisp.tech.coop/The%20Road%20to%20Lisp%20Survey

and if it's not searchable enough, tell me why and how i can fix it.
drewc

Post by d***@runbox.com
Thank you.
- Sergei

[Don Wells]

Both Lisp and Smalltalk are used by people who are working on
something important and new, with no time to waste. Either one is a
good choice for the work you wish to do.

I have used Lisp for about 10 years and Smalltalk for about 6. From
my point of view I would recommend Smalltalk to you. The critical
issue has nothing to do with technology or packages available for
download. Both languages have people much smarter than either of us
working very hard to develop good free downloads.

To me the key is which you think you can be comfortable with in time
to get your contract finished. It seems like you are thinking that
you find Smalltalk more comfortable, but hate to relinquish the
greater power of Lisp. Don't worry Smalltalk is plenty powerful
enough.

Smalltalk has an excellent book on style by Kent Beck called
"Smalltalk Best Practice Patterns." This little book has a wealth of
Smalltalk experience packed into it and is a good leg up. There are
similar books written for Lisp of course, but I find Beck's book easy
to understand and use.

Of greater concern to me is process. If you are new to programming
you might want to start out learning test driven development (TDD)
along with your new language. I think if you go over to
http://www.xprogramming.com/software.htm you can have a look at what
unit testing frameworks are already available. I personally recommend
you create your own, but if you are just starting out that can be
difficult. Look at the examples and see which you understand the
best. A good unit testing framework that you can enhance yourself can
be a real time saver long term, assuming you embrace the idea of well
tested code.

Emacs is not something to fear. Just open it up and start typing.
Most Emacs you will find these days have a menu bar across the top.
Fear of Emacs is not a good reason to choose Smalltalk.

The good news is that it doesn't matter which language you choose
since you will have made a good choice.

Don Wells
www.extremeprogramming.org

Post by d***@runbox.com
I'm primarily interested in insights from people who have worked with
both.
I'm not a programmer, but wish to become one.

[BR]

Emacs is not something to fear. Just open it up and start typing. Most
Emacs you will find these days have a menu bar across the top. Fear of
Emacs is not a good reason to choose Smalltalk.

TeXmacs.

[Kristof Bastiaensen]

Both Lisp and Smalltalk are used by people who are working on something
important and new, with no time to waste. Either one is a good choice
for the work you wish to do.
<snip>

Hi,

you may be also interested in the Ruby language, which has features of
both lisp and smalltalk. It has the same Object-model as Smalltalk, but a
bit more convenient syntax (IMHO). Also it has several features of other
languages, like lambdas, everything is an expression (lisp), continuations
(scheme), regular expressions and convenient methods in the standard libs
(perl). As a whole, it is very well designed and brought together. I'd
say it is always useful to learn both lisp and smalltalk, but since you
explicitly said you weren't interested in that, I'd give Ruby a go.

Some pointers:
http://www.rubycentral.com/book/
http://www.ruby-lang.org/en/

and of course the newsgroup.

Kristof

[Rahul Jain]

Post by d***@runbox.com
Someone (Avi?) once wrote that Lisp is multi-paradigm while Smalltalk
is not, but that since the one paradigm Smalltalk uses is so powerful,

It's powerful if that's the only paradigm that your application needs.

[d***@runbox.com]

In an attempt to curtail some of the language 'skirmishes' that are
going on, I'd like to reiterate that I'm primarily interested in the
practical aspects that attend a programming project like mine at this
point (vendor support, implementations, preexisting code, thread
support, frameworks, tools, etc.), and not so much the language design
issues. I think the discussion has gotten off-track, whether due to
my own poorly worded questions, or due to people's general passion
about their favorite languages.

I realize that Lisp is a more flexible/powerful language than
Smalltalk. That was never my question. I knew that before I posted
the first question, and I don't know many Smalltalkers who would
dispute that...Smalltalk was, after all, designed in part to be a
language to teach children programming, while Lisp comes from a lambda
calculus/AI-type lineage. I don't know many children that are into
lambda calculus or genetic algorithms ;-)

So, yes, Lisp is powerful and flexible, but...

If I needed to screw in a flathead screw, I would use a flathead
screwdriver that I could purchase at a hardware store. I would not
want to fashion my own tool out of a "perfect metal alloy." Nor would
I want to use a Swiss Army knife. Now, a Swiss Army knife is a more
powerful and flexible tool, because it has multiple screwdrivers and
knives, a file, scissors, and a leather punch,etc. It is a greater
feat of design and engineering. But it is NOT THE BEST TOOL FOR THE
JOB. [Have you ever tried to open a tool on a Swiss Army knife, only
to have to open three others before you find the one you actually
wanted? Have you ever had a Swiss Army knife screwdriver be too short
to reach a given task?]

I marvel at the "programmable programming language," but I was trying
to find out which of the two languages (Lisp and Smalltalk, not
Ruby/Python/PHP/Perl/Java/etc.), was better suited for a programming
team of mostly amateurs in my given problem domain. And which would
provide more support from the community, in the form of preexisting
code and solid tools/vendors/implementations/frameworks.

I now know (thanks to pointers to the JP Morgan and LingoMotors
projects), that Smalltalk is particularly well-suited, like Lisp, to my
problem domain. That is, moreso that most other languages. I also know
that VisualWorks support on OS X is not ideal, but improving. I was
privately emailed about basic threading design using VisualWorks. I've
also learned much about Lisp, why to learn Lisp, and how to begin
learning Lisp. But I've learned less about the practical aspects of
using Lisp than I have about the language design features.

I'd mentioned that I was interested in LispWorks, SBCL, and UnCommon
Web, for example. LispWorks is now probably our only Lisp
implementation option (Windows support is mandatory for one of our
customers. And, yes, I'm aware of Franz and Clisp.) I only just now
realized that Uncommon Web is not currently supported on LispWorks.
THAT is the type of information I am still seeking...but, even moreso,
I am seeking information about specific things you know that might be
an issue for me that I will not find on an public website or without
wasting many hours/months finding out...

Not a total brain dump, mind you, but things that might be pertinent to
someone who doesn't have a Unix background and is beginning a web
project that will have NLP and XML components. How to approach the
problem, what tools you would avoid,etc. What Marc Battyani wrote about
modeling objects as CLOS classes in his framework is an example of
pointing out how they approach a problem. That helps. Pascal Costanza
alerted me to the fact that the LW editor can map to Mac or Emacs key
bindings and is extensible via CL. That helps.

Thanks to everyone who is taking time to help me. I greatly appreciate
it.

- Sergei

P.S.

I'm still cross-posting only because I still want feedback from both
lists, I apologize if any one message is too focused on only one
language or too verbose for those who are uninterested. I'm getting
lots of nice (and some crazy) private messages and posts. Everyone is
helping.

[Wade Humeniuk]

Post by d***@runbox.com
If I needed to screw in a flathead screw, I would use a flathead
screwdriver that I could purchase at a hardware store. I would not
want to fashion my own tool out of a "perfect metal alloy." Nor would
I want to use a Swiss Army knife. Now, a Swiss Army knife is a more
powerful and flexible tool, because it has multiple screwdrivers and
knives, a file, scissors, and a leather punch,etc. It is a greater
feat of design and engineering. But it is NOT THE BEST TOOL FOR THE
JOB. [Have you ever tried to open a tool on a Swiss Army knife, only
to have to open three others before you find the one you actually
wanted? Have you ever had a Swiss Army knife screwdriver be too short
to reach a given task?]

Sergei, in all honesty, you DO NOT KNOW what the job is. Also equating
Common Lisp to a toy like a Swiss Army knife is pretty insulting and
ignorant.

Wade

[d***@runbox.com]

Wade,

Please do not get so offended simply because I'm bad with analogies.
English is my third language, so I sometimes err. Perhaps a better
analogy would be that I do not wish to pay extra for a specialist
physician who has six board certifications when I only need my tonsils
removed. Paying extra as in needless complexity and poor tool support.
Lisp can seem overwhelming in its splendor, so I am concerned about
the learning curve and tool support.

It seems like Lisp is a wonderful building material and blueprint, but
that everyone in the Lisp community wants to cut down the trees and
make their own mortar to build a house, instead of using drywall and
pre-cut lumber or bricks...this makes sense sometimes, but not all the
time. I am simply trying to figure out why this is. I am not making
criticisms as an outsider, but as someone who wants to learn. If it
makes sense to make my own bricks, then I want to learn the best method
;-)

You and many others in the Lisp community have been very helpful, and I
have gotten many private emails from both sides of the fence that have
been very helpful...but I have also gotten seven private emails -
exclusively from Lispers - that are abusive and tell me that I am
doomed to fail and that they will ENJOY seeing me fail, except that
they wish I would fail with another language. (?!) It seems as if the
authors take great joy in being arrogant and condescending. Yet it is
obvious that most have not read much of what I've written about my
willingness to learn and the fact that there WILL be professional
programmers brought in on the project to help us. Most of the
Smalltalkers that have emailed me, on the other hand, have said that my
goal is attainable and have given me pointers on how to achieve it.
Why are Lisp users so DEFEATIST when their language is essentially a
superset of Smalltalk? I had thought smug lisp wienies were a myth,
but they are apparently not? Cultural issues are important to me, so I
ask these questions seriously, not to inflame....

- Sergei

[d***@runbox.com]

Google Groups is DEFINITELY still "beta"

[Wade Humeniuk]

Post by d***@runbox.com
It seems like Lisp is a wonderful building material and blueprint, but
that everyone in the Lisp community wants to cut down the trees and
make their own mortar to build a house, instead of using drywall and
pre-cut lumber or bricks...this makes sense sometimes, but not all the
time. I am simply trying to figure out why this is. I am not making
criticisms as an outsider, but as someone who wants to learn. If it
makes sense to make my own bricks, then I want to learn the best method
;-)

Programming languages and especially Lisp are neither materials nor
blueprints. They belong to a rare class of tools which I suppose
you can call "mental tools". Other things that belong in there are
things like the scientific method, written language and logic.
However programming languages are slightly different in that they
allow external execution of mental constructs. To program
one has to constrain one's thoughts to those which are executable,
you have to become rigorous. If you think your thoughts are
already expressed by some current set of pre-created libraries
(with some orgranizational glue), then you can use whatever you wish,
the problem is for all-intensive purposes solved.

If one applies a mental tool like the scientific method to curing
cancer and the process fails then one does not blame the scientific
method or even the researcher. But already you are showing signs
of blaming Lisp as a mental tool (if you get lost and confused
and you do not get the results you desire). It is not Lisp that will
confuse you, it is your own mental constructs.

From my standpoint you have become too focused on the programming
language and programming tools. One needs to take personal
responsibility instead.


Wade

[Tayssir John Gabbour]

Post by d***@runbox.com
You and many others in the Lisp community have been very helpful,
and I have gotten many private emails from both sides of the fence
that have been very helpful...but I have also gotten seven private
emails - exclusively from Lispers - that are abusive and tell me
that I am doomed to fail and that they will ENJOY seeing me fail,
except that they wish I would fail with another language. (?!) It
seems as if the authors take great joy in being arrogant and
condescending. Yet it is obvious that most have not read much of
what I've written about my willingness to learn and the fact that
there WILL be professionalprogrammers brought in on the project to
help us. Most of theSmalltalkers that have emailed me, on the other
hand, have said that mygoal is attainable and have given me pointers
on how to achieve it.Why are Lisp users so DEFEATIST when their
language is essentially asuperset of Smalltalk? I had thought smug
lisp wienies were a myth,but they are apparently not? Cultural
issues are important to me, so Iask these questions seriously, not
to inflame....

Holy crap! I was actually impressed when you weren't discouraged by
that guy (non-Lisp user?) who claimed programming is a profession.
Because I dislike the idea that "programmers" are supposed to wear
fancy hats and have some pseudo-standard of professionality; we are
just people who use tools. And I thought Lisp rewarded people who come
to the table with few preconceptions.

But apparently these mean-spirited guys from the 1999-2002 period are
still around. So sure, take that as a negative spot against this tool,
because you'll want to enjoy using it.

I've thought about this phenomenon a little, and I think during that
period, Lisp was wiped away from both CS and industry. So people who've
invested a lot in that skill were suddenly in a world of hurt. And
also, the more friendly types sometimes left computing altogether and
became bartenders. (Literally, in one case.) So while wonderful people
remained, there also grew a cesspool of poisonous ones.

What is a mistake but an external thing? It is an interesting
correlation that children are allowed to make the most "mistakes" and
also tend to learn the fastest.


MfG,
Tayssir

[Kenny Tilton]

Post by Tayssir John Gabbour

Post by d***@runbox.com
You and many others in the Lisp community have been very helpful,
and I have gotten many private emails from both sides of the fence
that have been very helpful...but I have also gotten seven private
emails - exclusively from Lispers - that are abusive and tell me
that I am doomed to fail and that they will ENJOY seeing me fail,....

Holy crap!

So you believe him?

kt

[Wade Humeniuk]

Post by Kenny Tilton

Post by Tayssir John Gabbour

Post by d***@runbox.com
You and many others in the Lisp community have been very helpful,
and I have gotten many private emails from both sides of the fence
that have been very helpful...but I have also gotten seven private
emails - exclusively from Lispers - that are abusive and tell me
that I am doomed to fail and that they will ENJOY seeing me fail,....

Holy crap!

So you believe him?

All he has to do is post these abusive emails he is talking about.
I would like to see them. I just ignore claims with no
evidence from an anonymous source.

Wade

[Rahul Jain]

Post by d***@runbox.com
Please do not get so offended simply because I'm bad with analogies.
English is my third language, so I sometimes err. Perhaps a better
analogy would be that I do not wish to pay extra for a specialist
physician who has six board certifications when I only need my tonsils
removed. Paying extra as in needless complexity and poor tool support.
Lisp can seem overwhelming in its splendor, so I am concerned about
the learning curve and tool support.

So why not learn just the things that you need? No one is forcing you to
learn logical pathnames, and you don't need them for your task, so don't
feel compelled to learn them just because they're in the standard. I
thought one of the points of your question was to find out what parts of
the language you needed to know to do what you needed to do.

[d***@runbox.com]

Wade,

Please do not get so offended simply because I'm bad with analogies.
English is my third language, so I sometimes err. Perhaps a better
analogy would be that I do not wish to pay extra for a specialist
physician who has six board certifications when I only need my tonsils
removed. Paying extra as in needless complexity and poor tool support.
Lisp can seem overwhelming in its splendor, so I am concerned about
the learning curve and tool support.

It seems like Lisp is a wonderful building material and blueprint, but
that everyone in the Lisp community wants to cut down the trees and
make their own mortar to build a house, instead of using drywall and
pre-cut lumber or bricks...this makes sense sometimes, but not all the
time. I am simply trying to figure out why this is. I am not making
criticisms as an outsider, but as someone who wants to learn. If it
makes sense to make my own bricks, then I want to learn the best method
;-)

You and many others in the Lisp community have been very helpful, and I
have gotten many private emails from both sides of the fence that have
been very helpful...but I have also gotten seven private emails -
exclusively from Lispers - that are abusive and tell me that I am
doomed to fail and that they will ENJOY seeing me fail, except that
they wish I would fail with another language. (?!) It seems as if the
authors take great joy in being arrogant and condescending. Yet it is
obvious that most have not read much of what I've written about my
willingness to learn and the fact that there WILL be professional
programmers brought in on the project to help us. Most of the
Smalltalkers that have emailed me, on the other hand, have said that my
goal is attainable and have given me pointers on how to achieve it.
Why are Lisp users so DEFEATIST when their language is essentially a
superset of Smalltalk? I had thought smug lisp wienies were a myth,
but they are apparently not? Cultural issues are important to me, so I
ask these questions seriously, not to inflame....

- Sergei

[d***@runbox.com]

Wade,

Please do not get so offended simply because I'm bad with analogies.
English is my third language, so I sometimes err. Perhaps a better
analogy would be that I do not wish to pay extra for a specialist
physician who has six board certifications when I only need my tonsils
removed. Paying extra as in needless complexity and poor tool support.
Lisp can seem overwhelming in its splendor, so I am concerned about
the learning curve and tool support.

It seems like Lisp is a wonderful building material and blueprint, but
that everyone in the Lisp community wants to cut down the trees and
make their own mortar to build a house, instead of using drywall and
pre-cut lumber or bricks...this makes sense sometimes, but not all the
time. I am simply trying to figure out why this is. I am not making
criticisms as an outsider, but as someone who wants to learn. If it
makes sense to make my own bricks, then I want to learn the best method
;-)

You and many others in the Lisp community have been very helpful, and I
have gotten many private emails from both sides of the fence that have
been very helpful...but I have also gotten seven private emails -
exclusively from Lispers - that are abusive and tell me that I am
doomed to fail and that they will ENJOY seeing me fail, except that
they wish I would fail with another language. (?!) It seems as if the
authors take great joy in being arrogant and condescending. Yet it is
obvious that most have not read much of what I've written about my
willingness to learn and the fact that there WILL be professional
programmers brought in on the project to help us. Most of the
Smalltalkers that have emailed me, on the other hand, have said that my
goal is attainable and have given me pointers on how to achieve it.
Why are Lisp users so DEFEATIST when their language is essentially a
superset of Smalltalk? I had thought smug lisp wienies were a myth,
but they are apparently not? Cultural issues are important to me, so I
ask these questions seriously, not to inflame....

- Sergei

[d***@runbox.com]

Wade,

Please do not get so offended simply because I'm bad with analogies.
English is my third language, so I sometimes err. Perhaps a better
analogy would be that I do not wish to pay extra for a specialist
physician who has six board certifications when I only need my tonsils
removed. Paying extra as in needless complexity and poor tool support.
Lisp can seem overwhelming in its splendor, so I am concerned about
the learning curve and tool support.

It seems like Lisp is a wonderful building material and blueprint, but
that everyone in the Lisp community wants to cut down the trees and
make their own mortar to build a house, instead of using drywall and
pre-cut lumber or bricks...this makes sense sometimes, but not all the
time. I am simply trying to figure out why this is. I am not making
criticisms as an outsider, but as someone who wants to learn. If it
makes sense to make my own bricks, then I want to learn the best method
;-)

You and many others in the Lisp community have been very helpful, and I
have gotten many private emails from both sides of the fence that have
been very helpful...but I have also gotten seven private emails -
exclusively from Lispers - that are abusive and tell me that I am
doomed to fail and that they will ENJOY seeing me fail, except that
they wish I would fail with another language. (?!) It seems as if the
authors take great joy in being arrogant and condescending. Yet it is
obvious that most have not read much of what I've written about my
willingness to learn and the fact that there WILL be professional
programmers brought in on the project to help us. Most of the
Smalltalkers that have emailed me, on the other hand, have said that my
goal is attainable and have given me pointers on how to achieve it.
Why are Lisp users so DEFEATIST when their language is essentially a
superset of Smalltalk? I had thought smug lisp wienies were a myth,
but they are apparently not? Cultural issues are important to me, so I
ask these questions seriously, not to inflame....

- Sergei

[Espen Vestre]

Post by Wade Humeniuk
Sergei, in all honesty, you DO NOT KNOW what the job is. Also equating
Common Lisp to a toy like a Swiss Army knife is pretty insulting and
ignorant.

This reminded me of a more than 5 year old posting by Stig Hemmer
(http://groups-beta.google.com/group/comp.lang.lisp/msg/467f30b898a87f58),
where he points out that Lisp is not merely a tool, but a tool-making
tool. A nice anology, worth a re-read!

[d***@runbox.com]

Thanks, Espen. That is a nice analogy...descriptive just like
"programmable programming language." My analogy was apparently not
only poor, but offensive. I hope I have clarified my position a bit
better...or at least not made it worse ;-)

By the way, I have a bookshelf of Java, Python, and REBOL books that
I'm interested in trading for more Lisp and Smalltalk books. I would
especially like another copy of PAIP and Touretzky, and a first copy of
SICP and Kent Beck's Smalltalk Best Practice Patterns. If anyone has
any extras and wants to learn Java/Python/REBOL (for amusement or
employment), please email me directly.

Thank you,
-Sergei

[Pascal Bourguignon]

Post by d***@runbox.com
Thanks, Espen. That is a nice analogy...descriptive just like
"programmable programming language." My analogy was apparently not
only poor, but offensive. I hope I have clarified my position a bit
better...or at least not made it worse ;-)
By the way, I have a bookshelf of Java, Python, and REBOL books that
I'm interested in trading for more Lisp and Smalltalk books. I would
especially like another copy of PAIP and Touretzky, and a first copy of
SICP and Kent Beck's Smalltalk Best Practice Patterns. If anyone has
any extras and wants to learn Java/Python/REBOL (for amusement or
employment), please email me directly.

I would not hold my breath on the possibilities of trading Java books
for Lisp books. You'd better try to pass down these books to other
unsuspecting programmers, and buy Lisp books (or try to exchange them
against a Lisp Machine ;-).

[d***@runbox.com]

Pascal:
"I would not hold my breath on the possibilities of trading Java books
for Lisp books. You'd better try to pass down these books to other
unsuspecting programmers, and buy Lisp books (or try to exchange them
against a Lisp Machine ;-)"

True, but I thought it worth a try, since many must slave in the Java
mines to pay the mortgage :-(

[Will Hartung]

Post by Espen Vestre

Post by Wade Humeniuk
Sergei, in all honesty, you DO NOT KNOW what the job is. Also equating
Common Lisp to a toy like a Swiss Army knife is pretty insulting and
ignorant.

This reminded me of a more than 5 year old posting by Stig Hemmer
(http://groups-beta.google.com/group/comp.lang.lisp/msg/467f30b898a87f58),
where he points out that Lisp is not merely a tool, but a tool-making
tool. A nice anology, worth a re-read!

However, if you are not a tool maker, not interested in tool making, nor
inclined to master the skills necessary to become a tool maker, or your
timeline doesn't have space for you to learn and master those skills, then a
hardware store with perhaps less than perfect but adaptable tools is a
better option.

Regards,

Will Hartung
(***@msoft.com)

[Rahul Jain]

Post by Will Hartung
However, if you are not a tool maker, not interested in tool making, nor
inclined to master the skills necessary to become a tool maker, or your
timeline doesn't have space for you to learn and master those skills, then a
hardware store with perhaps less than perfect but adaptable tools is a
better option.

Unfortunately, he's looking to create one of the most ambitious bits of
software created to date. I'm not sure that simply using off-the-shelf
components will get him where he wants to be. You can use all the
standard lumber and nails you want, but you're not going to be able to
launch a rocket to the moon made of wood, as easy as it is to hammer the
pieces together.

[Chris Uppal]

Post by d***@runbox.com
I only just now
realized that Uncommon Web is not currently supported on LispWorks.
THAT is the type of information I am still seeking...but, even moreso,
I am seeking information about specific things you know that might be
an issue for me that I will not find on an public website or without
wasting many hours/months finding out...

[...]

Post by d***@runbox.com
I'm still cross-posting only because I still want feedback from both
lists

For the more practical stuff, cross-posting is probably not appropriate. I
don't want to wast the Lispers time with detailed discussions of what bits and
bobs work with which Smalltalk vendors' products on which OSes, and I'd hope
that they'd not want to waste my time with similar concerns about Lisp
implementations.

-- chris

[d***@runbox.com]

You are correct, Chris, I will be more careful about cross-posting.