4 ms·

I know where you're coming from, but I wonder if this observation is just a classic language rant waiting to be born. In other words: I wonder if the problem is

I know where you're coming from, but I wonder if this observation is just a classic language rant waiting to be born. In other words: I wonder if the problem is not that all higher-level APIs necessarily suck, but that the ones you have suck, and your language platform is too impoverished to profitably work around that. 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.)

jacquesm 17y ago
jquery is a good example to use, I've only been into it for a couple of days now (after asking on HN what would be a good js library), and after a few days I already like what it does: It hides the mess! Most software is so absolutely messy. Just the other day there was an argument that it is perfectly ok to see the user interface that results from interpreting a spec'd document as an approximation. Computers are supposed to be deterministic, you're supposed to get exactly the results you want and not something 'good enough for government work'. Elegance breeds excellence, bloat breeds badness. Cellphones that crash (who would have ever accepted that), computers that need to be periodically reinstalled and APIs that have manuals 10 times the size of the operating system components they interface to. Complexity is a given, so, then we should strive to make the complex simple, instead of more complex.
abalashov 17y ago
I'm not saying that there aren't real, valid reasons for the state of things today to have evolved in the manner I described. And I completely agree that designing APIs well, and doing object-oriented design hierarchy well in the manner in which it was intended is a formidable problem domain. Never did I mean to imply that it wasn't. And certainly, there is a qualitative, artistic dimension to the way in which one goes about stringing various APIs together, too. Nevertheless, the fact remains that today when I - and many others - program, we're spending 90% of our time putting together the pieces of some reference. Back when I was growing up writing code in C, there wasn't so much of that, aside from the sparse library functions and, of course, system calls. I actually felt like I was writing a lot of code; maybe unnecessary code from a contemporary point of view (lots of linked list containers, hash table implementations, etc.), but definitely code, and I was writing it. There's something in that productive bliss that's gone today, when it's basically a question of figuring out what the javadocs say.

jacquesm 17y ago

jquery is a good example to use, I've only been into it for a couple of days now (after asking on HN what would be a good js library), and after a few days I already like what it does: It hides the mess! Most software is so absolutely messy. Just the other day there was an argument that it is perfectly ok to see the user interface that results from interpreting a spec'd document as an approximation. Computers are supposed to be deterministic, you're supposed to get exactly the results you want and not something 'good enough for government work'. Elegance breeds excellence, bloat breeds badness. Cellphones that crash (who would have ever accepted that), computers that need to be periodically reinstalled and APIs that have manuals 10 times the size of the operating system components they interface to. Complexity is a given, so, then we should strive to make the complex simple, instead of more complex.

abalashov 17y ago

I'm not saying that there aren't real, valid reasons for the state of things today to have evolved in the manner I described. And I completely agree that designing APIs well, and doing object-oriented design hierarchy well in the manner in which it was intended is a formidable problem domain. Never did I mean to imply that it wasn't. And certainly, there is a qualitative, artistic dimension to the way in which one goes about stringing various APIs together, too. Nevertheless, the fact remains that today when I - and many others - program, we're spending 90% of our time putting together the pieces of some reference. Back when I was growing up writing code in C, there wasn't so much of that, aside from the sparse library functions and, of course, system calls. I actually felt like I was writing a lot of code; maybe unnecessary code from a contemporary point of view (lots of linked list containers, hash table implementations, etc.), but definitely code, and I was writing it. There's something in that productive bliss that's gone today, when it's basically a question of figuring out what the javadocs say.