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.
For me it has the opposite effect. Now I can finally use whatever programming language I want! Is my language missing a library? No worries Opus will write one!
I've ended up alternating between "the LLM can write the awful glue code I'm too lazy to hand wring for my proof of concept" and "ooh, what if this was in Fortran _and_ JavaScript?"
For me it's been liberating because I no longer have to worry about what languages I choose to spend my free time on at the risk of missing out on something more practical. For example, I love Common Lisp, but taking time relearn it always felt to come at the expense of something else that might also confer practical benefit. Now, in a sense, all programming languages are equally useless.
I recently did a major move and had to restructure my bookshelf pretty dramatically. The only programming books I kept out of storage where the Common Lisp and Prolog ones. Spending time learning a language that doesn't directly impact how you think about computation itself seems to be more of misuse of time (of course really, when programming truly for fun it shouldn't matter one way or the other).
I found Pharo's (Smalltalk's) image based programming environment interesting when I played around with it, but I'm not sure how well it'd play with an agent-first workflow, or whether it'd bring any advantages.
One thing that AI programming has done is made me care more about how well the AI can handle a language than my own facility with it. I wouldn't be surprised if programming languages begin to tilt toward being easier for agents to work with, while still remaining readable to people -- whatever that ends up meaning.
I've found most agents can work effectively and quickly with Go code, I think mainly due to the strong focus on simplicity in the language and tooling. Something like Pharo is a bit like the opposite end of the spectrum.
>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).
With enough interest in integrity computing, that they are still in business, selling development environments (there are community editions available).
Eiffel was also the very first OOP language to introduce non nullable references, which I bet many folks in HN would attribute to something more trendy.
Versioning and SCM solutions on image based systems has not been a problem in decades, but alas we keep getting people that don't learn from history and think they are the very first coming up with a solution for something.
Especially if their only understanding of programming is "the way UNIX does it".
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?
dunno why you're getting downvoted. also that original comment suffers from the fallacy of popularity (which is 50/50. Something popular is so either because it's good, or because of chance).
The comment mocking Pharo/Smalltalk could have been written by someone who probably writes in one of the Blub languages that are extremely popular. LOL.
I would recommend Cuis Smalltalk (https://cuis.st) as a more idiomatic solution that also looks much better due to it's vector graphic based rendering engine.
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.
Do you have any recommendations for starting points with the bb ecosystem? As in, good existing components or practices?
I've been using it on and off for a while, but never got around to doing any major customisation mainly because I hate reinventing wheels (and also I was busy with other things). But I now am looking for something like a cross between Warp and Zed's Delta (which is a very nice design), and bb might be able to give it to me.
EDIT: OK, the plugin marketplace is much more browsable than the last time I looked. It'd be lovely to have a gallery where people can show off their own configs. Maybe I should make one...
I literally just type into the input what functionality I want. In the beginning it was capability exploration: "integrate draw.io", which was quick work, but I never actually used it.
Then I threw actually useful things at it: find this directory of pdf scans, and create an interface where I can browse the files, preview them, and query an lmstudio server, and auto-rename the pdf based on the content.
Another is to ssh to a remote machine that has a particular file organization structure, and give me a preview gallery.
Nothing is particularly complex, but I couldn't be bothered to making that myself. It's also something that I would've used in emacs (the preview function is like dired-preview-mode in emacs), but a graphical interface would perform better.
> The second thing is that GT got really slow with all the data structure re-interpreting and rerendering.
Ironically enough, I was thinking about the same thing in the morning of the day I replied to you, that gives the amount of data JS provides in the runtime, do we really need Smalltalk for a live system? I agree with you fully.
I guess something about me doesn't want to accept that BB can be a superior GT!
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..
> but I also assume that there is very little training data available for Smalltalk.
Is this actually an issue? I was under the impression that the conclusion was that LLMs will invariably be terrible at writing good, working code (since their training sets are 90% garbage produced by humans), hence why agentic development now is heavy on verification tools and other software that can signal to the LLM whether the code works and has any code smells. Also why AI agents nowadays seem to write and execute scripts for a lot of tasks instead of spitting code directly. Hence, the volume of training data shouldn't be as relevant as it used to be.
I wonder if it’s a bubble thing. People carry on and do what they always did, or just began thinking about what to do with LLMs. Big tech companies and startups may have to move fast and adapt, but I guess many other companies and organisations do not have to rush or fear immediate extinction, just because the wind blows in the other direction elsewhere in the world. I see that Hacker News and X are very "noisy" about LLMs (naturally), but that doesn’t mean the whole tech industry must react in the same way.
>"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.
this is a welcome development. I've tried Pharo 14 and it's order of magnitudes better than say, Pharo 9-- in every way. Even Profstef was updated and made pedagogically appealing.
Someone asked for updated mooc--well since that is not there yet, the next best thing is the updated books both available for free (one needs to be compiled from the github repo (2026 version, Sept).
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.
I don't understand why Pharo doesn't proudly acknowledge that it is a version of Smalltalk on its landing page, rather than this lukewarm statement on its About page:
> A dynamic, pure, reflective object-oriented programming language in the tradition of Smalltalk
Why not call it a modern Smalltalk, which seems to be what it is?
Smalltalk is a great language and its ecosystem deserves to grow.
The "tradition of Smalltalk" is to experiment and exceed what came before. Alan Kay expressed disappointment about the ossification of Smalltalk upon the release of Smalltalk 80. Pharo and Squeak are trying to carry forward only the tradition of the original Smalltalk to produce new ideas, not "be a Smalltalk" (whatever that means).
If you say "Pharo is a Smalltalk" then you might get some of the religious elite come and claim "Thou must change this aspect of the system! For it is in violation of the law of Smalltalk as handed down to our forefathers in Smalltalk 80". Pharo is its own system, heavily inspired by Smalltalk to the extent that non-language lawyers look at it and say "it's Smalltalk".
People argue about whether Janet or Clojure are lisps. Some people say that only Common Lisp is Lisp. Some include Scheme as well. But the unqualified "Lisp" usually means Common Lisp when referring to an actual language with an actual specification that you can find an actual compiler to create binaries with. Pharo is a Smalltalk in a similar way to how Scheme is a Lisp. Different enough that saying "Scheme" means something different from "Lisp" to everyone who knows enough to know what you're talking about.
Alan Kay: A couple of years ago, we started this project 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 Squeak, please, please, think of it from that standpoint.
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.
Why is this thing so fast? I type 3 + 4, hit alt+p and the result appears instantly! (Or the better question: why are all the other things so slow?) I submitted it to <https://news.ycombinator.com/item?id=50259214>!
I did the MOOC recently with Pharo 14, there's some changes in the UI but it's easy enough to follow along. The only thing that changed significantly was the TinyBlog part, with some changes in Seaside and a lot of changes to Bootstrap, but I just asked an llm to update the code examples to the latest version and it worked without too much trouble.
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 think this was once the case. Smalltalk was very "so last year" once Java Marketing overtook the world (I worked for Cincom, final resting place of VisualWorks Smalltalk, may it rest in peace).
At this point, I think it's flipped. The people that might be attracted to it would probably enjoy the retro hat tip. The various language wars have all been pointlessly adjudicated, and lost in time, first to the dominance/explosion of JavaScript only programmers, and now due to LLM generated code.
Learning Smalltalk, and practicing it heavily for 20 years was probably the single best thing I learned in programming during 35+ years. It helped me get very good at modelling things. I work in Swift/Kotlin/Elixir/C now days, and I've learned some great things from those systems as well. But how to build representations of real world data as well as structure concepts/relationships more virtual, hands down to Smalltalk (for me).
I learnt Smalltalk on Smalltalk/V for Windows 3.1, so I also watched that transition take place.
Not sure how it was seen from inside at Cincom, however having a couple of Smalltalk vendors quickly pivoting from Smalltalk into Java, to the point most IDEs and libraries that appeared where from Smalltalk origin, was what ended up killing all existing interest into keeping using Smalltalk products.
There was this language that Sun was pushing for free, with SDKs on cover CDs, alongside plenty of stuff coming from Smalltalk, why pay for expensive Smalltalk IDEs, seemed to be the opinion back then.
So we ended up with Java, .NET, Objective-C, as half way to the whole Smalltalk experience.
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.
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.
For me it has the opposite effect. Now I can finally use whatever programming language I want! Is my language missing a library? No worries Opus will write one!
AI workflows don't seem to be suited to image-based environments like Smalltalk's, though.
On the contrary, when using SaaS based programming environments, aka iPaaS, it really feels like using Smalltalk and Lisp images.
With a very big difference, at least I could backup Smalltalk and Lisp images.
Unless you give them a tool which lets them execute arbitrary code in the running image.
Or at least this works wonderfully in Clojure via the nREPL.
On the other hand, ai agent harnesses work a bit like image based system - think: claude --resume
I've ended up alternating between "the LLM can write the awful glue code I'm too lazy to hand wring for my proof of concept" and "ooh, what if this was in Fortran _and_ JavaScript?"
Dark times.
For me it's been liberating because I no longer have to worry about what languages I choose to spend my free time on at the risk of missing out on something more practical. For example, I love Common Lisp, but taking time relearn it always felt to come at the expense of something else that might also confer practical benefit. Now, in a sense, all programming languages are equally useless.
I recently did a major move and had to restructure my bookshelf pretty dramatically. The only programming books I kept out of storage where the Common Lisp and Prolog ones. Spending time learning a language that doesn't directly impact how you think about computation itself seems to be more of misuse of time (of course really, when programming truly for fun it shouldn't matter one way or the other).
I found Pharo's (Smalltalk's) image based programming environment interesting when I played around with it, but I'm not sure how well it'd play with an agent-first workflow, or whether it'd bring any advantages.
One thing that AI programming has done is made me care more about how well the AI can handle a language than my own facility with it. I wouldn't be surprised if programming languages begin to tilt toward being easier for agents to work with, while still remaining readable to people -- whatever that ends up meaning.
I've found most agents can work effectively and quickly with Go code, I think mainly due to the strong focus on simplicity in the language and tooling. Something like Pharo is a bit like the opposite end of the spectrum.
>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).
This is exciting news, and I would like to say "hello" to Richard Kenneth Eng, the sole user of Pharo in the world.
It's getting harder to pick between Pharo vs Eiffel for a new project :)
What is compelling about Eiffel? Serious question.
I think that the interesting thing about Eiffel is that it supports design by contract, an idea that was created and implemented first in Eiffel.
With enough interest in integrity computing, that they are still in business, selling development environments (there are community editions available).
Eiffel was also the very first OOP language to introduce non nullable references, which I bet many folks in HN would attribute to something more trendy.
Somebody has never used ENVY[0].
[0]: https://paulhammant.com/2017/09/01/smalltalk-envy/
Versioning and SCM solutions on image based systems has not been a problem in decades, but alas we keep getting people that don't learn from history and think they are the very first coming up with a solution for something.
Especially if their only understanding of programming is "the way UNIX does it".
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.)
Learning vim motions is legitimately amazing, and well worth the effort, even if you never use vim itself.
that sounds like Lisp promotion. But in the case of Lisp, it's actually true.
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?
dunno why you're getting downvoted. also that original comment suffers from the fallacy of popularity (which is 50/50. Something popular is so either because it's good, or because of chance).
The comment mocking Pharo/Smalltalk could have been written by someone who probably writes in one of the Blub languages that are extremely popular. LOL.
I would recommend Cuis Smalltalk (https://cuis.st) as a more idiomatic solution that also looks much better due to it's vector graphic based rendering engine.
Weren't morphs also vector based? Here is one tiny "game" that Claude helped me bring back to life:
https://github.com/edragoev1/aquarium-for-squeak
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.
[1] https://gtoolkit.com/
[2] https://www.youtube.com/watch?v=MccJdr61xnc
[3] https://getbb.app/
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.
Do you have any recommendations for starting points with the bb ecosystem? As in, good existing components or practices?
I've been using it on and off for a while, but never got around to doing any major customisation mainly because I hate reinventing wheels (and also I was busy with other things). But I now am looking for something like a cross between Warp and Zed's Delta (which is a very nice design), and bb might be able to give it to me.
EDIT: OK, the plugin marketplace is much more browsable than the last time I looked. It'd be lovely to have a gallery where people can show off their own configs. Maybe I should make one...
I literally just type into the input what functionality I want. In the beginning it was capability exploration: "integrate draw.io", which was quick work, but I never actually used it.
Then I threw actually useful things at it: find this directory of pdf scans, and create an interface where I can browse the files, preview them, and query an lmstudio server, and auto-rename the pdf based on the content.
Another is to ssh to a remote machine that has a particular file organization structure, and give me a preview gallery.
Nothing is particularly complex, but I couldn't be bothered to making that myself. It's also something that I would've used in emacs (the preview function is like dired-preview-mode in emacs), but a graphical interface would perform better.
> The second thing is that GT got really slow with all the data structure re-interpreting and rerendering.
Ironically enough, I was thinking about the same thing in the morning of the day I replied to you, that gives the amount of data JS provides in the runtime, do we really need Smalltalk for a live system? I agree with you fully.
I guess something about me doesn't want to accept that BB can be a superior GT!
Here's a video about llm integration in GT https://m.youtube.com/watch?v=Atdy6D15iuM&pp=ygUVZ2xhbW9yb3V...
Ironically it is more in a Smalltalk/Lisp Machines fashion than Emacs, given how they evolved. :)
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..
> but I also assume that there is very little training data available for Smalltalk.
Is this actually an issue? I was under the impression that the conclusion was that LLMs will invariably be terrible at writing good, working code (since their training sets are 90% garbage produced by humans), hence why agentic development now is heavy on verification tools and other software that can signal to the LLM whether the code works and has any code smells. Also why AI agents nowadays seem to write and execute scripts for a lot of tasks instead of spitting code directly. Hence, the volume of training data shouldn't be as relevant as it used to be.
>Intuitively it seems like a match made in heaven, since the agent can directly manipulate the running program
This should be a BIG benefit for agent-driven development, but sadly it seems that few people is taking advantage of it.
It got me interested so i ashed ChatGpt about the options andit found this repo: https://pharo-llm.github.io/pharo-mcp
Sounds pretty cool. Never heard about Pharo before, but i will try it in spare time.
It works well, I mostly use Pi with MCP.
Niva is a Smalltalk-like language with static types:
https://github.com/gavr123456789/Niva
An implementation of Boids for Niva:
https://github.com/dharmatech/boids-niva
Maybe some comparison with Strongtalk?
https://strongtalk.org/history
Here I have listed all the main differences from standard Smalltalk syntax, including a couple of examples of syntax for type declarations https://www.reddit.com/r/smalltalk/comments/1xak1cw/comment/...
Basically its Receiver key: Type = [body] or Receiver key(localName): Type
Reading stuff like this continue to make advances and new releases is like a fever dream when everything else is all AI.
I wonder if it’s a bubble thing. People carry on and do what they always did, or just began thinking about what to do with LLMs. Big tech companies and startups may have to move fast and adapt, but I guess many other companies and organisations do not have to rush or fear immediate extinction, just because the wind blows in the other direction elsewhere in the world. I see that Hacker News and X are very "noisy" about LLMs (naturally), but that doesn’t mean the whole tech industry must react in the same way.
>"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?
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.
An odd typo in there.
Let's hope 9front is a seed, yet to fully germinate.
> 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.
But would doing any of that be anything more than a neat hobby? I don't mean that in a disparaging way, I'm genuinely curious.
> But is it anything more than a neat hobby at this point?
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)
It's like a protestant Smalltalk!
(Smalltalk is a religion, I will die on this hill!)
Interesting they seem to avoid mentioning Pharo is a smalltalk on the website, really only one passing mention on the about page.
Pharo with a GTK4+Libadwaita adapted IDE:
https://github.com/pharo-pulsar/pulsar
Almost "Pharo for Gnome".
this is a welcome development. I've tried Pharo 14 and it's order of magnitudes better than say, Pharo 9-- in every way. Even Profstef was updated and made pedagogically appealing.
Someone asked for updated mooc--well since that is not there yet, the next best thing is the updated books both available for free (one needs to be compiled from the github repo (2026 version, Sept).
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.
I don't understand why Pharo doesn't proudly acknowledge that it is a version of Smalltalk on its landing page, rather than this lukewarm statement on its About page:
> A dynamic, pure, reflective object-oriented programming language in the tradition of Smalltalk
Why not call it a modern Smalltalk, which seems to be what it is?
Smalltalk is a great language and its ecosystem deserves to grow.
The "tradition of Smalltalk" is to experiment and exceed what came before. Alan Kay expressed disappointment about the ossification of Smalltalk upon the release of Smalltalk 80. Pharo and Squeak are trying to carry forward only the tradition of the original Smalltalk to produce new ideas, not "be a Smalltalk" (whatever that means).
If you say "Pharo is a Smalltalk" then you might get some of the religious elite come and claim "Thou must change this aspect of the system! For it is in violation of the law of Smalltalk as handed down to our forefathers in Smalltalk 80". Pharo is its own system, heavily inspired by Smalltalk to the extent that non-language lawyers look at it and say "it's Smalltalk".
People argue about whether Janet or Clojure are lisps. Some people say that only Common Lisp is Lisp. Some include Scheme as well. But the unqualified "Lisp" usually means Common Lisp when referring to an actual language with an actual specification that you can find an actual compiler to create binaries with. Pharo is a Smalltalk in a similar way to how Scheme is a Lisp. Different enough that saying "Scheme" means something different from "Lisp" to everyone who knows enough to know what you're talking about.
> Pharo is its own system, heavily inspired by Smalltalk to the extent that non-language lawyers look at it and say "it's Smalltalk".
That is a pretty good argument for calling it "Pharo Smalltalk" or something, which would be accurate and descriptive.
Alan Kay: A couple of years ago, we started this project 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 Squeak, please, please, think of it from that standpoint.
Why don't they make a DOM/SVG front-end for the browsers? (Not canvas!)
It could serve as the engine for new, fun, interactive websites!
If you love that idea but don't mind the switching out the language, CLOG [1] does this on Common Lisp.
[1] https://github.com/rabbibotton/clog
PharoJS?
https://pharojs.org/
Cuis Smalltalk (https://cuis.st) uses vector graphics for its rendering engine!
you mean like amber smalltalk?
https://www.amber-lang.net/
https://en.wikipedia.org/wiki/Amber_Smalltalk
or more like https://squeak.js.org/ ?
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.
> https://squeak.js.org/demo/simple.html
Why is this thing so fast? I type 3 + 4, hit alt+p and the result appears instantly! (Or the better question: why are all the other things so slow?) I submitted it to <https://news.ycombinator.com/item?id=50259214>!
https://github.com/LivelyKernel/lively4-core
https://lively-kernel.org/lively4/lively4-core/start.html
?
The fact that the page says that this version was made by "more than [X] contributors" makes me think that maybe they don't have enough contributors?
Why does it look like something from 2012 tho :`)
You're right. They should add more soul, and make the next one look like it's from 2003!
Pharo MOOC is still based around Pharo 8. Any prospects to refresh It to the latest version?
I did the MOOC recently with Pharo 14, there's some changes in the UI but it's easy enough to follow along. The only thing that changed significantly was the TinyBlog part, with some changes in Seaside and a lot of changes to Bootstrap, but I just asked an llm to update the code examples to the latest version and it worked without too much trouble.
The kerning in clickonme in the example screenshot is unfortunate - I would change the font
In that example, the characters move.
All it needs now is an MCP server.
I asked AI if she had to rebuild everything from scratch what language would she pick?
Her answer, SmallTalk
C-f Smalltalk
Nothing found. Weird.
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 think this was once the case. Smalltalk was very "so last year" once Java Marketing overtook the world (I worked for Cincom, final resting place of VisualWorks Smalltalk, may it rest in peace).
At this point, I think it's flipped. The people that might be attracted to it would probably enjoy the retro hat tip. The various language wars have all been pointlessly adjudicated, and lost in time, first to the dominance/explosion of JavaScript only programmers, and now due to LLM generated code.
Learning Smalltalk, and practicing it heavily for 20 years was probably the single best thing I learned in programming during 35+ years. It helped me get very good at modelling things. I work in Swift/Kotlin/Elixir/C now days, and I've learned some great things from those systems as well. But how to build representations of real world data as well as structure concepts/relationships more virtual, hands down to Smalltalk (for me).
I learnt Smalltalk on Smalltalk/V for Windows 3.1, so I also watched that transition take place.
Not sure how it was seen from inside at Cincom, however having a couple of Smalltalk vendors quickly pivoting from Smalltalk into Java, to the point most IDEs and libraries that appeared where from Smalltalk origin, was what ended up killing all existing interest into keeping using Smalltalk products.
There was this language that Sun was pushing for free, with SDKs on cover CDs, alongside plenty of stuff coming from Smalltalk, why pay for expensive Smalltalk IDEs, seemed to be the opinion back then.
So we ended up with Java, .NET, Objective-C, as half way to the whole Smalltalk experience.
They want to avoid an implicit promise of backward compatibility.
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.
Where are the binaries for TempleOS?
7 minutes of Pharo Smalltalk for Rubyists: https://www.youtube.com/watch?v=HOuZyOKa91o
Has anyone pointed CC at Pharo? Or is the UI and IDE a limit in this case?
Why the downvotes?