Just give me a simple CPU and some I/O ports

Just give me a simple CPU and some I/O ports
jgc.org

It seems that the art of programming - or at least, the practice of it, equivalent to "proficiency" or "competency" - has shifted from fundamentals of the machine and the language's intrinsic semantics, which allowed you to actually create something anew, to spending 90-95% of the time trying to figure out someone else's API. In other words, the real skill now is reading reference material, and trying to figure out how to fashion a bunch of opaque, prebuilt Lego blocks together.

It's just no fun that way, and it relies on very different mental faculties than the ones present in fundamentals-based programming. Writing low-level backend processes in C may have taken a lot more work for boilerplate and nontrivial data primitive/data structure support, but it was real creation - using the actual power of the language to get something done. Now it's all about figuring out how the SynchronousIOGoatSoapBubbleVectorManagerFactory interacts with the SynchronousIOGoatSoapBubbleVectorReflectorParserTransformer.

EX: A new 8 bit CPU from 2008: The triple clock enables the selection of the most suitable clock frequency from 32.768 kHz, 500 kHz, and 4 MHz according to the processing type, thus minimizing the operating current. These power-management functions help prolong battery life and reduce product size. ... RAM 2 KB (http://www.okisemi.com/en/866/869/000576.html) And yes some people are really working on an 8 bit cpu at less than 40khz due to power limitations.

API design is hard. It's like composing poetry, or trying to design the game of chess. ("I know, the queen should be able to jump like a knight if she's on a white square!") It is bound to take thousands of little trials and errors in order to get things right. And my suspicion is that certain languages and platforms make it especially difficult to tinker with existing APIs, or wrap them while minimizing the leaks, or replace one part of them and leave the others alone, or build them in a way that makes it easy to compose complex higher-order objects and behaviors out of little pieces. When working with those systems, the most efficient way to solve any given problem is to just slog through, trying to make lemonade out of slightly-spoiled lemons by hand-sorting and hand-squeezing each lemon. And that can be effective -- at least it's more efficient than trying to use genetic engineering to construct a lemon out of raw amino acids -- but it's not always fun.

There are high-level APIs that are a joy to use. I love jQuery, for example, which is a layer of Javascript atop more Javascript atop an absolutely scary C program atop Unix or Windows and yet somehow manages to feel lightweight and elegant and composeable. But for every elegant API there are dozens of clunky ones.

The lovely thing about low-level C or assembly is that the building blocks tend to be simple, understandable, and composeable -- and, if they aren't, it's not so much work to rewrite them. (Though, as jgc points out, in modern times even assembly is hardly immune to complexity. The idiosyncrasies of modern processor architectures are so baroque that it takes years for optimizing compilers to be refined to take advantage of them.)