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...?

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?

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.]

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.?

devmail@runbox.com writes:

> 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

-- 
Peter Seibel                                      peter@javamonkey.com

         Lisp is the red pill. -- John Fraser, comp.lang.lisp

devmail@runbox.com writes:

> 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

-- 
Peter Seibel                                      peter@javamonkey.com

         Lisp is the red pill. -- John Fraser, comp.lang.lisp

devmail@runbox.com wrote:

> [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

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.

devmail@runbox.com writes:

> 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
-- 
Please remove just-for-news- to reply via e-mail.

devmail@runbox.com wrote:
> 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.

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

> 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.

> 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

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.

devmail@runbox.com writes:

> [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.


> 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
-- 
Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log
Recommended Common Lisp libraries/tools (see also http://clrfi.alu.org):
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface

> 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.

> 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.

> 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.

> 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.

> 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.

> 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).

> 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

devmail@runbox.com wrote:

> 
> 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

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.


devmail@runbox.com wrote in news:1106283206.658738.216180
@f14g2000cwb.googlegroups.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...?
> 



-- 
Alan Knight [|], Cincom Smalltalk Development
knight@acm.org
aknight@cincom.com
http://www.cincom.com/smalltalk

"The Static Typing Philosophy: Make it fast. Make it right. Make it 
run." - Niall Ross

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.

> 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

Alan Knight wrote:

> 
> 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

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

Wade Humeniuk <whumeniu+anti+spam@telus.net> wrote:
....
> 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

Wade Humeniuk <whumeniu+anti+spam@telus.net> writes:
> 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.

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.

<devmail@runbox.com> wrote in message
news:1106283206.658738.216180@f14g2000cwb.googlegroups.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
(willh@msoft.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?

> 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?

Will Hartung wrote:
<snip>
> 
> 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?

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."

"devmail@runbox.com" <devmail@runbox.com> writes:
> [...]
> 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?)

> [...]
> 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 ;-)
> [...]

-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
You're always typing.
Well, let's see you ignore my
sitting on your hands.

<devmail@runbox.com> wrote in message
news:1106207345.948719.274980@f14g2000cwb.googlegroups.com...
> An appeal to the collective wisdom of c.l.l. and c.l.s:
>
> Assume, for a few terrifying moments, that you are a pointy-haired boss
> put in charge of a team who are expected to implement some fairly
> advanced software using a language they don't know.
>
> Given the set of parameters below, would you choose Lisp or Smalltalk
> for the project...and why?
>
> 1. Most of team members are "systems analysts" (i.e. business and MIS
> majors), not programmers.  No experience with Emacs or Store, etc.
> 2. Project will be internet and intranet software -> browser-based UI.
> 3. Much of functionality is standard business-type stuff (groupware,
> etc.)
> 4. Part of functionality, however, will rely on natural language
> processing of 30,000 or so data feeds, many of which are XML-based.
> 5. Specific implementation choices are between SBCL or LispWorks and
> VisualWorks Smalltalk.
> 6. Would like to benefit from as much open-source code as possible.
> 7. There are only a couple real programmers to mentor the team.
> 8. Would like at least a remote possibility of project succeeding...

I agree with Steve Kelly's analysis:

    "I found Lisp exciting and easy to learn, but Smalltalk even easier.
    I suspect VW Smaltalk's better IDE played a significant role."

My own opinion is best summed up by a quote from Ron Jeffries:

    "I have programmed in a startling number of languages not (almost)
    including Java. There are only two languages worth looking at: Lisp
    and Smalltalk. Lisp makes me think in new ways. Smalltalk makes
    me think in simple ways."

Noting that Lisp also encourages simplicity and Smalltalk also encourages
new thoughts, this is the best summation I know of the qualitative
difference.  Given your project parameters, I think this gives Smalltalk the
edge.  However I remark that by narrowing the choice to Lisp or Smalltalk
you have already made a very good choice, and one that is more important
than which of the two you finally choose.  If the quality of the language
expert available to you differed significantly, that would be more
important.  If, as I understand from your follow-up post, you have your
choice of equally competent Smalltalk or Lisp mentors, I would choose
Smalltalk.

(I will also remark that in its context Ron's 'no other language worth
looking at' was not meant to condemn Python or Ruby for appropriate niches
and as experiments.  You remarked in post rejecting those two for your case
that 'I really dig image-based development'.  That is my view too;  I see it
as something you should give up only if the application has a very good
reason to object to it.)

            Yours faithfully
                Niall Ross

<devmail@runbox.com> wrote

> 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)

> 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

devmail@runbox.com writes:

