[Cuis-dev] new YouTube video on Cuis Smalltalk

[Boris Shingarov]

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

After decades of re-reading and re-reading "Children of All Ages", this
paragraph never ceases to astound me, by how explicit it is about the
nonclassical character of Smalltalk.  The 20th-century "New Science" —
the physics of Einstein/Bohr/Heisenberg, the logic of Brouwer/Gödel, etc
— is *essential* to it: if we restrict ourselves to the "Newtonian
epistemology" (classical physics, classical logic, classical calculus),
then, (paraphrasing Schweitzer) "nothing remains of it, beyond that there
was a teacher from California named Alan Kay".

The duality of object's state and behavior, is just the categorial
duality of algebra (data) and coalgebra (functions), perhaps along the
lines of Boehm–Berarducci encoding [1], or Vassili Bykov's "How to get
rid of Objects in Smalltalk" [2].  Of course this all is just another
name for the topological duality between open/closed sets, or the quantum
duality between adjoint bra/ket, etc etc — these are manifestations of
the same phenomenon discovered around the first decades of the 20th
century.  When I first bumped into Kay's writings, I was struck by the
magic how Kay was able to write the above paragraph so much earlier
before systems like CLOS (in which the connection is obvious) were
constructed [3–7].  So I became curious, and a little digging led me to
Papert, Rosenblatt and Minsky; this was the moment when I became aware
that Kay did not operate in a vacuum, that the ideas of biologically-
inspired massively-parallel communicating agents were already actively
researched; became aware of the fight between the "connectionists" and
the "symbolists"; and of how naïve that fight proved in light of the
tremendous progress which was made in the following decades [8].

>> 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,

Can you explain why you think they are exaggerating?
>From my own personal experience (which of course is not universal, this
is why I am genuinely interested in learning about others' experiences,
hence asking) of trying to advance Smalltalk from the systems in use
today towards what Kay appears to say in his writings, I find the above
quote quite literally correct.  And in this my-own-experience when I
describe building a Kay-like Smalltalk, I have in some cases heard
fierce criticism of Kay (in a few cases transitioning into ad-hominem
arguments against him).  When I try to poke harder, in most of such
cases the deeper problem turns out to be that the opponent is firmly
entrenched in the "Newtonian epistemology", and engages in quantum
denialism bordering on Cargo-Cult Science.  The real challenge of the
situation is *competition*.  It's 2024 on the calendar; my competitors
have implemented post-quantum (cf. post-intuitionist etc.) algorithms,
reconciled the Connectionist and the Symbolist viewpoint, they are
engaging in kinds of computing completely unthinkable in the Newtonian
context.

By saying this, I don't mean to criticize Smalltalk-80 or to say that
we should build a "Kay-like (nonclassical) Smalltalk" to *replace* Cuis
because the latter is Newtonian.  To suggest it, would indicate a lack
of understanding of Bohr's correspondence principle.

Finkelstein explains this very nicely [9, 10]:

"Most of the pioneers of the quantum theory, including Einstein, de Broglie,
Schrödinger, and Wigner, retained more of the ontic classical epistemology
than Heisenberg and Bohr, and rejected the quantum project in principle.
Einstein's view is clearly stated and frequently quoted:

> There is no doubt that quantum mechanics has seized hold of a beautiful
> element of truth, and that it will be a test stone for any future
> theoretical basis, in that it must be deducible as a limiting case from
> that basis, just as electrostatics is deducible from Maxwell's equations
> of the electromagnetic field, or as thermodynamics is deducible from
> classical mechanics.  However, I do not believe that quantum mechanics
> will be the starting point in the search for this basis, just as, vice
> versa, one could not go from thermodynamics (resp. statistical mechanics)
> to the foundations of mechanics.
– Einstein 1936

Bohr believed that quantum mechanics "will be the starting point in the
search", as Einstein put it, but proposed nevertheless to give classical
concepts a permanent place in its foundations.  To be sure, Bohr noted,
our "classical" (that is, classical) concepts are "gross and inadequate",
and nature "leaks through them like water through a net".  At the same
time, Bohr explicitly rejected the idea of a "quantum universe" (in the
sense of a universe described by a ψ vector).

When the concept of a "ψ vector" or ket for the universe was broached
to him, he responded vehemently "You might as well say that we are only
dreaming that we are here."  He held that we must use classical concepts
to communicate about our experiments if we wish to be understood.
Heisenberg soon accepted Bohr's position on this matter, and it became
part of the Copenhagen quantum theory:

> The concepts of classical physics form the language by which we
> describe the arrangements of our experiments and state the results.
> We cannot and should not replace these concepts by others.  Still
> the application of these concepts is limited by the relations of
> uncertainty.
– Heisenberg

The insistence of Bohr and Heisenberg that we *cannot* use quantum
concepts to describe the episystem seems over-dogmatic today. … We
experiment with a praxic, post-Copenhagen position here.

== END OF FINKELSTEIN CITATION

So even if one characterization of Smalltalk-80 would be that its
designers "rejected Kay's Smalltalk project in principle", they would
be just following in Einstein's and Schrödinger's footsteps.
More seriously, though, if we are to build a Kay-like Smalltalk, it does
not *replace* Smalltalk-80 just like quantum mechanics does not *replace*
Newtonian mechanics.  In other words, Bohr's correspondence says that
a Kay-like Smalltalk must necessarily be embedded in something like Cuis.

-----

Looking back at what I just wrote, I am sorry I am not really *explaining*
but merely pointing in the general direction of what kind of thoughts
have been occupying my mind in the past dozen years.

Also I must warn about my choice of quantum mechanics as the example of
"twentieth-century science".  It is only because that's what I am familiar
with, NOT because it's better.  A topologist reading this post, can
criticize me like "hey Boris, why don't you talk about the familiar
open/closed sets instead of those obscure bra/ket", and it would be
perfectly valid.

[1] https://okmij.org/ftp/tagless-final/course/Boehm-Berarducci.html
[2] https://live.exept.de/doc/online/english/programming/humor.html
[3] https://doi.org/10.1017/S0956796800001490
[4] https://dx.doi.org/10.1017/S0960129500000694
[5] https://doi.org/10.1007/978-1-4613-1437-0_5
[6] https://doi.org/10.1007/BFb0053063
[7] https://www.cs.ru.nl/B.Jacobs/PAPERS/JR.pdf
[8] M.L.Minsky, S.A.Papert.  Perceptrons. (Make sure you have the 1988
    edition, not the 1969 original).
[9] D.R.Finkelstein. Quantum Relativity.
[10] S.A.Selesnick. Quanta, Logic and Spacetime: Variations on
     Finkelstein's Quantum Relativity.



On Thu, Jun 27, 2024 at 06:32:39PM +0100, Ezequiel Birman via Cuis-dev 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.
> 
> [...] 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 http://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