7 ms·

I learned Smalltalk in the Elder Days (1985). Coming from C and Pascal, the power and majesty of true collections—dynamic lists! that you didn't have to build y

I learned Smalltalk in the Elder Days (1985). Coming from C and Pascal, the power and majesty of true collections—dynamic lists! that you didn't have to build yourself with pointers! sets! dictionaries! iteration over objects not integers! selection, rejection, injection!—was astounding. The ability to define behaviors in a generic not intensely specific way, the ability to meta-program, the ability to twiddle your environment directly—just so many world-changing innovations. Thankfully most of these advances are now baked into Ruby, Python, JavaScript, etc. (either right into the language, or with ready-to-hand libraries like itertools, more-itertools, and Underscore.js). The image—all your code, data/state, your entire OS and windowing system, your IDE, all rolled up into one—that was an interesting approach but honestly that is the worst thing about Smalltalk. No modularity. No version control. Your image persists your data and changes forever—including any mistakes you make, knocking around inside big ball of ever-declining clarity and reliability. Over time every image collects entropy, mistakes, and bitrot like no one's business! Eventually it gets to be impossible to figure out how to fix it, or takes so much energy to maintain you won't bother. Then you have to chuck it and start afresh. Rinse and repeat! Give me today's alternative, non-persistent dev environments and version control, any day.

jimbokun 5y ago
That seems to be the common complaint about image bases systems like Smalltalk and (some versions of) Common Lisp. The difficulty of collaborating, auditing, deploying, continuous integration and rolling back to specific versions of the code. Seems like it makes operational tasks, and really anything that involves distributing the code to anyone who is not the developer, is more difficult than with non-image based languages.
- scroot 5y ago
  There have been several different version control systems available for most Smalltalks for a while now. In the big open source Smalltalks (Squeak, Pharo, etc) there is even Git integration.
- xkriva11 5y ago
  Pharo has all this solved quite well.
  - jimbokun 5y ago
    Can you elaborate?
    - xkriva11 5y ago
      Pharo uses libgit2 binding and adds nice tools on top of it. The development of Pharo itself is based on Git/Github. So it uses standard Git workflow with branches, pull-requests, CI building and testing etc., but because it has methods based granularity, it is even better than plain Git for operations like merging and cherry-picking (it can, for example, easily resolve conflicts that plaintext based Git cannot). Moreover, it allows things like listing the history of a particular method. Even CI building can benefit from still-present image capabilities because you can have a basic prebuild image with project dependencies and then just load what you are really interested in in a few seconds (while still having an option to bootstrap it completely).
      - jimbokun 5y ago
        That sounds pretty cool.
- emschlr 5y ago
  Can't we just deploy the Smalltalk or Common Lisp code and not make changes to the live image? Then we can deploy Smalltalk/Common Lisp projects just like we deploy Python/Ruby prjoects. Can't we?
  - vindarel 5y ago
    For Common Lisp: sure we can. We can run a program from the sources, as a script, just like Python, and we can build a binary, with all dependencies baked in. CL has the feature to save the current image: it's excellent for development (see how Ravenpack ships images with several GBs of data baked in: the image will start instantly, you won't have to wait for your development data to be initialized again). And we can run the Lisp program and not touch it. But… if we want, we can easily connect to the running Lisp image, introspect it, change a couple parameters… or do a software upgrade, which can involve installing Lisp libraries… and we could connect to the image on the remote server from our editor and develop the app (while still saving the changes in source control locally), but that would be silly and it isn't a standard way.
  - scroot 5y ago
    Yeah, just don't save the image. Whenever you restart the program use a fresh image. This is pretty much indistinguishable from a "normal" program's state when it is running.
  - igouy 5y ago
    Here are some libraries and a program in Smalltalk Interchange Format being loaded into a Smalltalk image, the image being saved, and the saved image being used to run the program on the command line — https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/nbody-vw-1.html#log https://benchmarksgame-team.pages.debian.net/benchmarksgame/... ./bin/visual nbody.vw_run.im -nogui -pcl MatriX -filein nbody.vw -doit 'ObjectMemory snapshotThenQuit' ... ... ./bin/visual nbody.vw_run.im -nogui -evaluate "BenchmarksGame do: 50000000" ... ... -0.169075164 -0.169059907
