The first programming language I learned almost two decades ago was Ruby, later when I explored Smalltalk which gained some popularity due to Seaside I couldn't believe how much cleaner and easier the syntax was. However the image model is a tough pill to swallow and I never wrapped my head around it despite it being the selling point for those that can take advantage of it. I also never liked that the GUI is it's own thing and always felt foreign to the system I was running on. In the past there was some headless version with some minor syntax extensions I think called Coral? which could be used ordinarily from the shell like other scripting languages but I don't know if it's still a thing and it always surprised me this path wasn't explored or pushed further to make it more popular/approachable.
Cuis is an environment derived from Squeak as I understand it with all the "clutter" removed. So it is really a cut-down Squeak. Just as Pharo was a cut-down Squeak originally.
For me it was easier and quicker to get something done in Cuis than in any other Smalltalk (Squeak, Pharo, VA, Dolphin).
Cuis is the easiest entrypoint into modern Smalltalk. All the others have so, so much stuff (great stuff, just a lot of it). Cuis takes the approach of paring things down to something minimal. You can understand everything from top to bottom fairly easily.
The history link gives details, but if you want a quick analogy:
Pharo & Cuis both forked from squeak at roughly the same time
Squeak = Debian
Pharo = Arch
Cuis = Alpine
Cuis has rigorously simplified, so its much easier to explore & understand the system - because there's less of it
Cuis's re-engineering of morphic is really quite brilliant. Everything is hardware accelerated vector graphics. EVEN THE FONTS are drawn that way. And they remain crisp even when zoomed (in or out) & rotated.
Pharo does have some cool stuff though. I'd love to see fuel (object serialization) & soil (a fully oo database) ported to cuis. And the big one - seaside
But its not an either-or situation. 99% 9f what you learn & do in one is applicable to the other. But if you're starting out, I would definitely recommend cuis (not implying that you wouldn't necessarily stick with it)
Is the development experience compatible with modern AI-assisted workflows? Coding agents have drastically reduced the entry barrier for playing with software projects, and I can think of some fun ideas for Smalltalk things I've been curious about.
I saw a comment saying it is, and having a coding agent able to modify a running environment is a game changer, but I haven't wrapped my head around that yet.
AI isn't my personal cup of tea, but anyway. There is a monthly "show your cool stuff" online meetup, and the most recent one was directly about one dude using AI to build his own quasi-gnome-desktop-like morphic world within cuis.
I hadn’t heard anything about Smalltalk since seeing it used in version 1.4 of Scratch, so it’s a pleasant surprise to come across it again after all this time.
What most people do not know is that Smalltalk was originally a childrens' teaching language, a peer of Logo, which (I have learned in previous comments) preceded it.
"Smalltalk is a purely object-oriented programming language that was originally created in the 1970s for educational use, specifically for constructionist learning, but later found use in business."
Alan Kay, one of the lead developers of Smalltalk, said it was also valued for being good for bootstrapping ideas for building
systems. He went into that topic starting at 58:50 in this talk:
“To me the most distressing thing that happened to Smalltalk when it came out of Xerox PARC was for many respects and purposes it quit changing. Now I can tell you at Xerox PARC there were four major versions, completely different versions, of the language over about a ten year period. And many dozens and dozens of significant releases within those different versions. And I think one of the things we liked most about Smalltalk was not what it could do but the fact that it was such a good vehicle for bootstrapping the next set of ideas we had about how to do systems building. And that for all intents and purposes when Smalltalk went commercial ceased. Even though there was a book, the famous blue book, that Adele and Dave wrote that had the actual code in it for making Smalltalk interpreters and starting this process oneself, almost nobody took advantage of this. Almost no university took advantage of it, almost no commercial institution took advantage of it. And what they missed was, to me, the deepest thing I would like to communicate to you today, and that is we don’t know how to design systems yet. So let’s not make what we don’t know into a religion for God’s sake. What we need to do is to constantly think and think and think about what’s important. And we have to have our systems let us get to the next levels of abstraction as we come to them. And the thing that I’m most proud of about Smalltalk, pretty much the only thing from my standpoint that I’m proud of, is that it has been so good at getting rid of previous versions of itself until it came out into this world. Now one of the reasons we got involved in doing Smalltalk talk again, for me it was after 16 years of not working on programming languages, a couple of years ago we started this project we called Squeak, which is simply, not an attempt to give the world a free Smalltalk, but an attempt to give the world a bootstrapping mechanism for something much better than Smalltalk. And when you fool around with Squeak please please think of it from that stand...think of how you can obsolete the damn thing by using its own mechanisms for getting the next version of itself.”
The original Smalltalk-72 focused on teaching children, but for Smalltalk-76 Alan Kay and Dan Ingalls wanted different things. Alan wanted to continue the kid focus while Dan argued that a language focused on advanced programmers could be used to implement a children's language on top of it. He was proven right decades later when EToys and then Scratch were implemented on top of Squeak Smalltalk, which closely followed Smalltalk-76.
This confusion frustrated me when I first read about Smalltalk in the August 1981 issue of Byte magazine. I couldn't figure it out and at that point I had learned several programming languages and none of them took me more than two hours to become reasonably fluent in. So I was having problems with a language that kids were using?!? Later on I found out about the differences between Smalltalk-72 and -80 and that the Byte articles explained things that made sense if you already knew them but didn't help you learn in the first place. All variations of Smalltalk have become my favorite way to program ever since.
It isn't, the haters are the ones that don't get that there are many OOP flavours, mostly they only learnt one way and naturally everything is like that.
The original VB and Self are two other well known examples where there is no inheritance support.
Also most Lisp systems inspired in The Art of Metaobject Protocol tend to focus on multi-methods, instead of inheritance, to change current behaviours attached to structs.
I sometimes "hate", exactly because of people having learned one flavour of OOP, usually the Java flavor of "everthing must be a class" and trying to shoehorn everything into that style of programming, insisting that inheritance must be had, even though many people have already learned the lesson of composition over inheritance, and even though one of the most popular newer languages, Rust, doesn't even have inheritance or classes. Also the "mutate everything from everywhere, as long as I have a setter"-style.
That dogmatic Java-flavor-OOP and their ideas of translating design patterns 1-to-1 to other languages like Python, disregarding the language specifics and language design choices ... ugh, such a PITA.
That's where my guards are going up, and I start observing very closely, what that person's understanding of OOP is, and whether they merely throw out buzzwords, or actually know something about what they are talking about.
Some prototype based languages use delegation instead of inheritance, so people assume that is the case for Self as well. The difference is subtle. But as you pointed out and Mario Wolczko said: "Self is like Smalltalk, only more so". There were also languages with neither inheritance nor delegation but that still included some scheme for sharing.
When using so called OOP languages I specifically avoid inheritance, and in fact I think it's the worst aspect of it. In any case, I tend not to include inheritance into the definition of object orientation.
The first programming language I learned almost two decades ago was Ruby, later when I explored Smalltalk which gained some popularity due to Seaside I couldn't believe how much cleaner and easier the syntax was. However the image model is a tough pill to swallow and I never wrapped my head around it despite it being the selling point for those that can take advantage of it. I also never liked that the GUI is it's own thing and always felt foreign to the system I was running on. In the past there was some headless version with some minor syntax extensions I think called Coral? which could be used ordinarily from the shell like other scripting languages but I don't know if it's still a thing and it always surprised me this path wasn't explored or pushed further to make it more popular/approachable.
Same VM as Squeak and Pharo so just as fast but a bit lacking in libs but this is an opportunity to contribute to open source for me.
Currently using it to build a mostly static website (with Pocketbase & lighttpd). A good experience all round.
I haven't used these in a long while.
Is this a fork? What's Cuis' main selling point compared Squeak and Pharo?
Cuis is an environment derived from Squeak as I understand it with all the "clutter" removed. So it is really a cut-down Squeak. Just as Pharo was a cut-down Squeak originally.
For me it was easier and quicker to get something done in Cuis than in any other Smalltalk (Squeak, Pharo, VA, Dolphin).
> it was easier and quicker to get something done in Cuis than in any other Smalltalk (Squeak, Pharo, VA, Dolphin).
Is this a UI issue or library issue? Are the APIs more ergonomic?
Cuis is the easiest entrypoint into modern Smalltalk. All the others have so, so much stuff (great stuff, just a lot of it). Cuis takes the approach of paring things down to something minimal. You can understand everything from top to bottom fairly easily.
It looks like it is a fork started quite a long time ago.
https://cuis.st/documentation/explanation/history
The history link gives details, but if you want a quick analogy:
Pharo & Cuis both forked from squeak at roughly the same time
Squeak = Debian
Pharo = Arch
Cuis = Alpine
Cuis has rigorously simplified, so its much easier to explore & understand the system - because there's less of it
Cuis's re-engineering of morphic is really quite brilliant. Everything is hardware accelerated vector graphics. EVEN THE FONTS are drawn that way. And they remain crisp even when zoomed (in or out) & rotated.
Pharo does have some cool stuff though. I'd love to see fuel (object serialization) & soil (a fully oo database) ported to cuis. And the big one - seaside
But its not an either-or situation. 99% 9f what you learn & do in one is applicable to the other. But if you're starting out, I would definitely recommend cuis (not implying that you wouldn't necessarily stick with it)
Is the rendering in Cuis really hardware-accelerated? I agree it looks great but think it's all software-rendered using the CPU.
The first prototype implementation was pure "in-image" smalltalk, but a VM plugin to handle it has been in production use for well over a year now.
Is the development experience compatible with modern AI-assisted workflows? Coding agents have drastically reduced the entry barrier for playing with software projects, and I can think of some fun ideas for Smalltalk things I've been curious about.
I saw a comment saying it is, and having a coding agent able to modify a running environment is a game changer, but I haven't wrapped my head around that yet.
AI isn't my personal cup of tea, but anyway. There is a monthly "show your cool stuff" online meetup, and the most recent one was directly about one dude using AI to build his own quasi-gnome-desktop-like morphic world within cuis.
https://youtu.be/HPcCg66tdrM?is=ErVqY5BvzofE9uQ4
The shared VM is a nice advantage, especially if performance isn't the main tradeoff
This looks cool and beautiful! Ive looked at other Smalltalks and been pretty intimidated. This feels cool and welcoming.
I hadn’t heard anything about Smalltalk since seeing it used in version 1.4 of Scratch, so it’s a pleasant surprise to come across it again after all this time.
[dead]
I wonder if they will publish slides and talks from?:
https://smalltalks2026.fast.org.ar/talks
What most people do not know is that Smalltalk was originally a childrens' teaching language, a peer of Logo, which (I have learned in previous comments) preceded it.
"Smalltalk is a purely object-oriented programming language that was originally created in the 1970s for educational use, specifically for constructionist learning, but later found use in business."
https://en.wikipedia.org/wiki/Smalltalk
Alan Kay, one of the lead developers of Smalltalk, said it was also valued for being good for bootstrapping ideas for building systems. He went into that topic starting at 58:50 in this talk:
Alan Kay at OOPSLA 1997 - The computer revolution hasn’t happened yet https://www.youtube.com/watch?v=oKg1hTOQXoY&t=3530s
“To me the most distressing thing that happened to Smalltalk when it came out of Xerox PARC was for many respects and purposes it quit changing. Now I can tell you at Xerox PARC there were four major versions, completely different versions, of the language over about a ten year period. And many dozens and dozens of significant releases within those different versions. And I think one of the things we liked most about Smalltalk was not what it could do but the fact that it was such a good vehicle for bootstrapping the next set of ideas we had about how to do systems building. And that for all intents and purposes when Smalltalk went commercial ceased. Even though there was a book, the famous blue book, that Adele and Dave wrote that had the actual code in it for making Smalltalk interpreters and starting this process oneself, almost nobody took advantage of this. Almost no university took advantage of it, almost no commercial institution took advantage of it. And what they missed was, to me, the deepest thing I would like to communicate to you today, and that is we don’t know how to design systems yet. So let’s not make what we don’t know into a religion for God’s sake. What we need to do is to constantly think and think and think about what’s important. And we have to have our systems let us get to the next levels of abstraction as we come to them. And the thing that I’m most proud of about Smalltalk, pretty much the only thing from my standpoint that I’m proud of, is that it has been so good at getting rid of previous versions of itself until it came out into this world. Now one of the reasons we got involved in doing Smalltalk talk again, for me it was after 16 years of not working on programming languages, a couple of years ago we started this project we called Squeak, which is simply, not an attempt to give the world a free Smalltalk, but an attempt to give the world a bootstrapping mechanism for something much better than Smalltalk. And when you fool around with Squeak please please think of it from that stand...think of how you can obsolete the damn thing by using its own mechanisms for getting the next version of itself.”
The original Smalltalk-72 focused on teaching children, but for Smalltalk-76 Alan Kay and Dan Ingalls wanted different things. Alan wanted to continue the kid focus while Dan argued that a language focused on advanced programmers could be used to implement a children's language on top of it. He was proven right decades later when EToys and then Scratch were implemented on top of Squeak Smalltalk, which closely followed Smalltalk-76.
This confusion frustrated me when I first read about Smalltalk in the August 1981 issue of Byte magazine. I couldn't figure it out and at that point I had learned several programming languages and none of them took me more than two hours to become reasonably fluent in. So I was having problems with a language that kids were using?!? Later on I found out about the differences between Smalltalk-72 and -80 and that the Byte articles explained things that made sense if you already knew them but didn't help you learn in the first place. All variations of Smalltalk have become my favorite way to program ever since.
Also, even though it called itself purely object-oriented, the earlier versions lacked inheritance.
Nowadays object oriented programming is almost entirely associated with inheritance hierarchies.
Perhaps inheritance isn't as central to object oriented programming as initially envisioned.
It isn't, the haters are the ones that don't get that there are many OOP flavours, mostly they only learnt one way and naturally everything is like that.
The original VB and Self are two other well known examples where there is no inheritance support.
Also most Lisp systems inspired in The Art of Metaobject Protocol tend to focus on multi-methods, instead of inheritance, to change current behaviours attached to structs.
I sometimes "hate", exactly because of people having learned one flavour of OOP, usually the Java flavor of "everthing must be a class" and trying to shoehorn everything into that style of programming, insisting that inheritance must be had, even though many people have already learned the lesson of composition over inheritance, and even though one of the most popular newer languages, Rust, doesn't even have inheritance or classes. Also the "mutate everything from everywhere, as long as I have a setter"-style.
That dogmatic Java-flavor-OOP and their ideas of translating design patterns 1-to-1 to other languages like Python, disregarding the language specifics and language design choices ... ugh, such a PITA.
That's where my guards are going up, and I start observing very closely, what that person's understanding of OOP is, and whether they merely throw out buzzwords, or actually know something about what they are talking about.
Self has inheritance, using it far more pervasively than Smalltalk, and the original VB isn't OO.
Some prototype based languages use delegation instead of inheritance, so people assume that is the case for Self as well. The difference is subtle. But as you pointed out and Mario Wolczko said: "Self is like Smalltalk, only more so". There were also languages with neither inheritance nor delegation but that still included some scheme for sharing.
Prototype based inheritance is another matter.
Original VB was definitely OOP, especially since VB 4, when VBX was replaced by COM.
I suppose this goes back to the disambiguation of the term since Alan Kay coined it.
https://wiki.c2.com/?AlanKaysDefinitionOfObjectOriented
When using so called OOP languages I specifically avoid inheritance, and in fact I think it's the worst aspect of it. In any case, I tend not to include inheritance into the definition of object orientation.
18 year old endorsements are cute touch.
[flagged]
[flagged]
[dead]