Low-level is easy

I've found this very true, as I've moved over the years from very "high-level" programming (client/server apps, database-driven web sites) to "mid-level" programming (working on the Firefox browser) and then toward systems programming (working on Rust and Servo). The desire to stop dealing with masses of fragile dependencies keeps driving me lower in the stack. I really need to practice more assembly coding so I can continue in this direction...

You get some similar benefits if you are working on code where you have some control over the levels above or below, or if your project has any form of self-hosting. For example, Firefox, where most of the UI is rendered by Gecko and some of it even runs within a browser tab. If you're a web developer and you run into a rendering engine bug, you report it and then ship a workaround for three years as you wait for enough people to update. If you're a Firefox front-end developer, you can just fix the Gecko bug and ship the fix along with your feature.

Low level is a lot more fun in the very least.

I wouldn't say it is easier by any means.

The first time you open up the debugger and your v-table pointer is null (presuming you know what a v-table pointer is!) things start to be interesting.

Or there was that time I printf'd a 64bit number and a random stack variable was corrupted. That was a lot of fun.

Memory protection? Haha. No.

For that matter, my team just came across a bug in our own code a couple weeks ago, we were performing a DMA memcopy operation (for which you get to setup your own DMA descriptors yourself of course) over a bus and at the same time sending a command packet to the same peripheral that was being DMA'd to.

oops.

Expected things to be put into order for you? Nope. Not unless you implement your own queuing system. (Which we are doing for that particular component now.)

All in all it is a ton of fun though. I'm loving it. Having seen an entire system be built up from setting up a clock tree to init'ing peripherals to our very own dear while(1). (We actually moved away from while 1, async is where it is at baby! Callback hell in kilobytes of RAM! oooh yaaaah)

In the company I used to work for we covered quite a range of development targets, from embedded micros up to very high level factory control systems, and I always found the most challenging stuff was "in the middle" - stuff at the systems level.

At the bottom, it really felt like programming a machine, and I found it all good fun, much like solving a puzzle (with occasional obscure headaches, mostly compiler related). At the top everything is pretty abstract, and there's more freedom to do conceptually interesting things (for example we were doing quite a bit of adaptive control type stuff, which would have been a nightmare to write with lower-level languages).

In the middle, however, it seemed to me to be largely just a complicated network of interacting conventions. Those systems are neither firmly grounded in "reality", because they are generally trying to abstract away those details, nor are they "theoretically pure", because they need to be efficient (though there is a lot of interesting stuff there). What that means is that you simply have to learn and understand all those human-defined conventions to know what you're doing, and that makes solving problems at that level more difficult, or perhaps rather it requires much more hard-won expertise (which I never got much of - I just bugged other people until they would help me out!).

Obviously, my views are coloured by my personal experience, so make of them what you will.

I get the point of the blog author and I partly agree with it; but there are different types of "hard" and "easy".

To produce much of value at the low-end you need a really comprehensive understanding of the technology at the level you are working at which has significant upfront learning (and likely just plain aptitude) costs that aren't really addressed too much here. Once you have that knowledge, then yes, you get far less surprises, but acquiring it in the first place is not at all trivial or "easy" (though it may seem like it if you're a geek that's been banging away with assembler for years... you've just forgotten how much effort you expended at that stage, probably because it felt fun to learn).

At the higher-end you can string together a bunch of frameworks and glue code you cut and pasted off Stack Overflow and get something that pretty much does what you want, most of the time, maybe, while barely understanding the underlying technology.

Which is "easier" or "harder" depends a lot on what you mean by those terms.

Also the assumption that "high-level" means HTML/CSS/JavaScript is not that useful for the overall debate since not all high-level development is as annoyingly unpredictable as HTML/CSS/JavaScript.

