Comment by hn_throwaway_99 | Hacker News Reader

Comment by hn_throwaway_99 | Hacker News Reader

Parent Full thread

hn_throwaway_99

You're totally correct, I'm thinking this is basically just a troll post.

I started my software career in the late 90s, and having worked at a company last year with pretty much greenfield development, I was thinking how so many big, harry problems in software engineering that I experienced are just finally solved now:

1. You bring up version control, the first SCM system I used in the late 90s was CVS. I don't understand how any human that used CVS who now uses git+GitHub/GitLab/GitWebFrontendOfYourFancy can claim things are "stagnating".

2. Similarly, setting up a build and test process (the term "CI/CD" didn't exist in the late 90s) was a relatively huge undertaking, now it's trivial to get tests to run on every merge to master and then autodeployed with something like GitHub Actions.

3. Package management security, while not a fully solved problem, is leaps and bounds better than it was even a couple years ago. Again, I can automate my build process to run things like `npm audit` or other tools from providers like Snyk.

4. Umm, the cloud anyone? You may argue that this is a hardware change but it's really much more of a software issue - the cloud is only enabled by the huge amounts of software running everything.

I think the biggest thing I notice from the early 00s to now is that now I'm able to spend the vast majority of my time, even at a small company, worrying about features for my users, as opposed to the huge about of time I spent in the past just on the underlying infrastructure and maintenance to keep everything working.

If we start with CVS in the 90s (incidentally my first version control system as well) everything looks like great progress.

But if we actually look at what was around, both in theory and practice, CVS was a giant leap backwards.

Examples:

1. Smaltalk ENVY (1990s, I think?): Automatic class/method level versioning on save. Programmable, introspectable history to easily build CI type stuff. See user comments here: https://news.ycombinator.com/item?id=15206339.

> you could easily introspect every change to code and by combining introspection of classes and methods quickly determine which changes were happening where. We built a test framework that could list the changes since the last run, then compute dependencies and run an appropriate selection of test cases to check. This cut down test time by 90%

2. DOMAIN Software Engineering Environment (1980s): a distributed source control and config system where the provenance of built artifacts to source files was maintained. More than that:

> DSEE can create a shell in which all programs executed in that shell window transparently read the exact version of an element requested in the user's configuration thread. The History Manager, Configuration Manager, and extensible streams mechanism (described above) work together in this way to provide a "time machine" that can place a user back in a environment that corresponds to a previous release. In this environment, users can print the version of a file used for a prior release, and can display a readonly copy of it. In addition, the compilers can use the "include" files as they were, and the source line debugger can use old binaries and old sources during debug sessions. All of this is done without making copies of any of the elements. (from Computer-Aided Software Engineering in a Distributed Workstation Environment, 1984, http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.575...)

Note again, the above is from 1984.

3. PIE reports (1981): Describes a model of "contexts" and "layers" (roughly analogous to branches and revisions) for nodes (not files) that version methods, classes, class categories and configurations. On merging work from multiple authors:

>Merging two designs is accomplished by creating a new layer into which are placed the desired values for attributes as selected from two or more competing contexts.

(from An Experimental Description Based Programming Environment By Ira Goldstein and Daniel Bobrow, 1981, http://esug.org/data/HistoricalDocuments/PIE/PIE%20four%20re...)

The early 90s also had SRC's Vesta file system which had some interesting properties: https://www.hpl.hp.com/techreports/Compaq-DEC/SRC-RR-106.htm... CMU's Gandalf project had some interesting "semantic" version-control features.

However: it's easy to build experimental systems with cool properties. It's really hard to make them appealing in practice when you have to give up simplifying assumptions.

In particular a lot of these systems were not well adapted to managing collections of text files in unknown formats, edited by unknown tools. That made sense for research purposes, since you can't have as many cool properties without understanding the file formats, but it made them substantially less useful in practice, which I think is partly why they didn't get adopted.

Reply on news.ycombinator.com