What was the developer experience like in the old days? | Hacker News Reader

What was the developer experience like in the old days?

encrypted-tbn0.gstatic.com

10 pointsenagrimm10 comments

At University, I learned the joys of TSO, emacs, and unix. There was no mouse or arrow keys or delete keys. I had to learn weird key combinations to line up, line down, character left, character right, delete etc. To see the output, I had to print the dang thing out which was across the street in a different building.

First real job was at Southwest Research Institute in San Antonio. I programmed in a DEC VMS environment. My Fortran program read the raw output from strain gauges attached to a USAF jet trainer and processed the data which made it possible to track the airframe's weakening due to cyclic fatigue. It was just a bunch of I/O calls and loops. It was delivered to the USAF as part of their program to predict airframe fatigue. This time, there was a mouse but it didn't do anything. Because once I logged into the DEC VMS, it was all keystrokes again. My program was one giant file something like 5K lines.

I've been curious about this for a long time as to how did the people during the old days finish writing software that went on to reshape the world. I mean, nowadays we have an lsp that is there to correct us and give us syntax cause who wants to go through the pain of remembering keywords right? If you're from the webdev world then you have frameworks with hot module replacement or reloading so that we don't have to go through the process of compiling things or the minor inconvenience of saving our files and restarting our dev servers, something that the new generation of devs seem to have no gratitude for at all. This speed with which we can produce software seems to make us too lazy I guess, we don't seem to be that concerned with getting it right the first time and we adopt that attitude of, "I'll eventually fix it.", which often leads to horrendous software experiences. Then there is AI, which kind of takes away the need to really and I mean really learn what we are doing. Just the understanding of how the boilerplate works is something that can only be achieved if we try to write it down and reason about it. But that is gone, ai can just generate that and the people with no experience are expected to write the parts in the middle that connects everything and the problem is that they don't even have the fundamentals down to be able to do that. Basically, developer experience nowadays is getting automated to a level where we'll probably stop having good new programmers.

And that really makes me appreciate the generation that was stuck on a few kilobytes of ram with just a plain text editor making things for the future. I don't even get why we are so ungrateful and unwilling to learn the fundamentals. Where is the humility? Do you really think that the code that an ai wrote that you just copied over proves thay you have any sort of intelligence? Be humble and keep learning.

My CS teacher in high school used to talk about writing FORTRAN code on punched cards in the 1960s where you could “edit” the deck by reordering the cards, type new cards on a punch machine, etc. Remember that 80 columns was the standard width for terminals for a long time because a punch card had 80 columns.

Minicomputers and mainframes had advanced interactive facilities in the early 1970s, you could use BASIC on a PDP-11 and it was about the same as using BASIC on an Apple ][ (no graphics though unless you had a GIGI terminal), edit Assembly, FORTRAN and COBOL programs with the TECO text editor and compile just like you would with C or Go on a Linux machine today. By the 1980s most mainframe development was done with VM/CMS which was a lot like using virtual machines today, to do development you would spin up a VM that ran a single user OS that was a lot like MS-DOS (or maybe it was the other way around.)

Dan Luu wrote about this: https://danluu.com/essential-complexity/ "If you look at the complexity of moderately large scale modern software projects, they're well beyond any software project that had been seen in the 80s. If you really think about what it would mean to approach these projects using old school correctness practices, I think the speedup from those sorts of practices to modern practices is infinite for a typical team since most teams using those practices would fail to produce a working product at all if presented with a problem that many big companies have independently solved, e.g., produce a distributed database with some stated SLO.

A version control system that multi-file commits, branches, automatic merging that generally works as long as devs don't touch the same lines, etc., is a fairly modern invention. ...there was still easily an order of magnitude speedup available from better version control tooling, test tooling and practices, machine speedups allowing faster testing, etc. ... For large projects, just having CI/CD alone and maintaining a clean build over building weekly should easily be a 2x productivity improvement"

Up until not long time ago, I used to use text editors (notepad/notepad++/etc) as my main editor for my program in C++ and the likes, and I used to either remember stuff, or having my own cheetsheet, or the books at my disposal for any quick reference, even books in electronic form weren’t searchable as today (basically images in pdf with no OCR functionality), and later when some tools are out that will convert books to be searchable it was like a breakthrough for me, “you mean I can quickly search for a text in 400+ pages?! Wow?!!”, even for other domains like electronics, none of Rpi or arduino existed, for anything we used to use PIC controllers and program them then dump the code with dumping kit, while now you just load python on Rpi and call it a day. We used to have arguments which one is better MASM or NASM as an assembler, just like flame wars now for React vs Vue, and I’m not even that old, all of that technological advancement happened primarily in the past decade!

In the computer labs in the 1980s, you had a room with 100 or so VT100 terminals each with a Computer Science student trying to get their programs written, served by a DEC VAX 11/780 running VMS. They had routed the compiler into a batch queue because it was resource intensive. Unfortunately, the batch queue was set to background priority, so compiles didn't get done for about 30-60 minutes.

One Saturday, I figured this out, and started pushing the first job in the queue to above interactive priority, and it would finish in a few seconds. I repeated... and repeated this manual tweaking.... about 2 hours later, everyone had gotten their work done faster than usual, and the room was practically empty.

Most academic environments suffered from similar issues... too many students all trying to get their work done at the last minute.

---

When I got my own PC/AT clone and ran Turbo Pascal, the compile times were effectively instant (on the order of a few seconds), and just kept getting faster with each new release.

'C Programming on System 6' (in 2020-22) https://jcs.org/system6c

https://68kmla.org/bb/index.php?threads/getting-started-with...

Period correct programming books https://vintageapple.org/macprogramming/

My introduction to shared library was: I had two blocks of storage (512k?) and my C program's executable (statically linked by default) was too big, filling my quota.

I wasn't able to do interesting graphics programming on the Apple because I had to learn assembly language and the Apple's weird graphics format (amusingly, somebody recently released a nice high performance assembly graphics library for the Apple II).

The stack limit on my first PC's C compiler was 6 function calls.

I had to upgrade my second PC from 4MB RAM to 32MB RAM before I could run X, emacs, and g++ all at the same time without swapping.

coding punch cards.

keybding hex codes.

coding with assembler mnemonics

coding with macros, and compiler, whew, intimate knowledge of hardware no longer required.

coding with system calls, fingers dont cramp as much, a degree of universality existed accross platforms. yay DOS.

coding with WIN API, yay Microsoft fingers dont hurt, brain fatigues from use of arcane API calls

C comes to rescue no macro assembly required, but variable type hell begins to burn.

proprietery lockouts and secret source, MASM makes freedom.

DLL hell awakes.

LINUX ! yay linus.

QBasic was a joy to work with.

Reply on news.ycombinator.com