A beautiful elaboration of what I've been feeling for many years. I don't get all this excitement over web programming. The process is a pain in the neck -- why doesn't this color turn red when it's supposed to? Oh, this IE workaround conflicts with this Firefox bug. To me it feels like a house of cards held up with old, dessicated duct tape. Yeah, you can do amazing things with cards and duct tape, but because of the shaky foundation, it ends up being vastly more frustrating and so much more work than it really should be.

I haven't responded by going as far down the stack as this guy has -- although I've done a fair bit of assembly and enjoyed it, I spend most of my time in Python and Erlang -- but coding web apps can be such a ghetto.

Playing the piano is easier than playing a violin. I would argue that a world-class pianist is about as skilled as a world-class violinist.

If you could allocate skill points like an MMO, the violinist is spending 3 points on instrument mastery, and 7 points on musical mastery, while the pianist spends 1 and 9.

I hate spending my limited skill points on "browser mastery," so I mostly do lower level things.

The big difference, and the reason most find low level harder, is that you can do a pretty bad job on front end code and still produce something of value. Whereas low level code tends to need to be more solid.

I would not say that dependency of the layers is like a tree and if trunk breaks, everything does. I'd rather see the levels of programming abstractions as a graph with lower/higher level nodes.

As it is pointed out in the comments above, x86 has surprisingly much of a duct tape in it. There is a lot of much more saner platforms, but programming still lives happily on x86. Why? Because it does not matter at all so often. x86 is hidden from us with OS, compilers and virtual machines. That's where the beauty of programming shines: if you have a lame implementation below your level, just abstract it away as far as resources allow you (e.g. full-scale managed memory programming is theoretically possible in DOS but noone did it because of CPU/memory constraints). Another example: Win32 API and MFC and other native stuff is horrible, but .NET platform seems to be quite sane. Javascript is horrible, but jQuery is, um, beautiful.

On the other hand, a hardware guy still operates with an abstraction of a microcontroller. If memory is corrupted, his abstraction fails also. It's just that the HW guy does not have to invent good abstractions often (or rather at all).

The point is, abstracting may be self-healing: if something is broken at some level, a level above can use the good parts to build a fully functional emulation.

This seems pretty spot on to me. More moving parts = more failure points...as a web engineer, I find myself bitten more by the trappings of abstract code structure than by things like faulty algorithms. This ties pretty heavily into why I feel the standard technical interview for web engineering talent is severely broken, but I digress.

The author makes some valid points, but he seems indifferent to the most important question: why program computers at all? He doesn't seem to enjoy it much (although that may be more of a sarcastic tone). I think we need more devs who do it because they want to accomplish something particular, and less devs who are doing it cause computers are kewl (or to get paid for that matter). With a utility view, the choice of low-high level gets less emotional:

* high-level is more productive in the short run, but may hinder you in the long run

* mid-level (C-ish level) tend to be more portable and more future proof

* low-level will probably give you better resource usage (speed, memory etc), but not necessarily these days

Personally, I find C++ (plus open source libraries) gives the best trade-off, but that's probably dependent on the task (I do audio/video analysis/synthesis).

"Memory-mapped devices following a hardware protocol for talking to the bus will actually follow it, damn it, or get off the market."

Says somebody who clearly never had to deal with cheapass webcams in Linux... :)

And the similar: server-side/back-end is easy!

Sure, there's an ubersmooth learning curve with HTML/CSS/Javascript, but once you get to heavy client side SPAs and supporting every device and format under the sun and then someone say "it's not good enough, try and make it feel like a 100% native iOS app - and no, you can't just write an iOS app" ...and good luck hiring a good front-end guy (at least if you don't do the expensive way of "hire 5 instead and fire 4 of them after two months" route).

I agree with this article. The Web is a shambling mess of crap technologies, just a Jenga tower of crap. When is it going to collapse under its own weight? The rise of native apps suggests that the collapse has already begun.

I found this very true, even for other kinds of low-level. I do database engines in low level Java.

