Ask HN: Programmers of the 80s how do I learn to build the things you built?
From reading the history, I found that a lot of things that play central role in our machines were designed and built in the 80s and early 90s.
Things like Linux, GNU, BSD, Apache, MySQL, IRC.
Programmers of 80s, how did you know how to build these things given that many of these were hobbyist projects? How did the later contributors understand the design of these projects?
How did you get started? What resources did you use?
If were to build today something like you did, low level systems in C, how do I get started? What's the best available resources?
15 comments
[ 1.9 ms ] story [ 45.5 ms ] threadHow much did he know when he started? A university CS degree, basically. Enough to write a bare-bones working OS kernel that only ran on i386.
We got talking about Linux which was still pretty early, though certainly moving out of its hobbyist days. This guy said that the OS guys at DEC used to project portions of the Linux source code up on a screen and sit around making jokes at some of the coding.
Isn't it interesting that in the end the open source collaborative model outlasted and kept improving while the closed source commercial model got bogged down in acquisitions and disinterest from Compaq and then HP and eventually mostly faded away.
"You are a brilliant implementor, more able than me and possibly (I say this after consideration, and in all seriousness) the best one in the Unix tradition since Ken Thompson himself. As a consequence, you suffer the curse of the gifted programmer -- you lean on your ability so much that you've never learned to value certain kinds of coding self-discipline and design craftsmanship that lesser mortals must develop in order to handle the kind of problem complexity you eat for breakfast."
[1] http://lwn.net/2000/0824/a/esr-sharing.php3
I'm frankly mildly disturbed that no other comment in this thread at the time of writing gave you the same answer.
http://matt.might.net/articles/what-cs-majors-should-know/
To add a few of my own that aren't mentioned here which are more in the vein of what you're really looking for (disclaimer: I have not read most of these all the way through, some at all.)
Compilers: The Dragon Book, the dragon book is usually criticized for being outdated so try and find another compilers book if you want, what you're looking for here is switching your mindset from 'I will try to hack up a compiler.' like the other comments here seem to be recommending, which will never work, to going 'this is a complicated piece of software it wouldn't be intuitive to me how to build, is there a theory behind it?'. Quite often the answer is yes.
Operating Systems: The dinosaur book.
Databases: At the University Of Washington I was told to read Database Systems by Garcia-Molina: https://www.amazon.com/Database-Systems-Complete-Book-2nd/dp...
To talk a little bit more about what recommends this approach over other ones:
The other comments seem to be recommending a mindset that your first step to trying to understand these complex systems is to implement them from scratch with your own naive view of the problem. This is at best a good beginners exercise to teach you the value of humility and learning from the work of others, or perhaps to get some practical experience in why the problem is hard. In general, you are never going to be able to have one of these systems spring forth from your brow on its own strength, unless you are a genius beyond genius who can in days or weeks replicate the hard work of years of study by some of the smartest people in your field.
C isn't a bad language, and is far nicer to learn than C++. It'll bite hard if you get things wrong though.
Most of got a start sat at a terminal in front of a BSD or SVR4 flavour Unix, or a BSD Sun Workstation. Never occured to me so much would still exist 25 years later!
If you want to understand BSD and all the *nix family "The Design and Implementation of the FreeBSD Operating System" is a great starting point. You'll understand what the kernel is doing, why and how. The earlier version of the book that I've had for years is online ("Design and ... 4.4 BSD OS") at freebsd. I think the online version is complete, but not certain. That and a few other classic nix books, like W Richard Stevens, give a decent grounding.
You probably have a harder time replicating being surrounded by semi-benevolent greybeards nudgng your habits in the preferred direction! Early newsgroups were free of spam and full of people to answer. IRC and web came later. Needing to consider security came later too!
Reading through BSD code, a lot of the core code is very good, and starting to mess around with simple things like MUDs and simple client server things will put you in a reasonable place. We couldn't just download from web, so had to write a simple in-office chat service, test tools etc.
What you won't get easily is the need and desire to minimise memory use, or CPU cycles, or even pack data, so some of the effort just isn't bothered with. Regularly needing to consider that made us naturally wary of being wasteful. In truth I wish some of it were still around when waiting needless time for some app to update some small data from cloud.
Resources were programmers reference guides, technical publications (i.e. BYTE in the 80s, Dr. Dobb's Journal) Lots of snacks and hours bashing code.
If you look at a lot of the games of the time some programmer would figure out say a cool looking jump for a game character, and from that build it into a platformer. Same with productivity someone devises a faster method to edit a file bigger then system memory and bases a new word processor on that.
So in today's world it's pretty much the same thing; you see a technology and figure out how to improve upon it, try to adapt it to your platform of choice (and employ new methods), or stumble upon some other idea while messing around and you build from that. There's a lot more resources to build and bolster your concepts now then there was back in the 80s - that's for sure.
Given the time period there has been ample time for a large number of highly skilled people to contribute high quality code, increasing the overall project quality and stability.
I would hazard a guess the early beta versions of Apache, MySQL etc. were far from the quality and stability we see today