[Cuis-dev] new YouTube video on Cuis Smalltalk

Tue Aug 6 10:00:49 PDT 2024

Thank you for such a thoughtful reply! I will be thinking about it.

I'll delimit more precisely where I think they were exaggerating (I agree
with the rest):

...that it actually became hard to read.

Did it? Are Smalltalk-80 predecessors easier to read? And by the way, is
reading the hardest part?

...It fell back into data-structure-type programming instead of
> simulation-type programming.
>
Again, were Smalltalk-80 predecessors, —with the exception of
Smalltalk-72—, so much different? It is true that it requires some
imagination. We must enter willingly into a world of make believe.

Thanks again for all the references and detailed footnotes, I hope to be
able to understand what you are up to, some day... :)

On Mon, 5 Aug 2024 at 14:01, Boris Shingarov via Cuis-dev <
cuis-dev at lists.cuis.st> wrote:

> > 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
>
> --
> 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/20240806/3394f0fa/attachment-0001.htm>