Nice talk! I guess many of us agree to a large degree with your goals.

Two comments:

• Onions. I was surprised to learn that the layer structure was emphasized by Adele Goldberg in the context of Smalltalk, because I feel that's what it mostly missing from Smalltalk. The Smalltalk class browser displays a huge unstructured list of classes, and inside many of these classes you get a huge weakly structured list of methods. Even if a package does have layers, they are not displayed by the system.
• Your reason for choosing the Web for implementing Simpletalk (in the question session) is unfortunately exactly what makes the Web ever more inevitable for everyone. Everyone who hates the Web but builds on it makes it harder to build anything else in the future. We are accumulating technical debt at a collective scale. Not that I have a better solution of course...

Thank you Konrad Hinsen ! much appreciated

The idea of peeling back layers was always present in the Learning Research Group at PARC, but it was certainly beyond Smalltalk (whichever you take ’72 to the present). It was the emphasis that systems should not have synthetic barriers of understandability, i.e. barriers that are completely irrelevant and outside of the environment itself. Just think of how much you have to learn in order to add a button to your OS desktop to display or make so many of the even trivial changes. There is no path from A->B which does require you to learn new programming languages, paradigms, etc etc

  It is as if to write down your thought you needed to  go and study stone carving/chiseling for 3 years… This is exactly the sort of thing the LRG wanted to avoid. And I would argue that this is  the case for Smalltalk, but whether the way things are organized or the metaphor used for this organization is good, i.e. evocative, is a different conversation.

 And one we should be having! - one of the reasons to make more authorship environments! This is what Alan Kay wanted/thought was going to happen. He even insisted that they burn all the disks and start over in ~’78 but that was vetoed by the group.

Smalltalk was an engine for thinking about how computing could be in the future. It was not intended to be the engine of computing. Simpletalk goes along the same direction. It is a conversation starter not an end-all. That in no way takes away from what it should be able to do - it should be the real thing.

Papert said that “in order to think about thinking you need to think about thinking about something.”

In order to author an authorship environment you need to author the authoring of something. Awkward but you get the point…

And yes as you intuited our starting point was to build a system from the ground up. But we counted on an initial 3-6 months of funding, and going ‘from the bare metal’ to something like this with three people in that time is not realistic. Moreover we wanted to ask slightly different questions as step one, those which were beyond specificities of implementation, hardware and all that.

So thank you for comments! They are exactly inline with what I hope will generate the sort of thinking about such environments and computing as a whole.

From the manifesto:

The current situation can be summarized as elementary education concerned with teaching children how to read and write, but only through the use of pre-formatted bureaucratic forms. No scribbling on paper, no coloring outside the lines – just letters and words within labelled boxes that have been specified for some purpose that remains opaque to the children.

❤ I've said something similar: programming today is largely just bureaucracy by other means.

Reminds me of the discussion of the difference between education and propaganda in https://consilienceproject.org/we-dont-make-propaganda-they-do/. The goal of education is to bring the student to the level of the teacher. The goal of propaganda is to maintain an epistemic gap. Teaching programming within predefined limits is then closer to propaganda than to education.

Konrad Hinsen I feel you on the "using the web" argument. The problem is that there still isn't a quick way to easily make malleable, cross-platform UI without a lot of hassle. We used Ohm as our PEG because we hoped to make a Smalltalk version of the system at some point, but as you know Morphic is too heavy (and undocumented) a beast to get modern-capable UIs running. I'm hopeful for Bloc and that might have been another target down the road.

@Eric Gade I have been using feenk's Glamorous Toolkit for a while. It demonstrates that Bloc can be used to build very nice user interfaces.

Konrad Hinsen I've been following Bloc's development (and GT, which is great) for years. I think it's very promising, though there are still speed issues that can be quite jarring. Juan Vuletich's Vector Graphics work is also promising (btw I'm "darth-cheney" over on the GT/Pharo Discord)

Ooh, Mariano Guerra, Eric's talk video talks about the desire of kids to learn the "real thing" at the 31 minute mark. (Context: https://futureofcoding.slack.com/archives/C5T9GPWFL/p1634484364391100?thread_ts=1634445846.387500&cid=C5T9GPWFL)

💯 to throwing away web browsers. I said this recently: https://twitter.com/akkartik/status/1448894658252185601

@Eric Gade shameless plug: you could have a look at https://github.com/ErikOnBike/CodeParadise to make this all run in pure Smalltalk (all the way down to running the UI in the browser using a tiny Smalltalk image in it). Seeing you seem to liken the idea of using Smalltalk. The documentation and demo's for CodeParadise are lacking a bit atm, but I am actively working on it (building business software in line with Richard Pawson's ideas about Expressive Systems, see https://www.youtube.com/watch?v=xBGoOipssN0).

Another idea that comes to mind is to have Simpletalk use the Smalltalk language but simply have it 'show' the objects and classes which are understandable by the user. A non-programmer user will see objects like Card, Part and Window and programmer users will also see things like OrderedCollection and WebSocket for example. I can't change or repair my own car (besides the fact I don't own one), but I can use it and move stuff around with it. So I would be the non-programming user of my car. Both the programming and non-programming user would send messages to objects to request them to perform some behaviour (for which they are responsible).

