There was once a programmer who was attached to the court of the warlord of Wu. The warlord asked the programmer: "Which is easier to design: an accounting package or an operating system?"<p>"An operating system," replied the programmer.<p>The warlord uttered an exclamation of disbelief. "Surely an accounting package is trivial next to the complexity of an operating system," he said.<p>"Not so," said the programmer, "When designing an accounting package, the programmer operates as a mediator between people having different ideas: how it must operate, how its reports must appear, and how it must conform to the tax laws. By contrast, an operating system is not limited by outside appearances. When designing an operating system, the programmer seeks the simplest harmony between machine and ideas. This is why an operating system is easier to design."<p>The warlord of Wu nodded and smiled. "That is all good and well, but which is easier to debug?"<p>The programmer made no reply.<p>– The Tao of Programming, 3.3
This applies so much do gamedev.<p>I’ve tried Unity, Unreal, and Godot. But I’ve never been able to produce anything, because there’s just so much to learn. Rigging, particle systems, AI pathing, etc. And so much weird bugs and workarounds. Unity in particular sometimes seems like it was hacked together, and there’s always multiple ways to do everything (DOTS, UI, animation), the broken “beta” way and the “legacy” way.<p>In contrast, I write my own engine, and even though I have to make everything it’s so much easier. All I need to know is graphics and code. My game engines are much more intuitive to me because I wrote them. And no workarounds, because if the engine has a bug, I can fix it at the source. Of course, this means I end up making smaller games and it’s harder to collaborate with others. But it’s better than no games at all.<p>With the like 20+ different game engines out there I know I’m not alone.
I have known this for many years but found it difficult to explain to others. Backends are so much easier to build compared to frontends, and I mean decent and reliable ones. The attitude of the backend people of looking down upon frontend people is really stupid and unsubstantiated. Though scalable backends are increasingly getting their own layers of complexity these days, but still, on the backend you will never deal with frameworks with <i>millions of entry points</i>. If you don't believe me, UIKit alone exposes I think about half a million public symbols.<p>Nevertheless, I chose the path of the frontend (specifically mobile) because it fascinates me when a lot of people see on their screens something that you have built. A lot more than building a system that only the internal frontend devs are going to appreciate (or not).
It has been easy over the years:<p><i>Low-level is easy (2008)</i> - <a href="https://news.ycombinator.com/item?id=20568736" rel="nofollow">https://news.ycombinator.com/item?id=20568736</a> - July 2019 (26 comments)<p><i>Low-level is easy</i> - <a href="https://news.ycombinator.com/item?id=7538150" rel="nofollow">https://news.ycombinator.com/item?id=7538150</a> - April 2014 (56 comments)
Anyone who becomes sufficiently experienced in a domain will inevitably learn and take advantage of their underlying platform's characteristics.<p>A web developer who wants an app to load and render quickly will take advantage of the browser's characteristics. For example, loading compressed assets in the right order to get a short time-to-first-paint, updating styles without reflowing the page, using requestAnimationFrame to render animations at a consistent frame rate and play nicely with the event loop, etc.<p>Likewise, a systems programmer ends up learning the quirks of their OS and hardware. For example, loop tiling to take advantage of cache locality, reducing data dependencies to reduce pipeline hazards, using splice() to copy data on Linux to avoid context switching, etc.<p>It's all <i>just</i> programming. Even if the distance from hardware is different, the concepts are consistent. Historically, hardware has been under-documented, which I think led to the community glorifying low-level programming. But under-documented and buggy platforms are essentially universal nowadays, so I think the low-level vs high-level distinction is not very useful.
I recently switched from being a more general "software" dev to an embedded systems dev. Despite the fact that I'm using mostly C, I find everything much easier in general.<p>There are so many less layers of abstraction and "magic" to dig through that at I can always figure out what's going on easily enough. I think this article hits the nail on the head.
Staying as far from business as possible while still keep a thin line of contact with it, IMHO is the best way to live a programmer's life. Even when programming low-level systems such as Operating System or Compilers one still keeps a thin line of though of real world business through communicating with your users.
I wonder how much of this is due to the fact that the programming education today comes from a top-down approach, where one starts with a high-level language with little knowledge of the underlying system or the layers of abstraction on top of which it runs. Your upper year courses is where you begin learning more about operating systems, computer architecture, and the like.<p>Naturally, those programmers become focused on the high-level content because that's what they're brought up with/am comfortable with.<p>It would be interesting to see courses being taught from a bottom-up approach, maybe not at the gate/transistor level but rather at the assembly level. Teach the basic instructions, move on to C, then move on the high level languages - I actually learned programming this way and found that it helped a lot in understanding why and how things happen the way they do.
I used to be naive and think frontend was just pushing pixels around and messing with html. Now that I like to think I know better.<p>I think people generally perceive low-level/backend work as more objective, scientific, and rigorous.
I guess I'm just an idiot ¯\_(ツ)_/¯<p>I guess let's define what "low-level" is because I see a lot of abstractions in low level stuff. A couple years ago I had a sudden interest in the x86 platform. That entire architecture just seems like a piling of new abstractions on top of legacy stuff. And the hardware platform it typically runs on seems impossible to understand without being an insider. I remember trying to fully understand the entire UEFI boot process, and all the stuff below it and other modern components. The docs we're horrendous, and at times seemed non-existent for a lot of stuff and it was just too much information to try to take in.<p>I don't think I'll ever come around on the tooling. C is just a bit too barebones for me and I'm not fond of the "portable assembler" aspect of a lot of behavior being offloaded tot eh platform, which I now have to know in depth. I can read it, and write a little bit, but I don' think I could ever become good at it or enjoy it. C++ seems immeasurably complicated and i recall reading the phrase "I've been learning C++ for 10 years" the other day. There are some languages I don't mind as much. I like Ada, but no one uses it anymore. I'm working on what I suppose you could consider some systems software at the moment, and have resorted to using higher level languages that provide features or abstractions that provide exactly what I need (notably Erlang bitstrings) and only dropping to C when I need it.<p>I've tried other things too: driver development on both Windows, Linux, and BSDs (when the docs are decent, this is the thing I've tried that makes the most sense), FPGA stuff (For some reason, I can never wrap my head around digital logic, It makes sense at a very abstract level, but combing components into useful designs is just so foreign to me)
The last few months I have developed a web app. The shit you have to go through to make basic stuff work is insane. I would get depressed if this was my full time job. How browser can be one of the most important technologies and still suck so hard is truly mind boggling.
Shh, don’t tell people this - we’re trying to keep the other programmers out. ;)<p>In all seriousness embedded feels like the last safe place for a programmer like me, who grew up in the [redacted ancient decade] and has watched with befuddlement the tumescent froth of abstractions in other programming disciplines. I just can’t do web programming, for example. I did for many years but it broke my spirit and made me really dislike programming.<p>The “aha” moment was when I realized I like programming <i>computers.</i> Not browsers, not VMs, but actual computers. When I think about that old quote about computer science and telescopes, well... it turns out I really do like telescopes.
Every programming job is hard enough that the average programmer doing it will struggle, since it is those you will be compared against. So there is no hard or easy, you just struggle with different things. If you have a comparative advantage doing low level tasks then that will be easier for you, if you have a comparative advantage doing high level tasks then those will be easier.<p>Of course if a field is very popular compared to demand that they can be more selective then those jobs will be harder, since you are compared against better people. Game development is one such area.
I took a compiler construction course this year, and successfully passed it. We implemented an imperative/functional hybrid, with dozens of the implied (the Prof had warned us) swearing/cursing/regretting/all-nightering along the way. The employed toolchain comprised flex, bison, and LLVM, all wrapped with C++ and running on x86_64.<p>I still don't feel any confidence around user-space code. Lots of stuff was abstracted away--especially during the code generation part. Before taking this course, I had imagined that <i>every</i> component of <i>my</i> compiler would be hand-crafted by yours truly. Note that I do not expect an undergrad course to demand such levels of skill.<p>The thing I want to say, I guess, is this gut feeling that there are projects more appropriate than a compiler to draw your first userLand blood. Like a memory allocator, for instance; in my opinion, systems programming carries far all-arounder knowledge on its shoulders, with knowledge meaning a reliable representation of what takes place under the hood of a modern computer, in a comfy level of abstraction (program, threads, data, memory hierarchy, user, kernel, etc).<p>I am afraid, however, that I'm just too amateur to actually judge, and that I'm projecting a considerable amount of CS-revolving insecurities on the above statements. Any help with clarifying that is deeply appreciated.