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.
·······@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
······@acm.org
·······@cincom.com
http://www.cincom.com/smalltalk
"The Static Typing Philosophy: Make it fast. Make it right. Make it
run." - Niall Ross
From: Wade Humeniuk
Subject: Re: Lisp or Smalltalk: Suicide Mission, Part II
Date:
Message-ID: <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
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?
<·······@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
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
·······@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?
Dear Pascal,
"Pascal Bourguignon" <····@mouse-potato.com> wrote in message
···················@thalassa.informatimago.com...
> ·······@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
"Niall Ross" <···@bigwig.net> writes:
> Dear Pascal,
>
> "Pascal Bourguignon" <····@mouse-potato.com> wrote in message
> ···················@thalassa.informatimago.com...
> > ·······@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
Pascal Bourguignon wrote:
> ·······@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?
"Pascal Bourguignon" <····@mouse-potato.com> wrote:
> ·······@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
Pascal Bourguignon <····@mouse-potato.com> writes:
> ·······@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.
·······@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
From: Rahul Jain
Subject: Re: Lisp or Smalltalk: Suicide Mission, Part II
Date:
Message-ID: <87zmz0ynqo.fsf@nyct.net>
·······@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
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
<·······@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
On Sun, 23 Jan 2005 21:15:25 +0100, Marc Battyani wrote:
> You have to make your own.
A blessing and a curse.
From: Rahul Jain
Subject: Re: Lisp or Smalltalk: Suicide Mission, Part II
Date:
Message-ID: <873bwq17sc.fsf@nyct.net>
BR <··········@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
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
········@runbox.com" <·······@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
From: Hans-Martin Mosner
Subject: Re: Lisp or Smalltalk: Suicide Mission, Part II
Date:
Message-ID: <35d90rF4ic9vfU2@individual.net>
Wade Humeniuk <··················@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
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: Christopher C. Stacy
Subject: Re: Lisp or Smalltalk: Suicide Mission, Part II
Date:
Message-ID: <umzv2a3to.fsf@news.dtpq.com>
Wade Humeniuk <··················@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.
Wade Humeniuk <··················@telus.net> wrote in
·························@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
······@acm.org
·······@cincom.com
http://www.cincom.com/smalltalk
"The Static Typing Philosophy: Make it fast. Make it right. Make it
run." - Niall Ross
From: Rahul Jain
Subject: Re: Lisp or Smalltalk: Suicide Mission, Part II
Date:
Message-ID: <874qh80ylf.fsf@nyct.net>
Alan 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
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist