[Cuis-dev] new YouTube video on Cuis Smalltalk

[Ezequiel Birman]

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.

[...] 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. 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.

“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. 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. 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

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