As a long time Ruby developer I frequently hear older developers talking fondly about their experiences working with Smalltalk long ago. When I saw this post, I was curious enough to watch a video just now by a respected Ruby dev (who's admittedly new to Smalltalk and using an older version of Pharo): https://www.youtube.com/watch?v=HOuZyOKa91o. The video is short, but it looks to me like the advantage of developing in this environment is mainly that you can write a test, run it in a kind of debug mode, and when the environment encounters something it doesn't understand it gives you some options for creating something new like an object or a method to solve the problem. This seems kind of cool, but I feel like there must be more to it. Can anyone better explain the selling point, or share a video that highlights how this environment is so cool?
There is no single selling point. Here are some surface things that I immediately liked:
1. You can download a single zip file (Pharo Standalone) and it will give you all the tools of a modern IDE without shitting all over your system and with faster startup than Atom, VS Code or even LINQPad.
2. The environment retains all its state across restarts. The editor stuff, the running state of the program - everything.
3. You have the same capabilities as the people who developed the language. You program, the run-time environment and the editor itself can be browsed and edited by the same set of tools, without any extra hoops. There is very little "magic".
4. The syntax of the language is designed so that you can create DSLs without using macros or pre-processors.
5. It's the only environment in my recent memory where I can do stuff without opening the web browser to search for something every 5 minutes.
6. IMO, breaking the system into four-tier structure made the whole thing much more tractable than infinitely nested directories or namespace hierarchies. I also like that there is no need to manage files with code.
The 'more to it' is the fact that you are always effectively in 'debug mode'. By default, there is no distinction between development and deployment in Smalltalk[1] so when something fails, you typically will get a debugger pop of the method at the exact statement where the problem occurred with the live state as of the moment of the problem. The entire environment is as static or dynamic as you want it to be since it's entirely malleable.
Since Ruby was largely inspired by Smalltalk, you'll find similarities in their views of OO and code. Where they fundamentally differ is in the environment since Smalltalk is based on a monolithic persistent image so it can do things like have the debugger, and other GUI tools, built in. All that video was showing was built in stuff from the Pharo image... other dialects have their own takes on the tools.
[1] You can create a distinction by removing the development tools and replacing their functionality with non-interactive logging/error handlers for production deployment.
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.
16" MacBook Pro, Catalina, I get "“PharoLauncher.app” can’t be opened because Apple cannot check it for malicious software." "This software needs to be updated."
For others coming along later, right click, pick "open". If you don't get an "open" button on the dialog, go to system preferences, security, general. You should see a button that says "Pharo Launcher wouldn't open. Open anyway" or something of that nature. Click. Profit!
I resolved the issue by navigating to the directory where it downloaded the vm's, deleting the folder and unzipping manually. Seems the launcher corrupts the files when it unzips them.
One click on the "Documentation" tab provides links to several screencasts/tutorials. Are you looking for something specific? "Hello world" doesn't cleanly map to an environment as comprehensive as Pharo because there are so many options. Do you want "hello world" to output to the terminal (Stdio stdout << 'Hello world')? A window? A growl-style popup (UIManager default inform: 'Hello world')? The transcript (Transcript show: 'Hello world')?
> This page (http://pharo.org/news/pharo8.0-released) is currently offline. However, because the site uses Cloudflare's Always Online™ technology you can continue to surf a snapshot of the site.
Except that I see a big error page.
Isn't CloudFlare supposed to help with this? The message on top seems to indicate that, but when I (back in the day) tested with CF on my domain it just proxied every request and failed when my server didn't respond, having zero advantage over just using my server directly (in fact, even having the downside that Tor users now couldn't reach my site anymore). Seems like that's still the case.
It is optional to let CloudFlare cache the content. I believe you can control it from the CloudFlare control panel as well as affect it from your HTTP headers. So I bet they have the feature enabled on the panel but their HTTP headers tell CloudFlare not to cache the page, maybe accidentally.
It is caching the static assets (js, css, png, etc) based on default extensions[1]. The page itself is dynamic, likely for the comment feature at the bottom of the page. If they wanted to cache it, they could probably add some caching headers (have to change the responses on the origin) or a Page Rule in cloudflare (and not have to change anything on the server). But that won't be a good idea if people can login to the page to comment (not sure if CloudFlare can tell if someone is not-logged-in and return a cached version; that would be interesting). I see CF-Cache-Status: DYNAMIC header, which is:
"The resource content type was not cached by default and your current Cloudflare caching configuration doesn't instruct Cloudflare to cache the resource. Instead, the resource was requested from the origin web server. Use Page Rules to implement custom caching options."
Who runs the Pharo site? Let's try to diagnose and help them. I don't actually believe in the hackers news hug of death, since many sites survive it just fine (because they take "static content" as seriously as one needs to in order to do so). I see that pharo.org has a "login" link at the bottom. Could the homepage be doing an auth cookie DB lookup on each pageview?
I don't have much static content, no cdn, do multiple database queries per request, my server isn't beefy enough to run any of the common content managers like WordPress or typo3 (well, each pageload took a very long time), and yet it survived the HN homepage on a few occasions.
A huge system like WordPress can't do dynamic content for more than a small number of visitors per second no matter how beefy the server and has to hackily convert content from dynamic to static content. Which is fine since it uses a lot less power to do static content instead of buying beefier and beefier servers, but it is not how WordPress meant its blogging software to have to be (maybe they gave up by now and do static rendering by default, but it used to be all plugin based). By writing my own tiny blogging software I implemented what I needed and it worked just fine on an Intel Atom CPU, even on the HN homepage.
2) I'm pretty sure the initial JVM was a clone / extension of a Smalltalk VM. Having trouble googling the details, but while you may be having trouble getting it to work on your particular Windows install you might want to consider that you're possibly ignorant of the fact that the Smalltalk VM is not only one of the best available but battle tested over decades.
I would guess that what you're seeing is a particular windows issue that has nothing to do with the VM itself.
I did, yes I know that Smalltalk needed a VM, Pharo == smalltalk, and the like.
Wikipedia for Pharo says they have a VM with JIT, etc. I have never heard a peep about the Smalltalk VM in any circumstance as a performant target for any language. Ever.
If it's battle tested and great, why isn't it used for anything else than Smalltalk ports? Is there a python, ruby, javascript, java, etc port to the smalltalk VM?
If it sounds like I'm being dismissive, that's not the point. The point is the Smalltalk ecosystem, like Lisp derivatives, likes to have its own top-to-bottom stack completely isolated from "real" execution platforms.
For Lisp it's so bad that Clojure is rejected by some Lisp purists because it can JVM / JS compile.
IMO, for example, Ruby made a strategic error writing their own VM rather than just embracing the JVM as the main VM, although when Ruby was writing their VM invokedynamic hadn't been added to the JVM. Well, and they should have added some optional typing.
So, still no HiDPI/Retina support. This is probably the most requested feature since at least Pharo 4, and nobody seems to be interested in implementing it.
> This is probably the most requested feature since at least Pharo 4
I don't see any page where it says this is the most requested feature. If it was, it would've been developed by now.
It's kinda funny, few hours ago there was a post on the frontpage by burntsushi on the terrible way FOSS developers are treated. And here we have a live example of the usual drive-by commenters who take one glance at the project and decide their own niche requested feature is the most important one.
I am a Smalltalk enthusiast who worked with Cincom ST, Dolphin ST (when it was still a thing), Squeak, Amber, and Pharo. I would be happy to use Pharo. It is so beautiful. It is full-featured. It would be a joy to work with... but I can’t, because I see the pixels.
Pharo’s rendering layer is complicated, to say the least. I made a few approaches in attempting to figure out how it works and perhaps starting adapting it to hidpi screens... but it is a really complicated endeavor. I am not demanding anything from Pharo developers, I am just saying it is a pity I can’t use this beautiful, innovative Smalltalk system. Pixelated UI among the smooth lines of other apps make it unusable for me, and I am not smart enough to fix it.
I asked about this on the mailing list a while back. Apparently it requires changes in the VM, and as you can imagine there are fewer people working on the VM side. This must also be a problem for Squeak, too, but they work around it by having better options for scaling morphic components. Obviously it needs to be addressed.
This is the first thing I noticed when I opened it up. Whoa, fuzzy text, no retina support? I'm guessing this isn't important to the Pharo developers, or at least, it isn't a top priority for one reason or another. I guess I'm a bit of a resolution snob. I find it off putting. But, hey. It's open source.
If it is the most requested, then perhaps one of those requesting it should try to do it themselves? HiDPI support sounds like a high effort low reward task (according to this[0] HiDPI monitors practically do not exist in the wild and chances are none of the main developers have one), so unless someone who really wants it puts the effort themselves it may take a long time to appear.
Generally speaking unless there is a big company behind the scenes that pays the developers for an open source project, it doesn't matter how many people ask for something if the developers themselves aren't interested in working on it and your best bet is to do it the old fashioned way (yourself :-P).
Every Macbook after around 2015 is HiDPI. Windows Surface laptops, too. Hardly "practically do not exist in the wild". I love Smalltalk, but I am not qualified to rewrite the entire Pharo rendering layer, unfortunately.
Also, statscounter doesn't account for high resolution displays at all, grouping them all as "other". And these are around 20%.
Look, if all you work with is Macbooks and similar computers, it is very likely that your view is biased (pretty much like the people who wonder why others are making a fuss about Electron applications when they can run several of them without issues). According to this (1 year old):
...Apple only had around 7% of the global market share of computer sales between big brands and not only that is very low but also it doesn't include local brands that assemble the computers themselves nor custom built computers (even though i do not believe this is a big number, considering the size of the custom built market that exists, it still is a significant number). And it is about all Mac sales, including the lower end iMac (that have a regular DPI monitor) and monitorless desktops like Mac Mini that can be connected to a regular DPI monitor.
HiDPI on desktop might be a mainstream thing in 10 years or so, but right now every single statistic available shows otherwise. On mobile is a different story though (which is why i tried to avoid any statistics page that focuses on mobile).
The first link counts 4k displays with 2x scaling as 1920x1080. It doesn’t seem to differentiate for hidpi monitors. People who use 4k displays without UI scaling are rare indeed. Perhaps macs are “rare” (though 7% is hardly rare). HiDPI desktops are still rare indeed. But HiDPI laptops are pretty common these days.
When I first saw a hidpi display (on iPhone 4), this was a game changer for me. Since then, I don’t understand how it is even possible to settle for something with visible pixels. iPhone 4 was releases 10 years ago.
How is a table of resolutions supposed to tell you anything about DPI? A 640x480 screen can be high DPI while a 3840x2160p screen standard DPI. Or the other way around. Or neither. Or both. It depends on both resolution AND physical size.
It'd also be interesting if they were even checking physical resolution or virtual (scaled) resolution.
This is a table of desktop resolutions, while it is possible that someone might have connected a 2" 640x480 screen to their desktop, it is very safe to assume that only resolutions above 2560x1440 are HiDPI and anything else is just noise.
"Desktop" includes laptop at statcounter. 1080p is supposed to be 23".
And again if it's simply the resolution the browser reports it is post scale so a 2560x1440 laptop at 150% would show as 1920x1080 anyways. It's web stats, they only care about the size of the viewport.
Yes, i'm also talking about laptops here, not just desktops.
If you can go by with 150% this isn't HiDPI (and on most laptops 150% for 1080p is too big anyway, at least on Windows, you want something around 125%). HiDPI is something that you need at least 200%, like Apple's 2560x1600 at 13" where anything less is unusable. Using 100% scaling on a laptop at 1080p is perfectly fine (this is my laptop configuration and how i use it).
Remember that "HiDPI" was the generic term that was used in place of Apple's trademarked "Retina" and what is i am talking about.
The entire discussion is about why HiDPI isn't supported and the answer is simply that few people need it (as shown by the stats i linked above and below) and fewer are in a position to implement it.
Anything above 100% is considered high DPI on Windows, including 125%. I.e. if the display DPI is not 100% and the app isn't DPI aware you will end up with a blurry mess since the OS will stretch the app for you via bitmap scaling by a factor of DPI / 100%. Apple is the only one that does integer factor only DPI for their hardware (100%, 200%, 300%...) and their entire current lineup is >100% now.