- vindarel 5y ago
  What CL versions could they be? Even in versions with their own, very interactive IDE (LispWorks), we work with source files, with git and all, and we can run a program either from the sources as a script or from a pre-built binary (which is built from clean sources, not from our development image).
- rbanffy 5y ago
  I once interviewed James Gosling and one of the questions was precisely that - what did Smalltalk do wrong and what did Java do right for one to fail and the other to dominate the market? The “doesn’t play well with others” problem of Smalltalk was kind of a killer.
  - igouy 5y ago
    Might he possibly have had an agenda to promote? :-)
    - rbanffy 5y ago
      At that point I doubt it. I was expecting that answer in fact. Smalltalk had a couple problems Java didn’t. Its syntax scared people used to C while Java made them feel comfortable. The tooling was also free, which was not the case for Smalltalk at the time. Finally, the idea of storing source code inside a memory image didn’t help with interoperability (something I also observed while working with Zope).
      - igouy 5y ago
        "The Rise and Fall of Commercial Smalltalk" discussions provide a fuller picture: https://news.ycombinator.com/item?id=29223880 https://news.ycombinator.com/item?id=29223880 > … storing source code inside a memory image didn’t help with interoperability… "Interoperability" covers a lot of things, was there something particular you had in mind?
        rbanffy 5y ago
        In this case it was about being adaptable to the tools programmers already used. Smalltalk required one to buy into the whole thing - it’s an IDE with its own OS and GUI.
        igouy 5y ago
        What if those already-used tools weren't as-good for writing Smalltalk programs? ---- > … its own OS and GUI. Well there are examples of bare metal Smalltalk (I'm guessing we could say the same of Java?) https://github.com/michaelengel/crosstalk but that was kind-of unusual and afaik commercial Smalltalk implementations targeted specific host OSes. ---- Similarly back in the '80s commercial Smalltalk implementations provided their own GUI L&F (and in the '90s Java provided their CrossPlatformLookAndFeel aka Metal). When OS GUIs became available in the '80s, Smalltalk implementations either targeted specific host OS GUIs (so on MS Win use MS Win controls) or provided portable GUIs based on emulated L&Fs (OS/2, Motif, MacOS, MSWin) (and in the '90s Java provided AWT/Swing…). IBM Smalltalk (Visual Age) GUIs were based on what would become in the '90s Java SWT. ---- So no, not really "its own OS and GUI" — when GUIs became provided by the host OS, Smalltalk implementations provided ways to use the platform L&F.
- igouy 5y ago
  > … common complaint… For sure! Is it a well-founded complaint or just an obvious difference? What if the Smalltalk image is a cache not an archive? What if source code is exported from the image as text files and archived, and each week the source code is loaded into a base image for test? https://news.ycombinator.com/item?id=29911384 https://news.ycombinator.com/item?id=29911384
0x445442 5y ago
Most of the Smalltalk implementations I know support version control via Git or some other mechanism as a means of code distribution. And as I understand it, production code is built with CI/CD pipelines using a base image and checking out the code that's the app from a repo.
- coliveira 5y ago
  That's correct, while using an image for development is possible, it is not the preferred way to operate. Any industrial application in ST will use version controlled files, like in other languages.
snek_case 5y ago
> Over time every image collects entropy, mistakes, and bitrot like no one's business! Eventually it gets to be impossible to figure out how to fix it, or takes so much energy to maintain you won't bother. That's an interesting perspective, thank you for sharing. Smalltalk was trying hard to be different, and there were a lot of neat ideas in there, but while it seems like a very powerful concept to have your OS/editor and language all rolled up into one, that doesn't mean it's a good idea. Kind of like LISP macros. Seems like such a powerful and useful concept, but on the other hand, if you give programmers too much power, they are guaranteed to misuse it.
- igouy 5y ago
  > That's an interesting perspective, thank you for sharing. One person's perspective; here's another: https://news.ycombinator.com/item?id=29895839 https://news.ycombinator.com/item?id=29895839
