What I Have Learned

Journal Sloppy's Journal: What I Have Learned 6

Journal by Sloppy on Monday January 10, 2005 @02:27AM

I'm a little slow. I finally figured out something that I should have picked up, decades ago. Most programming isn't programming at all. It's all about learning interfaces. Interfaces that are here today, gone tomorrow.

I started C programming in 1986, but guess what: I still can't tell you, off the top of my head, what the order of the parameters to open() is! I guess there's a filename and a mode in there, and maybe something else. I don't remember. I always have a reference handy, even for something I've probably typed a thousand times. Someday, at a job interview, someone is going to ask me to write a trivial program, and I'm not going to know on-the-spot how to open a file! Yog-Sothoth help me if I have to remember all the rules in scanf()'s formatting string.

But nowdays, no one would ask for that, probably. The interface du jour would be something else. And I wouldn't even get the interview, because I don't have J2EE on my resume. ;-) Still, I guess the standard C library is something that lasted longer than most things. Maybe I'll get around to memorizing it.

Lately I've been trying to learn to be proficient with wxPython and Twisted. This is a drag. I just try to think about all the neat (and profitable, I hope) stuff I'll be able to whip off, once I have mastered these libraries. I've been using KDE for a few days (I usually run xfce4), and I think the whole "kioslaves" thing might be pretty neat to work with. Maybe I'll learn that too.

At work, I used to be the "talk to the OS" guy. My boss wanted to know how to do something, and didn't know how. Not because he lacked programming skill, but just because it was something beyond the scope of an app programmer. He'd want to take advantage of some service that MS Windows offers, and he'd hand it to me. I'd research around a bit, eventually find what part of the API handled it, then maybe translate someone's C example into the proprietary language we used (don't get me started on that subject), then write him a little function or something that let him do it, maybe give him a little sample code. My job was done. I'm talking about really simple stuff, functions in user32.dll. It was really the same 15 years earlier, when the API was MS DOS instead of Windows. I was the only guy at the company who ever bothered to learn all that "int 21h" stuff, or who thought reference books that listed all this stuff, was worth looking at.

One of the reasons I enjoyed programming on the Palm platform, is that the API gave me a feeling of nostalgia. It reminds me of some of the ideas I used to get, whenever memory started getting tight.

I was always the interface guy. Say we needed to generate a file that would get sent to some banking company, or claims processing company. I was the guy who read their specs and wrote the code that wrote (or read) the appropriate file. Data conversions from a competitor's product's data files to ours? Yep, that always came to me, too. I've RE'd more file formats than I care to think about.

