4 ms·
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
by 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 agothere 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 agoYou 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 agoThis 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.