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 to 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 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.
Recently I mentioned that mathematician John Conway died last April. To his eternal disgruntlement, he is most famous for his “game” of Life — something he considered trivial and inferior to his real mathematical work. That fame is largely due to a Martin Gardener column in Scientific American — the most popular column the magazine had published up to then.
I said I wasn’t going to write about Life because it’s such a well-covered topic, but I thought I might whip up an implementation in Conway’s honor. (Went there; did that; videos below.) Getting into it made me realize Life connects back to my virtual reality posts.
So it turns out I am going to write about it (a little).
Last time I left off with a virtual ball moving towards a virtual wall after touching on the basics of how we determine if and when the mathematical ball virtually hits the mathematical wall. It amounts to detecting when one geometric shape overlaps another geometric shape.
In the physical world, objects simply can’t overlap due to physics — electromagnetic forces prevent it. An object’s solidity is “baked in” to its basic nature. In contrast, in the virtual world, the very idea of overlap has no meaning… unless we define one.
This time I want to drill down on exactly how we do that.
Last time we saw that, while we can describe a maze abstractly in terms of its network of paths, we can implement a more causal (that is: physical) approach by simulating its walls. In particular, this allows us to preserve its basic physical shape, which can be of value in game or art contexts.
This time I want to talk more about virtual walls as causal objects in a maze (or any) simulation. Walls are a basic physical object (as well as a basic metaphysical concept), so naturally they are equally foundational in the abstract and virtual worlds.
And ironically, “Something there is that doesn’t love a wall.”
First I discussed five physical causal systems. Next I considered numeric representations of those systems. Then I began to explore the idea of virtual causality, and now I’ll continue that in the context of virtual mazes (such as we might find in a computer game).
I think mazes make a simple enough example that I should be able to get very specific about how a virtual system implements causality.
With mazes, it’s about walls and paths, but mostly about paths.
This is the third of a series of posts about causal systems. In the first post I introduced five physical systems (personal communication, sound recording, light circuit, car engine, digital computer). In the second post I considered numerical representations of those systems — that is, implementing them as computer programs.
Now I’d like to explore further how we represent causality in numeric systems. I’ll return to the five numeric systems and end with a much simpler system I’ll examine in detail next time.
Simply put: How is physical causality implemented in virtual systems?