Here are a few naive un-optimised single-thread #8 programs transliterated line-by-line literal style into different programming languages from the same original.
with originally i meant before the use of version control systems became common and expected. i don't know the actual history here, but i just found this thread that looks promising to contain some interesting details: https://news.ycombinator.com/item?id=15206339 (it is also discussing lisp which bring this subthread back in line with the original topic :-)
that's very interesting, thank you, i should have realized that even early on there had to be a way to share code between images. (and i don't know why i missed that comment before responding myself)
but, doesn't building a new system image involve taking an old/existing image, adding/merging all the changes, and then release new image and sources file from that?
in other words, the image is not recreated from scratch every time and it is more than just a cache.
what is described there is the process of source management in the absence of a proper revision control system. obviously when multiple people work on the same project, somewhere the changes need to be tracked and merged.
but that doesn't change the fact that the changes first happen in an image, and that you could save that image and write out a new sources file.
The image is not stand-alone: there should also be a sources file and a changes file (and of course a virtual machine).
"When you use a browser to access a method, the system has to retrieve the source code for that method. Initially all the source code is found in the file we refer to as the sources file. … As you are evaluating expressions or making changes to class descriptions, your actions are logged onto an external file that we refer to as the changes file. If you change a method, the new source code is stored on the changes file, not back into the sources file. Thus the sources file is treated as shared and immutable; a private changes file must exist for each user."
1984 "Smalltalk-80 The Interactive Programming Environment" page 458
~
The image is a cache. For a reproducible process, version and archive source-code.
1984 "Smalltalk-80 The Interactive Programming Environment" page 500
"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."
> Refactorings were defined as syntactically correct transformation of one AST into another
Refactorings preserved behavior.
Maybe that isn't what we wanted:
"A very large Smalltalk application was developed at Cargill to support the operation of grain elevators and the associated commodity trading activities. The Smalltalk client application has 385 windows and over 5,000 classes. About 2,000 classes in this application interacted with an early (circa 1993) data access framework. The framework dynamically performed a mapping of object attributes to data table columns.
Analysis showed that although dynamic look up consumed 40% of the client execution time, it was unnecessary.
A new data layer interface was developed that required the business class to provide the object attribute to column mapping in an explicitly coded method. Testing showed that this interface was orders of magnitude faster. The issue was how to change the 2,100 business class users of the data layer.
A large application under development cannot freeze code while a transformation of an interface is constructed and tested. We had to construct and test the transformations in a parallel branch of the code repository from the main development stream. When the transformation was fully tested, then it was applied to the main code stream in a single operation.
Less than 35 bugs were found in the 17,100 changes. All of the bugs were quickly resolved in a three-week period.
If the changes were done manually we estimate that it would have taken 8,500 hours, compared with 235 hours to develop the transformation rules.
The task was completed in 3% of the expected time by using Rewrite Rules. This is an improvement by a factor of 36."
from “Transformation of an application data layer” Will Loew-Blosser OOPSLA 2002
ENVY suffered of a problem that many other Smalltalk technologies suffered: a conflict between a culture of proprietary zeal as a business model and powerful network effects of adoption. Visualage in general was plagued by this. I used to blame Microsoft and Apple successes for the pervasive push for lock-in and "integration" as a feature that defined the era so strongly.
You had on the one hand had a technology that desperately needed adoption to build a culture and best-practices documentation, and on the other hand you had short term profit motive seriously getting in the way, so what you had that was completely cutting edge for decades, eventually it wasn't anymore - or the world moved in another direction and your once revolutionary technology became an ill fit for it.
By the 2000s with monotone and darcs, but specially with the rise of git, other standards for versioning have superseded what could have been. Smalltalkers already by the 2010s should have been wise to try to incorporate what is clearly a standard now but instead a bunch of invented-here systems for versioning and repositories and hybrids have developed in its place. And by incorporate i don't mean "let's make X for ST" but making it core in their implementation so that the system itself is more easily understood and used, even if its to take pieces of it away and use them which is actually a strength and not a weakness! contrary to some brand of 90s-era beliefs.
Generally speaking, to this very day it's regarded as cool and as a feature in ST world that something is ST-only, conveniently "integrated" into the system as tightly as possible and, implicitly but insidiously and glaringly, near-impossible to use elsewhere except maybe as a concept and laundered of its origin.
iirc reverse-complement reads and writes a GB, fasta and mandelbrot write, regex-redux reads, k-nucleotide reads and uses a hash table.
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...