"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.
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.