taylodl 5y ago
I learned Smalltalk in 1994, which was well past the Elder Days. I came from a strong C++ background. I had the same experience you had in that Smalltalk showed a completely different way of doing things. Unfortunately we were hampered by garbage collection. We tried to tune and optimize as much as the environment would allow to no avail - when it came time to garbage collect the system would freeze for several seconds, sometimes up to tens of seconds. That was completely unacceptable for commercial software. Marketing also wasn't thrilled the UI came bundled with the environment. It was rather ironic that Java would come out the next year and the entire industry would pour so many resources into solving the garbage collection problem. Nowadays on a multi-processor system with concurrent garbage collection enabled the garbage collection can run faster than on manually-managed memory! That sure didn't seem like it would ever be possible in 1994!
- worik 5y ago
  > [a] system with concurrent garbage collection enabled the garbage collection can run faster than on manually-managed memory Maybe. But not predictably. It will have delays, they may be small, but there is know way to know when they will come. This can be managed but it is all overhead. Manual memory management has none of that run-time overhead (but a tonne of programmer overhead)
  - maemre 5y ago
    Manual memory management is much more predictable (which is really nice for interactive/real-time programs), it does have nontrivial runtime overhead: malloc and free aren't free (pun slightly intended), and often costlier than a bump allocator most moving/copying GCs use (just increment a pointer and have a very branch-predictable conditional to check OOM). Also, moving/copying GCs increase data locality by bringing live objects closer, which is more cache friendly. I agree that manual memory management is much more predictable than garbage collection, I just wanted to touch on the nuances of the memory overhead of manual memory management. Also, if the program creates lots of short-lived objects (which is often the case), a generational garbage collector would be pretty fast because it will reclaim/move a few objects rather than deallocating many objects. An arena collector or allocating on the stack might be better (and manual methods) in this scenario though.
coliveira 5y ago
This is like saying that using an OS with long term storage is a problem because it accumulates incorrect files, mistakes, and other long term choices that will hamper your productivity. It may be true, but it is not necessarily the case. You can use images in the way you describe, but you can also use them as a support technology that is available only when useful for development. Modern development in Smalltalk uses source control like any other language.
- jrumbut 5y ago
  > an OS with long term storage is a problem because it accumulates incorrect files, mistakes, and other long term choices that will hamper your productivity This is why containers became so successful, IMO. For a long time I thought being able to log in to a server and set up a new cron job to deal with some maintenance task was a strength. It turns out that over time it does become a problem.
esfandia 5y ago
I don't know about the current state of Smalltalk, but back in the late 90s there was a very elegant version control system for Smalltalk called Envy. It provided version control at the level of each method, and it was integrated nicely in the IDE.
- igouy 5y ago
  2001 book "Mastering ENVY/Developer" https://www.google.com/books/edition/Mastering_ENVY_Developer/ld6E19QIMo4C?gbpv=1 https://www.google.com/books/edition/Mastering_ENVY_Develope...
- swamp_cypress 5y ago
  I use Envy on VA Smalltalk professionally. Coming from Mercurial and SVN, when I first encountered it, I thought "WTF". Now I regard it as the greatest version control tool I have ever used. (It is also a package manager as well as a build tool). Version control at the method level!
  - smackeyacky 5y ago
    I would second that. Incredible control aimed at the strengths of Smalltalk. I'm not sure the way it worked would ever really translate to other languages but I really miss it sometimes. It was very expensive though.
