Back in the early '90s, an envelope was delivered to me containing a physical 3.5 inch diskette. The contents was a Smalltalk/V 286 image file. A bug had been found in a program I'd written a couple of years earlier.
The client had saved the program state (including the full dev environment) at the bug (and exported their current data to CSV files, just in case). I stepped into the debugger, fixed the problem, saved the new image file to a 3.5 inch diskette, went to the post office and sent it back to them.
Of course they had continued working but I don't recall which approach they took to merging their new data with the corrected program.
Too bad 99% of real world (c)(tm) workloads don't look kindly on hauling not only a debugger but "the full dev environment" in every product shipped out there...
'We read and heard many stories about confident and experienced programmers plunging into self-study tutorials, only to give up in frustration after several hours, still wondering, "Where is the application code?" The object paradigm, in which program control is distributed across a set of tightly encapsulated and high-function software objects, was alien to experts in procedural design.
… to use Smalltalk fluently, a programmer must become familiar with a huge class hierarchy and with the tools of a sophisticated interactive programming environment. New programmers often became lost in the hierarchy or spent considerable time in unfocused exploration of the interactive tools.'
"Making Use: scenario-based design of human-computer interactions", 2000, page 103
Not quibbling at all, but I recall some discussion somewhere saying that the history of the Squeak impl itself (not the name) traces back via saved base images to the original Smalltalk implementations, including via customs at-rest transformation tools when backwards incompatible changed where made in the primordial days. Base images, at least back when I was toying with Squeak, where never rebuilt from scratch, just modified, transformed etc. In some sense, at least for the image, they were decades old.
March 7, 1988 — "Smalltalk/V 286 is available now and costs $199.95, the company said. Registered users of Digitalk's Smalltalk/V can upgrade for $75 until June 1."
I bought that. (We just don't discuss how much money was spent in the 80's and 90's on hardware, books, software, etc.) I had to drive from the So Cal South Bay up to Sherman Oaks to find a store on Ventura Blvd that had it. It was pretty cool at the time, but, it didn't have very good documentation on getting "your first app" up, so it mostly just sat and lingered.
There was a lot of reliance on the Smalltalk books. While the blue book was common, the green (history) and orange (how the GUI works) were not. I don't even recall stumbling across those at OpAmp back in the day (and if anyone would have had those, they would have). I was very excited about ST back in the day.
All of my forays into ST ended up being a struggle and I never got any real momentum to make progress.
To explain what I meant. I knew that that in the end this was a microbenchmark. It can certainly give you some clue about a language, but it doesn't tell you the whole picture. In the end it tells you how good a language is (or can be) at loops and floating point math.
That's what I meant. I hope that makes it clearer.
Thanks for the links - the benchmarks game is a great resource and has been around for a long time.
That said, I'm not sure what "do better" means here. This is an open source project I maintain in my spare time. If you see room for improvement, PRs are always welcome. That's how open source works - if something is useful to you and you want it improved, contribute.
The project exists because some people find it useful. If it's not for you, that's fine too.
