Hacker News Reader

Comment by jmathai | Hacker News Reader

Joel Spolsky, Things You Should Never Do, Part I

http://www.joelonsoftware.com/articles/fog0000000069.html

  Back to that two page function. Yes, I know, it's just a 
  simple function to display a window, but it has grown 
  little hairs and stuff on it and nobody knows why. Well, 
  I'll tell you why: those are bug fixes. One of them fixes 
  that bug that Nancy had when she tried to install the 
  thing on a computer that didn't have Internet Explorer. 
  Another one fixes that bug that occurs in low memory 
  conditions. Another one fixes that bug that occurred when 
  the file is on a floppy disk and the user yanks out the 
  disk in the middle. That LoadLibrary call is ugly but it 
  makes the code work on old versions of Windows 95.

View on HN

The right way to resolve such bugs is to have abstraction layers that hide these awful hairiness.

If hair regarding low-memory conditions, Internet Explorer and other things all appears in the same function, some abstractions are definitely missing.

Also, if the reason for these things isn't clear, that's what comments are for.

Rewriting code, from my experience, has had only great results.

Rewriting can be great as long as you take all the things Joel notes into account and decide it is still the right decision for your project.

This is so absolutely true. What nobody recognizes is that most of these really fundamental systems we run on - unix system calls, our window managers, our shells, etc - were designed and implemented in an era where the supercomputers couldn't dent your Nexus 5 in terms of most computing performance metrics.

They didn't have the luxury of having an API that might be a few thousand KB big loaded into memory to act as a single redirection to your underlying implementation. They worked in the confines of bytes of memory, not gigabytes.

We can afford to be generic, to make extensible runtime programmable interfaces and runtime evaluation type dynamism, because we have the performance necessary. But our core APIs are still written like its 1980.

My only concern is that over the years I've seen everything go in cycles. So maybe 8mb is not a lot of RAM for a computer nowdays. A few years ago it was a lot for a router. I like my OpenWRT router that runs Linux. Before that the same could be said for mobile computers with GSM modules (cellphones).

I'd like to think that Linux will continue to run on machines with at most 4mb of RAM with not much processing capacity because if history keeps repeating itself we're going to keep on inventing new devices with those constraints.

However, this line of reasoning also leads to slow web applications that make a high-powered workstation feel like a slow 386 from 15 years ago.

But our core APIs are still written like its 1980.

Exactly what level of abstraction is good for the "core APIs"? Something actually has to send a series of bytes to be written to the disk, even if a bunch of serialization and encoding abstractions are written on top of that. If the latter is the "core", what's the less abstract stuff that inside that?

Then you end up with "abstraction layer" like autoconf, and the "cure" is MUCH worse than the disease.

autoconf is operating within difficult constraints (only /bin/sh and make are assumed to be installed), and uses shell scripts that write shell scripts that write shell scripts.

A) autoconf is not similar at all to an API layer hiding hairiness in its domain

B) autoconf becoming terrible does not mean that portability abstractions are necessarily terrible

Reply on news.ycombinator.com