taeric 5y ago
I will note that image based deployments seems to be what the ml world has moved to. Such that I'm curious if moving models around for use would have been easier in some image based languages.
igouy 5y ago
I taught myself Smalltalk in 1988 coming from Modula-2. It's simply anachronistic to judge Smalltalk implementations of that past decade against version control of this decade, when there have been newer Smalltalk implementations with version control. Even back in 1983 the blue book discussed "Storing the set of Changes on a File" (page 465) and "Commands that check for conflicts" ( http://rmod-files.lille.inria.fr/FreeBooks/TheInteractiveProgrammingEnv/TheInteractiveProgrammingEnv.pdf http://rmod-files.lille.inria.fr/FreeBooks/TheInteractivePro... page 472). "Whether your development team consists of one person, or many: Do understand and use the change manager. The change manager is one of the most important tools for software development in the Smalltalk-80 environment. … It allows you to selectively browse [changes], remove [changes] incorporate them into another version of the system, check for conflicts, and prepare the changes for release to other members of the development team or to end users." (page 500 "Smalltalk-80 Software Development Do's and Dont's") > Your image persists your data and changes forever—including any mistakes you make… Even back in 1988, source code changes made with the Smalltalk IDE were automatically logged to a text file (the change log) and we could choose which of the logged source code changes to apply later to an unchanged image file. So no, mistakes were not forever.
- smackeyacky 5y ago
  I don't know about that. For most of the VisualWorks programmers I was tasked with helping in the 1990s, the change log was an error prone way of sharing changes amongst your team members - this was before ParcPlace implemented packages properly and whatnot. All of it was pretty useless compared to using Envy/Developer which was a unique version control system that was based entirely around Smalltalk and collected up your changes in a way that made sense for sharing. The guys at ParcPlace never seemed to quite understand what we were facing back then - your average departmental programmer trying to replace a green screen in a team of 20 other programmers not only had to cope with a complete change of paradigm for the programming language, but the version control systems were non-existent or useless even compared with simple systems like SCCS. Change logs just didn't cut it when you got past 2 developers. The vanilla VisualWorks simply didn't scale to multiple users trying to share code. Envy/Developer fixed that (and how! Still the best version control system I have ever used). The "forever" thing might be an exaggeration, but in practical terms I had a lot of guys destroy images accidentally by over-ridding something in Object or whatever while they were learning and causing havoc for themselves. Trying to piece together their good work from the change log was...effectively impossible until they learned what they were doing due to the total scattergun approach a lot of them used. So perhaps not "forever", but given the time constraints in a normal development environment, it was forever for certain values of forever.
methehack 5y ago
Any persistent storage will exhibit the cruft problem over time for any system of even limited complexity. You're describing people, not Smalltalk. And Smalltalk has had version control for more than a decade. Smalltalk always felt like it was from the future to me. Its vision and respect for human thought and creativity is so grand it makes me blush. It represents a real belief in technology and what people might do with it. It's full of hope and humanity. It's basically the Shire of programming environments -- if the Shire were part of the Standford campus. If you haven't checked Smalltalk out, you should free your mind and give it a shot.
arendtio 5y ago
I agree. While there are many things to admire about Smalltalk (e.g. clean syntax, real Object Orientation, feeling of a high-level language), the image idea is certainly the least favorite of mine. The idea of a bundled IDE is also something I am not completely convinced that it is the best solution. On the one hand, it allows powerful operations, but on the other hand, every feature has to be developed explicitly for that language. Instead, I prefer the modularity of Unix tools which can be used to develop tools by combining multiple technologies.
- 7thaccount 5y ago
  Text based technologies able to be called from via the command line and piped around to each other with other Linux commands is best for me.
tonyg 5y ago
https://github.com/tonyg/squeaker https://github.com/tonyg/squeaker "Like Docker, but for Smalltalk images."

jimbokun 5y ago

That seems to be the common complaint about image bases systems like Smalltalk and (some versions of) Common Lisp. The difficulty of collaborating, auditing, deploying, continuous integration and rolling back to specific versions of the code. Seems like it makes operational tasks, and really anything that involves distributing the code to anyone who is not the developer, is more difficult than with non-image based languages.

scroot 5y ago
There have been several different version control systems available for most Smalltalks for a while now. In the big open source Smalltalks (Squeak, Pharo, etc) there is even Git integration.
xkriva11 5y ago
Pharo has all this solved quite well.
- jimbokun 5y ago
  Can you elaborate?
  - xkriva11 5y ago
    Pharo uses libgit2 binding and adds nice tools on top of it. The development of Pharo itself is based on Git/Github. So it uses standard Git workflow with branches, pull-requests, CI building and testing etc., but because it has methods based granularity, it is even better than plain Git for operations like merging and cherry-picking (it can, for example, easily resolve conflicts that plaintext based Git cannot). Moreover, it allows things like listing the history of a particular method. Even CI building can benefit from still-present image capabilities because you can have a basic prebuild image with project dependencies and then just load what you are really interested in in a few seconds (while still having an option to bootstrap it completely).
    - jimbokun 5y ago
      That sounds pretty cool.
