Leaky Abstraction and Lord Palmerston
What I have been gathering from these two articles is that Joel believes that abstraction doesn't solve the problems that it should and has consequently made programming more difficult than easier. But is that the fault of abstraction through API or is that a problem with using those things as crutches and not making good algorithms. For example, one of my personal objectives in any algorithm is to try and avoid nested looping and recursive looping (there are always exceptions). I don't see how I can't do anything I want within a programming paradigm (ie .NET, VB, ASP) using good algorithms and APIs. And at the end of the day I have fast, efficient code that is easy to read (because of API calls). It is true that I could improve the really speed-critical stuff using some C++ and Assembly, but do I need it? Maybe if was programming a video game. What about servers? This is a good one. I been involved in many server projects, and I must say that the issue that comes up time and time again is concurrency and performance. The only language I know of that does concurrency really well is Micro C++, but no one uses it. Other than that, most of the other tools (excluding VB) can handle concurrency in an equivalent way. So that leaves us with performance again. Which brings me back to good algorithms. How much faster is a hand-coded QuickSort in C++ than an API call? There really shouldn't be a difference. So how do I squeeze good performance out of my server? Do complexity checks on your algorithms, I bet if you get rid of some of those loops, your performance issue will start to go away. Yeah you could get right to the nitty-gritty and wring out a little more performance using C++ and Assembly. But what does that buy you? It takes a long time to code in those low-level languages due to the extra lines of coding and figuring out how to re-invent the wheel takes a while. Further, only a handfull of people will be able to read your code. So what am I saying in this extremely long-winded thread? Don't use APIs as a crutch. People try to fit square pegs into round holes. If the API doesn't fit, don't force it too. You will muck up performance and readability. Reverse engineer that API to meet your needs and try to stick to base types of the language you are using, and you will probably end up with some solid perf numbers. I am glad there aren't many flamers on these discussion threads. :)
"don't start a new project without at least one architect with several years of solid experience in the language, classes, APIs, and platforms you're building on. "
I would suggest that, if portions of your APIs and platforms aren't even a full year old, or if the only people with experience are the folks who wrote it, that's a case not covered by Joel's argument. Joel's talking about building large apps with well-known tools.
Brent P. Newhall
"Which begs the question of what to do if portions of your APIs and platforms aren't even a full year old, or if the only people with experience are the folks who wrote it."
I second b. "Don't do that, then".
Fog Creek Home