💾 Archived View for yujiri.xyz › software › guide captured on 2023-03-20 at 18:14:53. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-01-29)
-=-=-=-=-=-=-
I have a very good reason for creating a new tutorial when there are so many existing ones. It's obvious even to non-programmers that there are pervasive problems with modern software. When I was a kid, I had a computer with 256MiB of memory, and it could run all the apps I wanted. Today my laptop has *16 times* that much memory (and its processor is more powerful by a similar factor), but do programs run 16 times faster? Can it run 16 times as many programs at once? Absolutely not. Somehow, ordinary apps like Element still lag, even when there's nothing else running. It's no secret that since the start of this millenium, software has become much less efficient.
It has also become less reliable. Nearly every graphical program I use has regular bugs and crashes. In fact, somehow these programs - such as Firefox - seem to have *more* bugs than they did when I was a child. When I have to fill out web forms for government or commercial purposes, I often find the form is buggy or fails to submit with an error message as helpful as "Something went wrong, try again later". It is amazing that these institutions with their massive resources and huge teams of programmers can't make a working web page.
I attribute these problems to the culture of modern software development, and partly the ways it's influenced by capitalism. There are a few aspects of the cause.
How do you make money as a software company? You need to do something new, stand out, attract users with hype. Reliability and efficiency don't generate hype. Software that just does its job and gets out of the way doesn't generate hype. It lets you forget it even exists. What generates hype is lofty promises that can't be fulfilled and fancy features that no one's ever done before, for good reasons. So, that's what programmers are paid to do.
Many of the problems in software stem from the bad design of platforms they're built on top of. The operating systems and user interface frameworks we use have many design flaws. But fixing those flaws is much harder to do and to monetize than making new apps, because there are no users you can sell it to. People will pay for an app or a web service, but no one will pay for a user interface framework or a new, better-designed operating system with no apps yet.
In general, the only things you can monetize are end-user applications (and software-as-a-service in particular), so that's what most programmers focus on, and may be all they know how to do. Many web developers don't know basic facts about how operating systems work. They may not know what a file descriptor is or the difference between heap and stack memory.
This one isn't related to capitalism, but rather the accessibility and easy searchability of information via the internet. This is of course a good thing, but has the following side effect: it is easier for a programmer to find an immediate solution to a specific problem than to gain a deep understanding of the system the problem is with. When your code doesn't work and you can't figure out why, you can search for other people who've had the same problem and often find a solution on a website like StackOverflow, that you can paste into your code editor without understanding why it works or why it was necessary in the first place. Often, these quick solutions lead to more problems elsewhere, but that's okay - you can always patch it with another trick you found on StackOverflow.
My guess is this was less true before the information revolution, because the only way to find a solution would've been to read the manual of the system you were using, start to finish, which would open your eyes to the correct, robust solution.
I think the way people learn programming needs to change. Programmers need to learn how systems work *before* they try to build on top of those systems. It won't be as satisfying, because you'll have to do a lot of reading and hard thinking before getting your hands dirty with code, and it's not optimal for getting a job as a programmer, but if you're interested in helping solve these pervasive problems with modern software, this is the way.
This work in progress will be somewhere between a curriculum and a study guide for everything I believe programmers should understand. I link to resources made by others when I feel I couldn't write a better one myself, or when I haven't had time to do so. Also, I sometimes include overlapping resources, because they each contribute some unique information or explanatory angles.
I recommend starting at some of the very basics of computer science.
Video explanation of binary, the way computers count and store information
Unix and Internet Fundamentals
The Unix and Internet Fundamentals is very old and some of the details are outdated, so I'm working on replacing it with my own writings, but for the time being I still recommend it. Also, despite the name, most of it isn't specific to Unix or Linux. Don't worry if you don't understand everything it says. You'll get at least something out of it.
What it covers that I don't yet cover myself: booting (BIOS -> bootloader -> kernel -> init), ASCII and UTF-8, partitions, i-nodes, mount, file permissions, IP, TCP, DNS, HTTP.
If you use Windows or Mac as a daily driver, I want to bring up that you should switch to Linux or a similar operating system. For ordinary people I say it's okay to keep using Windows or Mac if they find it more convenient, but if your goal is to help fix fundamental pervasive problems with software, I think this is not optional. We don't need more software that only supports proprietary platforms and more programmers that only understand proprietary platforms.
How does an operating system work?
How graphical and windowed prorgams work
The Ubuntu command-line tutorial
My short appendix to that turorial
How processes can communicate with each other
How software development works
I intend to expand this page with many more resources, not all of which necessarily ought to come before you learn to code. I won't define any specific point at which I think you should do that; I'll encourage you to decide when you're ready (or impatient, or just curious) and go here: