I use it, mostly for toy stuff (work is 80% Java).
Once you get used to it, Smalltalk is really the most amazing development environment. It's hard to describe how it feels to work with live objects - it's an incredible speed boost, because instead of grepping logs or stepping through code, you just interact with the objects directly, you can examine the state of instance variables, add new methods, or change code while the code is running. The feedback loop is so short, you get amazing productivity.
There's a great video floating around somewhere of someone debugging an Asteroids game while the game is running.
From what I've read, the downside is that working on larger programs in a team is challenging. It takes a lot more communication to keep the code base consistent and structured.
I worked on a large legacy application (in production since 1996) implemented in Smalltalk for a couple of years. I don't feel we had any particular issues keeping the codebase consistent due to Smalltalk itself (there were some issues due to the Smalltalk system's version control system which was pretty terrible), but Smalltalk enabled us to implement new features in the application very smoothly, and debugging issues was simply a joy compared to other systems I've worked in. Finally, we could also fix bugs in the platform itself, which was quite useful since the vendor stopped supporting this particular Smalltalk compiler around 2000; I did a couple of small but quite important fixes like this while working on the project.
Are you using VSE? I've wondered what happened to all the folks on it. I assumed most converted to VisualWorks, but it would be interesting if Pharo becomes an option.
Yeah, VSE is the culprit. I think the main reason the application was never moved off VSE is that the application is developed by a consultancy firm (my employer at the time) for a public-sector client, and the leadership of the client isn't interested in investing in long-term stuff for this particular program, they'd rather try to get an extraordinary allocation on the order of a few hundred million USD and do a massive, more buzzword-compliant rewrite of a big portion of their application portfolio. Never mind that the application in question is strategically important for their ability to do their job and it's already suffering under a rather long period of under-funding and general mismanagement from the client's side. Replacing VSE would have been nice, Pharo even better (but then you need to do something about almost 25 years of GUI made in WindowBuilder...).
The funny part is that even though VSE isn't a very good Smalltalk, it's one of the most productive environments I've ever worked in.
>From what I've read, the downside is that working on larger programs in a team is challenging. It takes a lot more communication to keep the code base consistent and structured.
I don't think that's an inherent limitation of image based development -- just that the current systems don't offer facilities for syncing etc.
Maybe grandpa already knows, but in Pharo's case, there is Iceberg. It's a Git interface that's included in default Pharo images that understands Pharo's packages, and so on. You can push your stuff to Github etc. and teams can work together that way.
I've never worked in a team in a Pharo projects, but I imagine it works well somehow. There's ~75 contributors to the 8.0 release.
I once interviewed a candidate who decided to use Pharo to solve my technical problem. It was an absolute joy to see not only a good approach, but such an interesting and alien language employed to solve it.
We give onsite candidates affordances to install any environment that makes them feel comfortable, or to allow them to bring their own machines. The interview machines get wiped on a regular cadence, so installing packages is no big deal.
If candidates send us a list of the software they want beforehand, we usually try to set it up for them in advance. If not, it's fine for the schedule to run over a bit for them to tweak things as they like.
Interviews are stressful enough. We want everything working in a candidate's favor so they can do their best.
"The future is already here – it's just not evenly distributed." - William Gibson
I did some work in Smalltalk (working on a mod of Scratch 1.4, which was written in Squeak Smalltalk from the turn of the century). Once you got used to it, it was amazing. The environment is lively, and you can debug into everything.
The tech is great; it is just that the community of people who know it is relatively small. If you wanted to develop an open-source project in it, you may have a harder time finding other developers to help.
On the other hand, if you wanted to make a cross-platform desktop application that doesn't look native (which, given the prevalence of Electron, doesn't seem to matter too much to people), this would be an excellent choice.
I wish I could do more development with Pharo. I also think the web framework Seaside would be fun to work with. http://seaside.st/
We just need to go back in time to twenty years or so and take a different fork ...
> On the other hand, if you wanted to make a cross-platform desktop application that doesn't look native (which, given the prevalence of Electron, doesn't seem to matter too much to people), this would be an excellent choice.
Yeah, as if people are going to install a whole virtual machine to run a chat application...
Yep, it still amazes me how a lot of the criticisms of Smalltalk have been become the new, cool solution. Smalltalk on Electron would be an interesting answer.
I have a short anecdote about Amber, which may or may not be widely known.
Amber.js was the original name of Ember.js (so named after the style of beer one of its creators was drinking when they were searching for a name; if memory serves it was also the result of pulling bits and pieces out of SproutCore.js). When it came time to release the project, the authors of A/Ember were notified that they were encroaching on the name of a pre-existing project and changed it.
what bewildered me at the time was that they never did a google search for it before publicizing their chosen name. Or that maybe they did and said "screw it. who cares about smalltalk. we'll steal their name"
Iliad says Latest commit 0be1977 on Jul 18, 2017. Seaside says last commit 24 August 2019. Any actively maintained web framework that will work with Pharo 8?
That is considered active. The Smalltalk community is far smaller than other languages and web development is a small subset of that community. So you won't see nearly the frequency of commits of projects. Also, the major web frameworks are pretty stable these days so most of the action is in the integration of support for various client-side Javascript libraries. Those are often published as separate projects.
keep in mind that smalltalk is freaking ancient and like most useful but freaking ancient things in unix, most of the stuff "just works" and doesn't need constant poking.
Also, Smalltalk offers a much more transparent development environment. So, you're not writing code that goes into a black box and produces results. You can see what's going on in the box and make sure its doing it correctly.
also, the Squeak by example book (i think Pharo by example is a fork of this) very quickly starts showing people how to write tests. So the mentality isn't "oh, yeah, i guess i could add tests" it's "oh hey, tests are part of making smalltalk code" so you've got that going for it too.
combine those things with the smaller community, and thus a much more narrowly defined set of "needs" for a web framework and yeah, it doesn't get poked constantly.
I've been using various Smalltalk dialects (Squeak/Cuis/Pharo) for over a decade. I've gone a bit off the deep end and use it for prototyping pretty much everywhere I can.
Pharo would be the one Smalltalk environment I would not use for non-toy stuff because it has historically been so unstable. This is at least somewhat by design since the developers have always stated they didn't want to be constrained by backwards compatibility... and they have never let themselves be. It's a great environment for playing around with ideas, not for developing code you expect to work as is a few years from now without some (potentially serious) work. In fairness, all the Squeak dialects have this issue to varying degrees. It just seems to me that it's more extreme with Pharo.
Due to Pharo/Smalltalk being not just a language, but a language/libraries/IDE, I think it's important to distinguish between API instability (which IHMO is better called evolution) vs. bugginess. API evolution is a core part of Pharo's mission. I've personally upgraded projects from Pharo 1.x all the way to Pharo 7 and have been very willing to trade a small amount of effort porting for big increases in productivity.
> I've personally upgraded projects from Pharo 1.x all the way to Pharo 7 and have been very willing to trade a small amount of effort porting for big increases in productivity.
Wow, any chance you've written about the upgrade process?
I don't exactly have a playbook. I generally just fix as I go. I try to install the project, fix any errors, run the test, fix the errors, etc. I can say that some version jumps have been almost no work and probably the max time I've spent is an hour to get everything working. It used to be a bit harder, but nowadays Pharo has automatic refactoring for deprecated methods, which helps...
Writing small web services in seaside has been like living in the distant future since something like 2006. JavaScript made a lot of strides towards making seaside less impressive in recent years, but as someone who hates frontend stuff I still vastly prefer it.
Playing with it in 2006 was like using magic. Sure, it is not REST, but whenever I show it off to someone used to handling a lot of stuff client side they still have to pinch themselves :)
Yeah, I use it. It is a highly productive development environment. My daily work is Java, C#/.NET, Angular, React, but when I'm in deep in the zone, in Pharo, developing web applications, those other platforms and tools looks like monkeys throwing turds at each other.
I always use smalltalk when the problem would allow for it since I'm much more productive in smalltalk than anything else.
It's great for certain random tasks - i.e. Want to set up a websocket server for some reason? Program it in smalltalk, test it interactively (literally debugging on execution errors, fixing and resuming execution until it works).
If I'm writing a native windows app I'll go with dolphin smalltalk which imo is much nicer to work with and gives you a native gui. I have to say though pharo is getting better all the time and has an active community.
Yup, and that is the reason I refused to look at it for so long. And then I went to work for a large corporate where Windows is mandated since forever and will be until eternity. And from my impression most businesses wont touch any other OS for use on desktops.
You can of course use Wine/Wineskin and there are guides on how to get this done for Dolphin apps, but I just wont bother for my clients. Not one has ever mentioned compatibility with anything other than Windows 10.
Me. It is my go-to tool to build everything/prototype. It is the most productive tool I know of to get things up and running. There is nothing like it. I also know Python, Lua and various Schemes, but they do not come close. Smalltalk presents the smallest barrier between idea and working code for me.
Especially if with the "live in the debugger" type of development where you write a test and get the debugger to tell you the next step.
