Just curious as to the views of experienced users of Lisp on Smalltalk
as a language. It seems to be getting slightly increased attention
lately, despite some vendor stability problems. There are also now
some (apparently) decent public domain or gnu licence versions
available.
Ian Garmaise
Lisp > Smalltalk >> Java >> C++
In general, the debugging and development environments for Smalltalk are
better than the ones available for the PD Lisps I've been able to get my
hands on, but I personally find single inheritance constraining and I like
generic functions a bit more than the class located methods in Smalltalk -
plus Lisp's MOP is better. As for experience, so you can judge if my
comments are valid, I spent 2.5 years working for ParcPlace Systems and I've
been playing with Lisp for the last 10 years or so - I still can't find
anyone to pay me to write in it :-(. I could get more specific about
particular Smalltalk and Lisp systems, but I think my generic comments cover
most of the terrain. Also - I find programming in either Smalltalk or Lisp
MUCH better than programing in Java or C++.
--
Frank A. Adrian
First DataBank
············@firstdatabank.com (W)
······@europa.com (H)
This message does not necessarily reflect those of my employer,
its parent company, or any of the co-subsidiaries of the parent
company.
Ian Garmaise wrote in message <···············@news.concentric.net>...
>Just curious as to the views of experienced users of Lisp on Smalltalk
>as a language. It seems to be getting slightly increased attention
>lately, despite some vendor stability problems. There are also now
>some (apparently) decent public domain or gnu licence versions
>available.
>
>Ian Garmaise
>
"Frank Adrian" <············@firstdatabank.com> writes:
< Lisp > Smalltalk >> Java >> C++
<
< In general, the debugging and development environments for Smalltalk are
< better than the ones available for the PD Lisps I've been able to get my
< hands on,
...
What things about smalltalk environments did you find better or
different? I ask because I don't know how a lisp debugger/stepper
could be improved. This is not to say that I think they can't be - I
just don't know what things would be nice to have that aren't there (I
have very little experience writing programs).
Maybe a programmable stepper like gdb's while and until?
I would like a debugger to fix my spelling errors... This is probably
possible, but very hard to do...
Do any of the Lisp IDE debuggers allow you to drop to a selected stack
frame, modify the source code in situ, and then resume execution? This is
standard Smalltalk debugging capability.
While I'm just a learning Lisp programmer, I find that Smalltalk's class and
code browsers are more revealing of my software's design (and possibly more
robust as well). This is perhaps enabled (or should I say facilitated?) by
the fact that source code in Smalltalk is not externalized in ASCII files,
but rather managed by the image itself - IOW, you can't make source code
changes in Smalltalk without going through the IDE, which, in turn, enforces
compilation and linking incrementally, therefore you can't (non-fraudulently
;-) ) have source code that's "out of wack" with your compiled image.
Again, I'm only a learning Lisp'er so I don't know if Lisp somehow addresses
this issue in some other fashion.
Bob Manjoney
McHugh Software International
Steve Gonedes <········@worldnet.att.net> wrote in message
···················@KludgeUnix.com...
>
>"Frank Adrian" <············@firstdatabank.com> writes:
>
>< Lisp > Smalltalk >> Java >> C++
><
>< In general, the debugging and development environments for Smalltalk are
>< better than the ones available for the PD Lisps I've been able to get my
>< hands on,
>...
>
>What things about smalltalk environments did you find better or
>different? I ask because I don't know how a lisp debugger/stepper
>could be improved. This is not to say that I think they can't be - I
>just don't know what things would be nice to have that aren't there (I
>have very little experience writing programs).
>
>Maybe a programmable stepper like gdb's while and until?
>
>I would like a debugger to fix my spelling errors... This is probably
>possible, but very hard to do...
>
In article <············@birch.prod.itd.earthlink.net>, "Bob Manjoney"
<·····@acm.org> wrote:
> Do any of the Lisp IDE debuggers allow you to drop to a selected stack
> frame, modify the source code in situ, and then resume execution? This is
> standard Smalltalk debugging capability.
Here is an example on a Symbolics Lisp machine:
Command: (defun foo (x) (/ x 0))
FOO
Command: (defun bar (x) (foo x))
BAR
Command: (compile 'foo)
FOO
Command: (compile 'bar)
BAR
Command: (bar 3)
Trap: There was an attempt to divide by zero in SYS:RATIONAL-QUOTIENT.
FOO
Arg 0 (X): 3
s-A, Return a value from the RATIONAL-QUOTIENT instruction
s-B: Retry the RATIONAL-QUOTIENT instruction
s-C, Return to Lisp Top Level in Dynamic Lisp Listener 1
s-D: Restart process Dynamic Lisp Listener 1
> Eval (program): (defun foo (x) (/ x 2))
FOO
> Eval (program): (compile 'foo)
FOO
> :Reinvoke
Restart call to #<Compiled function FOO 22011642127> on arguments (3)? (Y
or N) Yes.
3/2
> Again, I'm only a learning Lisp'er so I don't know if Lisp somehow addresses
> this issue in some other fashion.
Actually some of this stuff is not that easy. To keep the correspondence
between source and running code is not trivial. It might even not be
helpful to see the original source. Smalltalk has a simpler model
and I would expect that it is easier to debug. But for comparable language
facilities several Lisp environments are comparable to Smalltalk IDEs.
But remember, tail call removal, macros, optimizing incremental
compilers, inlining, etc., have a cost -> you get less debugable code.
Rainer Joswig
--
http://www.lavielle.com/~joswig
On Tue, 1 Dec 1998 07:50:04 -0500, "Bob Manjoney" <·····@acm.org>
wrote:
>While I'm just a learning Lisp programmer, I find that Smalltalk's class and
>code browsers are more revealing of my software's design (and possibly more
>robust as well). This is perhaps enabled (or should I say facilitated?) by
>the fact that source code in Smalltalk is not externalized in ASCII files,
>but rather managed by the image itself - IOW, you can't make source code
>changes in Smalltalk without going through the IDE, which, in turn, enforces
>compilation and linking incrementally, therefore you can't (non-fraudulently
>;-) ) have source code that's "out of wack" with your compiled image.
But does this approach of smalltalk produce complications, such as
corrupted images, etc? If you suspect corruption, how easy is it
totally reconstruct the image, do you have to start from earlier
versions, etc.?
>Again, I'm only a learning Lisp'er so I don't know if Lisp somehow addresses
>this issue in some other fashion.
>
I presume that as an experienced smalltalker, if you've decided to
learn lisp there must be some task you feel might be better handled
by lisp than by smalltalk?
Ian
Image corruption certainly can occur, but when it does, the better
commercial Smalltalk IDE's (a la IBM's VA Smalltalk w/ENVY) maintain a code
repository from which the state of your image can always be reconstructed -
with all up to date editions of your system automatically. ENVY, for those
who've never checked it out, is an impressive source code/revision
control/configuration management system.
As far as *why* I'm looking at Lisp, it's mainly because I'm always
searching for better ways to do my job - incremental development, an
interactive programming environment, a MOP, dynamic typing, no static type
checking, etc...are things that have always appealed to me when developing
software, and Lisp seems to offer such features in spades.
Why I feel Lisp might benefit me as a developer comes from the presence of
accessible and explicit metaclass programming, and multiple inheritance. So
far as I can tell, it lags behind Smalltalk in availability of
sophisticated business application building tools and frameworks that I've
grown accustomed to in Smalltalk.
Regards,
Bob Manjoney
McHugh Software International
Ian Garmaise <····@cris.com> wrote in message
······················@news.concentric.net...
>On Tue, 1 Dec 1998 07:50:04 -0500, "Bob Manjoney" <·····@acm.org>
>wrote:
>
>>While I'm just a learning Lisp programmer, I find that Smalltalk's class
and
>>code browsers are more revealing of my software's design (and possibly
more
>>robust as well). This is perhaps enabled (or should I say facilitated?)
by
>>the fact that source code in Smalltalk is not externalized in ASCII files,
>>but rather managed by the image itself - IOW, you can't make source code
>>changes in Smalltalk without going through the IDE, which, in turn,
enforces
>>compilation and linking incrementally, therefore you can't
(non-fraudulently
>>;-) ) have source code that's "out of wack" with your compiled image.
>
>But does this approach of smalltalk produce complications, such as
>corrupted images, etc? If you suspect corruption, how easy is it
>totally reconstruct the image, do you have to start from earlier
>versions, etc.?
>
>>Again, I'm only a learning Lisp'er so I don't know if Lisp somehow
addresses
>>this issue in some other fashion.
>>
>
>I presume that as an experienced smalltalker, if you've decided to
>learn lisp there must be some task you feel might be better handled
>by lisp than by smalltalk?
>
>Ian
>
Bob Manjoney wrote:
>
> the fact that source code in Smalltalk is not externalized in ASCII files,
> but rather managed by the image itself - IOW, you can't make source code
> changes in Smalltalk without going through the IDE, which, in turn, enforces
> compilation and linking incrementally, therefore you can't (non-fraudulently
> ;-) ) have source code that's "out of wack" with your compiled image.
This is pretty what I'm working toward
with the web server-side persistent lisp machine project.
Using the persistent object system, where code is represented as
objects, one edits the state of the objects. By using versions
and transactions, you can rollback to a previous state if needed.
-Kelly Murray ···@intellimarket.com
On Mon, 30 Nov 1998 22:16:25 GMT, "Frank Adrian"
<············@firstdatabank.com> wrote:
>... but I personally find single inheritance constraining and I like
>generic functions a bit more than the class located methods in Smalltalk -
>plus Lisp's MOP is better.
Could you elaborate a bit more on why you prefer generic functions and
the MOP better than their counterparts in Smalltalk?
> As for experience, so you can judge if my
>comments are valid, I spent 2.5 years working for ParcPlace Systems and I've
>been playing with Lisp for the last 10 years or so - I still can't find
>anyone to pay me to write in it :-(.
This seems to be a key point, that somehow it's been possible to
convince companies Smalltalk is more commercially useful
than Lisp, to the extent that one now regularly sees fairly
well-paid jobs available to those with even moderate Smalltalk skills.
> I could get more specific about
>particular Smalltalk and Lisp systems, but I think my generic comments cover
>most of the terrain. Also - I find programming in either Smalltalk or Lisp
>MUCH better than programing in Java or C++.
Better in which ways? Initial effort, ease of redesign,
maintainability, reliability?
Ian
I didn't expect this to become an huge essay but, given that you ask good
questions...
Ian Garmaise wrote in message <·················@news.concentric.net>...
>On Mon, 30 Nov 1998 22:16:25 GMT, "Frank Adrian"
><············@firstdatabank.com> wrote:
>
>>... but I personally find single inheritance constraining and I like
>>generic functions a bit more than the class located methods in Smalltalk -
>>plus Lisp's MOP is better.
>
>Could you elaborate a bit more on why you prefer generic functions and
>the MOP better than their counterparts in Smalltalk?
I like the generic functions because they are that - generic. Even though
you can write different methods that respond to the same messages for
different objects, there isn't that "closeness" that you can get with a
functional organization of the same code. Some code simply is functional,
while some IS class based - what I'd really like to see is a hybrid, but
that's another issue... Plus, double dispatch is a real hack that I am glad
multimethods do away with.
As for the MOP, you can change method lookup in a fairly straightforward and
efficient manner in CLOS. When using Smalltalk, the closest you can come is
to not include a message on an object, get a messageNotUnderstood:
exception, and roll your own lookup and invocation from there. Not only is
this inefficient, but it is also a lot of code to write. This is because
much of Smalltalk's vaunted MOP machinery is hardwired into a VM that
usually has no hooks for specialization. What else? No instance specific
methods (like you can get with EQL specializers), no optional arguments (to
be fair, I once extended the message lookup capability to do this, but as I
noted above, it was both slow and tedious), no keyword arguments (unless you
want to hack like I did or add all keyword combinations).
Trivia - many Smalltalks still don't lexically scope their blocks, the
synatx baggage makes code generation a pain, and NO MACROS.
>
>> As for experience, so you can judge if my
>>comments are valid, I spent 2.5 years working for ParcPlace Systems and
I've
>>been playing with Lisp for the last 10 years or so - I still can't find
>>anyone to pay me to write in it :-(.
>
>This seems to be a key point, that somehow it's been possible to
>convince companies Smalltalk is more commercially useful
>than Lisp, to the extent that one now regularly sees fairly
>well-paid jobs available to those with even moderate Smalltalk skills.
Yup. Lisp wenr down in flames at the end of the great AI debacle and has
never really come back. Smalltalk has a certain cachet from being close to
the first OO language and, as OO is still going strong, is still marketable.
Lisp is still seen as an AI language and not as a general purpose language.
Before the flames start - I don't think this, but I do believe that this is
a widespread industry myth.
>> I could get more specific about
>>particular Smalltalk and Lisp systems, but I think my generic comments
cover
>>most of the terrain. Also - I find programming in either Smalltalk or
Lisp
>>MUCH better than programing in Java or C++.
>
>Better in which ways? Initial effort, ease of redesign,
>maintainability, reliability?
All of the above. Due to the decrease in code volume for most Lisp and
Smalltalk programs, most downstream costs are reduced. Due to their dynamic
nature, redesign and extension is simpler (but slightly more hazardous
becuase you tend to do more of it). And all of these languages' development
environments are MUCH better than most C++ or Java environments I've seen -
doing away with the explicit compilation and invocation steps are a big plus
(as is the dynamic nature of the languages - a double-edged sword, but one
I'm comfortable handling).
--
Frank A. Adrian
First DataBank
············@firstdatabank.com (W)
······@europa.com (H)
This message does not necessarily reflect those of my employer,
its parent company, or any of the co-subsidiaries of the parent
company.
Frank Adrian wrote in message <············@client2.news.psi.net>...
>[...]
>Trivia - many Smalltalks still don't lexically scope their blocks [...]
Unless you have a different definition of "many", this is not true. In all
the current commercial Smalltalks--VA, VW and VisualSmalltalk--blocks are
lexical closures. Lexical scoping is also a requirement of the ANSI
Smalltalk standard.
--Vassili