Even earlier, back in high school (shit, this is even a couple years before high school; I'm talking like 1981-1982 here), the "cool" hackers were the ones who mastered interfaces, not programming. The machine was a PDP-11 and the OS was RSTS/E, and most everyone programmed in BASIC. At some point in a budding hacker's career, they would find the big ring-bound books that showed all the syscalls available in the BASIC runtime system, and suddenly they could write lots of programs that they used to not be able to. But the BASIC runtime system used up a lot of memory, so you could only write a program where the combined code+data size was up to 16 Kwords. Or you could write programs in Pascal, which were linked to the much smaller RT11 runtime system, and you had a whopping 28 Kwords to use (and it was a little-known fact (i.e. I was probably the only one who knew it) that the Pascal programs could be linked to use overlays!), so you could write bigger programs. But there wasn't any way to access all the syscalls (at least the "normal" way) in a Pascal program, so people were limited. Severely limited -- people didn't even know how to poll the keyboard like you would need to in a video game; they could only do standard Pascal whole-line-at-a-time I/O.

One day I found some obscure little PDP11 handbook that showed the RT11 API, examples all being in PDP11 assembly language. So I just wrote a little library that used all this stuff, to make it so that Pascal programmers could link it into their programs and do the same stuff that the BASIC programmers could do. And that made me the famous star of the computer room that week, even though I hardly wrote any code at all. Each function was just a few assembly instructions, one of them being .. heck I think it was called EMT (for Emulator Trap or something like that -- basically just a software interrupt). It wasn't programming; it was translation. But you had to be a programmer to do it, and no one else at the site had done it, or even known it could be done.

It's fun at first, I guess, but it gets old. Now I'm trying to make sense out of Twisted. I could write my own dealing-with-sockets code I guess, but that's "bad" and unproductive. You're not supposed to re-invent the wheel. Indeed, code-reuse and building up higher and higher levels of abstraction is an ideal that programmers are supposed to aspire to. This is how the real productivity gains happen, right?

But it means you're always researching. Always learning how to interface. Always reading someone else's code or documentation, hardly ever spending much time writing your own.

I think I'm getting tired of it. When I was a teenager 20 years ago, I was already a pretty good programmer, and I thought that all I had ahead of me, was learning to be an even better programmer. I had no idea that what I really would have to do, was to keep learning new interfaces all the time. New OS APIs. New libraries, new reusable components. And the need to keep learning will never stop, because no matter what you do, you'll find that someone else already did it, and you were supposed to inherit their object -- after spending a few hours making sure you understood how it worked.

And unlike programming knowledge, interface knowledge becomes obsolete. Do you think it does me any good to know RSTS/E or MSDOS trivia? Does knowing that the Amiga's Exec library can always be found through memory location 4, really benefit me these days? Or what happens if you load a character into the accumulator and then JSR $FFD2 on a C64 or VIC20? Ten years from now, will I need to know how Twisted works? Everything I ever learned about programming still applies to this day, but interface knowledge is tomorrow's garbage. And it doesn't really do you any good to notice this, and then decide you're not going to take it anymore. Keeping up to date, and resigning yourself that you will always have to keep learning new ephemeral interfaces, is what being a programmer is all about. Either you do it, or you slip behind.

Yes, I'm tired of it.

The last really fun project I worked on, was in the early 90s. An amateur project, of course. I was playing around with graphics. I wrote a homebrew ray-tracing program that ran, distributed, on the company's networked computers at night. (The 486s were so much faster than the 386s -- wow, floating point in hardware! What will they think of next?!) Except for some vector math functions that I stole from someone else's ray tracer, there wasn't any code reuse at all. Except for just a tiny little I/O, there wasn't any OS interfacing either. Almost pure compute-bound. That was GOOD! I was actually programming -- spending time in my editor, typing code -- instead of researching how to call someone else's functions. And then I wrote my own damn code that took the 24-bit output from the raytracer, selected a 256-color palette, and F-S dithered it down to something a VGA display could show. No Photoshop for me!!

Was that project a colossal waste of my time? Yes, if you look at it from a productivity viewpoint. I shouldn't have written a raytracer at all. I should have used povray (I think it was around at the time?) and some canned thingie (there's gotta be hundreds of them) to convert true color images to palette images. But I sure had fun.

I can't have fun anymore, though, because I know I shouldn't do anything so "foolish." And even if I were to decide, "Oh hell, let's be a fool! Dance the night away, on my keyboard!" I wouldn't be able to kid myself that I was exploring a new frontier, as opposed to wasting the few remaining seconds of my life.

There's still stuff to work on, of course. But I can't think of anything, that doesn't somehow involve building on someone else's work, and harnessing the power of stacking components upon components. So I have to keep learning about those damn components. So I have to figure out the damned Twisted documentation. And yet.. I'm not having fun. And if I'm not going to have fun, then there's no reason to start the project at all.

Why learn Twisted? I'd rather go to a bar and drink beer and listen to heavy metal. Maybe even get laid. I'm driving to Denver next weekend for the Deep Freeze fest. Gonna see Jag Panzer and Flotsam and Jetsam, and some relatively obscure Colorado bands. I'm staying at a hotel within walking distance of the bar, so that the usual drinking constraints don't apply. Fuck Twisted's twisted framework! Then I remember: learning Twisted is one of the ways I'm going to get money, for future gasoline, beer, and cover charges.

It's a means now, not an end. It used to be an end; I was a hacker. It's not an end anymore, and that says something that I can't bear to type.

I should have been a pair of ragged claws, scuttling across the floors of silent seas. Then nobody would care if I knew J2EE or not.

This discussion was created by Sloppy (14984) for no Foes, but now has been archived. No new comments can be posted.