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)
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.
It was my understanding that C4 doesn't do pauses.
But what is it? Where can I find out about it? A deterministic garbage collector would (a) prove me wrong and (b) be a Very Good Thing
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/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.
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.
Just curious, what process did you tell them to get past their "scattergun approach"?
I never looked at the 1984 "Smalltalk-80 The Interactive Programming Environment" book until about a year ago, so very much with the benefit of hindsight —
"At the outset of a project involving two or more programmers: Do assign a member of the team to be the version manager. … The responsibilities of the version manager consist of collecting and cataloging code files submitted by all members of the team, periodically building a new system image incorporating all submitted code files, and releasing the image for use by the team. The version manager stores the current release and all code files for that release in a central place, allowing team members read access, and disallowing write access for anyone except the version manager." (page 500)
http://rmod-files.lille.inria.fr/FreeBooks/TheInteractivePro...
Envy fixed that, you could start with a fresh envy image and grab your updates. You could also isolate developers in their own branch like git and get proper warnings when you had integration issues when merging.
Basically the integration job went from full time to a couple of hours a week.
> … filing that into other developers images as they went…
Seems to me that after "building a new system image" all their developers worked with that same fresh system image (built from known archived sources).
(Perhaps I'm wrong about that.)
Then we settled on pre built images with just the across team shared code. But that got difficult too, as some teams didn't want to upgrade as quickly as others on the shared code base, so we were maintaining several versions of that.
The teams themselves had regular image consolidations saved, plus file outs and some PVCS for those, but it got increasingly harder to make a consistent merged image no matter what and devs were spinning their wheels in a kind of code merge hell at the method level that is unique to smalltalk.
Then we got envy and it fixed everything.
ParcPlace did eventually come up with a different structure for packaging and sharing code but it was too late and too simplistic to be useful.
Puzzled. ENVY/Developer is still Smalltalk and code merge still method level?
Perhaps what was shared within teams and between teams changed?
(With the benefit of hindsight) seems to me that many teams made their mistakes with vanilla Smalltalk and avoided those same mistakes when they moved to ENVY/Developer.
You tell us the people didn't know what they were doing — so why blame the tools?
(Incidentally, I used Envy/Developer for years.)
Not every programmer is a superstar. Visual basic was a much better environment for average guys doing green screen replacement jobs.
I was briefly involved with a project that sounds a bit like that — a 2 week training course for current staff, then rewrite everything from data model to U/X in half-the-usual time because someone said OO is more productive.
That project used ENVY/Developer. The staff admin deleted the repo. The staff wouldn't have passed phone screen for Smalltalk work (maybe some would have in 6 or 12 months). When the people don't know the basic tools, that's what matters.
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.
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!
https://www.google.com/books/edition/Mastering_ENVY_Develope...
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.
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.
One person's perspective; here's another:
Such that I'm curious if moving models around for use would have been easier in some image based languages.
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.
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.
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.169059907For 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?
The “doesn’t play well with others” problem of Smalltalk was kind of a killer.
Here's some "play well with others” "interoperability" —
Sept 21, 1987 — "A version of the Smalltalk-80 object-oriented development environment … has been announced by Parcplace Systems.
Smalltalk-80 DE version 2.2 is said to provide Unix environments with interprocess communication via sockets and access to Unix C shells. On the Apple Macintosh, it provides access to Desk Accessories and provides the ability to cut and paste between the Smalltalk-80 system and the clipboard."
https://books.google.com/books?id=ldk7z4Q-WWYC&pg=RA4-PA4&lp...
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?
----
> … 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
----
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.
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.
"Like Docker, but for Smalltalk images."
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.