I also don't like this convention, since it flips dependent-independent variable dichotomy on its head, but it seems to be the widely accepted norm now.
Worst example to me is the common use of the “ugly American” — in the book, he was the good guy who got out there and got dirty, as opposed to the pampered ones who stayed in the green zone, didn’t know any locals, and assumed everything in whatever country they were in was the same as in the ol’ USA, but just broken or corrupt.
I’m not American but I always cringe when I hear this usage. Why do people have to hollow out metaphors, destroying language in the process?
This is my pet peeve about Smalltalk and I love Smalltalk. Image basically means a single huge file. It's fine if the IDE lets you navigate inside it when you are working alone. But with multiple authors the issue becomes how do you merge two or more huge files.
Within a file all parts of it must work together. If you have a huge file the number of pairs or parts which must work together is exponentially larger. So merging "images" together is a problem on a class of its own.
But things got tricky when different people use different base-images and it is so easy to create new base-images. When you depend on (specific facts about) your base-image you don't need to declare such dependencies anywhere. Combine that with dynamic typing of Smalltalk. Then when you try to move to a different Smalltalk things just don't work and it takes time and effort to figure out why.
I guess the way to do it would be to never save your image, but that is so easy and convenient. But if you never save your image, it is as if you are not using the feature of having the "image", so you can't really say it is a good feature if you never use it.
When you do image-based development it is hard to control what and how many dependencies you create that are dependencies on the image you are currently working in.
Where I ran into trouble was trying to port an app from one Smalltalk to another. Should be easy right because Smalltalk really is a very simple language. But the ways your code could depend on anything in your image are countless. And no standard language definition with conformance tests.
I guess the situation with Smalltalk versions was much like the trouble you have with database vendors today. Or perhaps cloud-providers. Except that Smalltalk was so productive that anybody could easily create their own customizations.
In the database world you can write your own views and stored procedures. But you can't modify the base platform on which you must write those things. In Smalltalk it is very easy to modify the platform, and save those modifications in your image.
IF you had to declare every class and method you use from the image you wouldn't do so much of it. It would not feel very productive having to declare every dependency. But then, you would have fewer dependencies in the end and your code would be much more portable.
Compared to which other 1980's language?
> … smart team working together.
If the team isn't working together the language isn't the problem.
> Where I ran into trouble was trying to port an app from one Smalltalk to another. Should be easy right…
Compared to porting an app between which other 1980's languages?
Say from one C-compiler to another. C is still alive and kicking, Smalltalk not as much as it used to be.
You could write perfectly portable utilities in Smalltalk as long as they didn't rely on any services that were not comparable to what C the language contained within itself.
(Just like "trying to port an app from one Smalltalk to another" would mean trying to port between different Smalltalk gui libraries.)
Even back in 1984 pre-ENVY the explicit advice was —
"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)
1984 "Smalltalk-80 The Interactive Programming Environment"
https://rmod-files.lille.inria.fr/FreeBooks/TheInteractivePr...
> When you depend on (specific facts about) your base-image you don't need to declare such dependencies anywhere.
Why would you do image-based development when you had ENVY/Developer prerequisites "defining exactly which other code an application expects to access"?
https://www.google.com/books/edition/Mastering_ENVY_Develope...
What guarantees such pre-requisites are accurately documented and abided by?
Again if you never save or switch the image it can't give you too many problems. But what's the benefit of image-based development then?
I think it is like GOTO. You don't need to use GOTO even if your language provides it. But it is a bad idea for a language to provide a GOTO because then many people will use it. and shoot themselves in the foot.
Remember when you used ENVY? You could save the image. You could come back next day and pickup your work where you stopped. Even though all the methods were versioned and shared.
I'm saying that using an image and relying on it, having undeclared dependencies on it, saving it and versioning the image has an adverse effect on the long term maintainability and integrability of the software.
Say you had your source-code neatly stored and organized in Envy. Then could you just give your Envy-stored source to some developer in the field-office or an open-source collaborator around the world and say: Use this source-code to develop this further? Probably not. You would ALSO have to say by the way you must use this particular version of the base-image. Right?
And then, when there are several divergent base-images for different projects, how do you merge those base-images?
Envy is the cure to the problem that is reliance on the image. Then you say it is great. Yes because of Envy. Not because of the "image".
What exactly do you mean by "having undeclared dependencies" ?
Doesn't the changes file show everything that's been changed, added or removed?
"Within each project, a set of changes you make to class descriptions is maintained. … Using a browser view of this set of changes, you can find out what you have been doing. Also, you can use the set of changes to create an external file containing descriptions of the modifications you have made to the system so that you can share your work with other users.
…
The storage of changes in the Smalltalk-80 system takes two forms: an internal form as a set of changes (actually a set of objects describing changes), and an external form as a file on which your actions are logged while you are working (in the form of executable expressions or expressions that can be filed into a system). … All the information stored in the internal change set is also written onto the changes file."
1984 Smalltalk-80 The Interactive Programming Environment page 461
https://rmod-files.lille.inria.fr/FreeBooks/TheInteractivePr...
Incidentally multi-site development (page 89) and remote work (page 312) are discussed in "Mastering ENVY/Developer" but here's the part of your comment that puzzles me: you write this as-if it's some-kind-of gotcha?
> You would ALSO have to say by the way you must use this particular version of the base-image. Right?
To make the build process reproducible we start with the same thing and then add, remove and change stuff. Right?
That wasn't because of ENVY. That was something that would be written as a Smalltalk script — because reproducible.
I'd think the main problem was the underpowered hardware - especially the small address space (both for main and virtual memory) - which was too small for the more challenging Lisp programs and their data. Users moved to Symbolics and also very quick to UNIX based Lisps on SUNs.
> It was much more intensely networked even than most computing today.
I'd like to hear more about that... what was it like?
So the service implementations were smart: located via what was essentially an anycast and contacted via RPC. Everybody needed a client (for mail or whatever) but the implementations were easier.
The MIT style machines were of course networked and rarely had, say, a local filesystem either, but those services were typically provided by a host (typically a PDP-10): basically a client/server model. The D machine environments just treated the (LAN of course) cloud services and not much different from any other local resource. It was easier to write and run shared services in those days than to use websockets today.
Years later when I first encountered a Sun-3 I was shocked to discover it included an entire copy of sendmail and needed it to get the user's mail of the workstation! What an incredibly primitive approach, worse than I had had access to a decade before.
Of course that crappy model survived, but the apparently dominant model of (say) reading your mail is even more retrograde: gmail is just you logging into a remote computer and running a modern version of elm on it to get your mail. In the late 70s D-machine environments you grabbed an object (e.g. mail message) frm the network, maybe presented it to the user, then used it in a reply, and cast it into the void for someone else to take care of. None of the modern siloing which simply recapitulates the worst part of the PC era.
One of the reasons I like digital archeology is the way my degree was all about regarding computing evolution subjects, and we had a proper campus library to go along them, e.g. most published Xerox books.
It's peculiar as so much early CS came from people trained as mathematicians.
(a statement as true in 2023 as it was in 1963?)
At heart, the InterLisp language itself isn't that different from MIT lisps, as Interlisp started down the road at BBN and there was a lot of cross fertilization in both directions. And CommonLisp, while heavily based on the "MIT" model has a lot of Interlisp influence in it.
But as far as the interfaces are concerned things are quite different. Writing code on an "MIT-style" machine was like writing it on the '10: type into an emacs and away you go. Interlisp-D's conception was heavily influenced by the SmallTalk experience: structured rather than text editing, mouse as a primary interface tool, and development based on images rather than files of code. It was much more intensely networked even than most computing today. Although I ultimately still preferred the MIT model, I learned a lot from Interlisp and there are many things I preferred in that environment. The most annoying part for me was the dependence on the mouse.
A nit:
> "The learning curve of such a complex system is steep, almost vertical."
This means you could effectively learn everything overnight. A shallow learning curve is the terrible one: takes a long time to learn.