Ask HN: Programmers of the 80s how do I learn to build the things you built? | Hacker News Reader

Ask HN: Programmers of the 80s how do I learn to build the things you built?

10 pointsmohanmcgeek15 comments

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?

View on HN

If you want to understand how to build those things, you need to understand the actual theory of Computer Science. Textbooks and papers exist that will tell you (in the abstract) how to implement pretty much everything you named there. Of course, creating systems on the level of quality those have would require immense effort from a single person, that's why they all have a team of contributors rather than one lone genius past the founding stage.

I'm frankly mildly disturbed that no other comment in this thread at the time of writing gave you the same answer.

Can you give me a list of said textbooks and papers? Or point me to a list that already exists?

Basics list:

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.

Linux started as a hobby project, but you can't look at Linux today and think "a hobbyist wrote that". A hobbyist started that. He got a lot of people to help him by choosing the right license. In the process, he learned an insane amount more than he knew when he started.

How 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.

I recall talking to some DEC guys about the time it was acquired by Compaq. In the High Performance Computing world DECs UNIX based OS (Tru64)for Alpha workstations was very highly regarded.

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.

Wasn't Linus already pretty familiar with Minix at the time, too?

Plus the hobbyist in question, was a rather brilliant[1] programmer at a young age. According to ESR:

"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

You can still start in a very similar place.

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.

Actually, one could just unpack shar archives from comp.sources.unix. (-:

We messed around and discovered neat hacks. From those hacks we expanded on the concepts and developed more robust things.

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.

Counterargument: Projects built in the 80s/90s that are still alive today are the 0.001% of projects that have survived for a myriad of reasons, not necessarily code quality or programmer ability

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

My 2p: Don't pay too much heed to the CS crowd. Get a book on 6502 & maybe the Complete Commodore 64 ROM Disassembly. Download VICE, cc65, Contiki OS, lbForth, QEMU. Google Dave Cutler, Alan Kay. Remember the 80s is luxury land it was all done & dusted in the 70s, maybe the 50s or even the 30s. Good luck best wishes all that.

Software ingenuity came from overcoming hardware limitations. The new hardware to chart and exploit may be quantum computing.

Bulletin Board Systems.

Ah yes! Do any beginner friendly newsgroups or BBS exist today?

Reply on news.ycombinator.com