4 ms·

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

koko775 12y ago
> 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.
username223 12y ago
> 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.
- vixen99 12y ago
  Rhetoric can get carried away with itself but your last sentence does, in my experience, hit the nail on the head. Rather a shame.
ianbicking 12y ago
"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 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 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 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-futuristic.html 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.
- 12y ago
krapp 12y ago
> 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.
- wtallis 12y ago
  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.
  - krapp 12y ago
    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.
    - CookWithMe 12y ago
      https://github.com/HPI-SWA-Teaching/SwaLint https://github.com/HPI-SWA-Teaching/SwaLint 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/packages/SwaLint-Core.package/SLResult.class/instance/asString.st 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 ;-)
    - wtallis 12y ago
      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.

koko775 12y ago

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

username223 12y ago

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

vixen99 12y ago
Rhetoric can get carried away with itself but your last sentence does, in my experience, hit the nail on the head. Rather a shame.

ianbicking 12y ago

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

12y ago

krapp 12y ago

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

wtallis 12y ago
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.
- krapp 12y ago
  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.
  - CookWithMe 12y ago
    https://github.com/HPI-SWA-Teaching/SwaLint https://github.com/HPI-SWA-Teaching/SwaLint 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/packages/SwaLint-Core.package/SLResult.class/instance/asString.st 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 ;-)
  - wtallis 12y ago
    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.