Rendered at 22:30:43 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
edfsadfer 19 hours ago [-]
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.
ajasmin 19 hours ago [-]
I haven't used these in a long while.
Is this a fork? What's Cuis' main selling point compared Squeak and Pharo?
edfsadfer 19 hours ago [-]
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).
rbanffy 7 hours ago [-]
> 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?
AlanYx 9 hours ago [-]
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.
dialogbox 19 hours ago [-]
It looks like it is a fork started quite a long time ago.
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)
frou_dh 13 hours ago [-]
Is the rendering in Cuis really hardware-accelerated? I agree it looks great but think it's all software-rendered using the CPU.
isr 6 hours ago [-]
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.
ssivark 18 hours ago [-]
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.
DennisP 9 hours ago [-]
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.
isr 6 hours ago [-]
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.
The shared VM is a nice advantage, especially if performance isn't the main tradeoff
yje07039 18 hours ago [-]
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.
Bosustir 15 hours ago [-]
[dead]
sroerick 19 hours ago [-]
This looks cool and beautiful! Ive looked at other Smalltalks and been pretty intimidated. This feels cool and welcoming.
fhub 15 hours ago [-]
18 year old endorsements are cute touch.
chasil 19 hours ago [-]
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.”
jecel 3 hours ago [-]
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.
0xpgm 16 hours ago [-]
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.
pjmlp 14 hours ago [-]
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.
zelphirkalt 6 hours ago [-]
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.
kragen 7 hours ago [-]
Self has inheritance, using it far more pervasively than Smalltalk, and the original VB isn't OO.
jecel 3 hours ago [-]
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.
backhold 14 hours ago [-]
I suppose this goes back to the disambiguation of the term since Alan Kay coined it.
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.
Currently using it to build a mostly static website (with Pocketbase & lighttpd). A good experience all round.
Is this a fork? What's Cuis' main selling point compared Squeak and Pharo?
For me 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?
https://cuis.st/documentation/explanation/history
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)
https://youtu.be/HPcCg66tdrM?is=ErVqY5BvzofE9uQ4
"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 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.”
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.
Nowadays object oriented programming is almost entirely associated with inheritance hierarchies.
Perhaps inheritance isn't as central to object oriented programming as initially envisioned.
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.
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.
https://wiki.c2.com/?AlanKaysDefinitionOfObjectOriented