As I posted Tuesday, I finished the software for my virtual CPU on Monday, but now I’ve finished the most important part: the project graphic.
Now that I’m done, the project is obsolete, and it’s time to start the next version, cj68 vII. The other protocol would be to bump the number, but cj69 might lead to smirks.
Stay processing, my friends! Go forth and spread beauty and light.
∇
Long distance runners talk about “hitting the wall” — the point where their body runs out of resources, making it almost impossible to continue. I hit an intellectual wall late Monday night. Fortunately, I not only finished the race but went an unexpected extra mile. (And now my brain circuits are fried.)
Not an actual race (beyond a vague self-imposed deadline), but a hobby project like one of those ships in a bottle. A painstaking and challenging task in the name of fun and exercise of acquired skill. But no race, no ship, no bottle. This was a software project.
My inner geek rampant, I built a virtual 32-bit CPU (in Python).
This is part five of a series celebrating the passing of BOOL, the “ship in a bottle” computer language I’ve been tinkering with for three decades. It’s a design dream, and I’ve decided to wake up.
Last time I talked about how BOOL handles data and why that was such an issue. This time I’ll ramble on about some of the other snarls that ultimately made things more complicated than I wanted. Simplicity and elegance were key design goals. I intended the run-time environment, especially, to be utterly straightforward.
Unfortunately, the behavioral design goals — the way BOOL should act at run-time — ended up in direct conflict with that.
This is part four of a series commemorating BOOL, a computer language I started designing somewhere around 1990. After 30 years of sporadic progress, I finally gave up. There were so many contradictions and (for lack of a better word) “epicycles” in the design goals that it just wasn’t viable.
So, I’m mourning the passing of an idea that’s shared my headspace for three decades. Previously I’ve introduced BOOL and provided a tour of its basic aspects. Now I have to start talking about why it failed.
It has a lot to do with data, but that wasn’t the only issue.
This is part three of a series mourning the death of a computer language I birthed around 1990. Now it’s turning 30, and I’ve decided it’s too old for this sort of thing. I’ve retired and now I’m retiring it (in the “sleeps with fishes” permanent retirement sense). These posts are part of a retirement party. BOOL might not be here to celebrate, but I’ll raise glasses in its honor.
First I introduced BOOL, a deliberate grotesquery, an exercise in “and now for something completely different!” Then I illustrated basic procedural programming in BOOL. This time I’ll get into the object-oriented side.
This aspect of BOOL is one of several that changed repeatedly over the years.
This is part two of a series commemorating a computer language I started designing somewhere around 1990. After 30 years of tinkering, I’ve finally accepted that it’s just not meant to be, and I’m letting it go. These posts are part of that letting go process.
Last time I introduced BOOL, said a bit about what motivated it, and started laying out what made it a language only a parent could love. Later I’ll explain why things didn’t work out, but for now I’d like to tell you about what BOOL was supposed to be:
A glorious deliberate useless Frankenstein’s Monster (insert mad laughter).
Somewhere around 1990 I started designing a programming language I named BOOL (Beginner’s Object-Oriented Language). It was always a personal “ship in a bottle” project — something more for aesthetic expression than utility. Like that guy constantly working on an old car in his garage, I’ve dabbled with it ever since.
I’ve decided to, at long last, take BOOL off life support and let it die (another dead dream). But enough of dreams. I’m tired of the weight of dreams; time to shed a pointless burden. I’ve carried it for 30 years, and I think it’s time to chalk this one up to experience.
So this is a eulogy and a memorial.
I don’t know if it’s having been in the saddle so long, having all this retirement time, or the magic of Python (perhaps all three), but I’ve made major advances in personal projects that have been on my drawing board for a very long time. One of them, in fact, goes back to my earliest days of programming in late 70s!
It’s certainly true that 35 years of writing computer software teaches you a few tricks. At the very least, you learn all sorts of things not to do! On some level, the computer language doesn’t matter, but a highly expressive language makes some kinds of development not just easier, but actually fun!
And Python! I haven’t laughed with delight over a computer language since Lisp!
If nothing else (and I think there is plenty of else), I can look back on all those years of writing code and pick out the main themes and principles, the things that seemed to matter most.
That’s what this CS101 series is about: things I think matter most when it comes to designing software.
Lately I’ve been looking into fours, doing things in fours. With that in mind, here’s Four Primary Principles for Programmer:
Clarity is the #1 priority when writing code. Clarity trumps everything else; it’s even more important than the code being correct! One of the biggest wins a serious programmer can offer is writing clear, readable code.
Source code is for the human reader; it’s not written like that for the computer. If it were up to the computer, humans would use the same ones and zeros it does. It would be much more efficient that way.
But we (inefficient) humans need ways to write and talk about computer programs.
Posts pertaining to programming!
Logos con carne 