This seems like a kind of selection bias to me. For the most part we only build "high level" things on top of "low level" things when we're successful in finding a use for them, by definition. The more successful you are, the easier success seems. Put another way, if they weren't "easy" then there wouldn't be a "high level" above them to make the concept of "low level" meaningful or concrete.

Also, as a caution against asserting low level means "easy", I will take this opportunity to drop one of Murphy's Laws:

    "An easily understood, workable falsehood is more useful than a complex, incomprehensible truth."

sometimes written as

    "All abstractions are wrong, some abstractions are useful."

As an example of a low level abstraction that is both useful and wrong, consider the libc strtod() function, which converts a decimal string to a native floating point representation. If I were to give you the pre-parsed integer significand and integer exponent, base 10, then you'll find there's no mechanism in the C standard library to convert those two integers to the correct double value, despite strtod() having to do the very same thing, at some point after the parsing stage. If all you ever want to do are string to double conversions then this function will always have appeared quite low level, but the reality is that this is only the case because it's always been so damned useful.

Low level things are intrinsically useful and the more useful something is the less wrong it seems.

I suppose if you just want to program because you like to program, then this article makes sense. If you want to program because you want to make stuff non-programmers can use, then you are more interested in productivity and distributability and are likely to choose higher level languages like JavaScript.

I've been thinking about this a bit lately. I'm not a low-level developer in the slightest, but the question I've been pondering is, when you get the low-level stuff, is it a lot more focused on simple I/O? The complexity (as I understand it) comes from understanding the register, address, hexadecimal stuff (which I don't really understand).

If I understand correctly, the OP is basically saying the same thing. The complexity in the higher-levels comes in when we try to create an API further up the stack which is responsible for manipulating the more understandable data into something that the device understands at a low level. The difference in retrieving a file stream vs getting the file in standard utf-8 format, which anybody can read.

What are your thoughts on this. Have I got it right? Or am I on the right track?

The conundrum is that the high-level customer-facing stuff wouldn't be possible without the low-level behind-the-scenes work that was done on protocols and kernels.

If you look at the author's actual arguments you realize most of them rely on other people. I don't know about others, but I include many more bugs in my code when I write low level code as opposed to high level code. Having to deal with the chance that someone else included a bug below me, I think, is worth it if I don't have to worry about anywhere near as many bugs in my code.

IIRC pg has an essay about this.

I'm sure making the assembly instruction set was not an easy task. The instructions are small, but the simplicity and the beauty of keeping it simple is in itself a great accomplishment.

How floating points are represented in computers is such a neat hack, yet it can be done with a simple formula on pen and paper.

Doesn't mean you can come up with.

Everyone knows E= mc^2. It's easy, But you didn't come up with it.

As a young web engineer who have had the pleasure of dealing with what seems like 30 different versions of RSS-feeds, which also appear to be evolving in random directions like living things, I can confirm this. (I've also messed around in C, and even Assembly at one point.)

The higher you go, more abstractions, more specs, standards and frameworks. Its actually more complex, but once you understand "all" of it is not that hard. Lower level is easier to get started but the more complex problem the more difficult to solve.

Please add 2008 to the title. Halfway through I realised I had already read this a few years back.

This is overly simplistic. Sure, low level programming can be easy if you understand the basics of what you are doing, and the same is true for high level programming.

However, there are aspects of low level programming which are far more technical than anything you are likely to run into programming UI's or the like. Thread scheduling, OS development, compiler development, standard library stuff, etc. tend to be quite challenging from a technical perspective (I've done all but one of them.)

The author is picking one type of low level development and painting the rest with the same brush. Low level development occurs on more complicated architectures as well.

Of course, high level development can be challenging as well, but often in a different way. The challenge here lies in understanding the quirks of your libraries, creating a good user experience (terribly hard at times, but not often technically challenging), working around oddities of your platform, etc.

>And it sucks when you change a variable and then the other processor decides to write back its outdated cache line, overwriting your update.

Well... that's why you use memory fences (volatile if your language supports it) even for writes on types which would be atomic.