"In fact, I'd say the image is perhaps the biggest problem with Smalltalk."
There need not be a single image. You can save and load as many images as you like. In fact, you can have thousands or hundreds of thousands of images if you prefer. You may think I'm being uncharitable to the author by construing his words as I did, but it's entirely appropriate given the tendency of those ignorant of Smalltalk (like him) to speak and act as if there is some monolithic, fragile image that everyone on a project shares and each must strive to avoid breaking.
The Smalltalk image may seem unfamiliar or even scary at first, but it's really little different from a standard Ruby or Python process, except that it is serializable and contains all of the code (both compiled and in source form), data, and execution state as objects that you can manipulate.
Further, every Smalltalk (that I know of) supports saving and loading source code to text files and often some form of package management and source control as well. Many Smalltalk also integrate with file-based tools quite well. For example, you can use git with Pharo, and many Pharo developers use Github exclusively for their development.
People citing the image as a reason for not using Smalltalk clearly don't know Smalltalk. They're also likely hypocrites, because at some point or another they've no doubt asked themselves why, after so many years, are programmers still programming by the mere editing of dumb text files? Well, in part because of your hostility to any system that isn't the mere editing of dumb text files.
> why, after so many years, are programmers still programming by the mere editing of dumb text files?
I only program by the mere editing of smart text files! They happily talk to other programs, intrepidly make their way through networks, and gladly offer themselves up for inspection and change almost anywhere.
Meanwhile, SmallTalk is off playing with its own toys in its own little sandbox, refusing to play with the other children.
> why, after so many years, are programmers still programming by the mere editing of dumb text files?
Well, there's nothing wrong with text per se. Text is easy, it's simple, it's persistent and platform-agnostic. Text based source code is portable, because it's human readable. You could print it on paper or write it on a napkin if you wanted. Alternatives have the potential of locking programming, and programming knowledge, into some company's particular black box.
The only thing there that actually distinguishes text is the natural canonical printable representation. Text-based source code is not inherently more portable or resistant to lock-in; binary formats can be standardized or proprietary just as easily as text formats.
There are numerous tools that work on text files without knowing a specific structure. Some tools are more sophisticated with their knowledge of formats and can do more with the text files. Binary files don't allow for this extremely useful range of functionality.
True, but having that representation available is what makes it portable. In particular, being able to write it in any text editor, as well as read it.
This is a Smalltalk/Squeak program I worked on in University back in 2008. Apparently, it is still maintained and on GitHub now. As you can see, it's all text files, e.g. here is a simple asString method: https://github.com/HPI-SWA-Teaching/SwaLint/blob/master/pack...
I wouldn't call it exactly portable, as you need a Squeak image to run it. Then again, I wouldn't call a C-program written against the Win32 API portable, just because it is saved in text-files ;-)
Ok, so you're using the loosest and least useful definition of "portable". And ignoring any issues about character encoding. And the advantages you're citing still aren't inherent to textual formats, they're just due to the widespread availability (on Unix systems, at least) of basic tools for manipulating text files.
I'm not saying text files are universal, or that they should only be ASCII, i'm saying text is (practically) universal. No one owns "text" as a format, or a medium of communication. No one has to pay a license fee in order to use "text." There's no "text" working group which makes the one tool that anyone can use to display "text" or pass "text" around.
Complain all you want about unicode support, or the lack thereof, there are a million different uses for character sets, which means textual communication is likely to be around in ten or twenty years, which means support for text-based programming is more future-proof.
The encoding used is really entirely irrelevant to the point i am (apparently failing) to make. Source code isn't merely a way to pass instructions to a compiler, it's also a way of preserving knowledge, both technical and historical, and I believe that making that accessible to as many people as possible is important. It is a means of communication between humans as well - and I believe making it easy to facilitate this communication is important.
"The United States of America is awesome. We are awesome, but we've had this discussion.
The reason you want to have this discussion is not to show how awesome we are;
rather, you want to have this discussion to show us how we're not awesome."
You would be correct, in that I have never seen source code written in Unicode in multiple languages.
However, i'm trying to make an argument that text is fundamentally more free than the alternatives. When I say "simple, persistent, and platform-agnostic" I mean, literally, you don't even need a computer to deal with it, much less an IDE. Source code is a means of communication between people, as well as between people and a machine. Imagine how restricted the development of the early web would have been if you couldn't just bang together some html and javascript and put it on a server?
> They've no doubt asked themselves why, after so many years, are programmers still programming by the mere editing of dumb text files?
While I've thought that there might be interesting ways of editing code before, I have literally never once asked myself why programmers are "still programming" with text files. All things considered, structured text files are a pretty darn good way of describing program behavior.
"The Smalltalk image may seem unfamiliar or even scary at first, but it's really little different from a standard Ruby or Python process, except that it is serializable and contains all of the code (both compiled and in source form), data, and execution state as objects that you can manipulate."
Well that's not very similar to a Ruby or Python process then, is it? And those processes are short lived and built from scratch on every execution. Anything you want to keep around you have to serialize and save explicitly. This is a painful but useful discipline. Perhaps an interesting analog, Docker emphasizes recreating over storing, while in normal sysadmin practice you update systems in place. In theory they can achieve the same results, but enforcing discipline makes a difference in practice.
Smalltalk of course is code, and you can do whatever you want with it. And Smalltalk is delightful in many ways, I enjoyed it a great deal when I used it, and people using Smalltalk can be very productive when they have to recreate the world. But you have to recreate the world. And there's strong cultural drift. Lots of things are possible, but possibilities aren't enough to create a community of practice.
Looking at files, I looked up "using git with smalltalk" and got the GitHub list of Smalltalk projects: https://github.com/trending?l=smalltalk – I look at one that has a couple contributors, find Cuis: https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev – it's got giant files and images at the root, overlapping senses of version (versions and dates and authors in filenames). Not a great example. Though to be fair, Iliad looks like a totally legit use of Git and filesystem integration: https://github.com/NicolasPetton/iliad – but they seem to be focusing on GNU Smalltalk, which is notably conventional.
Regarding the use of text files in general, I think it's an interesting thing to consider, but to think about it you have to engage with all the reasons that text files have remained so dominant. I tried to do that some in this post: http://www.ianbicking.org/blog/2013/10/why-isnt-programming-... (under "text dump -> spatial representations").
Has Smalltalk achieved all the success it deserves? If so that would be a sad conclusion about its worth. The "people are just too stupid to realize" argument for Smalltalk is a terrible argument, and a terrible way to build something better. If I am going to ask why Smalltalk didn't achieve the success it deserved, I will look to Smalltalk, not to the world.
> Well that's not very similar to a Ruby or Python process then, is it?
Actually, that is very similar, particularly since Ruby's design is so patterned on Smalltalk.
> And those processes are short lived and built from scratch on every execution.
Ummm, no. When running a simple script, maybe, but for a whole host of applications you have processes that run for a very, very long time.
> But you have to recreate the world.
No, you really don't. There were certainly purists who argued for that, but there's nothing about the language that requires that at all. It's actually got a pretty nice FFI.
The Smalltalk world has had some pretty sweet version management for a long time, and of course the language hasn't had much adoption for a long time, so I don't think the Smalltalk code on GitHub is terribly representative.
> The "people are just too stupid to realize" argument for Smalltalk is a terrible argument, and a terrible way to build something better. If I am going to ask why Smalltalk didn't achieve the success it deserved, I will look to Smalltalk, not to the world.
Like a lot of languages, the community is what matters, and unfortunately the Smalltalk community wasn't stewarded terribly well for a while there, so I'd say the the outcome is function of how Smalltalk engaged the world, and the reality that sometimes you just don't succeed, regardless.
Smalltalk is (literally) a window on an alternative computer architecture and OS/language paradigm. There's a reason it runs on a 'virtual machine'! It's the path that computing could once have taken, the equivalent of a parallel universe: What if computers had gone with this different design; what if the language and underlying operating system were one-and-the-same... (There was even a initial attempt at object-oriented hardware: http://en.wikipedia.org/wiki/Rekursiv)
Of course, Lisp is the other example of an alternative computing ecosystem: the famous Lisp Machines, with Lispy turtles all the way down; and Interlisp, that came closest to Smalltalk's emulation of a physical machine.
Modern Smalltalk is the environment that would have emerged from this kind of platform. That it includes modern tooling and inter-operability (however limited) is a huge bonus - it represents a genuine effort to coexist with the mainstream.
That there's so much criticism of its 'image' and language syntax only drives home the absolute grip on our thinking that Algol languages and Von Neumann architectures have imposed. In my mind, that makes it an environment of inestimable value.
Ecological diversity is more than good; it's essential.
There was a third window that many people tend to forget.
Mesa/Cedar, a interactive environment first done in Mesa, the Modula-2 predecessor and later on improved as Cedar, which was a system programing language with GC!
It was a working environment similar to Interlisp-D and Smalltalk, but using dynamic libraries, an interactive debugger, REPL and lots of nice goodies for an Algol like language. Back when at AT&T green phosphor terminals were being used.
Mesa was the inspiration for Lilith operating system done in Modula-2.
Similarly Cedar was the inspiration for Oberon and its derivatives.
Using Oberon felt to certain extent like Smalltalk, in a strong typed system programming language with a GC.
But Oberon based systems had the bad luck to appear at the same time the world was paying attention to Java and rise of VMs. So just like Plan9, only a few of us enjoyed using such environments.
It's not just that the syntax looks weird to people -- though that doesn't help -- but it also looks weird to other programming languages.
Not sure if it's any consolation, but Smalltalk was the first non-ALGOL language that I really "got", and remarkably quickly. The saying that Smalltalk syntax fits on a postcard is no joke, see: http://c2.com/cgi/wiki?SmalltalkSyntaxInaPostcard
The hardest part is wrestling with the class libraries and getting used to the hermit kingdom that is the image-based environment, though the community behind Pharo and other modern Smalltalk environments have done some interesting advances when it comes to bridging the gap, such as the Monticello VCS for snapshotting code state to a regular file system in the form of an archive.
That said, I haven't used Smalltalk all too extensively.
I don't find Smalltalk's syntax bad per se, but I think there's too much of it. When I see it, my eyes glaze over. Not because I don't understand the concepts behind what is being represented, but because I have a hard time getting a handle on the shape of things.
It's a matter of familiarity, and while I've spent some time looking at the object model I haven't written a lot of code in it. So perhaps that complaint is only really valid for newcomers. On the other hand, I still think it's a bit convoluted since a language like Io can express much the same stuff with less. The postcard version is something like:
That doesn't account for [] and {} being translated to messages (with their contents as arguments) or for the infix operator stuff (sends the operator message—eg. +, xyzzy, etc.—to LHS with RHS as the argument) which also has precedence. Aside from that there's nothing much going on. Everything except infix operators always look like like regular message sends unless you're using a DSL. I think that's shat Smalltalk ought to look like, since that's what it's trying to be about.
Edit: Before anyone gets the wrong idea, I don't mean Smalltalk should look like Io, but that it should have little more shape than looking like message sends.
Unless you always stick to languages with the same familiar "look", learning a new language will always need more time to acclimate to. I've used FORTRAN, Tandem TAL, C/C++/C#/Objective-C, Java, Python, Go, and Smalltalk. No real problems with picking any of these up, but I always struggle with Lisp.
Language design is often a balance between making something terse and something human readable. Smalltalk strikes the perfect balance, AFAIC. Having English-like method names and variables is really quite nice. And Smalltalk still manages to be a lot less verbose than every other language I've ever used.
I have always liked Smalltalk's (via Objective-C) message syntax as it put the meaning of the function call slots where I am calling them. I hate what they've done in Swift however.
I have toyed with a scripting language that had:
Object.[setSlot:"foo" to:12]
Still not sure on that. I immensely respect the creator of Io but it didn't click with me (my fault, not the language).
exampleWithNumber: x
"[ *wall-of-text elided* ]"
| y |
true & false not & (nil isNil) ifFalse: [self halt].
y := self size + super size.
#($a #a "a" 1 1.0)
do: [ :each |
Transcript show: (each class name);
show: ' '].
^x < y
I'm talking about an Io equivalent of the "Syntax In a Postcard" link provided above, partly reproduced here for convenience. What the code does isn't so important as how much of the syntax it covers.
True, too true, but it does ease people into the language and proves the language is not defined by the implementation. This is important since most of the discussion in this thread is based on the common implementation and not the language.
Usually I am the first to push for comments "Language != Implementation", however the whole Smalltalk experience only makes sense in the official implementation of the IDE married with the language and OS.
Using an implementation like GNU Smalltalk, while valid in terms of language implementation, leaves out the whole development experience back to the stone age of UNIX tools.
Exactly the development experience of environments inspired by Smalltalk is what made me always favor IDEs over vim, emacs + CLI.
and usually I will defend the different environments, but I have to disagree with you here. Smalltalk environments try to build their own everything. Squeak and Visual Works do not use native widgets, heck Squeak is a horrible UI. Both have editors that are inferior to current text editors. They have cool attributes, but there rejection of every part of the OS is problematic.
I think the situation is way simpler than the author contends.
Smalltalk simply has poor workflow from the programmers perspective, compared to what he's used to.
It may be awesome. But no one will ever know, because it's too different from the normal developer's work flow to easily gain adoption, even if the benefits are substantial.
Could something like Smalltalk work in such a way that the "image" is a series of files and folders, so if something goes nuts we can do what we always do and poke around in the data?
Could automatic code reloading and online introspection be applied through a more traditional client (debugger) - server (running process) setup?
Something like that may have a better chance. This machine ain't got time to slow down and make repairs.
> Could something like Smalltalk work in such a way that the "image" is a series of files and folders, so if something goes nuts we can do what we always do and poke around in the data?
Well, speaking for Squeak: The image is just a file. You can open it and poke around in it.
I don't recall why I had to do it exactly (did some meta-programming with Smalltalk at university... maybe my program overwrote some fundamental functions in Object or similar), but I don't remember it to be terribly complicated.
Definitely not as simple as opening a JSON file, but not as hard as decrypting the assembly of a compiled C-program or analyzing the memory of a crashed program.
I think that's good because it shows (a) is really different so is a direct hit to the Comfort Zone on many and (b) its significative value is real, otherwise it wouldn't annoy them to the point of talking about it.
It seems that a source of anger for some people is that Smalltalk is good enough to get mainstream but it didn't reached really mainstream. Probably due to the strategic mistake of not making it open source right from the start in the 80's. This interview puts some light into what happened, who influenced that decision and why was made: https://www.youtube.com/watch?v=IGNiH85PLVg
If Smalltalk would have been open sourced in 1980 the world would be different: programming would be more humane and less technologically-self-serving.
Now we have the "pleasure" of listening people that tells you "the compiler is your friend"
This is exactly right. People are so invested in what they've learned that they are reluctant to give it up and try something new and different. Humans are creatures of habit.
For some reason, this has never afflicted me. I've used many languages and environments in my time (eg, FORTRAN, Tandem TAL, C/C++/C#/Objective-C, Java, Python, Go, and Smalltalk), and I've treated each and every one of them as a fun opportunity to play and learn. This is my intellectual playground and those languages are my toys! Smalltalk was completely different from everything else I had used over 20+ years, and it still didn't phase me. Go figure.
Today, I continue to have a warm place in my heart for Smalltalk.
I find this resistance to the Smalltalk environment a bit puzzling. It's really fundamentally no different from modern IDEs and virtual machine runtimes such as JVM. The key differentiator is the fact that every object in the Smalltalk environment is "live" and can be examined and altered at will. One of the great benefits from this fallout is the powerful debugger.
Rather than whining about how Smalltalk doesn't play well with existing file-based tooling, we should focus on improving and extending the tooling for the Smalltalk environment. We have an opportunity here to define the future. Smalltalk is a break from the traditional way of doing things (the use of files and folders is positively antediluvian!). It's truly innovative.
The transition may incur some cost and pain now, but positive change is never free. If you argue we should wait for a more opportune time, the question is, "If not now, then when?" What exactly are we waiting for?
If you argue we should never change, files and folders are perfect forever and ever, then I say we are stuck in a rut. Software engineering is off the rails.
Also, people bitch about not being able to use their favourite editors. I've never understood this, either. In my 20+ years in IT, I've never been wedded to any particular editor. And the way source is organized and presented in the Smalltalk environment (via the class browser), I've never needed the power of emacs or Eclipse or Sublime Text. Super-editors are for file-based software development. In Smalltalk, they're rather unnecessary.
I think there is really something that makes people prefer files over some database, even though the latter has undeniable advantages.
Do you remember IBM's VisualAge for C++? It had a clear Smalltalk pedigree (there was a VisualAge for Smalltalk first, and I think the IDE was written in ST, but I could misremember that point).
And a "translation unit" was not a file, like in every other C++ compiler. All translation units were entries in an internal database. And you couldn't find the header files with a file manager search.
Some people liked it. A lot. But in the end IBM reverted to the common approach.
Personally I think the biggest problem was the hardware requirements. If memory doesn't fail me, it already required 8 MB when most PCs were still being shipped with 4 MB.
Also I think the version to go for was the OS/2 one, which didn't help as well.
Vague memories now, so I don't recall how it really was.
I'm not sure the image paradigm would be much of a problem today.
Virtualization is common today, Docker is very trendy, and many such tools rely on the concept of images. Smalltalk images are similar to VM snapshots, and not very different to Docker images.
I think the Image was one of Smalltalk's best ideas.
I used Parkplace, VisualAge and Cincom professionally, and I think the real problem has always been the cost: Smalltalk tools were expensive, Java tools were free.
* Being image based has traditionally been a problem for many, except now that VMWare and Xen allow you to pause your running Image, move it somewhere else and restart it running from the snapshot point, you now have for an operating system what Smalltalk has always had at an application level.
* One traditional problem with a Smalltalk Image is that it can be hard to reproduce - to get from scratch to where it has evolved to. Pharo is working hard to make a reproducible bootstrap that builds up from scratch using CI infrastructure.
* Squeak and Pharo are strong and responsive open source communities. In [pharo-dev] maillist you often see people report a problem and its fixed the next day.
* Traditional interpretive performance issues are mitigated by Cog's JIT compiler.
Q: Where did Smalltalk go wrong?
A: Excessive cost of development tools at a time when Java was free.
Java was easy for C, C++ and Pacal programmers to migrate to. It had enough incremental benefits to justify the leap. Most importantly, Java surfaced with inbuild support for the Internet, just when the Internet rally was building.
If Smalltalk development tools had been less costly, it would have surpassed Java on every front. And, Smalltalk is such a joy to use.
Smalltalk is a success on the technical front. Current software technologies are still duplicating the innovations originated in Smalltalk. Docker is the latest, saving the state of a software solution.
Developer productivity is where Smalltalk really shines. There are many ways to measure productivity and code quality. Ultimately, total effort per function point is a useful one. On page 46 of http://namcookanalytics.com/wp-content/uploads/2013/07/Funct... a table sets out number of months to implement a 1,000 function point program. Here's a few metrics for dynamic and static languagues:
By these measures, Smalltalk projects will be completed in less than half the time as projects using C#, Java or C++. Javascript centric projects will take 3x, but this is not really an apples to apples comparison.
Where Smalltalk really failed, was on the commercial side. It failed to be adopted by a critical mass of developers. Smalltalk was used successfully, due to tool costs, mostly in Fortune 1000 class enterprises. For my small software company, it was a secret weapon enabling me to outperform competitors. I didn't sell Smalltalk, I sold "solutions."
Here's my thoughts about the demise of Smalltalk, if you will. There are of course many reasons, and as said by others it's still alive and well with Pharo.
The first reason may be just that it was too good, too ahead of its time. A huge programmer population already existed for C and C++ at the time Java with its C-like syntax came around. In programming languages "incrementalism" rules, which is easy to understand when considering how big an effort it takes to become an expert in one.
I think Smalltalk was also a victim of its own success. It promised a huge increase in productivity and software quality. This caused a business-war among its few suppliers at the time (Parc Place, Digitalk) and wars are never good.
And there's a technical reason for that too. Smalltalk is not just a language, it is an environment with a big library built into it. Even though the class-hierachy was mostly given by the original Smalltalk-80 there were small differences between the vendor-provided libraries which made it hard to run a Smalltalk application written for one Smalltalk virtual machine on another one. Which made it more important for every Smalltalk vendor to try to tightly own their users.
Here again ST was a victim of its own "goodness". The class-hierarchy is a tightly-knit set of classes which allows for maximum of code-reuse, but also means that it was not easy to combine classes from different platforms. If you took one class from vendor X it meant that many other classes had to follow and those could override similarly named classes in the target environment, which again would break many other things in the target platform and so on.
In other words Smalltalk was not modular enough, it was not easy to combine classes written on different platforms with each other. Smalltalk is not only an "island of its own", every Smalltalk is more or less an island of its own. Then again there's still only talk about bringing modularity to Java. But Java has the benefit of non-diverged platform. THAT also almost happened, with "Microsoft Java".
The ability to easily reuse large portions of the Smalltalk platforms is a huge benefit for productivity, at the same time it hinders co-operation between programmers working on different Smalltalk platforms.
Back in university, I did an introductory course in Smalltalk/Squeak as well as three seminars that used Smalltalk, two of which were group projects. (One chair was heavily invested into Smalltalk)
I won't use Smalltalk/Squeak professionally, and I've come to enjoy functional programming much more than OO programming (at least for non-UI tasks, which I generally enjoy more). That said, I do not regret learning and investing time into Smalltalk [1].
I'm dismissing the syntax-argument, as Obj-C has brought a Smalltalk-like syntax into the mainstream [2].
The one thing that I REALLY miss about Smalltalk sometimes is the ease of working with (stored) objects. You basically don't have to do anything. So much CRUD - just removed. I don't know how much time I wasted debugging or optimizing Hibernate-stuff in Java, or wrestling with CoreData in iOS.
With Smalltalks image, you just don't have to waste ANY braincycles on storing your data [3]. If you've created the object in memory, consider it stored. If you remove the last reference to it, consider it deleted. It's just so much more natural (for an OO program) than working with an ORM.
However, the image in Squeak was, in fact, the most difficult thing to get used to. The image contains not only your runtime, it is also your IDE. As an IDE, it had some good parts (similar to a browser where you can inspect any HTML-element, you can inspect any (visual) object with a right click), and after a while I was kinda OK with navigating the (not file-based) code. That said, it does neither rival a full-blown IDE nor Vim - the IDE always kept disturbing my flow somehow. And, with limiting your methods to a maximum of 7 lines of code, you're bound to use the IDE a lot.
> It's also hard to isolate a "program" in Smalltalk -- it's all one big heap of code, you may have added methods to Object, who knows what.
This hasn't been my experience at all. If you use some sort of versioning (we used SVN), you'll have to separate your code from your workspace. I don't remeber it to be any harder than it is in a traditional environment (do a diff before you check-in to make sure you've cleaned up everything and if your code/unit tests use any non-code files, make sure to check them in as well).
[1] In fact, I'd recommend anyone who is serious about becoming a good programmer to learn several (>3) distinctly different programming languages (i.e. Java and C# are too similar to count). And Smalltalk is really different, not only syntax-wise but conceptually a lot of stuff will broaden one's horizon.
[2] Thankfully, it's being replaced by Swift now. I've worked with it in the last 3 weeks, but I'm more happy to see the C-stuff go and functional programming concepts arrive than the Smalltalk-stuff removed.
[3] Well, for a certain scale at least... not feasible for Big Data, but sufficient for your average mobile or desktop app.
I earn my bread with Pharo Smalltalk.
And I use all the modern trappings:
CI with Jenkins
Source versioned in Github
Unit tests
Used to use Java, C, C++, PHP, and some Tcl/Tk.
Smalltalk is above all of these in terms of pleasure of coding. That's factor number one for me as this is what keeps motivation high.
I've been able to be faster, with less errors, and more features than any of the aforementioned languages once I passed a given experience threshold.
Pharo works nicely with the command line and on headless servers.
One can write text files that are loaded at runtime too, so scripting it fine too.
It would be nice to have a webdav view on an image so that one could have that "files" view and edit things with Vim for example. Well, one can do that already with a git checkout, I am just speaking about doing it on a live image. There are working POCs of that (e.g. Spoon from Craig Latta) and some work is going forward in that direction as well these days.
DabbleDB was written using Seaside, a framework which ran in Squeak (and other Smalltalk implementations).
DabbleDB met with rave reviews. http://press.dabbledb.com/ Within a couple of years the company behind it were bought by Twitter (2010) and DabbleDB closed down. http://en.wikipedia.org/wiki/Dabble_DB Clearly Twitter didn't buy this Smalltalk company because their product was a threat to Twitter.
It may well be that there are hugely successful corporations who are using Smalltalk and keeping quiet about it. Or it may be that being a successful Smalltalk developer is a sign of being a great developer.
Pharo is the closest thing to a de facto standard. It has a huge following, perhaps even the biggest of all Smalltalk users. It's the reference implementation for Seaside, the best of the Smalltalk web frameworks. It's the reference implementation for Amber, the best of the client-side web tools. I see little reason to consider anything else.
The best part of Pharo is that you get everything from the ground up: VM code, image objects, tools, all is accessible and can be shaped to one's will.
Try to do that with Eclipse or IntelliJ's tools!
This is making one reach an understanding of the computing platform which is very beneficial in terms of mastering one's craft.
This, and also I am specifically interested in if you can do modern web development in it, and if playing with smalltalk will result in similar epiphanies that learning multiple functional languages did.
It's hard to embed in your regular flow because of the image based nature. If regular files systems and git(hub) are your thing be prepared for some drastic adjustments.
Also, it is quite slow. But it is definitely worth a look just for the added insights into what programming could be like.
There need not be a single image. You can save and load as many images as you like. In fact, you can have thousands or hundreds of thousands of images if you prefer. You may think I'm being uncharitable to the author by construing his words as I did, but it's entirely appropriate given the tendency of those ignorant of Smalltalk (like him) to speak and act as if there is some monolithic, fragile image that everyone on a project shares and each must strive to avoid breaking.
The Smalltalk image may seem unfamiliar or even scary at first, but it's really little different from a standard Ruby or Python process, except that it is serializable and contains all of the code (both compiled and in source form), data, and execution state as objects that you can manipulate.
Further, every Smalltalk (that I know of) supports saving and loading source code to text files and often some form of package management and source control as well. Many Smalltalk also integrate with file-based tools quite well. For example, you can use git with Pharo, and many Pharo developers use Github exclusively for their development.
People citing the image as a reason for not using Smalltalk clearly don't know Smalltalk. They're also likely hypocrites, because at some point or another they've no doubt asked themselves why, after so many years, are programmers still programming by the mere editing of dumb text files? Well, in part because of your hostility to any system that isn't the mere editing of dumb text files.