Carson N. Baker

Recently I came across an academic reference to Cliffard Pickover’s biomorphs, a generative fractal-like art that resembles cell structures. Outside of Richard Dawkins’ famous evolutionary invention of the same name, which is similar in purpose but different in design, I had never heard of Pickover’s work. Sadly I couldn’t find the original article for free. [Biomorphs: Computer displays of biological forms generated from mathematical feedback loops]

I did, however, find a good overview of the subject by Mad Teddy. [Explore his website to discover why he is, in fact, quite mad.]

Ten minutes later I generated my own biomorph:

Download the source code as an Xcode project (Mac only, 51 KB). Possible improvements, including animations, to follow.

These are a handful of the books I’ve enjoyed recently about finance. The summaries are brief because countless others have done the job for me, but from here I’ll be moving onto more niche topics in energy markets and sustainable growth and hopefully I can write about those issues with some real depth.

I want to highlight this particular link, “Top Ten of Programming Advice NOT to follow” [sic]. Except for #10 (throw exceptions), every one of these suggestions flies in the face of what programmers are traditionally taught. The general complaint that the author makes (suggestion #1) is that design is overrated. Start coding instead! I completely agree, with only a few provisions. Take time to think about what’s going on, but don’t waste valuable time creating formalisms.

Unless you’re working for NASA, you probably don’t have to prove your invariants—so stop pretending. If you understand the problem you’re approaching, and you’re competent enough, you’ll quickly figure out a reasonable way to get there. Even if you make mistakes along the way, who wants to bet it’s easier to correct them after the fact, when everything is set out plain and clear than it is to try to nail the solution the first time around. Think about the tradeoff you make everytime you draw a UML diagram. Is your careful planning really saving development time? No, you’re massaging yourself into delusion—your model isn’t robust; you’ve ignored the implementation details; and now you have to manage another component of the system.

Let’s think about the evolution of software design over the past decade and try to draw out a few points. In the beginning there was assembly, of which the function call pattern was a design issue. C made it obsolete—you had to use it. Then the theorists spent their time lecturing on the OO paradigm, writing books, and generally coercing the masses into its adoption. C++ obsoleted that. Since then, further refinements in the way we program have transpired, giving rise to Java, C#, and agile techniques.So at least for the moment, the issue of design has been resolved. Given the hardware we currently use it seems unlikely that there will be any new paradigm shifts. Oh no. What are the authors, the theorists, the managers to do?

Here’s a challenge: find all the software design books of the past few years and look up the author’s biographies. How many still regularly program? It should be surprising, except when you realize that there’s a lot more money in consulting than in actual programming. I’d say most of the “top ten” advice you get when you read about software engineering should be taken about as seriously as your horoscope.

Yet although they’re obnoxious, I don’t see the designarati as the reason people fall into the pit. To me software development is an art. It requires practice and learning by example, also by doing. And it’s a subjective thing; what works for you may not work for someone else. The important thing is think a little about what makes sense and then get to work. You can’t preemptively design your way to a solution. It’s a premature optimization of the very worst temptation.

If you’re new to this weblog, you may have been redirected here from a stale link of many years ago. You see, over the past decade or so I’ve leisurely toyed around on the web, maintaining various websites, and experimenting with various ideas. This post marks the culmination of my effort to consolidate my online self into one location. Of the old domains that I still own, I have now redirected them here.

The result is that I see a not insignificant amount of traffic to this website. This is great; having a website that many people visit challenges me to create interesting things. (Whether or not anyone cares about it is another matter.) My challenge now is to think of the genre that I want to write about, and the types of things people will read. Those who stumble upon this page are almost certainly of the techno-culture crowd, so my immediate vector is in that direction.

What I will not do is relate personal stories, comment on memes, or throw my voice into any discussion that is already too big. My intent is to make this weblog worthwhile to everyone who reads it—not just for friends or family, and not just for those who care only about something specific or obscure.

I’ve never really had a personal weblog before, so I guess we’ll see how it goes. Hopefully the fresh redesign and transition to Wordpress will be a catalyst to keep me on top of things. In summary, my rules:

• Stay fresh.
• No journaling, no meming.
• Be original. Be useful.

Many thanks to those that visit.

For the past six months or so, I’ve been learning the ins and outs of the PIC. It’s a small microprocessor that runs at 4 MIPS. One of the setbacks I’ve had to deal with is the lack of development tools for Mac OS X.

There are many packages for PC, some of them free, many of them commercial. The commercial variety can cost anywhere from $100 - $5000 dollars, depending on how gullible you are. I used the free and trial versions of MPLAB, the IDE that Microchip distributes, in conjunction with HiTech’s PICC Lite.

I began by installing the software that came with my PicKit into Virtual PC and working with the IDE there. As anyone who has actually tried using Virtual PC for any serious work will tell you, it’s very frustrating. I had to jump through a bunch of hoops and set up a few hacks to let me even compile what I needed. Then I would transfer the binary to Mac OS X and use usb_pickit to get the binary into the hardware. It was a slow, tedious process but it worked—which is important.

The second thing I tried was assembly. GNUPic has a package that contains an assembler, disassembler, profiler, and an interesting high-level language called gpal. Unfortunately, various parts of this collection only work with certain PIC models. I learned the asm codes from the datasheet (it wasn’t too hard) and proceeded to write code. I soon learned that complex math should not be attempted in asm. Flow-control was easy enough but beyond simple addition and subtraction, anything like sin(1.5) / 5.3 + 9^3 is heavily obfuscated. Yet this too worked.

GPAL, it seems, is not ready for prime-time. There is very little example code and sparse documentation. If I have some time though, I’ll plow on and see if I can figure things out and perhaps build a repository of code that others can use.

The things that didn’t work? Take a look. Half of these links are dead or broken and the other half lead to incomplete projects. SDCC looks to be the most promising. This isn’t saying much, and I only think that it’s being updated semi-regularly.

Lessons learned? Try Atmel and AVR-GCC. Also, some serious thought should be given to the idea that ANSI C probably isn’t the best language from which to compile code for a MCU that can’t do recursion or even floating-point arithmetic.

Perhaps this is obvious to most, but I thought I’d share my trick with C++ enums. Consider:

enum Face {ACE=1, TWO, THREE, ... , QUEEN, KING};

If you want to step through this datatype you can’t just do:

Face f; f++;

No, you must do some kind of conditional checking or integer-to-enum casting which becomes unsightly and difficult. Instead, simply overload the ++ operator for the enum type:

Face& operator++(Face& f, int) { // int denotes postfix++
    if (f == KING) return f = ACE; //rollover
    int temp = f;
    return f = static_cast<face> (++temp);
}

Now f++ works properly and you can enumerate away.