[Cuis-dev] new YouTube video on Cuis Smalltalk

[Jaromir Matas]

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.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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20240626/eb53d21a/attachment-0001.htm>