This (smalltalk has no source code)is kind of an interesting aspect involving
(commercial?) institutions. In some work environments there exists the concept
of source code and the manner of QAing source code is to be done in a very
proscriptive manner involving paper. I am not saying that QA can not be done
since smalltalk has been around for quite a while now and commercial vendors of
the language do exist. But doing QA in a manner consistent with the form
expected by such institutions has probably turned more than one ST enthusiast
away from using the language in favor of
fortran|cobol/basic/pascal/modula/c/c++/VB/java-choose according to decade/date
and location (commercial/academic). This fate is probably true of LISP too. It
is ironic, however, spreadsheets get by with little of no QA in this culture.
Yawn :O)

So who cares, why not enjoy ST or LISP or even fortran for the intellectual
leverage it buys you in a given circumstance. It is the 'aha' that we chase and
there is plenty of that still around.

Regards,
Michael Grant


--- Nevin Pratt <nevin at bountifulbaby.com> wrote:

> 
> >
> > For example, one of the people who responded to the blog message said
> > "A program is text".  But in Smalltalk, a program is not text, it is
> > objects.  ....Smalltalk is objects all
> > the way down.....We live in an
> > "image", which is an executing program.  We modify our applications in
> > the middle of their execution.  There is no "main".  When we write a
> > program, we are not just reusing some code that is thirty years old,
> > we are making it by modifying a program that started executing thrity
> > years ago and that has been changed by thousands of people ever since.
> >
> 
> And, the act of modifying the executing program is done by nothing more 
> than sending messages to the executing objects in this same program that 
> started executing thirty years ago.
> 
> Which I would argue makes even the concept of "source code" an ambiguous 
> concept in Smalltalk.
> 
> What is Smalltalk source code? 
> 
> An argument could be made for defining Smalltalk "source code" as a 
> transcript of the messages sent by the programmer (i.e., the contents of 
> the changes file).  This wouldn't be a widely accepted definition, but 
> never-the-less, I believe a good argument could be made for defining it 
> this way.
> 
> Another argument could be made for defining Smalltalk "source code" as 
> the string (text) result of asking each of the contents of the method 
> dictionaries of the classes to print themselves.  This would be a more 
> popularly accepted definition, but why?  Why would this definition be 
> any more correct than the previous one?
> 
> I would argue that there really is no "source code".  At best, you can 
> ask the system to recreate a sequence of message sends that you hope, 
> when replayed, with transform the internal state of the executing 
> program from one known state into another known state that you need and 
> want.  That's what a file-out is.  It is a synthesized sequence of 
> message sends, synthesized by the executing Smalltalk system, in a hope 
> that it can be replayed by yet another Smalltalk system to transform it 
> into what you want.
> 
> Thus, I would argue that Smalltalk really doesn't have source code.  It 
> has message sends, sent to live objects.  And I like it just fine that 
> way, thank you.
> 
> If you choose to define "source code" as a printed sequential list of 
> some known subset of message sends that can later be replayed, then you 
> can argue that Smalltalk has source code.
> 
> Nevin
> 
> 
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com