@Erik Stel Yeah that makes sense; we considered writing this in Smalltalk, Smalltalk + Seaside for the web, or LivelyKernel but in the end we were interested in asking fundamental questions about what an authorship systems could look like in a modern environments and whether a metaphor based approach to building such, or other, computing systems is fruitful.

Best way to do so was to take the ideas we like and go from there. Going into environments we knew and largely liked Smalltalk-like, Lisp-like etc would force us back into those modes of thinking/programming.

The idea, of course, is to throw this away and rebuild from scratch and have many authorship environments built in the world so we can better understand where this can go. With that we wanted to reach as many people as possible, from developers, to designers to current day “users.” Putting this in on the web has the dual advantages of being easy to distribute but also to surreptitiously undermine peoples’ current perceptions of what something is.

I have to read up a bit more about Simpletalk and the metaphor idea, because I don't completely understand it yet. I really like the idea of programmer and non-programmer user (or at least in my interpretation as given by my previous post 😉), because it more or less describes what I want to do with CodeParadise as well (becoming a development environment for kids). Gradually giving/showing deeper layers of the system to the user based on their experience/comfort/need.

In any case: I like what you are doing! 🙂

Alan Kay's often talked about how such a system should provide fences around each level of meta - so the end-user system (as shown in Expressive Systems video) would have no fences, and then the next meta level, which might be to add additional behaviors to the objects, might require some demonstration of experience/desire to modify the system

@Erik Stel Code paradise looks interesting! Is it necessary to run the server environment?

Hi @Naveen Michaud-Agrawal. Nice to read about your interest. Yes, you have to run a server environment. This means (atm) running a Pharo Smalltalk image. (To prevent hijacking this topic, please DM me or let's start a new thread if you like more information).

@Naveen Michaud-Agrawal That’s right. “Peeling the onion” is an important component here. Kay, and others in the LRG or community at large, insisted on this. They also insisted that it doesn’t mean that going to the next level is trivial, or that you don’t have to learn anything. They only insisted that it is possible and consistent within the environment or system.

@Erik Stel thanks again and also happy to start a different thread about CodeParadise. Also happy to talk about some of these ideas (feel free to DM). Or if there is sufficient interest @Eric Gade and I can find a time that works well for all and give a version of the talk ^^^, discuss whatever people want around these topics.

@Daniel Krasner Do you have references / quotes on "peeling the onion"? I have read quite a bit of the work of Kay and collaborators, but I don't remember this phrase. So perhaps I have been missing some corner of the LRG community.

Konrad Hinsen Although I am sure I’ve come across this somewhere in the literature (diSessa, Kay, Ingalls, Solomon) I can’t quite remember where. The “peeling the onion” quote you see in Eric’s talk, and the one that has stuck with us, is from footage from this documentary: https://messagenotunderstood.com/

It’s not released but we are working on it!

Oh my god I absolutely LOVE the moment when you physically flip the detector panel over at 1:09 to reveal how it works. You are doing a great job retaining the physicality of the world where it works, and breaking it where it doesn't.

Thanks Chris, I could have put the detectors in another layer so whenever I wanted access to them I could show the right layer all nice and proper. But putting them on a panel I can just flip open with the mouse physically is so much easier. Once again my laziness served me well 😀

We remember. Love the physicality of it. The interaction with the bottom middle logic popup panel is interesting, like an entirely different mode of expression.

Felipe Reigosa great work! do you have a working version to participate on Review Jam? http://marianoguerra.github.io/review-jam/

@William Taysom Thanks, I'm often surprised by how powerful the motherboard programming is (the logic panel as you call it), that was kind of an accident. Back in the early days, each motherboard contained a little snippet of Clojure code but I noticed that a lot of them were simple if/them clauses and when they weren't you could simplify them to be so by making the other logic physical, if you know what I mean? For instance instead of writing code to detect a recent button press in the Simon game by having a Clojure variable to keep track of the last time a button was pressed, I just created a physical thingamajig that is in a certain state for a while after each button press. So if each motherboard can just be simple if/then statements with or/and/not conditions, then it can be represented by a simple graph. Even things I thought couldn't be simplified this way like a while loop turned out to be possible, the "player" circuit is a physical while loop for instance.

Mariano Guerra Thanks, the Review Jam sounds like a great idea! Perfect not only to get real feedback but also try some really interesting tools from the other people here. I have to focus on work for a few weeks and trying all those tools does sound time consuming but since it's still a month away I think I probably can make it. I'll prepare a new version when I can, it's more involved than you would think, that's why the version on my site is so old, but I'll get it done.