emschlr 5y ago
Can't we just deploy the Smalltalk or Common Lisp code and not make changes to the live image? Then we can deploy Smalltalk/Common Lisp projects just like we deploy Python/Ruby prjoects. Can't we?
- vindarel 5y ago
  For Common Lisp: sure we can. We can run a program from the sources, as a script, just like Python, and we can build a binary, with all dependencies baked in. CL has the feature to save the current image: it's excellent for development (see how Ravenpack ships images with several GBs of data baked in: the image will start instantly, you won't have to wait for your development data to be initialized again). And we can run the Lisp program and not touch it. But… if we want, we can easily connect to the running Lisp image, introspect it, change a couple parameters… or do a software upgrade, which can involve installing Lisp libraries… and we could connect to the image on the remote server from our editor and develop the app (while still saving the changes in source control locally), but that would be silly and it isn't a standard way.
- scroot 5y ago
  Yeah, just don't save the image. Whenever you restart the program use a fresh image. This is pretty much indistinguishable from a "normal" program's state when it is running.
- igouy 5y ago
  Here are some libraries and a program in Smalltalk Interchange Format being loaded into a Smalltalk image, the image being saved, and the saved image being used to run the program on the command line — https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/nbody-vw-1.html#log https://benchmarksgame-team.pages.debian.net/benchmarksgame/... ./bin/visual nbody.vw_run.im -nogui -pcl MatriX -filein nbody.vw -doit 'ObjectMemory snapshotThenQuit' ... ... ./bin/visual nbody.vw_run.im -nogui -evaluate "BenchmarksGame do: 50000000" ... ... -0.169075164 -0.169059907
vindarel 5y ago
What CL versions could they be? Even in versions with their own, very interactive IDE (LispWorks), we work with source files, with git and all, and we can run a program either from the sources as a script or from a pre-built binary (which is built from clean sources, not from our development image).
rbanffy 5y ago
I once interviewed James Gosling and one of the questions was precisely that - what did Smalltalk do wrong and what did Java do right for one to fail and the other to dominate the market? The “doesn’t play well with others” problem of Smalltalk was kind of a killer.
- igouy 5y ago
  Might he possibly have had an agenda to promote? :-)
  - rbanffy 5y ago
    At that point I doubt it. I was expecting that answer in fact. Smalltalk had a couple problems Java didn’t. Its syntax scared people used to C while Java made them feel comfortable. The tooling was also free, which was not the case for Smalltalk at the time. Finally, the idea of storing source code inside a memory image didn’t help with interoperability (something I also observed while working with Zope).
    - igouy 5y ago
      "The Rise and Fall of Commercial Smalltalk" discussions provide a fuller picture: https://news.ycombinator.com/item?id=29223880 https://news.ycombinator.com/item?id=29223880 > … storing source code inside a memory image didn’t help with interoperability… "Interoperability" covers a lot of things, was there something particular you had in mind?
      - rbanffy 5y ago
        In this case it was about being adaptable to the tools programmers already used. Smalltalk required one to buy into the whole thing - it’s an IDE with its own OS and GUI.
        igouy 5y ago
        What if those already-used tools weren't as-good for writing Smalltalk programs? ---- > … its own OS and GUI. Well there are examples of bare metal Smalltalk (I'm guessing we could say the same of Java?) https://github.com/michaelengel/crosstalk but that was kind-of unusual and afaik commercial Smalltalk implementations targeted specific host OSes. ---- Similarly back in the '80s commercial Smalltalk implementations provided their own GUI L&F (and in the '90s Java provided their CrossPlatformLookAndFeel aka Metal). When OS GUIs became available in the '80s, Smalltalk implementations either targeted specific host OS GUIs (so on MS Win use MS Win controls) or provided portable GUIs based on emulated L&Fs (OS/2, Motif, MacOS, MSWin) (and in the '90s Java provided AWT/Swing…). IBM Smalltalk (Visual Age) GUIs were based on what would become in the '90s Java SWT. ---- So no, not really "its own OS and GUI" — when GUIs became provided by the host OS, Smalltalk implementations provided ways to use the platform L&F.
igouy 5y ago
> … common complaint… For sure! Is it a well-founded complaint or just an obvious difference? What if the Smalltalk image is a cache not an archive? What if source code is exported from the image as text files and archived, and each week the source code is loaded into a base image for test? https://news.ycombinator.com/item?id=29911384 https://news.ycombinator.com/item?id=29911384

