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

From:	devmail at runbox.com
Subject:	Re: Lisp or Smalltalk: Suicide Mission, Part II
Date:	23 Jan 2005 20:33:55 -0800

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.

From:	Wade Humeniuk
Subject:	Re: Lisp or Smalltalk: Suicide Mission, Part II
Date:	Mon, 24 Jan 2005 04:46:06 GMT

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

From:	devmail at runbox.com
Subject:	Re: Lisp or Smalltalk: Suicide Mission, Part II
Date:	23 Jan 2005 23:20:42 -0800

Google Groups is DEFINITELY still "beta"

From:	devmail at runbox.com
Subject:	Re: Lisp or Smalltalk: Suicide Mission, Part II
Date:	21 Jan 2005 19:34:21 -0800

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

From:	Pascal Bourguignon
Subject:	Re: Lisp or Smalltalk: Suicide Mission, Part II
Date:	22 Jan 2005 05:13:41 +0100

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?

From:	Niall Ross
Subject:	Re: Lisp or Smalltalk: Suicide Mission, Part II
Date:	Sat, 22 Jan 2005 12:58:25 +0000 (UTC)

Dear Pascal,

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

From:	Pascal Bourguignon
Subject:	Re: Lisp or Smalltalk: Suicide Mission, Part II
Date:	22 Jan 2005 18:30:34 +0100

"Niall Ross" writes:

> Dear Pascal,
>
> "Pascal Bourguignon" 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

From:	Marc Battyani
Subject:	Re: Lisp or Smalltalk: Suicide Mission, Part II
Date:	Sun, 23 Jan 2005 21:20:23 +0100

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

From:	Thomas Gagne
Subject:	Re: Lisp or Smalltalk: Suicide Mission, Part II
Date:	Sun, 23 Jan 2005 06:01:36 -0500

Pascal Bourguignon wrote:
> devmail@runbox.com writes:
>

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

>

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

From:	Marc Battyani
Subject:	Re: Lisp or Smalltalk: Suicide Mission, Part II
Date:	Sun, 23 Jan 2005 21:15:25 +0100

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

From:	BR
Subject:	Re: Lisp or Smalltalk: Suicide Mission, Part II
Date:	Sun, 23 Jan 2005 18:12:29 -0500

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

> You have to make your own.

A blessing and a curse.

From:	Pascal Costanza
Subject:	Re: Lisp or Smalltalk: Suicide Mission, Part II
Date:	Fri, 21 Jan 2005 11:39:31 +0100

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

From:	devmail at runbox.com
Subject:	Re: Lisp or Smalltalk: Suicide Mission, Part II
Date:	21 Jan 2005 13:41:15 -0800

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.

From:	Chris Uppal
Subject:	Re: Lisp or Smalltalk: Suicide Mission, Part II
Date:	Sat, 22 Jan 2005 15:46:10 -0000

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

From:	drewc
Subject:	Re: Lisp or Smalltalk: Suicide Mission, Part II
Date:	Sat, 22 Jan 2005 01:10:05 GMT

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

From:	Pascal Bourguignon
Subject:	Re: Lisp or Smalltalk: Suicide Mission, Part II
Date:	21 Jan 2005 23:18:11 +0100

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

From:	devmail at runbox.com
Subject:	Re: Lisp or Smalltalk: Suicide Mission, Part II
Date:	23 Jan 2005 13:53:13 -0800

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

From:	Darin Johnson
Subject:	Re: Lisp or Smalltalk: Suicide Mission, Part II
Date:	Sat, 22 Jan 2005 00:04:57 GMT

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

From:	lin8080
Subject:	Re: Lisp or Smalltalk: Suicide Mission, Part II
Date:	Mon, 24 Jan 2005 22:30:59 +0100

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

From:	devmail at runbox.com
Subject:	Re: Lisp or Smalltalk: Suicide Mission, Part II
Date:	23 Jan 2005 23:10:46 -0800

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

