[Cuis-dev] Lynn Conway (1938-2024) [was: change image in ImageMorph]

Juan Vuletich juan at cuis.st
Thu Jun 13 13:51:26 PDT 2024 

Thanks for this write-up Boris.

It is important to raise awareness of the things you mention. 
Smalltalk-80 was a high success, has had a tremendous influence in 
software technology, and is still the most powerful practical 
programming language for most problems. Hence, Cuis.

In any case, yes. There are other, more general ideas that still need to 
be further developed. The results would be pretty different from 
Smalltalk-80, and likely closer to the Internet itself

Keep pushing these ideas forward!

Cheers,

On 6/12/2024 8:51 PM, Boris Shingarov via Cuis-dev wrote:
>> So it seems the term "statement" is used in the template for creating new
>> methods.
> I believe there is a confusion here.
> As Hernán correctly pointed out, in the [mostly biologically-inspired]
> Smalltalk paradigm we talk about objects communicating by sending
> messages to each other.  Conceptually an object is an independent agent;
> perhaps an independent thinking entity.
> Methods are little programs through which an object is programmed how to
> respond to some particular message.
>
> What you see in that System Browser "when you are ready to implement
> a new method", is Smalltalk-80's "method pattern".  Smalltalk-80 is an
> approximate simulation of Smalltalk in computer technology that was
> achievable during The Decade of Research.
>
> [By the last phrase, I am alluding to the book edited by Giuliana
> Lavendel.  To those who haven't read that book, I full-heartedly
> recommend to read at least Pake's Introduction chapter].
>
> NB that I said "achievable", as opposed to "available".  The people at
> PARC were — to quote from Alan Kay — serious about their software and
> therefore built their own no-less-revolutionary hardware.  This morning
> I learned about the passing of Lynn Conway, the visionary at PARC who
> together with Carver Mead invented VLSI.  (See pp.283–294 in the above-
> mentioned book).
>
> But even those computers were limited by what was technologically
> attainable at the time.  Sadly, these limitations propagate to software,
> so the Smalltalk simulator implementations of the time, such as
> Smalltalk-76 or Smalltalk-80, were crude approximations, mapping the
> massively-parallel world of active objects to a sequential processor
> acting on a passive array of bytes as the only conceivable structure.
> The design decisions in such implementation are dictated by these
> limitations.
>
> Returning back to the subject of method-script.  The Smalltalk-80
> method-script is typical of the prevailing languages of the Research
> Decade: a method is a temporally-strict sequence of statememts.
> A statement may assign a result of a message send to an lvalue
> (or mutate the state in some other way).  Between statements, you have
> the "statement separator" (e.g. "full stop" (U+002E) in the Cuis
> concrete syntax) which acts as a temporal wall: in
>
>    S₁ . S₂
>
> the execution of statement S₁ must complete before the execution
> of statement S₂ can begin.
>
> Interestingly, even in the 1970s this was not assumed to be the only
> possible form for a method.  For example, to Robin Milner a method is a
> strategy for achieving a goal:
>
>> These goal-seeking activities are as widely different as seeking to
>> win at chess and seeking to meet a friend before noon on Saturday.
>> But the similarity can be articulated in terms of a little theory
>> of goal-seeking; a theory that has nothing to do with finding the
>> best strategy, or with minimizing the prospect of failure (important
>> though these things are), but which tries to make precise how concepts
>> like goal, strategy, achievement, failure, etc. relate logically to
>> each other [...]
>>
>> We may discern two prime entity classes in any sphere of goal-seeking
>> activity: the goals and the events.  A goal may sometimes be thought
>> of as a description that may be satisfied by one or more (or no)
>> occurrences, and an event is simply a particular occurrence.
>> For example:
>>
>>         a goal, G₁ : A and B to meet before noon on Saturday;
>>       an event, E₁ : A meets B under the clock at Waterloo Station
>>                      at 11h53 on Saturday.
>>
>> It is clear that event E₁ satisfies the description that has been
>> designated as goal G₁, i.e. it achieves goal G₁.
>
> So, in a method we might want to express some idea like, "to achieve G₁,
> we need both E₁ and E₂"; in your "method-template" syntax, it would be
> something like
>
> G₁
>    E₁ ∧ E₂
>
>
> or Gentzen would write
>
>    E₁   E₂
>    -------
>      G₁
>
> However we notate it, is a question of taste; what's important is that
> we can give the tasks E₁ and E₂ to two independent agents in parallel.
> This is decidedly NOT the same as writing E₁.E₂.
>
> Or we might want to say "to achieve G₁, it suffices to have E₁ or E₂":
>
> G₁
>    E₁ ∨ E₂
>
> and give E₁ to Agent1 and E₂ to Agent2.  Maybe Agent1 segfaults and
> crashes; we are still ok if Agent2 achieves E₂.
>
> One exciting thing is that even though such constructs are not
> expressible as Smalltalk-80 CompiledMethods, even the Back-to-the-Future
> Samlltalk already provides for them:  you could put something like
> (newly-written) MilnerStrategy into a MethodDictionary, then method
> lookup resolves to the MilnerStrategy, the VM sees it's not a
> Smalltalk-80 CompiledMethod, sends #run:with:in: to the MilnerStrategy,
> which can respond to it in any generalized way we want.
>
> In fact this is not even difficult (and we use this in MachineArithmetic
> to compute values that are not set elements); what I think would be
> really really cool, is to generalize the Smalltalk-80 Debugger from
> chains of Contexts as executions of CompiledMethods, to trees of
> Contexts as executions of arbitrary methods!
>
>
> On Sun, Jun 02, 2024 at 09:28:49AM -0500, Mark Volkmann via Cuis-dev wrote:
>> Thanks for the feedback! I definitely want to learn the proper terminology
>> for everything in Smalltalk.
>> Interestingly though, in a System Browser when I'm ready to implement a new
>> method I see this in the bottom pane:
>>
>> messageSelectorAndArgumentNames
>> "comment stating purpose of message"
>>
>> | temporary variable names |
>> statements
>>
>> So it seems the term "statement" is used in the template for creating new
>> methods.
>>
>> On Sat, Jun 1, 2024 at 10:25 PM Hernán Wilkinson via Cuis-dev<
>> cuis-dev at lists.cuis.st>  wrote:
>>
>>> Just a small comment. In Smalltalk we do not talk about statements but
>>> about messages.
>>> Everything is done sending messages to objects, and if the object knows
>>> how to answer that message, it does it evaluating the related method.
>>> At the end they are all bits and bytes, bit conceptually it is not the
>>> same, and understanding how objects collaborate sending messages is
>>> essential to understand the core of Smalltalk
>>>
>>> Cheers!
>>> Hernan
>>>
>>>
>>> *Hernán WilkinsonAgile Software Development, Teaching&  Coaching*
>>> *Phone: +54-011*-4893-2057
>>> *Twitter: @HernanWilkinson*
>>> *site: http://www.10Pines.com<http://www.10pines.com>*
>>> Address: Alem 896, Floor 6, Buenos Aires, Argentina
>>>
>>>
>>> On Sun, 2 Jun 2024 at 00:16 Ezequiel Birman via Cuis-dev<
>>> cuis-dev at lists.cuis.st>  wrote:
>>>
>>>> There is an example in ImageMorph's comment. You can also look at the
>>>> implementation of ImageMorph>>  readFromFile. It prompts for a file name
>>>> and then does what you are asking for:
>>>>
>>>>> ... self image: (Form fromFileNamed: fileName)
>>>>
>>>> So the statement could be:
>>>>
>>>>> myImage := Form fromFileNamed:
>>>>> '../Cuis/Learning-Cuis/CuisLiftsAboveItsWeight.png'
>>>>
>>>> See also
>>>> *ImageReadWriter class>>  imageMorphFromFileEntry:.*
>>>>
>>>> Happy hacking!
>>>>
>>>>
>>>> On Sun, 2 Jun 2024 at 01:36, Mark Volkmann via Cuis-dev<
>>>> cuis-dev at lists.cuis.st>  wrote:
>>>>
>>>>> I imagine that changing the image displayed in an `ImageMorph` requires
>>>>> two statements, one to load an image from a file and one to change the
>>>>> `ImageMorph`. I think the second one looks like this:
>>>>>
>>>>> `myImageMorph image: myImage.`
>>>>>
>>>>> What's the statement I need to set the variable `myImage` to an image
>>>>> object?
>>>>>
>>>>> --
>>>>> R. Mark Volkmann
>>>>> Object Computing, Inc.
>>>>> --
>>>>> Cuis-dev mailing list
>>>>> Cuis-dev at lists.cuis.st
>>>>> https://lists.cuis.st/mailman/listinfo/cuis-dev
>>>>>
>>>> --
>>>> Cuis-dev mailing list
>>>> Cuis-dev at lists.cuis.st
>>>> https://lists.cuis.st/mailman/listinfo/cuis-dev
>>>>
>>> --
>>> Cuis-dev mailing list
>>> Cuis-dev at lists.cuis.st
>>> https://lists.cuis.st/mailman/listinfo/cuis-dev
>>>
>>
>> -- 
>> R. Mark Volkmann
>> Object Computing, Inc.
>> -- 
>> Cuis-dev mailing list
>> Cuis-dev at lists.cuis.st
>> https://lists.cuis.st/mailman/listinfo/cuis-dev


-- 
Juan Vuletich
cuis.st
github.com/jvuletich
researchgate.net/profile/Juan-Vuletich
independent.academia.edu/JuanVuletich
patents.justia.com/inventor/juan-manuel-vuletich
linkedin.com/in/juan-vuletich-75611b3
twitter.com/JuanVuletich

More information about the Cuis-dev mailing list