[Cuis-dev] new YouTube video on Cuis Smalltalk

[Jaromir Matas]

Hi Ezequiel,

 > I'd also urge everyone to read Programming as Theory Building 
<https://archive.org/details/computinghumanac0000naur/page/36/mode/2up> 
by Peter Naur

Fascinating.

It states a programmer has an understanding (or insight) of a program 
that is _not_ describable in any documentation. Naur calls this 
understanding a theory of a program.

And hence advises to give up writing the traditional "documentation" 
because the most you can do - and should do - is help others to build 
the same theory of the program in their minds. This is what the 
documentation is about.

I personally call this understanding a mental model. I write my comments 
to refresh my mental model when it fades in time, and hopefully help 
others to build theirs.

I'm glad someone like Peter Naur said that. Thanks very much for sharing 
the article.


On 27-Jun-24 7:32:39 PM, "Ezequiel Birman via Cuis-dev" 
<cuis-dev at lists.cuis.st> wrote:

>Sorry in advance for the scattered replies
>
>Joseph Turco wrote:
>>When Alan Kay and Adele Goldberg were testing smalltalk-80, they were 
>>using kids in school to play with it (...)
>Children didn't use Smalltalk-80. For all that I know, children used 
>Smalltalk-72 through Smalltalk-76. A good summary is provided in the 
>article by Perry and Wallich, Inside the PARC: the `information 
>architects' <https://spectrum.ieee.org/xerox-parc/smalltalk-history> 
>from which I quote:
>>The first compiled version of Smalltalk, written in 1976, marked the 
>>end of the emphasis on a language that children could use. The 
>>language was now “a mature programming environment,” Ingalls said. “We 
>>got interested in exporting it and making it widely available.”
>>
>>The next major revision of Smalltalk was Smalltalk-80. Kay was no 
>>longer on the scene to argue that any language should be simple enough 
>>for a child to use. Smalltalk-80, says Tesler, went too far in the 
>>opposite direction from the earliest versions of Smalltalk: “It went 
>>to such an extreme to make it compilable, uniform, and readable, that 
>>it actually became hard to read, and you definitely wouldn’t want to 
>>teach it to children.”
>>
>>Kay, looking at Smalltalk-80, said, “It’s terrible that it can’t be 
>>used by children, since that’s who Smalltalk was intended for. It fell 
>>back into data-structure-type programming instead of simulation-type 
>>programming.”
>I think that both Tesler and Kay are exaggerating here, but the push by 
>Xerox to create “the office of the future” was real.
>
>Jaromir Matas wrote:
>>Your Youtube talk and especially your answers allowed me to read the 
>>articles with a whole new level of understanding. Especially Alan 
>>Kay's "A Personal Computer for Children of All Ages" has so much to 
>>say [...]
>I wonder what percentage of people understand “children of all ages” 
>the same way I do. Cyril Connolly said that Imprisoned in every fat 
>man, a thin one is wildly signalling to be let out. I want to believe 
>that I don't have much difficulty in letting my inner-child out. For 
>good or ill, this view of children as unprejudiced, unspoiled, playful, 
>curious little people (childlike) can coexist with the reality of their 
>capricious and demanding nature (childish). One of the things we like 
>about computers is the almost instant gratification they can provide.
Great point!

>
>
>>[...] I have a problem with documenting though. You know I've tried to 
>>write as thorough comments as possible documenting intentions, 
>>explaining sticking points etc. (even if just to help myself 
>>understand it again a few months/weeks later) but IMHO it's still 
>>woefully insufficient - in addition to the more or less terse 
>>in-method comments I'd like to be able to add somewhere really close 
>>(even in-image Help files are too far away) more detailed 
>>descriptions, reasons for tradoffs, motivations, future plans, 
>>examples, etc. - but in a way that wouldn't clutter the environment.
>and
>>I'm not sure I understand the part about "knowledge" though: "Write, 
>>describe, communicate knowledge" - what does it mean exactly? Is it 
>>about Smalltalk as a language? The language itself is not that 
>>different from other (high-level) languages. A good language certainly 
>>is a great help to formulate things but it's still a "programming 
>>language".  I guess there more to it I didn't get :)
>>
>>Or is it about the whole concept including the live "OS-like" 
>>environment? But where the "writing knowledge" fits in?
>Maybe the misunderstanding is due to the fact that you are taking 
>“documentation” at face value. In my mind, every program, at least 
>every program written in something higher level than assembly language, 
>can be regarded as “documentation”. And in a way, it is the best sort 
>of documentation because it must execute.
Eze, I think I understand what you're getting at. However, I strongly 
disagree a program, even if nicely written, can be regarded as a 
documentation on its own. Gleaning author's idea from the code is, IMO, 
the reverse engineering :) But I agree it's much better to follow Naur's 
approach and provide e.g. appropriate metaphors to help build reader's 
own "theory" (mental model) rather than the traditional documentation.

>This is also different from Knuth's idea and realization of literate 
>programming. I like his point of view only because I like reading for 
>reading's sake, and I like books, and I like how he writes; but code is 
>not literature <https://gigamonkeys.com/code-reading/>. What I am 
>talking about is more like a deliberate confusion between the map and 
>the territory.
Interesting point, I'll think about it, thanks... Ok, but the idea of 
literate programming still seems very nice for writing a tutorial, an 
active "book" where you both read stuff _and_ run stuff. No window 
switching. I should check Erudite as Mariano suggested.

>
>
>“For the people that want a system that is fully malleable, even if 
>limited, Smalltalk is still the best thing that has been built” said 
>Juan in the interview, because all of the things you mentioned combined 
>together with thoughtful design evolved during decades (if you also 
>take into account Self, Morphic and other developments). If this is not 
>a qualitative jump, I don't know what it is.
Indeed!

>I cannot avoid thinking about the balloon 
><https://wiki.squeak.org/squeak/3459>; it conveys such an adequate 
>picture.
>
>Jaromir Matas wrote:
>>I've played a bit with Javascript and Python recently and my 
>>impression is they try to follow basically the same goal [...]
>I disagree. Their original goal was to be “scripting” languages and 
>thus, they favored scripting over robustness, comprehensibility, 
>design, clarity, simplicity, and consistency.
ok, I get it :) Smalltalk started with much grander vision than most 
newer languages and it's still palpable.

>Of course you can still write beautiful Python or JavaScript as you can 
>write ugly Smalltalk. Kay has used the Ford-T metaphor; Ingalls 
>compared Smalltalk to a musical instrument. I don't know about you but 
>I prefer to play or learn to play a keyboard instrument in a 
>beautifully crafted Steinway rather than in a cheap electronic Casio 
>keyboard.
>
>Ken Dickey wrote:
>>  The Squeak folks noted Scheme48, which is/was a Scheme written in 
>>Scheme
>>which compiled to C and had decent performance on computers of the day
>>-- so they knew it could be done.
>Thanks for reminding us! Scheme 48 <https://s48.org/> was my scheme of 
>choice back in the day.
>
>Juan Vuletich wrote:
>>There are several links at 
>>https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/blob/master/Documentation/AboutCuis.md#the-philosophy-behind-cuis 
>>. Have you read them? Please do.
>I'd also urge everyone to read Programming as Theory Building 
><https://archive.org/details/computinghumanac0000naur/page/36/mode/2up> 
>by Peter Naur

Thanks again for your comments,
best,
Jaromir

>
>
>--
>Eze
>>>
>A quarta, 26/06/2024, 23:47, Jaromir Matas via Cuis-dev 
><cuis-dev at lists.cuis.st> escreveu:
>>Hi Juan,
>>
>>
>>On 24-Jun-24 12:22:00 AM, "Juan Vuletich via Cuis-dev" 
>><cuis-dev at lists.cuis.st> wrote:
>>
>>>On 6/23/2024 5:19 AM, Jaromir Matas via Cuis-dev wrote:
>>>>I'm not sure I understand the part about "knowledge" though: "Write, 
>>>>describe, communicate knowledge" - what does it mean exactly? Is it 
>>>>about Smalltalk as a language? The language itself is not that 
>>>>different from other (high-level) languages. A good language 
>>>>certainly is a great help to formulate things but it's still a 
>>>>"programming language".  I guess there more to it I didn't get :)
>>>>
>>>>Or is it about the whole concept including the live "OS-like" 
>>>>environment? But where the "writing knowledge" fits in?
>>>>
>>>
>>>There are only some many things that can be said in an hour.
>>>
>>>There are several links at 
>>>https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/blob/master/Documentation/AboutCuis.md#the-philosophy-behind-cuis 
>>>. Have you read them? Please do.
>>I'm so glad you nudged me to read them. Your Youtube talk and 
>>especially your answers allowed me to read the articles with a whole 
>>new level of understanding. Especially Alan Kay's "A Personal Computer 
>>for Children of All Ages" has so much to say; here's what caught my 
>>attention (re objects vs. processes):
>>quote
>>>The following principles should be used in the design of the Dynabook 
>>>language.
>>>
>>>1. We need a uniform notion as to what objects are, how they may be 
>>>referred to, and how they can manipulate other objects.
>>>
>>>2. If each object can have its own control path, then there must be a 
>>>concise way to coordinate and "control" these paths when more than 
>>>one is active.
>>>
>>>3. The evaluation of a control path should follow simple rules which 
>>>show how objects are passed messages and return results.
>>>
>>>4. Every object in a system should be redefinable in terms of other 
>>>objects.
>>>
>>>The basic idea is to exploit the duality between 'functions and 
>>>tables (or processes and memory). English has nouns which refer to 
>>>"objects", and verbs which refer to "actors" and "relators". This is 
>>>a Newtonian epistemology. Modern physics and philosophy tend towards 
>>>the idea that both "objects" and "actors" are just different aspects 
>>>of the notion of process. A process has state (a set of relations 
>>>having only to do with it) which changes as time (defined as 
>>>interactions with other objects) passes. Using this view "data" is a 
>>>process which changes "slowly", "function" is a process which changes 
>>>more rapidly. Each process has the logical attributes of a complete 
>>>"micro" computer: they can have inputs, give back outputs, act as a 
>>>memory on file system, perform computations, be interrupted, etc. […] 
>>>Since multiple control paths are allowed, many processes can be in 
>>>various stages of evaluation and debugging.
>>>
>>
>>
>>
>>
>>
>>
>>unquote
>>
>>Do I understand correctly that Alan Kay suggests in (2) that each 
>>object should have its own control path (i.e. a thread, aka a process 
>>in Smalltalk vocabulary)? Is he somehow placing an equal sign between 
>>objects and actors (like e.g. Squeak Actors by Tony Garnock-Jones, 
>>https://tonyg.github.io/squeak-actors/) where actors are implemented 
>>as processes. Would that implicate that the idea was that objects 
>>should do their jobs in parallel, each in its own process (control 
>>path), i.e. asynchronously, rather than synchronously and on a single 
>>control path unless explicitely forked?
>>
>>This part really confused me; it's quite a difference whether you do:
>>     car driveTo: aPlace
>>and assume the car just does it (asynchronously) until it arrives 
>>there while the current control path continues or:
>>     [car driveTo: aPlace] fork
>>where you explicitly give the car it's own control path.
>>
>>Or have I misunderstood it completely? :)))
>>
>>>
>>>
>>>And, as I said at the start of the podcast, Smalltalk is an attitude. 
>>>If you are a programmer, wanting to solve some problem with code, 
>>>then Smalltalk is a good programming language. But if you want to 
>>>explore a field, understand, and document your journey of discovery 
>>>and invention, you could use pencil and paper. Or perhaps Jupyter 
>>>Notebooks. Or Smalltalk. If you use Smalltalk this way, it is way 
>>>more than a programming system.
>>Yup, that's what I use Smalltalk for - exploring, seeking active 
>>understanding. I have a problem with documenting though. You know I've 
>>tried to write as thorough comments as possible documenting 
>>intentions, explaining sticking points etc. (even if just to help 
>>myself understand it again a few months/weeks later) but IMHO it's 
>>still woefully insufficient - in addition to the more or less terse 
>>in-method comments I'd like to be able to add somewhere really close 
>>(even in-image Help files are too far away) more detailed 
>>descriptions, reasons for tradoffs, motivations, future plans, 
>>examples, etc. - but in a way that wouldn't clutter the environment.
>>
>>Now that you mentioned Jupyter Notebooks - I was wondering why Cuis 
>>Text Editor won't allow running code fragments - like the Workspace; 
>>whether it could serve as a richer documentation medium and "active" - 
>>able to run the examples just like Jupyter Notebooks. Or maybe I just 
>>missed something that already works that way...
>>
>>A note about exploration: I like to use Smalltalk to explore 
>>exceptions and e.g. tried to use them just as another workflow control 
>>mechanism. Recently, however, I've attended an OOP lecture where this 
>>type of use of exceptions was strongly discouraged. But this has 
>>nothing to do with OOP - maybe in Python or Java is doesn't make much 
>>sense due to their particular implementation but in Smalltalk - why 
>>not? :) And besides that Smalltalk is the only language I'm aware of 
>>that implements exceptions that can resume the computation - all other 
>>mainstream ones can only make return.
>>
>>>
>>>
>>>>Other question - Smalltalk was originally supposed to be the 
>>>>universal environment above the hardware level. Everything below the 
>>>>VM is the hardware (a machine language), everything above the VM is 
>>>>Smalltalk (the UI, apps...). Even the VM is written in a simplified 
>>>>Smalltalk (Slang); what was supposed to be the role of C - to stay 
>>>>as an intermediary between the Smalltalk level and the hardware or 
>>>>was (is?) it supposed to be eliminated somehow eventually?
>>>
>>>In my opinion, "Design Principles Behind Smalltalk" is the canon 
>>>here. C had no role originally, only much later. And its only role is 
>>>to be a useful implementation language for VMs. Nothing special.
>>>
>>>>
>>>>And one more note about "easy to use, intuitive, for children" - 
>>>>this refers to the DynaBook concept, right? Smalltalk as a language 
>>>>is a lot of things but certainly not those things :) Simple syntax 
>>>>doesn't mean simplicity but it thank god it saves me from 
>>>>remembering tons of syntactic rules :) Anyway, many thanks for 
>>>>explaining the DynaBook concept!
>>>>
>>>>Thanks again for the great talk!
>>>>best,
>>>>Jaromir
>>>
>>>Yes. Smalltalk was started as the "software half" of a Dynabook. 
>>>You'd read about the history, starting from Smalltalk-72, its 
>>>objectives and the experiences done by the Parc Learning Research 
>>>Group. And what happened after that, how they did Smalltalk-80, and 
>>>to what extent focus was changed. Same with the developments 
>>>described in the Green Book, and later commercial Smalltalks. How / 
>>>why focus changed? What happened with "for children"? Out of where 
>>>did Etoys, Scratch, and the whole world of tile programming came to 
>>>be?
>>>
>>>I think it is best to read what the people who did all this wrote. 
>>>For instance, start with 
>>>https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/blob/master/Documentation/Philosophical/OnMakingDynabooksReal.md 
>>>. Yes, the stuff in the Cuis repo is there for a reason.
>>Alan Kay writes:
>>"we'll know if we have the first Dynabook if we can make the end-user 
>>experience one of "reading and writing" about "powerful ideas" in a 
>>dynamic form, and to do this in such a way that large percentages of 
>>the bell-curve can learn how to do this."
>>
>>Q: Would an AI count as a UI? I'm thinking supplying an AI 
>>intermediary between the user and the system (replacing or rather 
>>complementing a keyboard) would make the system accessible to a wider 
>>range of users. It would help using the system, facilitate the user's 
>>learning, you name it. I hope this fantasy doesn't contradict somehow 
>>the Dynabook's idea :)
>>
>>Thanks again,
>>Jaromir
>>
>>>
>>>
>>>Cheers,
>>>--
>>>Juan Vuletich
>>>cuis.stgithub.com/jvuletichresearchgate.net/profile/Juan-Vuletichindependent.academia.edu/JuanVuletichpatents.justia.com/inventor/juan-manuel-vuletichlinkedin.com/in/juan-vuletich-75611b3twitter.com/JuanVuletich
>>--
>>Cuis-dev mailing list
>>Cuis-dev at lists.cuis.st
>>https://lists.cuis.st/mailman/listinfo/cuis-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20240629/4527c764/attachment-0001.htm>