0x445442 5y ago

Most of the Smalltalk implementations I know support version control via Git or some other mechanism as a means of code distribution. And as I understand it, production code is built with CI/CD pipelines using a base image and checking out the code that's the app from a repo.

coliveira 5y ago
That's correct, while using an image for development is possible, it is not the preferred way to operate. Any industrial application in ST will use version controlled files, like in other languages.

snek_case 5y ago

> Over time every image collects entropy, mistakes, and bitrot like no one's business! Eventually it gets to be impossible to figure out how to fix it, or takes so much energy to maintain you won't bother. That's an interesting perspective, thank you for sharing. Smalltalk was trying hard to be different, and there were a lot of neat ideas in there, but while it seems like a very powerful concept to have your OS/editor and language all rolled up into one, that doesn't mean it's a good idea. Kind of like LISP macros. Seems like such a powerful and useful concept, but on the other hand, if you give programmers too much power, they are guaranteed to misuse it.

igouy 5y ago
> That's an interesting perspective, thank you for sharing. One person's perspective; here's another: https://news.ycombinator.com/item?id=29895839 https://news.ycombinator.com/item?id=29895839

taylodl 5y ago

I learned Smalltalk in 1994, which was well past the Elder Days. I came from a strong C++ background. I had the same experience you had in that Smalltalk showed a completely different way of doing things. Unfortunately we were hampered by garbage collection. We tried to tune and optimize as much as the environment would allow to no avail - when it came time to garbage collect the system would freeze for several seconds, sometimes up to tens of seconds. That was completely unacceptable for commercial software. Marketing also wasn't thrilled the UI came bundled with the environment. It was rather ironic that Java would come out the next year and the entire industry would pour so many resources into solving the garbage collection problem. Nowadays on a multi-processor system with concurrent garbage collection enabled the garbage collection can run faster than on manually-managed memory! That sure didn't seem like it would ever be possible in 1994!

worik 5y ago
> [a] system with concurrent garbage collection enabled the garbage collection can run faster than on manually-managed memory Maybe. But not predictably. It will have delays, they may be small, but there is know way to know when they will come. This can be managed but it is all overhead. Manual memory management has none of that run-time overhead (but a tonne of programmer overhead)
- maemre 5y ago
  Manual memory management is much more predictable (which is really nice for interactive/real-time programs), it does have nontrivial runtime overhead: malloc and free aren't free (pun slightly intended), and often costlier than a bump allocator most moving/copying GCs use (just increment a pointer and have a very branch-predictable conditional to check OOM). Also, moving/copying GCs increase data locality by bringing live objects closer, which is more cache friendly. I agree that manual memory management is much more predictable than garbage collection, I just wanted to touch on the nuances of the memory overhead of manual memory management. Also, if the program creates lots of short-lived objects (which is often the case), a generational garbage collector would be pretty fast because it will reclaim/move a few objects rather than deallocating many objects. An arena collector or allocating on the stack might be better (and manual methods) in this scenario though.

coliveira 5y ago

This is like saying that using an OS with long term storage is a problem because it accumulates incorrect files, mistakes, and other long term choices that will hamper your productivity. It may be true, but it is not necessarily the case. You can use images in the way you describe, but you can also use them as a support technology that is available only when useful for development. Modern development in Smalltalk uses source control like any other language.

jrumbut 5y ago
> an OS with long term storage is a problem because it accumulates incorrect files, mistakes, and other long term choices that will hamper your productivity This is why containers became so successful, IMO. For a long time I thought being able to log in to a server and set up a new cron job to deal with some maintenance task was a strength. It turns out that over time it does become a problem.

esfandia 5y ago

I don't know about the current state of Smalltalk, but back in the late 90s there was a very elegant version control system for Smalltalk called Envy. It provided version control at the level of each method, and it was integrated nicely in the IDE.