From:	Arie van Wingerden
Subject:	Re: Lisp or Smalltalk: Suicide Mission, Part II
Date:	Sat, 22 Jan 2005 11:43:10 +0100

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

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

From:	devmail at runbox.com
Subject:	Re: Lisp or Smalltalk: Suicide Mission, Part II
Date:	20 Jan 2005 21:12:21 -0800

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

From:	devmail at runbox.com
Subject:	Re: Lisp or Smalltalk: Suicide Mission, Part II
Date:	21 Jan 2005 19:30:00 -0800

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

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.

From:	Peter Seibel
Subject:	Re: Lisp or Smalltalk: Suicide Mission, Part II
Date:	Fri, 21 Jan 2005 05:29:36 GMT

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

From:	Wade Humeniuk
Subject:	Re: Lisp or Smalltalk: Suicide Mission, Part II
Date:	Fri, 21 Jan 2005 20:42:15 GMT

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

From:	Alain Picard
Subject:	Re: Lisp or Smalltalk: Suicide Mission, Part II
Date:	Sun, 23 Jan 2005 16:44:05 +1100

"Tayssir John Gabbour" 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.

From:	Edi Weitz
Subject:	Re: Lisp or Smalltalk: Suicide Mission, Part II
Date:	Sat, 22 Jan 2005 18:08:58 +0100

On 22 Jan 2005 09:01:04 -0800, "Tayssir John Gabbour" 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")

From:	Rahul Jain
Subject:	Re: Lisp or Smalltalk: Suicide Mission, Part II
Date:	Sun, 23 Jan 2005 14:10:51 -0500

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

From:	Chris Uppal
Subject:	Re: Lisp or Smalltalk: Suicide Mission, Part II
Date:	Sun, 23 Jan 2005 20:08:06 -0000

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

From:	Paolo Amoroso
Subject:	Re: Lisp or Smalltalk: Suicide Mission, Part II
Date:	Sat, 22 Jan 2005 13:20:11 +0100

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

From:	Bulent Murtezaoglu
Subject:	Re: Lisp or Smalltalk: Suicide Mission, Part II
Date:	Sun, 23 Jan 2005 22:14:45 +0200

>>>>> "CU" == Chris Uppal 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

From:	Chris Uppal
Subject:	Re: Lisp or Smalltalk: Suicide Mission, Part II
Date:	Sun, 23 Jan 2005 21:17:43 -0000

Bulent Murtezaoglu wrote:

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

Thanks.

-- chris

From:	Peter Seibel
Subject:	Re: Lisp or Smalltalk: Suicide Mission, Part II
Date:	Sun, 23 Jan 2005 19:17:43 GMT

"Tayssir John Gabbour" writes:

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

From:	devmail at runbox.com
Subject:	Re: Lisp or Smalltalk: Suicide Mission, Part II
Date:	21 Jan 2005 14:06:02 -0800

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

From:	devmail at runbox.com
Subject:	Re: Lisp or Smalltalk: Suicide Mission, Part II
Date:	23 Jan 2005 23:13:24 -0800

From:	Tayssir John Gabbour
Subject:	Re: Lisp or Smalltalk: Suicide Mission, Part II
Date:	22 Jan 2005 18:03:01 -0800

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

From:	Mairi Ross
Subject:	Re: Lisp or Smalltalk: Suicide Mission, Part II
Date:	Fri, 21 Jan 2005 22:58:59 +0000 (UTC)

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

From:	Niall Ross
Subject:	Re: Lisp or Smalltalk: Suicide Mission, Part II
Date:	Sat, 22 Jan 2005 11:31:55 +0000 (UTC)

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

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

From:	Isaac Gouy
Subject:	Re: Lisp or Smalltalk: Suicide Mission, Part II
Date:	21 Jan 2005 13:59:04 -0800

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

From:	Will Hartung
Subject:	Re: Lisp or Smalltalk: Suicide Mission, Part II
Date:	Fri, 21 Jan 2005 13:53:07 -0800

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 yo