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 don't think that's an inherent limitation of image based development -- just that the current systems don't offer facilities for syncing etc.
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.
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.
That would be this: https://www.youtube.com/watch?v=L2rD2YSTMV4&list=PL62E3E45E6...
He got the job. :)
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.
I hope he's now writing CRUD apps in J2EE.
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 ...
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.
but that's ok.
Yeah, as if people are going to install a whole virtual machine to run a chat application...
Wait...
I'm sure you could do it with https://www.amber-lang.net/ ;-)
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.
You can install an application that launches the VM with the desired image and the user will never know the app is running inside a Smalltalk VM.
I'll just mention that the announcement (which is now down) and the readme mentions spec2:
> Spec 2 (preview) - UI building framework with multiple backends
The announcement (main hn link) mentioned spec2 and native look together.
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.
Wow, any chance you've written about the upgrade process?
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 :)
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.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.
True, but more and more software is delivered using web-based technologies - from desktop apps like Slack to most SaaS offerings.
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.
Try it, you might like it.
Projects screenshots look way better than I expected.