igouy 5y ago
2001 book "Mastering ENVY/Developer" https://www.google.com/books/edition/Mastering_ENVY_Developer/ld6E19QIMo4C?gbpv=1 https://www.google.com/books/edition/Mastering_ENVY_Develope...
swamp_cypress 5y ago
I use Envy on VA Smalltalk professionally. Coming from Mercurial and SVN, when I first encountered it, I thought "WTF". Now I regard it as the greatest version control tool I have ever used. (It is also a package manager as well as a build tool). Version control at the method level!
- smackeyacky 5y ago
  I would second that. Incredible control aimed at the strengths of Smalltalk. I'm not sure the way it worked would ever really translate to other languages but I really miss it sometimes. It was very expensive though.

taeric 5y ago

I will note that image based deployments seems to be what the ml world has moved to. Such that I'm curious if moving models around for use would have been easier in some image based languages.

igouy 5y ago

I taught myself Smalltalk in 1988 coming from Modula-2. It's simply anachronistic to judge Smalltalk implementations of that past decade against version control of this decade, when there have been newer Smalltalk implementations with version control. Even back in 1983 the blue book discussed "Storing the set of Changes on a File" (page 465) and "Commands that check for conflicts" ( http://rmod-files.lille.inria.fr/FreeBooks/TheInteractiveProgrammingEnv/TheInteractiveProgrammingEnv.pdf http://rmod-files.lille.inria.fr/FreeBooks/TheInteractivePro... page 472). "Whether your development team consists of one person, or many: Do understand and use the change manager. The change manager is one of the most important tools for software development in the Smalltalk-80 environment. … It allows you to selectively browse [changes], remove [changes] incorporate them into another version of the system, check for conflicts, and prepare the changes for release to other members of the development team or to end users." (page 500 "Smalltalk-80 Software Development Do's and Dont's") > Your image persists your data and changes forever—including any mistakes you make… Even back in 1988, source code changes made with the Smalltalk IDE were automatically logged to a text file (the change log) and we could choose which of the logged source code changes to apply later to an unchanged image file. So no, mistakes were not forever.

smackeyacky 5y ago
I don't know about that. For most of the VisualWorks programmers I was tasked with helping in the 1990s, the change log was an error prone way of sharing changes amongst your team members - this was before ParcPlace implemented packages properly and whatnot. All of it was pretty useless compared to using Envy/Developer which was a unique version control system that was based entirely around Smalltalk and collected up your changes in a way that made sense for sharing. The guys at ParcPlace never seemed to quite understand what we were facing back then - your average departmental programmer trying to replace a green screen in a team of 20 other programmers not only had to cope with a complete change of paradigm for the programming language, but the version control systems were non-existent or useless even compared with simple systems like SCCS. Change logs just didn't cut it when you got past 2 developers. The vanilla VisualWorks simply didn't scale to multiple users trying to share code. Envy/Developer fixed that (and how! Still the best version control system I have ever used). The "forever" thing might be an exaggeration, but in practical terms I had a lot of guys destroy images accidentally by over-ridding something in Object or whatever while they were learning and causing havoc for themselves. Trying to piece together their good work from the change log was...effectively impossible until they learned what they were doing due to the total scattergun approach a lot of them used. So perhaps not "forever", but given the time constraints in a normal development environment, it was forever for certain values of forever.

methehack 5y ago

Any persistent storage will exhibit the cruft problem over time for any system of even limited complexity. You're describing people, not Smalltalk. And Smalltalk has had version control for more than a decade. Smalltalk always felt like it was from the future to me. Its vision and respect for human thought and creativity is so grand it makes me blush. It represents a real belief in technology and what people might do with it. It's full of hope and humanity. It's basically the Shire of programming environments -- if the Shire were part of the Standford campus. If you haven't checked Smalltalk out, you should free your mind and give it a shot.

arendtio 5y ago

I agree. While there are many things to admire about Smalltalk (e.g. clean syntax, real Object Orientation, feeling of a high-level language), the image idea is certainly the least favorite of mine. The idea of a bundled IDE is also something I am not completely convinced that it is the best solution. On the one hand, it allows powerful operations, but on the other hand, every feature has to be developed explicitly for that language. Instead, I prefer the modularity of Unix tools which can be used to develop tools by combining multiple technologies.

7thaccount 5y ago
Text based technologies able to be called from via the command line and piped around to each other with other Linux commands is best for me.

tonyg 5y ago

https://github.com/tonyg/squeaker https://github.com/tonyg/squeaker "Like Docker, but for Smalltalk images."