> 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."

-- 
Darin Johnson
    "Look here.  There's a crop circle in my ficus!"  -- The Tick

devmail@runbox.com wrote:
[snip]
> 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


> 
> 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.
> 

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 ;-)

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?

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.

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

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

No lobotomy jokes, please.

devmail@runbox.com writes:

> 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/


> 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__               _  Software patents are endangering
()  ASCII ribbon against html email (o_ the computer industry all around
/\  1962:DO20I=1.100                //\ the world http://lpf.ai.mit.edu/
    2001:my($f)=`fortune`;          V_/   http://petition.eurolinux.org/

devmail@runbox.com writes:
> 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.

> 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. 

-- 
__Pascal Bourguignon__                     http://www.informatimago.com/

In a World without Walls and Fences, 
who needs Windows and Gates?

Wade Humeniuk <whumeniu+anti+spam@telus.net> wrote in
news:AxdId.39749$06.20006@clgrps12: 

> Alan Knight wrote:
> 
>> 
>> 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 

-- 
Alan Knight [|], Cincom Smalltalk Development
knight@acm.org
aknight@cincom.com
http://www.cincom.com/smalltalk

"The Static Typing Philosophy: Make it fast. Make it right. Make it
run." - Niall Ross 

On 21 Jan 2005 19:17:54 -0800, <devmail@runbox.com> wrote:

> 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.

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

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

<devmail@runbox.com> schreef in bericht
news:1106283206.658738.216180@f14g2000cwb.googlegroups.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...?
>

I accidentally sent the post above from my wife's email account;  any reply
should be sent to this post (removing SPAM trap of course), not the one
above, but can of course just be sent to this newsgroup and
comp.lang.smalltalk - I'll see it soon enough.

            Niall Ross

> <devmail@runbox.com> wrote in message
> news:1106207345.948719.274980@f14g2000cwb.googlegroups.com...
> > An appeal to the collective wisdom of c.l.l. and c.l.s:
> >
> > Assume, for a few terrifying moments, that you are a pointy-haired boss
> > put in charge of a team who are expected to implement some fairly
> > advanced software using a language they don't know.
> >
> > Given the set of parameters below, would you choose Lisp or Smalltalk
> > for the project...and why?
> >
> > 1. Most of team members are "systems analysts" (i.e. business and MIS
> > majors), not programmers.  No experience with Emacs or Store, etc.
> > 2. Project will be internet and intranet software -> browser-based UI.
> > 3. Much of functionality is standard business-type stuff (groupware,
> > etc.)
> > 4. Part of functionality, however, will rely on natural language
> > processing of 30,000 or so data feeds, many of which are XML-based.
> > 5. Specific implementation choices are between SBCL or LispWorks and
> > VisualWorks Smalltalk.
> > 6. Would like to benefit from as much open-source code as possible.
> > 7. There are only a couple real programmers to mentor the team.
> > 8. Would like at least a remote possibility of project succeeding...
>
> I agree with Steve Kelly's analysis:
>
>     "I found Lisp exciting and easy to learn, but Smalltalk even easier.
>     I suspect VW Smaltalk's better IDE played a significant role."
>
> My own opinion is best summed up by a quote from Ron Jeffries:
>
>     "I have programmed in a startling number of languages not (almost)
>     including Java. There are only two languages worth looking at: Lisp
>     and Smalltalk. Lisp makes me think in new ways. Smalltalk makes
>     me think in simple ways."
>
> Noting that Lisp also encourages simplicity and Smalltalk also encourages
> new thoughts, this is the best summation I know of the qualitative
> difference.  Given your project parameters, I think this gives Smalltalk
the
> edge.  However I remark that by narrowing the choice to Lisp or Smalltalk
> you have already made a very good choice, and one that is more important
> than which of the two you finally choose.  If the quality of the language
> expert available to you differed significantly, that would be more
> important.  If, as I understand from your follow-up post, you have your
> choice of equally competent Smalltalk or Lisp mentors, I would choose
> Smalltalk.
>
> (I will also remark that in its context Ron's 'no other language worth
> looking at' was not meant to condemn Python or Ruby for appropriate niches
> and as experiments.  You remarked in post rejecting those two for your
case
> that 'I really dig image-based development'.  That is my view too;  I see
it
> as something you should give up only if the application has a very good
> reason to object to it.)
>
>             Yours faithfully
>                 Niall Ross
>
>

devmail@runbox.com writes:

> 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
-- 
Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log
Recommended Common Lisp libraries/tools (see also http://clrfi.alu.org):
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface

"devmail@runbox.com" <devmail@runbox.com> writes:

> 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
-- 
Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log
Recommended Common Lisp libraries/tools (see also http://clrfi.alu.org):
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface

devmail@runbox.com writes:

> 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
-- 
Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log
Recommended Common Lisp libraries/tools (see also http://clrfi.alu.org):
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface

Dear Pascal,

"Pascal Bourguignon" <spam@mouse-potato.com> wrote in message
news:87fz0um77u.fsf@thalassa.informatimago.com...
> devmail@runbox.com writes:
> > 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

devmail@runbox.com wrote:
> I do intend to read books
[...]
> 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

Chris Uppal wrote:
> devmail@runbox.com wrote:
> > I do intend to read books
> [...]
> > 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

On 22 Jan 2005 09:01:04 -0800, "Tayssir John Gabbour" <tayss_temp2@yahoo.com> wrote:

> 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.

-- 

Lisp is not dead, it just smells funny.

Real email: (replace (subseq "spamtrap@agharta.de" 5) "edi")

"Niall Ross" <nfr@bigwig.net> writes:

> Dear Pascal,
> 
> "Pascal Bourguignon" <spam@mouse-potato.com> wrote in message
> news:87fz0um77u.fsf@thalassa.informatimago.com...
> > devmail@runbox.com writes:
> > > 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.

You're confusing the model of the domain (with the real objects) and
the model of the application, which is a blueprint of the program (and
the program can be automatically generated from this blueprint model).

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

is a blueprint, an application model.  It can be generated into a
program. A partial generated stage would be:

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

--> 
(LET NIL
 (EVAL-WHEN (COMPILE LOAD EVAL)
  (CLOS::ENSURE-CLASS 'INVOICE :DIRECT-SUPERCLASSES
   (LIST (OR (FIND-CLASS 'PJB-OBJECT NIL) 'PJB-OBJECT)) :DIRECT-SLOTS
   (LIST
    (LIST :NAME 'DATE :ACCESSORS '(DATE) :READERS '(DATE) :WRITERS
     '((SETF DATE)) :INITARGS '(:DATE))
    (LIST :NAME 'ISSUER-FISCAL-ID :ACCESSORS '(ISSUER-FISCAL-ID) :READERS
     '(ISSUER-FISCAL-ID) :WRITERS '((SETF ISSUER-FISCAL-ID)) :INITARGS
     '(:ISSUER-FISCAL-ID))
    (LIST :NAME 'INVOICE-NUMBER :ACCESSORS '(INVOICE-NUMBER) :READERS
     '(INVOICE-NUMBER) :WRITERS '((SETF INVOICE-NUMBER)) :INITARGS
     '(:INVOICE-NUMBER))
    (LIST :NAME 'PAYER-FISCAL-ID :ACCESSORS '(PAYER-FISCAL-ID) :READERS
     '(PAYER-FISCAL-ID) :WRITERS '((SETF PAYER-FISCAL-ID)) :INITARGS
     '(:PAYER-FISCAL-ID))
    (LIST :NAME 'TITLE :ACCESSORS '(TITLE) :READERS '(TITLE) :WRITERS
     '((SETF TITLE)) :INITARGS '(:TITLE))
    (LIST :NAME 'CURRENCY :ACCESSORS '(CURRENCY) :READERS '(CURRENCY) :WRITERS
     '((SETF CURRENCY)) :INITARGS '(:CURRENCY))
    (LIST :NAME 'LINES :ACCESSORS '(LINES) :READERS '(LINES) :WRITERS
     '((SETF LINES)) :INITARGS '(:LINES))
    (LIST :NAME 'TOTAL-HT :ACCESSORS '(TOTAL-HT) :READERS '(TOTAL-HT) :WRITERS
     '((SETF TOTAL-HT)) :INITARGS '(:TOTAL-HT))
    (LIST :NAME 'TOTAL-VAT :ACCESSORS '(TOTAL-VAT) :READERS '(TOTAL-VAT)
     :WRITERS '((SETF TOTAL-VAT)) :INITARGS '(:TOTAL-VAT))
    (LIST :NAME 'TOTAL-TTC :ACCESSORS '(TOTAL-TTC) :READERS '(TOTAL-TTC)
     :WRITERS '((SETF TOTAL-TTC)) :INITARGS '(:TOTAL-TTC))
    (LIST :NAME 'ALL-INVOICES :ACCESSORS '(ALL-INVOICES) :READERS
     '(ALL-INVOICES) :WRITERS '((SETF ALL-INVOICES)) :ALLOCATION :CLASS
     :INITARGS '(:ALL-INVOICES)))))
 (DEFMETHOD DATE ((CLOS::OBJECT INVOICE)) (DECLARE (COMPILE))
  (SLOT-VALUE CLOS::OBJECT 'DATE))
 (DEFMETHOD (SETF DATE) (CLOS::NEW-VALUE (CLOS::OBJECT INVOICE))
  (DECLARE (COMPILE)) (SETF (SLOT-VALUE CLOS::OBJECT 'DATE) CLOS::NEW-VALUE))
 (DEFMETHOD ISSUER-FISCAL-ID ((CLOS::OBJECT INVOICE)) (DECLARE (COMPILE))
  (SLOT-VALUE CLOS::OBJECT 'ISSUER-FISCAL-ID))
 (DEFMETHOD (SETF ISSUER-FISCAL-ID) (CLOS::NEW-VALUE (CLOS::OBJECT INVOICE))
  (DECLARE (COMPILE))
  (SETF (SLOT-VALUE CLOS::OBJECT 'ISSUER-FISCAL-ID) CLOS::NEW-VALUE))
 (DEFMETHOD INVOICE-NUMBER ((CLOS::OBJECT INVOICE)) (DECLARE (COMPILE))
  (SLOT-VALUE CLOS::OBJECT 'INVOICE-NUMBER))
 (DEFMETHOD (SETF INVOICE-NUMBER) (CLOS::NEW-VALUE (CLOS::OBJECT INVOICE))
  (DECLARE (COMPILE))
  (SETF (SLOT-VALUE CLOS::OBJECT 'INVOICE-NUMBER) CLOS::NEW-VALUE))
 (DEFMETHOD PAYER-FISCAL-ID ((CLOS::OBJECT INVOICE)) (DECLARE (COMPILE))
  (SLOT-VALUE CLOS::OBJECT 'PAYER-FISCAL-ID))
 (DEFMETHOD (SETF PAYER-FISCAL-ID) (CLOS::NEW-VALUE (CLOS::OBJECT INVOICE))
  (DECLARE (COMPILE))
  (SETF (SLOT-VALUE CLOS::OBJECT 'PAYER-FISCAL-ID) CLOS::NEW-VALUE))
 (DEFMETHOD TITLE ((CLOS::OBJECT INVOICE)) (DECLARE (COMPILE))
  (SLOT-VALUE CLOS::OBJECT 'TITLE))
 (DEFMETHOD (SETF TITLE) (CLOS::NEW-VALUE (CLOS::OBJECT INVOICE))
  (DECLARE (COMPILE)) (SETF (SLOT-VALUE CLOS::OBJECT 'TITLE) CLOS::NEW-VALUE))
 (DEFMETHOD CURRENCY ((CLOS::OBJECT INVOICE)) (DECLARE (COMPILE))
  (SLOT-VALUE CLOS::OBJECT 'CURRENCY))
 (DEFMETHOD (SETF CURRENCY) (CLOS::NEW-VALUE (CLOS::OBJECT INVOICE))
  (DECLARE (COMPILE))
  (SETF (SLOT-VALUE CLOS::OBJECT 'CURRENCY) CLOS::NEW-VALUE))
 (DEFMETHOD LINES ((CLOS::OBJECT INVOICE)) (DECLARE (COMPILE))
  (SLOT-VALUE CLOS::OBJECT 'LINES))
 (DEFMETHOD (SETF LINES) (CLOS::NEW-VALUE (CLOS::OBJECT INVOICE))
  (DECLARE (COMPILE)) (SETF (SLOT-VALUE CLOS::OBJECT 'LINES) CLOS::NEW-VALUE))
 (DEFMETHOD TOTAL-HT ((CLOS::OBJECT INVOICE)) (DECLARE (COMPILE))
  (SLOT-VALUE CLOS::OBJECT 'TOTAL-HT))
 (DEFMETHOD (SETF TOTAL-HT) (CLOS::NEW-VALUE (CLOS::OBJECT INVOICE))
  (DECLARE (COMPILE))
  (SETF (SLOT-VALUE CLOS::OBJECT 'TOTAL-HT) CLOS::NEW-VALUE))
 (DEFMETHOD TOTAL-VAT ((CLOS::OBJECT INVOICE)) (DECLARE (COMPILE))
  (SLOT-VALUE CLOS::OBJECT 'TOTAL-VAT))
 (DEFMETHOD (SETF TOTAL-VAT) (CLOS::NEW-VALUE (CLOS::OBJECT INVOICE))
  (DECLARE (COMPILE))
  (SETF (SLOT-VALUE CLOS::OBJECT 'TOTAL-VAT) CLOS::NEW-VALUE))
 (DEFMETHOD TOTAL-TTC ((CLOS::OBJECT INVOICE)) (DECLARE (COMPILE))
  (SLOT-VALUE CLOS::OBJECT 'TOTAL-TTC))
 (DEFMETHOD (SETF TOTAL-TTC) (CLOS::NEW-VALUE (CLOS::OBJECT INVOICE))
  (DECLARE (COMPILE))
  (SETF (SLOT-VALUE CLOS::OBJECT 'TOTAL-TTC) CLOS::NEW-VALUE))
 (DEFMETHOD ALL-INVOICES ((CLOS::OBJECT INVOICE)) (DECLARE (COMPILE))
  (SLOT-VALUE CLOS::OBJECT 'ALL-INVOICES))
 (DEFMETHOD (SETF ALL-INVOICES) (CLOS::NEW-VALUE (CLOS::OBJECT INVOICE))
  (DECLARE (COMPILE))
  (SETF (SLOT-VALUE CLOS::OBJECT 'ALL-INVOICES) CLOS::NEW-VALUE))
 (FIND-CLASS 'INVOICE)) ;

For a completely generated stage, put it in a file, COMPILE it and
dump the .fas file obtained.



On ther other hand, in the domain model, an invoice could be modelized as:

(defclass** invoice object
  (date issuer-fiscal-id invoice-number payer-fiscal-id title currency lines))

(the totals being computed in methods instead of being attributes of
the instances).


> In an agile methods approach (which I strongly recommend), you express your

Who "you"?  The domain specialists?


> 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.

UML is only a language. You may use to describe stuff in the real
world, or you may use it to describe a computer system.

You may decide that it's not worth describing the real world because
you're not able to describe it fast enough to make a sensible
description, but that's your problem, not that of UML (assuming UML is
fast enough a language to describe some non-trivial real world stuff).

-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
Our enemies are innovative and resourceful, and so are we. They never
stop thinking about new ways to harm our country and our people, and
neither do we. -- Georges W. Bush

In article <1106413264.748178.283810@c13g2000cwb.googlegroups.com>,
 "Tayssir John Gabbour" <tayss_temp2@yahoo.com> wrote:

> Chris Uppal wrote:
> > devmail@runbox.com wrote:
> > > I do intend to read books
> > [...]
> > > 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.


> 
> 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

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

Thank you.

- Sergei

devmail@runbox.com wrote:
> 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


> 
> Thank you.
> 
> - Sergei
> 

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


On 20 Jan 2005 20:53:26 -0800, devmail@runbox.com wrote:

>I'm primarily interested in insights from people who have worked with
>both.
>
>I'm not a programmer, but wish to become one.

On Sat, 22 Jan 2005 18:23:28 -0500, Don Wells wrote:

> 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.

Edi Weitz wrote:
> On 22 Jan 2005 09:01:04 -0800, "Tayssir John Gabbour"
<tayss_temp2@yahoo.com> wrote:
>
> > 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

"Tayssir John Gabbour" <tayss_temp2@yahoo.com> writes:

> 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.

Pascal Bourguignon wrote:
> devmail@runbox.com writes:
> 
<snip>
> 
> 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>
> 
> 
> 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'!
> 

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?

On Sat, 22 Jan 2005 18:23:28 -0500, Don Wells wrote:
> 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

devmail@runbox.com writes:

> 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...

-- 
Rahul Jain
rjain@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist

"devmail@runbox.com" <devmail@runbox.com> writes:

> 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.

Why do you think you can't implement your application without an
extremely small portability layer?

-- 
Rahul Jain
rjain@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist

"Isaac Gouy" <igouy@yahoo.com> writes:

> 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
rjain@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist

devmail@runbox.com writes:

> 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.

-- 
Rahul Jain
rjain@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist

Alan Knight <knight@acm.org> writes:

>   - 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. :)

-- 
Rahul Jain
rjain@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist

devmail@runbox.com writes:

> 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.

-- 
Rahul Jain
rjain@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist

"Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> writes:

> "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.

-- 
Rahul Jain
rjain@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist

"Tayssir John Gabbour" <tayss_temp2@yahoo.com> writes:

> Edi Weitz wrote:
>> On 22 Jan 2005 09:01:04 -0800, "Tayssir John Gabbour"
> <tayss_temp2@yahoo.com> wrote:
>>
>> > 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

-- 
Peter Seibel                                      peter@javamonkey.com

         Lisp is the red pill. -- John Fraser, comp.lang.lisp

Alain Picard wrote:
> "Tayssir John Gabbour" <tayss_temp2@yahoo.com> writes:
> > 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 wrote:

> > "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

>>>>> "CU" == Chris Uppal <chris.uppal@metagnostic.REMOVE-THIS.org> writes:
[...]
    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

<devmail@runbox.com> wrote

> 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 :)

> 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.

> 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...?

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

"Pascal Bourguignon" <spam@mouse-potato.com> wrote:
> devmail@runbox.com writes:
> > 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

Bulent Murtezaoglu wrote:

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

Thanks.

    -- chris

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

On Sun, 23 Jan 2005 21:15:25 +0100, Marc Battyani wrote:

> You have to make your own.

A blessing and a curse.

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.

devmail@runbox.com wrote:

> 
> 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

Up spake lin8080:
> > 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.

-- 
-trent
<foo> I'm off the hard liquor for a while. I gave it up for lent.
<bar> What does lent do to you?
<bar> Does it fuck you up?

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

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

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

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

Google Groups is DEFINITELY still "beta"

Pascal Bourguignon <spam@mouse-potato.com> writes:

> devmail@runbox.com writes:
>> 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

-- 
Please remove just-for-news- to reply via e-mail.

Wade Humeniuk <whumeniu+anti+spam@telus.net> writes:

> 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!
-- 
  (espen)

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

"devmail@runbox.com" <devmail@runbox.com> writes:

> 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 ;-).

-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
The rule for today:
Touch my tail, I shred your hand.
New rule tomorrow.

devmail@runbox.com wrote:

> 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...
[...]
> 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

devmail@runbox.com wrote:

> 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

devmail@runbox.com wrote:
> 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

Tayssir John Gabbour wrote:

> devmail@runbox.com wrote:
> 
>>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

-- 
Cells? Cello? Cells-Gtkk?: http://www.common-lisp.net/project/cells/
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
Land o' Kenny? http://www.tilton-technology.com/index.html

Obligatory quote to make me seem cool:

"Doctor, I wrestled with reality for forty years, and I am happy to 
state that I finally won out over it." -- Elwood P. Dowd

Kenny Tilton wrote:
> 
> 
> Tayssir John Gabbour wrote:
> 
>> devmail@runbox.com wrote:
>>
>>> 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

Tayssir John Gabbour schrieb:
> Edi Weitz wrote:
> > On 22 Jan 2005 09:01:04 -0800, "Tayssir John Gabbour"
> <tayss_temp2@yahoo.com> wrote:

> > > 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

Dear Rahul,

> > 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 be 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 improbably 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

> ... 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

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

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 :-(

"Espen Vestre" <espen@*do-not-spam-me*.vestre.net> wrote in message
news:kw7jm3w6jx.fsf@merced.netfonds.no...
> Wade Humeniuk <whumeniu+anti+spam@telus.net> writes:
>
> > 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
(willh@msoft.com)

"Niall Ross" <nfr@bigwig.net> writes:

> FWIW, my analysis is that LTCM were managing risk by moving risk, while
> under the impression they were managing risk by reducing it.
[...]
> 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
>
>> ... 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.

I see. I was under the impression that they were mostly doing arbitrage
of almost-fungible securities with very different liquidities. I guess I
was mistaken. :)

Thanks for the explanation.

-- 
Rahul Jain
rjain@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist

"devmail@runbox.com" <devmail@runbox.com> writes:

> 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.

-- 
Rahul Jain
rjain@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist

"Will Hartung" <willh@msoft.com> writes:

> 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.

-- 
Rahul Jain
rjain@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist

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

"Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> writes:

> (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.

-- 
Rahul Jain
rjain@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist

BR <brodriguez@comcast.net> writes:

> On Sun, 23 Jan 2005 21:15:25 +0100, Marc Battyani wrote:
>
>> You have to make your own.
>
> A blessing and a curse.

Unfortunately, no one has standardized thought constructs and
information organization. Until that happens, I doubt one could
standardize programmatic constructs within which one structures
information and thoughts.

-- 
Rahul Jain
rjain@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist

Rahul Jain wrote:
"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."

This is very true.  And before I can understand  that I must find out
what parts of the language exist to start with, and maybe find out how
they interoperate, and maybe find out the benefits of each approach for
a given task, or even find out how each implementation might interpret
the standard slightly differently, etc.  etc.

There is a great deal of learning overhead in figuring out how the map
is written, before I can even begin to find my way to my destination.
Lisp is a strange map to me, like a Russian learning Chinese.
Smalltalk's simpler abstraction and terminology is not quite as strange
to me.  It is like a Spaniard learning Portuguese.  Part of my original
question was an attempt to find out if this initial Lisp learning curve
would bring greater benefits to my short-term (2-3 year) future in
regards to my current projects, or if I should concentrate on Smalltalk
only at this point in time.  I tend to focus very intently on things I
am trying to learn, and there are only so many hours in a day.  I knew
all along I wanted to learn both languages eventually - but I thought I
could get more of a "tiebreaker" for which language to start with on
this project by getting a better feel for the landscape.  And that IS
happening.  Both languages are definitely capable of handling anything
I need to do,  I think, so  (as someone else noted) it shouldn't make a
huge difference.

There is also another aspect to the language decision which I have
avoided discussing so far because of secrecy issues and because I
thought it would cloud the discussion.  I have more /specific/
questions (and responses) that I will post later...I have a big day
today meeting with our potential venture investors, so I am rushed for
time now.

Thank you,

- Sergei

comp.lang.smalltalk trimmed for irrelevance...

Rahul Jain <rjain@nyct.net> writes:

> 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.

Both books have a lot to offer and I don't see why one should choose
one over the other.  One should get both!  I suppose with time
constraints, I would spend more time on PAIP than SICP because I am
more into Common Lisp than Scheme.  In an ideal world, I wouldn't make
that compromise.

The SICP lectures posted in another thread:

  http://swiss.csail.mit.edu/classes/6.001/abelson-sussman-lectures/

are pretty cool.  I'm fetching all the Divx encoded ones and burning
them to CD.  I don't have the room for the MPEG versions :-(.

Anyway, I have both in dead tree form and I have spent more time on
PAIP.

-- 
An ideal world is left as an excercise to the reader.
   --- Paul Graham, On Lisp 8.1

A second set of lectures, should a different take prove useful, is
here:
http://aduni.org/courses/sicp/index.php?view=cw

I have no idea about their quality, since I didn't watch them.

MfG,
Tayssir


David Steuber wrote:
> comp.lang.smalltalk trimmed for irrelevance...
>
> Rahul Jain <rjain@nyct.net> writes:
>
> > 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.
>
> Both books have a lot to offer and I don't see why one should choose
> one over the other.  One should get both!  I suppose with time
> constraints, I would spend more time on PAIP than SICP because I am
> more into Common Lisp than Scheme.  In an ideal world, I wouldn't
make
> that compromise.
>
> The SICP lectures posted in another thread:
>
>   http://swiss.csail.mit.edu/classes/6.001/abelson-sussman-lectures/
>
> are pretty cool.  I'm fetching all the Divx encoded ones and burning
> them to CD.  I don't have the room for the MPEG versions :-(.
>
> Anyway, I have both in dead tree form and I have spent more time on
> PAIP.
>
> --
> An ideal world is left as an excercise to the reader.
>    --- Paul Graham, On Lisp 8.1

Trent Buck schrieb:
> Up spake lin8080:

Right. There are some problemes with technical books. Needs time to do
some editing, but who have time for that? Even to rewrite pdf-files.

But well, I have a copy of the HyperSpec and edit that to have frames,
only to flip quickly to the interesting parts. Also I do this to the
CL-Impnotes, but this text updates nearly 2 times a year, so my actual
version is old. 
While typing this, I have logox runing (text2speech) and listen the next
posting, but as you say, this is not portable, at least until now...
Also I have three cds with lisp-oriented books on it for a cdplayer, but
meanwhile I know them by heart.

stefan

Kenny Tilton wrote:
> Tayssir John Gabbour wrote:
> > devmail@runbox.com wrote:
> >>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?

Who cares. It's still entirely plausible that 1-7 smuglispweenies
flamed him privately. So even if he were the Master of Trolls, it's
because he's saying something believable to anyone with half a brain
and comp.lang.lisp experience.

What I don't believe is how some would prefer to waste an interesting
opportunity to know more about the Smalltalk culture, since their goals
tend to be harmonious with Lisp's.

And how would one would go about 'insulting' a tool? How about: "Lisp
is so old, those aren't parentheses, those are wrinkles."

"Lisp programmers write so much trash, no wonder why they developed
garbage collection."

"Lisp is so ugly, most computer geeks wouldn't touch her for free."


I mean, The Daily Show doesn't need the Bush Administration to find
ridiculous new material; they only need to read Usenet. "The first rule
of the ALU is -- you do not talk about the ALU. The second rule of the
ALU is -- you DO NOT talk about the ALU."

But I'm sure Lisp might fail for another 50 years because of some
troll, right? ;) Always some external boogieman bringin' us down, like
Microsoft or Alan Kay, despite the zillions pumped into Lisp/AI during
the Cold War. It's the ESTABLISHMENT, man! The Man is keepin' us down
and all the brainwashed drones don't get it!

But I make fun because I love... Lisp is fun for being insane. The evil
mastermind Alan Kay claimed that a better perspective is worth 80 IQ
points; and a few smug lisp weenies provide us all a lot of
entertainment because they don't realize this IQ boost doesn't apply
all around.

....

MfG,
Tayssir

"devmail@runbox.com" <devmail@runbox.com> writes:

> Rahul Jain wrote:
> "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."
>
> This is very true.  And before I can understand  that I must find out
> what parts of the language exist to start with, and maybe find out how
> they interoperate, and maybe find out the benefits of each approach for
> a given task, or even find out how each implementation might interpret
> the standard slightly differently, etc.  etc.

In CL, most of that happens in the corner cases of the pathname
manipulation functions. You probably won't find them to be all that
useful for you anyway, particularly not the corner cases. :)

> There is a great deal of learning overhead in figuring out how the map
> is written, before I can even begin to find my way to my destination.
> Lisp is a strange map to me, like a Russian learning Chinese.
> Smalltalk's simpler abstraction and terminology is not quite as strange
> to me.  It is like a Spaniard learning Portuguese.

I don't know. You can use the parts of lisp that correspond to the
things you already know and file away the stuff others say is useful in
your project for later investigation. E.g., learn the basic defining and
iterative constructs, list manipulation functions, basic macro usage,
symbols and packages, CLOS, basic arrays (maybe not fill-pointers,
adjustability, or displaced arrays yet), hash tables, and some basic
character stream functionality, maybe. Mostly, going through Peter's
book and skipping stuff that seems to be a bit irrelevant to your uses
will teach you everything you need to get started.

When you're looking to make the code more robust, learn the condition
system. When you're looking to make the build and deployment process
more manageable, learn asdf. As you see more opportunities for
abstraction, learn more advanced macrology, maybe from _On_Lisp_.

Another recommendation: for your development box, it's a lot easier if
you use Debian. It's got dozens of packages for lisp compilers,
libraries, and even a few complete applications.

-- 
Rahul Jain
rjain@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist

David Steuber <david@david-steuber.com> writes:

> Both books have a lot to offer and I don't see why one should choose
> one over the other.  One should get both!  I suppose with time
> constraints, I would spend more time on PAIP than SICP because I am
> more into Common Lisp than Scheme.  In an ideal world, I wouldn't make
> that compromise.

Yes, that was my point :)

Although the Y combinator is the only thing I can think of in SICP that
is useful to read after PAIP, but I didn't read SICP in too much detail,
as I only picked it up seriously after having read PAIP and seeing the
references to how SICP's solutions to those problems were different.

-- 
Rahul Jain
rjain@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist

"Rahul Jain" <rjain@nyct.net> wrote in message 
news:87zmyvy0r9.fsf@nyct.net...
> David Steuber <david@david-steuber.com> writes:
>
>> Both books have a lot to offer and I don't see why one should choose
>> one over the other.  One should get both!  I suppose with time
>> constraints, I would spend more time on PAIP than SICP because I am
>> more into Common Lisp than Scheme.  In an ideal world, I wouldn't make
>> that compromise.
>
> Yes, that was my point :)
>
> Although the Y combinator is the only thing I can think of in SICP that
> is useful to read after PAIP, but I didn't read SICP in too much detail,
> as I only picked it up seriously after having read PAIP and seeing the
> references to how SICP's solutions to those problems were different.


All I found on Y in SICP was a footnote pointing to another
publication.

--
Geoff 

"Geoffrey Summerhayes" <sRuEmMrOnVoEt@hotmail.com> writes:

> All I found on Y in SICP was a footnote pointing to another
> publication.

Heh. Maybe that's all I got out of SICP, then.[1] :P

-- 
Rahul Jain
rjain@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist

[1] Sometimes, the best parts are in the footnotes.

Geoffrey Summerhayes wrote:
> All I found on Y in SICP was a footnote pointing to another
> publication.

SICP has an excercise showing how you could write a recursive factorial
function with just lambdas and function calls, which is a simplified
and expanded case of the Y combinator, and tell the student to write a
recursive Fibonnaci function using the same technique. They then say,
in a footnote, that this is called the Y combinator. It's just a
mind-stretching excercise, not a formal introduction to the Y
combinator.

(Disclaimer: details above are hopefully remembered correctly, but I
don't have the book in front of me at the moment)

-Peter