I know at least 5 Pharo users, and one of them wrote a book about it (for the other 4 :P).
They were part of a research group at university and made us students use it. I get why it's nice and all, but honestly it feels a bit like Crossfit, or Vim. There are a small handful of excited users who try to convice everyone else how amazing it is. (Sorry, Oscar et al.)
tbh im not sure what the value of this comment is here; also not a fan of talking down on other people's work (irrespective of how much you might dislike them). the most charitable explanation is that this was sarcasm?
Like many here, I've always been a language buff -- programming in assmebly, C(++), Java, various Lisps, Prolog, O'Caml/F#/Hask, etc. - and a fan of Smalltalk. (Used Tektronix ST and Smalltalk-V, but never Pharo.)
One thing that AI programming has done is made me care much less what programming language is being used. This is slightly regrettable, but for the most part very freeing, as I don't need to worry about what language is easier for me (as a human) to use for a particular problem, or make me inclined to use one of my "pet" programming languages over one that may be a better fit for more pedestrian reasons.
I am sorry to hear that, I hope you will rediscover the joys of programming one day again!
Humans haven't given up playing chess just because computers are able to do it better, there is still a point in recreational programming.
I am fondly remembering actually using Smalltalk in production for a small web project. I think I used Squeak with the Seaside framework. The image based workflow made deploying it surprisingly easy.
What I was trying to focus on was "getting the job done".
If I want to program for pure enjoyment, I can certainly still do that.
Although some people may play chess for a living, most that play chess don't.
>One thing that AI programming has done is made me care much less what programming language is being used
I'm right there with you. I really like programming in Python, the language. Now that I'm not writing much if any code, the rough edges in building and deployment have come to the forefront. Even "uvx run" has become a sticky wicket (I have some machines that don't have Internet access).
Does anyone know the current state of agent-assisted Smalltalk, Pharo or otherwise? Intuitively it seems like a match made in heaven, since the agent can directly manipulate the running program, but I also assume that there is very little training data available for Smalltalk.
I spent some time exploring Glamorous Toolkit [1] for agent-assisted custom UI development, in an emacs fashion, where you'd modify the interface you're working with on the fly. It was a pretty good experience and the built-in data exploration was top notch.
Ironically after watching glamorous toolkit videos on youtube, I was recommended a talk by Geoffrey Litt about dynamic documents [2] and at the end of his talk I learned about bb [3], which has much better agent integration compared to GT. Like @thelazydogsback said, with agents, the programming language matters less.
I was talking at around a year ago with Tudor Girba and asked him what is his opinion towards AI---I somehow believed it to be conflicting with his world view, but then he showed me some amazing demos of llms walking inside of the GT, making tools and molding it. It was way before these new agentic plugin-based IDEs.
I think Girba's really amazing idea of "language = ui = software = data" has a huge win in terms of AI that is not used anywhere else (maybe only in Chris Granger's Eve), but to work with data and build live on it, is something way better than BB.
I agree, it's an awesome concept in principle (and Girba is graciously welcoming people in discord). Working with an agent in GT, the agent will just look at the data and figure out how to express it in the graphical framework.
But in practicality, at least at this point, bb wins out by sheer expansiveness of ecosystem. I was working on a mishmash of an editor interface that combined obsidian with heptabase, directly in GT. It kind of worked. And the amazing thing is, everything has just a single representation: window positions displayed as text automatically have 2 way bindings across widgets, because they are the same data. But even with agents doing everything, 2 things creep up.
First is in JS/TS, all these binding problems are solved 1000x already. You can fake shared memory with callbacks and the agent won't lose track. In GT you move the cursor around, and have to decide at what point do you convert a widget representation to source representation, and when to restore the widget: is it a delay? is it after changing lines? is it after you move off the text? before or after the whitespace? There's a package for that somewhere in npm that answered all these questions, and it has tables, and it's performant. It doesn't do the 2% stuff that GT does using its magical shared memory representation (which also makes TS->smalltalk porting not straightforward), but you can still tape over it with sheer optimized code.
The second thing is that GT got really slow with all the data structure re-interpreting and rerendering. As "dirty" as bb is in reloading dynamic code, the runtimes are so optimized, I wanted the markdown nodes to be GPU-accelerated in bb, and it turns out they already were.
SmallJS ( https://small-js.org ) is a file based Smalltalk with full agent support.
Here's a vid of Claude converting a Counter app into a Tic-tac-toe game in a single shot: https://www.youtube.com/watch?v=4_ir6h2MIRg
PS The context loading step is not even necessary anymore.
The reason why this works so well, is that Claude knows its way around VSCode well. And all SmallJS projects (apps) have full unit tests and GUI tests that run in a couple of seconds. Claude also reads these tests and can make new ones, maintaining coverage.
In tradtional live Smalltalks like Pharo, modifying stuff is easy, but running full tests not so much..
I have tinkered with Pharo before, but I have come across quite a few entries on HN front page where I encountered projects, releases and I had no idea what the thing was! It could be anything from a networking library to LLM wrapper, from a music band to an programming language.
Clicking on this page, one finds:
> What is Pharo?
>
> Pharo is a pure object-oriented programming language and a powerful environment focused on simplicity and immediate feedback.
I really appreciate these one liner introductions on any project.
>"Reading stuff like this continue to make advances and new releases is like a fever dream when everything else is all AI."
Do the advances mean anything though? Alan Kay is a personal hero of mine, I love the aesthetic of Smalltalk, and the dream-that-was once upon a time of such a system was a real missed opportunity for the evolution of programming environments. But is it anything more than a neat hobby at this point?
> But is it anything more than a neat hobby at this point?
The opposite. With LLMs you can now pick up any one of these obscure language and write a full blown AAA game engine in them. Or a database. Or a web framework. Or... anything you set your mind to. The language no longer matters. btw LLMs are exceptionally good at Smalltalk/Haskell/Perl/FORTRAN and other old/uncommon languages.
https://squeak.js.org/demo/simple.html this is canvas not DOM/SVG. It doesn't support fonts/text. Its text support feels less janky than I expected, select, copy, paste work, but it is still not browser-native.
I don't know how to start Amber in the browser and couldn't find demos.
I imagine that's a deliberate decision of the overall project to try and get people to evaluate it on its merits, rather than associating it with something old and unfashionable.
I did the same thing! I thought it was strange as I always heard it referred to as “pharo smalltalk”, at first I was confused if this was the right project.
[0]: https://paulhammant.com/2017/09/01/smalltalk-envy/
One thing that AI programming has done is made me care much less what programming language is being used. This is slightly regrettable, but for the most part very freeing, as I don't need to worry about what language is easier for me (as a human) to use for a particular problem, or make me inclined to use one of my "pet" programming languages over one that may be a better fit for more pedestrian reasons.
Humans haven't given up playing chess just because computers are able to do it better, there is still a point in recreational programming.
I am fondly remembering actually using Smalltalk in production for a small web project. I think I used Squeak with the Seaside framework. The image based workflow made deploying it surprisingly easy.
I'm right there with you. I really like programming in Python, the language. Now that I'm not writing much if any code, the rough edges in building and deployment have come to the forefront. Even "uvx run" has become a sticky wicket (I have some machines that don't have Internet access).
https://github.com/gavr123456789/Niva
An implementation of Boids for Niva:
https://github.com/dharmatech/boids-niva
Ironically after watching glamorous toolkit videos on youtube, I was recommended a talk by Geoffrey Litt about dynamic documents [2] and at the end of his talk I learned about bb [3], which has much better agent integration compared to GT. Like @thelazydogsback said, with agents, the programming language matters less.
[1] https://gtoolkit.com/
[2] https://www.youtube.com/watch?v=MccJdr61xnc
[3] https://getbb.app/
I think Girba's really amazing idea of "language = ui = software = data" has a huge win in terms of AI that is not used anywhere else (maybe only in Chris Granger's Eve), but to work with data and build live on it, is something way better than BB.
But in practicality, at least at this point, bb wins out by sheer expansiveness of ecosystem. I was working on a mishmash of an editor interface that combined obsidian with heptabase, directly in GT. It kind of worked. And the amazing thing is, everything has just a single representation: window positions displayed as text automatically have 2 way bindings across widgets, because they are the same data. But even with agents doing everything, 2 things creep up.
First is in JS/TS, all these binding problems are solved 1000x already. You can fake shared memory with callbacks and the agent won't lose track. In GT you move the cursor around, and have to decide at what point do you convert a widget representation to source representation, and when to restore the widget: is it a delay? is it after changing lines? is it after you move off the text? before or after the whitespace? There's a package for that somewhere in npm that answered all these questions, and it has tables, and it's performant. It doesn't do the 2% stuff that GT does using its magical shared memory representation (which also makes TS->smalltalk porting not straightforward), but you can still tape over it with sheer optimized code.
The second thing is that GT got really slow with all the data structure re-interpreting and rerendering. As "dirty" as bb is in reloading dynamic code, the runtimes are so optimized, I wanted the markdown nodes to be GPU-accelerated in bb, and it turns out they already were.
Sounds pretty cool. Never heard about Pharo before, but i will try it in spare time.
This should be a BIG benefit for agent-driven development, but sadly it seems that few people is taking advantage of it.
Clicking on this page, one finds:
> What is Pharo? > > Pharo is a pure object-oriented programming language and a powerful environment focused on simplicity and immediate feedback.
I really appreciate these one liner introductions on any project.
Do the advances mean anything though? Alan Kay is a personal hero of mine, I love the aesthetic of Smalltalk, and the dream-that-was once upon a time of such a system was a real missed opportunity for the evolution of programming environments. But is it anything more than a neat hobby at this point?
It effectively already is. It may end up in the same domain as Haiku OS, Plant 9, or Squeak, but they are all still interesting domains of research.
When was it anything else? The 80s? I've can count the number of Smalltalk jobs I've seen in my career on my hand (but I have seen them)
The opposite. With LLMs you can now pick up any one of these obscure language and write a full blown AAA game engine in them. Or a database. Or a web framework. Or... anything you set your mind to. The language no longer matters. btw LLMs are exceptionally good at Smalltalk/Haskell/Perl/FORTRAN and other old/uncommon languages.
(Smalltalk is a religion, I will die on this hill!)
It could serve as the engine for new, fun, interactive websites!
[1] https://github.com/rabbibotton/clog
https://www.amber-lang.net/
https://en.wikipedia.org/wiki/Amber_Smalltalk
or more like https://squeak.js.org/ ?
I don't know how to start Amber in the browser and couldn't find demos.
https://pharojs.org/
https://github.com/pharo-pulsar/pulsar
Almost "Pharo for Gnome".
Nothing found. Weird.