<div dir="ltr"><div>Thank you for such a thoughtful reply! I will be thinking about it.<br><br></div><div>I'll delimit more precisely where I think they were exaggerating (I agree with the rest):<br><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">...that it actually became hard to read.</blockquote></div><div><br>Did it? Are Smalltalk-80 predecessors easier to read? And by the way, is reading the hardest part?<br><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>...It fell back into data-structure-type programming instead of simulation-type programming.<br></div></blockquote><div>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.<br><br>Thanks again for all the references and detailed footnotes, I hope to be able to understand what you are up to, some day... :)<br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 5 Aug 2024 at 14:01, Boris Shingarov via Cuis-dev <<a href="mailto:cuis-dev@lists.cuis.st">cuis-dev@lists.cuis.st</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> The basic idea is to exploit the duality between 'functions and tables (or<br>
> processes and memory). English has nouns which refer to "objects", and<br>
> verbs which refer to "actors" and "relators". This is a Newtonian<br>
> epistemology. Modern physics and philosophy tend towards the idea that<br>
> both "objects" and "actors" are just different aspects of the notion of<br>
> process.<br>
<br>
After decades of re-reading and re-reading "Children of All Ages", this<br>
paragraph never ceases to astound me, by how explicit it is about the<br>
nonclassical character of Smalltalk. The 20th-century "New Science" —<br>
the physics of Einstein/Bohr/Heisenberg, the logic of Brouwer/Gödel, etc<br>
— is *essential* to it: if we restrict ourselves to the "Newtonian<br>
epistemology" (classical physics, classical logic, classical calculus),<br>
then, (paraphrasing Schweitzer) "nothing remains of it, beyond that there<br>
was a teacher from California named Alan Kay".<br>
<br>
The duality of object's state and behavior, is just the categorial<br>
duality of algebra (data) and coalgebra (functions), perhaps along the<br>
lines of Boehm–Berarducci encoding [1], or Vassili Bykov's "How to get<br>
rid of Objects in Smalltalk" [2]. Of course this all is just another<br>
name for the topological duality between open/closed sets, or the quantum<br>
duality between adjoint bra/ket, etc etc — these are manifestations of<br>
the same phenomenon discovered around the first decades of the 20th<br>
century. When I first bumped into Kay's writings, I was struck by the<br>
magic how Kay was able to write the above paragraph so much earlier<br>
before systems like CLOS (in which the connection is obvious) were<br>
constructed [3–7]. So I became curious, and a little digging led me to<br>
Papert, Rosenblatt and Minsky; this was the moment when I became aware<br>
that Kay did not operate in a vacuum, that the ideas of biologically-<br>
inspired massively-parallel communicating agents were already actively<br>
researched; became aware of the fight between the "connectionists" and<br>
the "symbolists"; and of how naïve that fight proved in light of the<br>
tremendous progress which was made in the following decades [8].<br>
<br>
>> The next major revision of Smalltalk was Smalltalk-80. Kay was no longer<br>
>> on the scene to argue that any language should be simple enough for a child<br>
>> to use. Smalltalk-80, says Tesler, went too far in the opposite direction<br>
>> from the earliest versions of Smalltalk: “It went to such an extreme to<br>
>> make it compilable, uniform, and readable, that it actually became hard to<br>
>> read, and you definitely wouldn’t want to teach it to children.”<br>
>><br>
>> Kay, looking at Smalltalk-80, said, “It’s terrible that it can’t be used<br>
>> by children, since that’s who Smalltalk was intended for. It fell back into<br>
>> data-structure-type programming instead of simulation-type programming.”<br>
><br>
> I think that both Tesler and Kay are exaggerating here,<br>
<br>
Can you explain why you think they are exaggerating?<br>
>From my own personal experience (which of course is not universal, this<br>
is why I am genuinely interested in learning about others' experiences,<br>
hence asking) of trying to advance Smalltalk from the systems in use<br>
today towards what Kay appears to say in his writings, I find the above<br>
quote quite literally correct. And in this my-own-experience when I<br>
describe building a Kay-like Smalltalk, I have in some cases heard<br>
fierce criticism of Kay (in a few cases transitioning into ad-hominem<br>
arguments against him). When I try to poke harder, in most of such<br>
cases the deeper problem turns out to be that the opponent is firmly<br>
entrenched in the "Newtonian epistemology", and engages in quantum<br>
denialism bordering on Cargo-Cult Science. The real challenge of the<br>
situation is *competition*. It's 2024 on the calendar; my competitors<br>
have implemented post-quantum (cf. post-intuitionist etc.) algorithms,<br>
reconciled the Connectionist and the Symbolist viewpoint, they are<br>
engaging in kinds of computing completely unthinkable in the Newtonian<br>
context.<br>
<br>
By saying this, I don't mean to criticize Smalltalk-80 or to say that<br>
we should build a "Kay-like (nonclassical) Smalltalk" to *replace* Cuis<br>
because the latter is Newtonian. To suggest it, would indicate a lack<br>
of understanding of Bohr's correspondence principle.<br>
<br>
Finkelstein explains this very nicely [9, 10]:<br>
<br>
"Most of the pioneers of the quantum theory, including Einstein, de Broglie,<br>
Schrödinger, and Wigner, retained more of the ontic classical epistemology<br>
than Heisenberg and Bohr, and rejected the quantum project in principle.<br>
Einstein's view is clearly stated and frequently quoted:<br>
<br>
> There is no doubt that quantum mechanics has seized hold of a beautiful<br>
> element of truth, and that it will be a test stone for any future<br>
> theoretical basis, in that it must be deducible as a limiting case from<br>
> that basis, just as electrostatics is deducible from Maxwell's equations<br>
> of the electromagnetic field, or as thermodynamics is deducible from<br>
> classical mechanics. However, I do not believe that quantum mechanics<br>
> will be the starting point in the search for this basis, just as, vice<br>
> versa, one could not go from thermodynamics (resp. statistical mechanics)<br>
> to the foundations of mechanics.<br>
– Einstein 1936<br>
<br>
Bohr believed that quantum mechanics "will be the starting point in the<br>
search", as Einstein put it, but proposed nevertheless to give classical<br>
concepts a permanent place in its foundations. To be sure, Bohr noted,<br>
our "classical" (that is, classical) concepts are "gross and inadequate",<br>
and nature "leaks through them like water through a net". At the same<br>
time, Bohr explicitly rejected the idea of a "quantum universe" (in the<br>
sense of a universe described by a ψ vector).<br>
<br>
When the concept of a "ψ vector" or ket for the universe was broached<br>
to him, he responded vehemently "You might as well say that we are only<br>
dreaming that we are here." He held that we must use classical concepts<br>
to communicate about our experiments if we wish to be understood.<br>
Heisenberg soon accepted Bohr's position on this matter, and it became<br>
part of the Copenhagen quantum theory:<br>
<br>
> The concepts of classical physics form the language by which we<br>
> describe the arrangements of our experiments and state the results.<br>
> We cannot and should not replace these concepts by others. Still<br>
> the application of these concepts is limited by the relations of<br>
> uncertainty.<br>
– Heisenberg<br>
<br>
The insistence of Bohr and Heisenberg that we *cannot* use quantum<br>
concepts to describe the episystem seems over-dogmatic today. … We<br>
experiment with a praxic, post-Copenhagen position here.<br>
<br>
== END OF FINKELSTEIN CITATION<br>
<br>
So even if one characterization of Smalltalk-80 would be that its<br>
designers "rejected Kay's Smalltalk project in principle", they would<br>
be just following in Einstein's and Schrödinger's footsteps.<br>
More seriously, though, if we are to build a Kay-like Smalltalk, it does<br>
not *replace* Smalltalk-80 just like quantum mechanics does not *replace*<br>
Newtonian mechanics. In other words, Bohr's correspondence says that<br>
a Kay-like Smalltalk must necessarily be embedded in something like Cuis.<br>
<br>
-----<br>
<br>
Looking back at what I just wrote, I am sorry I am not really *explaining*<br>
but merely pointing in the general direction of what kind of thoughts<br>
have been occupying my mind in the past dozen years.<br>
<br>
Also I must warn about my choice of quantum mechanics as the example of<br>
"twentieth-century science". It is only because that's what I am familiar<br>
with, NOT because it's better. A topologist reading this post, can<br>
criticize me like "hey Boris, why don't you talk about the familiar<br>
open/closed sets instead of those obscure bra/ket", and it would be<br>
perfectly valid.<br>
<br>
[1] <a href="https://okmij.org/ftp/tagless-final/course/Boehm-Berarducci.html" rel="noreferrer" target="_blank">https://okmij.org/ftp/tagless-final/course/Boehm-Berarducci.html</a><br>
[2] <a href="https://live.exept.de/doc/online/english/programming/humor.html" rel="noreferrer" target="_blank">https://live.exept.de/doc/online/english/programming/humor.html</a><br>
[3] <a href="https://doi.org/10.1017/S0956796800001490" rel="noreferrer" target="_blank">https://doi.org/10.1017/S0956796800001490</a><br>
[4] <a href="https://dx.doi.org/10.1017/S0960129500000694" rel="noreferrer" target="_blank">https://dx.doi.org/10.1017/S0960129500000694</a><br>
[5] <a href="https://doi.org/10.1007/978-1-4613-1437-0_5" rel="noreferrer" target="_blank">https://doi.org/10.1007/978-1-4613-1437-0_5</a><br>
[6] <a href="https://doi.org/10.1007/BFb0053063" rel="noreferrer" target="_blank">https://doi.org/10.1007/BFb0053063</a><br>
[7] <a href="https://www.cs.ru.nl/B.Jacobs/PAPERS/JR.pdf" rel="noreferrer" target="_blank">https://www.cs.ru.nl/B.Jacobs/PAPERS/JR.pdf</a><br>
[8] M.L.Minsky, S.A.Papert. Perceptrons. (Make sure you have the 1988<br>
edition, not the 1969 original).<br>
[9] D.R.Finkelstein. Quantum Relativity.<br>
[10] S.A.Selesnick. Quanta, Logic and Spacetime: Variations on<br>
Finkelstein's Quantum Relativity.<br>
<br>
<br>
<br>
On Thu, Jun 27, 2024 at 06:32:39PM +0100, Ezequiel Birman via Cuis-dev wrote:<br>
> Sorry in advance for the scattered replies<br>
> <br>
> Joseph Turco wrote:<br>
> <br>
> > When Alan Kay and Adele Goldberg were testing smalltalk-80, they were<br>
> > using kids in school to play with it (...)<br>
> ><br>
> Children didn't use Smalltalk-80. For all that I know, children used<br>
> Smalltalk-72 through Smalltalk-76. A good summary is provided in the<br>
> article by Perry and Wallich, Inside the PARC: the `information architects'<br>
> <<a href="https://spectrum.ieee.org/xerox-parc/smalltalk-history" rel="noreferrer" target="_blank">https://spectrum.ieee.org/xerox-parc/smalltalk-history</a>> from which I quote:<br>
> <br>
> > The first compiled version of Smalltalk, written in 1976, marked the end<br>
> > of the emphasis on a language that children could use. The language was now<br>
> > “a mature programming environment,” Ingalls said. “We got interested in<br>
> > exporting it and making it widely available.”<br>
> ><br>
> > The next major revision of Smalltalk was Smalltalk-80. Kay was no longer<br>
> > on the scene to argue that any language should be simple enough for a child<br>
> > to use. Smalltalk-80, says Tesler, went too far in the opposite direction<br>
> > from the earliest versions of Smalltalk: “It went to such an extreme to<br>
> > make it compilable, uniform, and readable, that it actually became hard to<br>
> > read, and you definitely wouldn’t want to teach it to children.”<br>
> ><br>
> > Kay, looking at Smalltalk-80, said, “It’s terrible that it can’t be used<br>
> > by children, since that’s who Smalltalk was intended for. It fell back into<br>
> > data-structure-type programming instead of simulation-type programming.”<br>
> ><br>
> I think that both Tesler and Kay are exaggerating here, but the push by<br>
> Xerox to create “the office of the future” was real.<br>
> <br>
> Jaromir Matas wrote:<br>
> <br>
> > Your Youtube talk and especially your answers allowed me to read the<br>
> > articles with a whole new level of understanding. Especially Alan Kay's "A<br>
> > Personal Computer for Children of All Ages" has so much to say [...]<br>
> ><br>
> I wonder what percentage of people understand “children of all ages” the<br>
> same way I do. Cyril Connolly said that Imprisoned in every fat man, a thin<br>
> one is wildly signalling to be let out. I want to believe that I don't have<br>
> much difficulty in letting my inner-child out. For good or ill, this view<br>
> of children as unprejudiced, unspoiled, playful, curious little people<br>
> (childlike) can coexist with the reality of their capricious and demanding<br>
> nature (childish). One of the things we like about computers is the almost<br>
> instant gratification they can provide.<br>
> <br>
> [...] I have a problem with documenting though. You know I've tried to<br>
> > write as thorough comments as possible documenting intentions, explaining<br>
> > sticking points etc. (even if just to help myself understand it again a few<br>
> > months/weeks later) but IMHO it's still woefully insufficient - in addition<br>
> > to the more or less terse in-method comments I'd like to be able to add<br>
> > somewhere really close (even in-image Help files are too far away) more<br>
> > detailed descriptions, reasons for tradoffs, motivations, future plans,<br>
> > examples, etc. - but in a way that wouldn't clutter the environment.<br>
> <br>
> and<br>
> <br>
> > I'm not sure I understand the part about "knowledge" though: "Write,<br>
> > describe, communicate knowledge" - what does it mean exactly? Is it about<br>
> > Smalltalk as a language? The language itself is not that different from<br>
> > other (high-level) languages. A good language certainly is a great help to<br>
> > formulate things but it's still a "programming language". I guess there<br>
> > more to it I didn't get :)<br>
> ><br>
> > Or is it about the whole concept including the live "OS-like" environment?<br>
> > But where the "writing knowledge" fits in?<br>
> ><br>
> Maybe the misunderstanding is due to the fact that you are taking<br>
> “documentation” at face value. In my mind, *every* program, at least every<br>
> program written in something higher level than assembly language, can be<br>
> regarded as “documentation”. And in a way, it is the best sort of<br>
> documentation because it must execute. This is also different from Knuth's<br>
> idea and realization of literate programming. I like his point of view only<br>
> because I like reading for reading's sake, and I like books, and I like how<br>
> *he* writes; but code is not literature<br>
> <<a href="https://gigamonkeys.com/code-reading" rel="noreferrer" target="_blank">https://gigamonkeys.com/code-reading</a>>. What I am talking about is more<br>
> like a deliberate confusion between the map and the territory.<br>
> <br>
> “For the people that want a system that is fully malleable, even if<br>
> limited, Smalltalk is still the best thing that has been built” said Juan<br>
> in the interview, because all of the things you mentioned combined together<br>
> with thoughtful design evolved during decades (if you also take into<br>
> account Self, Morphic and other developments). If this is not a qualitative<br>
> jump, I don't know what it is. I cannot avoid thinking about the balloon<br>
> <<a href="https://wiki.squeak.org/squeak/3459" rel="noreferrer" target="_blank">https://wiki.squeak.org/squeak/3459</a>>; it conveys such an adequate picture.<br>
> <br>
> Jaromir Matas wrote:<br>
> <br>
> > I've played a bit with Javascript and Python recently and my impression is<br>
> > they try to follow basically the same goal [...]<br>
> ><br>
> I disagree. Their original goal was to be “scripting” languages and thus,<br>
> they favored scripting over robustness, comprehensibility, design, clarity,<br>
> simplicity, and consistency. Of course you can still write beautiful Python<br>
> or JavaScript as you can write ugly Smalltalk. Kay has used the Ford-T<br>
> metaphor; Ingalls compared Smalltalk to a musical instrument. I don't know<br>
> about you but I prefer to play or learn to play a keyboard instrument in a<br>
> beautifully crafted Steinway rather than in a cheap electronic Casio<br>
> keyboard.<br>
> <br>
> Ken Dickey wrote:<br>
> <br>
> > The Squeak folks noted Scheme48, which is/was a Scheme written in Scheme<br>
> > which compiled to C and had decent performance on computers of the day<br>
> > -- so they knew it could be done.<br>
> ><br>
> Thanks for reminding us! Scheme 48 <<a href="https://s48.org" rel="noreferrer" target="_blank">https://s48.org</a>> was my scheme of<br>
> choice back in the day.<br>
> <br>
> Juan Vuletich wrote:<br>
> <br>
> > There are several links at<br>
> > <a href="https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/blob/master/Documentation/AboutCuis.md#the-philosophy-behind-cuis" rel="noreferrer" target="_blank">https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/blob/master/Documentation/AboutCuis.md#the-philosophy-behind-cuis</a><br>
> > . Have you read them? Please do.<br>
> <br>
> I'd also urge everyone to read Programming as Theory Building<br>
> <<a href="https://archive.org/details/computinghumanac0000naur/page/36/mode/2up" rel="noreferrer" target="_blank">https://archive.org/details/computinghumanac0000naur/page/36/mode/2up</a>> by<br>
> Peter Naur<br>
> <br>
> -- <br>
> Eze<br>
> <br>
> <br>
> A quarta, 26/06/2024, 23:47, Jaromir Matas via Cuis-dev <<br>
> <a href="mailto:cuis-dev@lists.cuis.st" target="_blank">cuis-dev@lists.cuis.st</a>> escreveu:<br>
> <br>
> > Hi Juan,<br>
> ><br>
> ><br>
> > On 24-Jun-24 12:22:00 AM, "Juan Vuletich via Cuis-dev" <<br>
> > <a href="mailto:cuis-dev@lists.cuis.st" target="_blank">cuis-dev@lists.cuis.st</a>> wrote:<br>
> ><br>
> > On 6/23/2024 5:19 AM, Jaromir Matas via Cuis-dev wrote:<br>
> ><br>
> > I'm not sure I understand the part about "knowledge" though: "Write,<br>
> > describe, communicate knowledge" - what does it mean exactly? Is it about<br>
> > Smalltalk as a language? The language itself is not that different from<br>
> > other (high-level) languages. A good language certainly is a great help to<br>
> > formulate things but it's still a "programming language". I guess there<br>
> > more to it I didn't get :)<br>
> ><br>
> > Or is it about the whole concept including the live "OS-like" environment?<br>
> > But where the "writing knowledge" fits in?<br>
> ><br>
> ><br>
> > There are only some many things that can be said in an hour.<br>
> ><br>
> > There are several links at<br>
> > <a href="https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/blob/master/Documentation/AboutCuis.md#the-philosophy-behind-cuis" rel="noreferrer" target="_blank">https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/blob/master/Documentation/AboutCuis.md#the-philosophy-behind-cuis</a><br>
> > . Have you read them? Please do.<br>
> ><br>
> > I'm so glad you nudged me to read them. Your Youtube talk and especially<br>
> > your answers allowed me to read the articles with a whole new level of<br>
> > understanding. Especially Alan Kay's "A Personal Computer for Children of<br>
> > All Ages" has so much to say; here's what caught my attention (re objects<br>
> > vs. processes):<br>
> > quote<br>
> ><br>
> > The following principles should be used in the design of the Dynabook<br>
> > language.<br>
> ><br>
> > 1. We need a uniform notion as to what objects are, how they may be<br>
> > referred to, and how they can manipulate other objects.<br>
> ><br>
> > 2. If each object can have its own control path, then there must be a<br>
> > concise way to coordinate and "control" these paths when more than one is<br>
> > active.<br>
> ><br>
> > 3. The evaluation of a control path should follow simple rules which show<br>
> > how objects are passed messages and return results.<br>
> ><br>
> > 4. Every object in a system should be redefinable in terms of other<br>
> > objects.<br>
> ><br>
> > The basic idea is to exploit the duality between 'functions and tables (or<br>
> > processes and memory). English has nouns which refer to "objects", and<br>
> > verbs which refer to "actors" and "relators". This is a Newtonian<br>
> > epistemology. Modern physics and philosophy tend towards the idea that both<br>
> > "objects" and "actors" are just different aspects of the notion of<br>
> > *process*. A process has *state* (a set of relations having only to do<br>
> > with it) which changes as time (defined as interactions with other objects)<br>
> > passes. Using this view "data" is a process which changes "slowly",<br>
> > "function" is a process which changes more rapidly. Each process has the<br>
> > logical attributes of a complete "micro" computer: they can have inputs,<br>
> > give back outputs, act as a memory on file system, perform computations, be<br>
> > interrupted, etc. […] Since multiple control paths are allowed, many<br>
> > processes can be in various stages of evaluation and debugging.<br>
> ><br>
> > unquote<br>
> ><br>
> > Do I understand correctly that Alan Kay suggests in (2) that each object<br>
> > should have its own control path (i.e. a thread, aka a process in Smalltalk<br>
> > vocabulary)? Is he somehow placing an equal sign between objects and actors<br>
> > (like e.g. Squeak Actors by Tony Garnock-Jones,<br>
> > <a href="https://tonyg.github.io/squeak-actors" rel="noreferrer" target="_blank">https://tonyg.github.io/squeak-actors</a>) where actors are implemented as<br>
> > processes. Would that implicate that the idea was that objects should do<br>
> > their jobs in parallel, each in its own process (control path), i.e.<br>
> > asynchronously, rather than synchronously and on a single control path<br>
> > unless explicitely forked?<br>
> ><br>
> > This part really confused me; it's quite a difference whether you do:<br>
> > car driveTo: aPlace<br>
> > and assume the car just does it (asynchronously) until it arrives there<br>
> > while the current control path continues or:<br>
> > [car driveTo: aPlace] fork<br>
> > where you explicitly give the car it's own control path.<br>
> ><br>
> > Or have I misunderstood it completely? :)))<br>
> ><br>
> ><br>
> ><br>
> > And, as I said at the start of the podcast, Smalltalk is an attitude. If<br>
> > you are a programmer, wanting to solve some problem with code, then<br>
> > Smalltalk is a good programming language. But if you want to explore a<br>
> > field, understand, and document your journey of discovery and invention,<br>
> > you could use pencil and paper. Or perhaps Jupyter Notebooks. Or Smalltalk.<br>
> > If you use Smalltalk this way, it is way more than a programming system.<br>
> ><br>
> > Yup, that's what I use Smalltalk for - exploring, seeking active<br>
> > understanding. I have a problem with documenting though. You know I've<br>
> > tried to write as thorough comments as possible documenting intentions,<br>
> > explaining sticking points etc. (even if just to help myself understand it<br>
> > again a few months/weeks later) but IMHO it's still woefully insufficient -<br>
> > in addition to the more or less terse in-method comments I'd like to be<br>
> > able to add somewhere really close (even in-image Help files are too far<br>
> > away) more detailed descriptions, reasons for tradoffs, motivations, future<br>
> > plans, examples, etc. - but in a way that wouldn't clutter the<br>
> > environment.<br>
> ><br>
> > Now that you mentioned Jupyter Notebooks - I was wondering why Cuis Text<br>
> > Editor won't allow running code fragments - like the Workspace; whether it<br>
> > could serve as a richer documentation medium and "active" - able to run the<br>
> > examples just like Jupyter Notebooks. Or maybe I just missed something that<br>
> > already works that way...<br>
> ><br>
> > A note about exploration: I like to use Smalltalk to explore exceptions<br>
> > and e.g. tried to use them just as another workflow control mechanism.<br>
> > Recently, however, I've attended an OOP lecture where this type of use of<br>
> > exceptions was strongly discouraged. But this has nothing to do with OOP -<br>
> > maybe in Python or Java is doesn't make much sense due to their particular<br>
> > implementation but in Smalltalk - why not? :) And besides that Smalltalk is<br>
> > the only language I'm aware of that implements exceptions that can resume<br>
> > the computation - all other mainstream ones can only make return.<br>
> ><br>
> ><br>
> ><br>
> > Other question - Smalltalk was originally supposed to be the universal<br>
> > environment above the hardware level. Everything below the VM is the<br>
> > hardware (a machine language), everything above the VM is Smalltalk (the<br>
> > UI, apps...). Even the VM is written in a simplified Smalltalk (Slang);<br>
> > what was supposed to be the role of C - to stay as an intermediary between<br>
> > the Smalltalk level and the hardware or was (is?) it supposed to be<br>
> > eliminated somehow eventually?<br>
> ><br>
> ><br>
> > In my opinion, "Design Principles Behind Smalltalk" is the canon here. C<br>
> > had no role originally, only much later. And its only role is to be a<br>
> > useful implementation language for VMs. Nothing special.<br>
> ><br>
> ><br>
> > And one more note about "easy to use, intuitive, for children" - this<br>
> > refers to the DynaBook concept, right? Smalltalk as a language is a lot of<br>
> > things but certainly not those things :) Simple syntax doesn't mean<br>
> > simplicity but it thank god it saves me from remembering tons of syntactic<br>
> > rules :) Anyway, many thanks for explaining the DynaBook concept!<br>
> ><br>
> > Thanks again for the great talk!<br>
> > best,<br>
> > Jaromir<br>
> ><br>
> ><br>
> > Yes. Smalltalk was started as the "software half" of a Dynabook. You'd<br>
> > read about the history, starting from Smalltalk-72, its objectives and the<br>
> > experiences done by the Parc Learning Research Group. And what happened<br>
> > after that, how they did Smalltalk-80, and to what extent focus was<br>
> > changed. Same with the developments described in the Green Book, and later<br>
> > commercial Smalltalks. How / why focus changed? What happened with "for<br>
> > children"? Out of where did Etoys, Scratch, and the whole world of tile<br>
> > programming came to be?<br>
> ><br>
> > I think it is best to read what the people who did all this wrote. For<br>
> > instance, start with<br>
> > <a href="https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/blob/master/Documentation/Philosophical/OnMakingDynabooksReal.md" rel="noreferrer" target="_blank">https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/blob/master/Documentation/Philosophical/OnMakingDynabooksReal.md</a><br>
> > . Yes, the stuff in the Cuis repo is there for a reason.<br>
> ><br>
> > Alan Kay writes:<br>
> > "we'll know if we have the first Dynabook if we can make the end-user<br>
> > experience one of "reading and writing" about "powerful ideas" in a dynamic<br>
> > form, and to do this in such a way that large percentages of the bell-curve<br>
> > can learn how to do this."<br>
> ><br>
> > Q: Would an AI count as a UI? I'm thinking supplying an AI intermediary<br>
> > between the user and the system (replacing or rather complementing a<br>
> > keyboard) would make the system accessible to a wider range of users. It<br>
> > would help using the system, facilitate the user's learning, you name it. I<br>
> > hope this fantasy doesn't contradict somehow the Dynabook's idea :)<br>
> ><br>
> > Thanks again,<br>
> > Jaromir<br>
> ><br>
> ><br>
> ><br>
> > Cheers,<br>
> ><br>
> > --<br>
> > Juan <a href="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" rel="noreferrer" target="_blank">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</a><br>
> ><br>
> > --<br>
> > Cuis-dev mailing list<br>
> > <a href="mailto:Cuis-dev@lists.cuis.st" target="_blank">Cuis-dev@lists.cuis.st</a><br>
> > <a href="https://lists.cuis.st/mailman/listinfo/cuis-dev" rel="noreferrer" target="_blank">https://lists.cuis.st/mailman/listinfo/cuis-dev</a><br>
> ><br>
<br>
> -- <br>
> Cuis-dev mailing list<br>
> <a href="mailto:Cuis-dev@lists.cuis.st" target="_blank">Cuis-dev@lists.cuis.st</a><br>
> <a href="https://lists.cuis.st/mailman/listinfo/cuis-dev" rel="noreferrer" target="_blank">https://lists.cuis.st/mailman/listinfo/cuis-dev</a><br>
<br>
-- <br>
Cuis-dev mailing list<br>
<a href="mailto:Cuis-dev@lists.cuis.st" target="_blank">Cuis-dev@lists.cuis.st</a><br>
<a href="https://lists.cuis.st/mailman/listinfo/cuis-dev" rel="noreferrer" target="_blank">https://lists.cuis.st/mailman/listinfo/cuis-dev</a><br>
</blockquote></div>