[Cuis-dev] new YouTube video on Cuis Smalltalk

Sat Jun 29 10:22:44 PDT 2024

Personally, I think the hardest part understanding how to design a program
is the algorithms available and data structures. This might be a bit off
topic, but when people tell me you don't need math to program, I somewhat
disagree.

On Sat, Jun 29, 2024, 12:38 p.m. Jaromir Matas via Cuis-dev <
cuis-dev at lists.cuis.st> wrote:

> 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 Vuletichcuis.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
>>
> --
> 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/e88bc75c/attachment-0001.htm>