3 ms·

I found myself nodding to this bit of the article: "Intellectually I know that it’s really hard to lose changes in a Smalltalk image, but it still feels fragile

I found myself nodding to this bit of the article: "Intellectually I know that it’s really hard to lose changes in a Smalltalk image, but it still feels fragile to me not to have files readable by an external tool." It has nothing to do with how reliable smalltalk is. With such an alien paradigm I'm sure I'll screw up and lose code somewhere and have no way of knowing how it happened. Perhaps putting code in a binary image has also hindered the spread of smalltalk? I see fewer code fragments of smalltalk than I do of say lisp. (I'd love pointers to more smalltalk code reading.)

gecko 15y ago
Code actually is not in the image, and I wish that the article weren't conflating that with what actually happens, which is at once better and worse. The image is just bytecode and a bunch of predefined objects. So where does your source code live? Inside of a file called YourImageName.changes, which contains every single line of Smalltalk you execute, including everything from class definitions to method renames to one-offs in workspaces and so on. If you blow up your image, you simply start with a new one, open a change sorter on your old .changes file, and file in the exact pieces you want, skipping over the part where you, say, accidentally did "Integer become: Boolean" or something equally stupid. So far, so good: your code is indeed in text, and it's always up-to-date, and it's trivially machine parsable. So what's the issue? The issue, for me, is that there isn't, by default, a dump of code that represents your program as it exists right now. With that trivial change, using traditional source-control becomes a royal pain the ass, if not outright impossible. That's why you see almost zero Smalltalk code on sites like GitHub, even though the community's active: they end up developing their own systems, such as Monticello, and their own hosting solutions, like SqueakSource and SmalltalkHub, that work with Smalltalk .changes files, rather than Smalltalk code living in text files. If Smalltalk made one-file-per-class, or something similar, the default, and if it automatically generated "compacted" changes on a regular basis (basically a .changes with all of the stuff you deleted thrown out--in other languages, you'd call these the source files), then I think it'd go a long way to helping adoption. Hell, as a side-benefit, writing Smalltalk code in Emacs would be a lot easier, for those who like that particular path. But in the meantime, that's the way things work.
- gruseom 15y ago
  there isn't, by default, a dump of code that represents your program as it exists right now If everything is in file xyz.changes, and the file is trivially parsable, could you write a program to parse the file, replay the changes up to time T, and dump out a textual representation of the program as it existed at T? I get that this isn't the Smalltalk way. Typically it's best to approach a system on its own terms. Ideas like this are probably the equivalent of a newcomer to Lisp trying to "improve" things by getting rid of the parens. I'm just curious about what the technical barriers to doing such a thing would be.
  - gecko 15y ago
    You can indeed, and it's borderline trivial, but attempts to get the community to adopt such a system in the past have failed completely, and I don't find value in writing code that no one except me will ever use.
- bergie 15y ago
  This problem rings a bell: With Midgard you traditionally kept all your website (PHP) code inside a database. This made web-based remote editing easy, and allowed us to use exactly same ACLs, versioning, and deployment rules for code as for the content. But at the same time, this meant that collaboration between users was hard, and that people were locked out of their favorite editors and VCSs.
avibryant 15y ago
Everyone voices this concern, but it's important for people to understand that most Smalltalkers consider the binary image a throwaway artifact, and sometimes a deployment mechanism - it is emphatically not how you store or distribute code. There are standard, largely textfile based ways of doing that. I almost if it would be an advantage to not show beginners the "save image" menu item, because then it would be like any editor or IDE: if you haven't saved your source files, you lose your work, and you have to start each session by loading your source back in.
- jamesladd 15y ago
  Gosh Avi, you could have mentioned Redline Smalltalk http://redline.st http://redline.st

gecko 15y ago

Code actually is not in the image, and I wish that the article weren't conflating that with what actually happens, which is at once better and worse. The image is just bytecode and a bunch of predefined objects. So where does your source code live? Inside of a file called YourImageName.changes, which contains every single line of Smalltalk you execute, including everything from class definitions to method renames to one-offs in workspaces and so on. If you blow up your image, you simply start with a new one, open a change sorter on your old .changes file, and file in the exact pieces you want, skipping over the part where you, say, accidentally did "Integer become: Boolean" or something equally stupid. So far, so good: your code is indeed in text, and it's always up-to-date, and it's trivially machine parsable. So what's the issue? The issue, for me, is that there isn't, by default, a dump of code that represents your program as it exists right now. With that trivial change, using traditional source-control becomes a royal pain the ass, if not outright impossible. That's why you see almost zero Smalltalk code on sites like GitHub, even though the community's active: they end up developing their own systems, such as Monticello, and their own hosting solutions, like SqueakSource and SmalltalkHub, that work with Smalltalk .changes files, rather than Smalltalk code living in text files. If Smalltalk made one-file-per-class, or something similar, the default, and if it automatically generated "compacted" changes on a regular basis (basically a .changes with all of the stuff you deleted thrown out--in other languages, you'd call these the source files), then I think it'd go a long way to helping adoption. Hell, as a side-benefit, writing Smalltalk code in Emacs would be a lot easier, for those who like that particular path. But in the meantime, that's the way things work.

gruseom 15y ago
there isn't, by default, a dump of code that represents your program as it exists right now If everything is in file xyz.changes, and the file is trivially parsable, could you write a program to parse the file, replay the changes up to time T, and dump out a textual representation of the program as it existed at T? I get that this isn't the Smalltalk way. Typically it's best to approach a system on its own terms. Ideas like this are probably the equivalent of a newcomer to Lisp trying to "improve" things by getting rid of the parens. I'm just curious about what the technical barriers to doing such a thing would be.
- gecko 15y ago
  You can indeed, and it's borderline trivial, but attempts to get the community to adopt such a system in the past have failed completely, and I don't find value in writing code that no one except me will ever use.
bergie 15y ago
This problem rings a bell: With Midgard you traditionally kept all your website (PHP) code inside a database. This made web-based remote editing easy, and allowed us to use exactly same ACLs, versioning, and deployment rules for code as for the content. But at the same time, this meant that collaboration between users was hard, and that people were locked out of their favorite editors and VCSs.

avibryant 15y ago

Everyone voices this concern, but it's important for people to understand that most Smalltalkers consider the binary image a throwaway artifact, and sometimes a deployment mechanism - it is emphatically not how you store or distribute code. There are standard, largely textfile based ways of doing that. I almost if it would be an advantage to not show beginners the "save image" menu item, because then it would be like any editor or IDE: if you haven't saved your source files, you lose your work, and you have to start each session by loading your source back in.

jamesladd 15y ago
Gosh Avi, you could have mentioned Redline Smalltalk http://redline.st http://redline.st