HyperCard, Visual Basic, Real Basic, and Me

When the Mac first appeared it was a revelation. A computer with a powerful, consistent user-interface (with undo!) that allowed users to figure out most programs without ever reading a manual.

I can remember back in 1984 sitting outside the Hayden-Allen Tank (a cylindrical lecture theater on the ANU campus that tended to house the largest humanities classes and many featured speakers) playing with a Mac on display while Apple reps inside introduced the Mac to a packed house. (My friends and I figured we’d rather spend time with the computer than watch a pitch.)

How did undo work? It wasn’t immediately obvious.

When we quit an application or closed a document, how did the program know we had unsaved changes? We checked, if the document had no changes, or the changes were saved, the computer knew.

We were hardcore math and CS geeks but computers had never, in our experience, done these kinds of things before so it took us a while to reverse-engineer what was going on. It was very, fucking, impressive.

But it was also really hard to do with the tools of the time. Initially, you couldn’t write real Mac software on a Mac. At best, there was MacPascal, which couldn’t use the toolbox and couldn’t build standalone applications, and QuickBasic, which provided no GUI for creating a GUI, and produced really clunky results.

To write Mac programs you needed a Lisa, later a Mac XL (same hardware, different software). It took over a year for the Mac SDK to appear (via pirate copies), and it was an assembler that spanned multiple disks. Eventually we got Consulair-C and Inside Macintosh but, to give you an idea, the equivalent of “hello world” was a couple of pages of C or Pascal most of which was incomprehensible boilerplate. The entire toolbox relied heavily on function pointers, really an assembly-language concept, and in some cases programmers had to manually save register state.

No-one’s to blame for this — Xerox provided much cleaner APIs for its much more mature (but less capable) GUI and far better tooling — the cost was a computer that ran dog slow, no-one could afford, and which actually was functionally far inferior to the Mac.

The first really good tool for creating GUI programs was HyperCard. I can remember being dragged away from a computer lab at ADFA (where a friend was teaching a course on C) which had been stocked with new Mac SEs running HyperCard.

For all its many flaws and limitations, HyperCard was easy to use, fast, stable, and forgiving (it was almost impossible to lose your work or data, and it rarely crashed in an era when everything crashed all the time). Its programming language introduced a yet-to-be-equalled combination of being easy to read, easy to write, and easy to debug (AppleScript, which followed it, was horribly inferior). When HyperCard 2 brought a really good debugger (but sadly no color) and a plugin architecture, things looked pretty good. But then, as Apple was wont to do in those days, Apple’s attention wandered and HyperCard languished. (Paul Allen’s clone of HyperCard, Toolbook for Windows, was superb but it was a Windows product so I didn’t care.)

Eventually I found myself being forced to learn Visual Basic 3, which, despite its many flaws, was also revolutionary in that it took HyperCard’s ease of use and added the ability to create native look and feel (and native APIs if you knew what you were doing, which I did not). With Visual Basic 3 you could essentially do anything any Windows application could do, only slower. (HyperCard was notably faster than VB, despite both being interpreted languages, owing to early work on JIT compilers.)

After using VB for a year or two, I told my good friend (and a great programmer) Andrew Barry that what the Mac really needed was its own VB. The result was Realbasic (now Xojo) of which I was the first user (and for a long time I ran a website, realgurus.com, that provided the best source of support for Realbasic programmers). Realbasic was far more than a VB for the Mac since it was truly and deeply Object-Oriented and also cross-platform. I could turn an idea into a desktop application with native look and feel (on the Mac at least) in an evening.

When MP3 players started proliferating on Windows, I wrote an MP3 player called QuickMP3 in a couple of hours after a dinner conversation about the lousy state of MP3 players on the Mac. By the next morning I had a product with a website on the market (I distributed it as shareware; registration was $5 through Kagi — RIP — which was the lowest price that made sense at the time, I think Kagi took about $1.50 of each sale, and I had to deal with occasional cash and checks in random currencies).

Over the years, I wrote dozens of useful programs using Realbasic, and a few commercially successful ones (e.g. Media Mover 3,  and RiddleMeThis) and an in-house tool that made hundreds of thousands of dollars (over the course of several years) with a few days’ effort.

Today, I find Xojo (which Realbasic rebranded itself to) to have become bloated, unstable, and expensive, and Xojo has never captured native look and feel in the post-Carbon world on the Mac, and anything that looks OK on Windows looks like crap on the Mac and vice versa, which undercuts its benefits as a cross-platform application. Also, my career has made me an expert on Javascript and web development.

So my weapon of choice these days for desktop development became nwjs and Electron. While web-apps don’t have desktop look and feel (even if you go to extremes with frameworks like Sproutcore or Cappuccino), neither do many desktop apps (including most of Microsoft’s built-in apps in Windows 10). Many successful commercial apps either are web apps (e.g. Slack) or might as well be (e.g. Lightroom).

I mention all of this right now because it closes the loop with my work on bindinator — anything that makes web application development faster and better thus helps desktop application development. I think it also clarifies my design goals with bindinator: I feel that in many ways ease of development peaked with Realbasic, and bindinator is an attempt to recreate that ease of development while adding wrinkles such as automatic binding and literate programming that make life easier and better.

Email & Equality

Since today is inauguration day, my thoughts are turning back to the last eight years and how we came to be inaugurating a Republican president, again, despite the fact that most Americans disagree with the GOP on most matters of substance.

It’s Not About Women

First off, let’s address the claim that Hillary lost because of American sexism.  Yes, Donald Trump is an unreconstructed 1950s male stereotype (i.e. a horrible human being), and many Americans — including many women, latinos, and a surprising number of blacks — chose to overlook this, but this ignores the fact that the GOP has been consistently lowering the bar for whom they will nominate for office, and it always causes outrage on the left, and it never matters.

Ike was a general. Nixon was an alcoholic witch-hunter. Reagan was a stool pigeon and an idiot. Quayle was an even bigger idiot. Palin made Quayle look professorial. Republicans don’t care if the president (or a senator, or a supreme court judge) has brains, or even sound character: they just want tax cuts and they’re pretty sure their guy is more likely to give them than the other person.

In fact, it’s quite surprising to me that the first black president turned out to be a Democrat, and the first female candidate was also a Democrat. It’s actually conservatives who tend to nominate minorities because it lets them ratchet up the crazy elsewhere. (Margaret Thatcher. Clarence Thomas. Heck, Neville Bonner.)

Incidentally, this is also the same reason that things like sexual peccadilloes and shady practices that would utterly destroy a Democrat seem to slide harmlessly off Republicans.

By the way, I should pause here and say that this has nothing to do with parties. When the Democrats were the party of White Supremacy and the Republicans were the party of Management it was the Democrats who were similarly immune to charges of corruption and sexual misconduct. When the Republicans subvert democracy today and argue that it’s something “everyone” does, they invariably point out actions of Dixiecrats — the folks who left the Democratic party after Roosevelt put desegregation into the Democratic Party platform and joined the Republicans.

A Thought Experiment

A very popular experimental template in the social sciences is to take some common process, like applying for a job or testifying in court, and compare how well candidates do if you signal that a participant is male or female, black or white, has a prison record or not, and so forth, find out there’s a different outcome (which I imagine there almost always is given a nearly inexhaustible number of disadvantaged categories of people), publish the results, and inch closer to tenure.

E.g. I heard on Radio Lab, and I have no reason not to believe, that if you apply for a job using a stereotypically black male name (such as “Jamal”) you are much less likely to be called back than if you use a stereotypically white male name (such as “Steve”), even if the white CV adds a criminal record. The white name is equivalent to eight years of experience. (This implies to me that whatever criminal record they invented was pretty minor.)

The same kind of study has shown women to be less credited as expert witnesses, less likely to be promoted, and so forth and so on. There’s no doubt a lot of sexism in our society, but I’m pretty sure women aren’t as far behind men as blacks are behind whites (eight years experience or a prison record…), and Barack Hussein Obama is more than a stereotypically non-white name. His middle name is the same as a guy we went to war with twice, and his surname is one letter away from Public Enemy Number One when he ran for office.

Obama was an exceptional candidate — he didn’t just beat Hillary for the 2008 nomination, he beat Biden (whom most Democrats think would have been a better candidate than Hillary) and Kucinich (who was a better Sanders than Sanders). And then he beat John McCain and Mitt Romney, the best candidates the Republicans have had in my lifetime.

Now, let’s look at Hillary. Imagine for a moment that Hillary Clinton were in fact some random male Democrat you’d vaguely heard of with her exact track record (post First Lady, since it’s hard to imagine a man with Hillary’s baggage from being married to Bill). So, forget Whitewater and Lewinski and just think — New York senator with a typically exceptional Ivy League education and legal background but no great accomplishments or distinction who then served as Secretary of State from 2009-2012. Would you elect him?

What if I remind you that Chelsea Manning released 10M State Department cables in 2010 and that despite this our candidate continued to use outdated and insecure email practices in direct contravention of State Department rules of which, apparently, he remained willfully ignorant throughout. What if I remind you that the 2012 Benghazi attack happened on his watch despite repeated requests for upgraded security. And yes, lots of requests are made, but this was in Libya during the aftermath of a war. As yes, it was a subordinate who turned down the requests, but who hired that subordinate?

Oh, and by the way, what Good Things happened in 2009-2012 that our candidate can point to?

I’m not saying Clinton did anything criminal. I’m saying that in any reasonable political system she would have been held accountable for Benghazi, forced to resign, and her career would have ended. Similarly, the email business reflects three spectacular failures of judgement (first: to ignoring security policies, second: to continue ignoring the security policies after an epic security breach, third: to fail to improve said security policies meaningfully after said epic security breach). Again, had she still been Secretary of State when the email business came out, she should have been fired for it, and that alone would probably have ended her political career.

By the way, I choose give her a free pass on the Iraq war vote, because I think she did it as a political calculation, and it was a reasonable choice at the time. (I’m actually far more critical of the far broader, unthinking support for the invasion of Afghanistan.) But for some of my friends her vote on Iraq, alone, is unforgivable.

Trump’s done a lot of shady and unpleasant things to people over the years — spending other people’s money and saddling them with his debts, stiffing contractors, ogling pageant contestants (for sure), molesting women (most likely), but there’s no positive evidence of Trump’s ignorance or incompetence in his chosen profession. He may well be an ignoramus (and bigot) in the same mold as Henry Ford (who nevertheless was a great businessman and provided many jobs to blacks). Hillary is a professional politician and civil servant who can’t use a smartphone or a computer and has made spectacularly poor judgement calls in her chosen profession. (Kelly Anne Conway points out, in reference to Russian interference in the campaign, that the Russians didn’t make Clinton spend money in Georgia instead of Michigan or Wisconsin.)

Trump is (rightly) decried as intellectually incurious. But how is it OK for Hillary to not learn to use a smartphone, or email, or a computer when both are, or should be, a constant part of her chosen profession? Trump is (rightly) decried for having publicly sort-of supported the invasion of Iraq, but being right about that war wasn’t his job.

Trump’s an asshole and a bigot, but he seems to be good at what he does. Elizabeth Warren is a smart person but she tried to go head-to-head with him on Twitter and failed abysmally. I’m not optimistic about his presidency, but sexism is only responsible for putting Trump in the Whitehouse insofar as it was perversely responsible for Hillary being nominated.

How Do We Stop Doing This?

It’s easy to point out the failings of Hillary’s campaign in retrospect. She nearly won despite all of it. The lack of a clear or coherent message. Poor strategy. The weak VP choice. Lousy slogan (“I’m with her”). This should have been easy: the country is in good shape, it’s in far better shape than it was 4 or 8 years ago. Its signal policy is at least an equivocal success. The outgoing president is popular. What. The. Fuck?

The fact that 2012 was even close (despite Romney being a solid candidate) points to a hard truth: the Democrats fucked up Obamacare. They created a barely functional healthcare plan because they figured it would get bipartisan support even when they didn’t need bipartisan support, and ended up with something that barely worked, couldn’t be explained, couldn’t be sold, and then rolled it out slowly and incompetently. And this led to their being annihilated in the mid-terms, which meant little of consequence could be done for the remaining six years.

Remember how exceptional Obama is? He’s been a pretty good, successful president despite Obamacare, not because of it.

The solution is to think of laws as products that have to be sold. Clearly, legislators understand this superficially, it’s why a law enabling a police state is named the “PATRIOT Act”. It’s why a healthcare law that costs poor people premiums they can’t afford for lousy coverage is called the “Affordable Care Act”. But good products are more than simply clever names (and legislators aren’t even that good at names…). Here’s a hint: if you design a product where the main reason for many people to buy it is that they will be fined if they do not, then you have failed. Design a new product.

Heterogeneous Lists

b8r's demo site uses a heterogeneous list to display source files with embedded documentation, tests, and examples
b8r’s demo site uses a heterogeneous list to display source files with embedded documentation, tests, and examples

One of the things I wanted to implement in bindinator was heterogeneous lists, i.e. lists of things that aren’t all the same. Typically, this is implemented by creating homogeneous lists and then subclassing the list element, even though the individual list elements may have nothing more in common with one another than the fact that, for the moment, they’re in the same list.

This ended up being pretty easy to implement in two different ways.

The first thing I tried was a effectively an empty (as in no markup) “router” component. Instead of binding the list to a superclass component, you bind to a content-free component (code, no content) which figures out which component you really want programmatically (so it can be arbitrarily complex) and inserts one of those over itself. This is a satisfactory option because it handles both simple cases and complex cases quite nicely, and didn’t actually touch the core of bindinator.

Here’s the file-viewer code in its entirety:

<script>
    switch (data.file_type || data.url.split('.').pop()) {
        case 'md':
        case 'markdown':
            b8r.component('components/markdown-viewer').then(viewer => {
                b8r.insertComponent(viewer, component, data);
            });
            break;

        case 'text':
            b8r.component('components/text-viewer').then(viewer => {
                b8r.insertComponent(viewer, component, data);
            });
            break;

        case 'js':
            b8r.component('components/literate-js-viewer').then(viewer => {
                b8r.insertComponent(viewer, component, data);
            });
            break;
    }
</script>

(I should note that this router is not used for a list in the demo site, since the next approach turned out to meet the specific needs for the demo site.)

The example of this approach in the demo code is the file viewer (used to display markdown, source files, and so on). You pass it a file and it figures out what type of file it is from the file type and then picks the appropriate viewer component to display it with. In turn this means that a PNG viewer, say, need have nothing in common with a markdown viewer, or an SVG viewer. Or, to put it another way, we can use a standalone viewer component directly, rather than creating a special list component and mixing-in or subclassing the necessary stuff in.

You’ll note that this case is pretty trivial — we’re making a selection based directly on the file_type property, and I thought it should be necessary to use a component or write any code for such a simple case.

The second approach was that I added a toTarget called component_map that let you pick a component based on the value of a property. This maps onto a common JSON pattern where you have a heterogeneous array of elements, each of which has a common property (such as “type”). In essence, it’s a toTarget that acts like a simple switch statement, complete with allowing a default option.

The example of this in the demo app is the source code viewer which breaks up a source file into a list of different kinds of things (source code snippets, markdown fragments, tests, and demos). These in turn are rendered with appropriate components.

This is what a component_map looks like in action:

<div
  data-list="_component_.parts"
  data-bind="component_map(
    js:js-viewer|
    markdown:markdown-viewer|
    component:fiddle|
    test:test
  )=.type"
>
  <div data-component="loading"></div>
</div>

From my perspective, both of these seem like pretty clean and simple implementations of a common requirement. The only strike against component_map is obviousness, and in particular the quasi-magical difference between binding to _component_.parts vs. .type, which makes me think that while the latter is convenient to type, forcing the programmer to explicitly bind to _instance_.type might be clearer in the long run.

P.S.

Anyone know of a nice way to embed code in blog posts in WordPress? All I can find are tools for embedding hacks in wordpress.

Announcing bindinator.js

Having recently set up bindinator.com, I am “officially” announcing my side-project Bind-O-Matic.js bindinator.js. It’s a small (currently 7kB gzipped and minified) Javascript library that is designed to make developing in vanilla javascript better in every way than using one or more frameworks. It embodies my current ideas about Javascript, Web, and UI development, and programming — for whatever that’s worth.

Also, I’m having a ton of fun hacking on it.

By way of “dogfooding”, I’m simultaneously building a skunkworks version of my main work project (which is an Electron-based desktop application) with it, adapting any code I can over to it, building b8r’s own demo environment, and slowly porting various other components and code snippets to it.

Above is my old galaxy generator, updated with a bunch of SVG goodness, and implemented using b8r (it was originally cobbled together using jQuery).

Why another framework?

I’ve worked with quite a few frameworks over the years, and in the end I like working in “vanilla” js (especially now that modern browsers have made jQuery pretty much unnecessary). Bindinator is intended to provide a minimal set of tools for making vanilla js development more:

  • productive
  • reusable
  • debuggable
  • maintainable
  • scalable

Without ruining the things that make vanilla js development as pleasant as it already is:

  • Leverage debugging tools
  • Leverage browser behavior (e.g. accessibility, semantic HTML)
  • Leverage browser strengths (e.g. let it parse and render HTML)
  • Be mindful of emerging ideas (e.g. semantic DOM, import)
  • Super fast debug cycle (no transpiling etc.) — see “leverage debugging tools”
  • Don’t require the developer to have to deal with different, conflicting models

The last point is actually key: pretty much every framework tries to abstract away the behavior of the browser (which, these days, is actually pretty reasonable) with some idealized behavior that the designer(s) of the framework come up with. The downside is that, like it or not, the browser is still there, so you (a) end up having to unlearn your existing, generally useful knowledge of how the browser works, (b) learn a new — probably worse — model, and then (c) reconcile the two when the abstraction inevitably leaks.

Being Productive

Bindinator is designed to make programmers and designers more (and separately) productive, decouple their activities, and be very easy to pick up.

To make something appear in a browser you need to create markup or maybe SVG. The easiest way to create markup or SVG that looks exactly like what you want is — surprise — to create what you want directly, not write a whole bunch of code that — if it works properly — will create what you want.

Guess what? Writing Javascript to create styled DOM nodes is slower, more error-prone, less exact, probably involves writing in pseudo-languages, adds compilation/transpilation steps, doesn’t leverage something the browser is really good at (parsing and rendering markup), and probably involves adding a mountain of dependencies to your code.

Bindinator lets you take HTML and bind it or turn it into reusable components without translating it into Javascript, some pseudo-language, a templating language, or transpilation. It also follows that a designer can style your markup.

Here’s a button:

<button class="awesome">Click Me</button>

Now it’s bound — asynchronously and by name.

<button class="awesome" data-event="click:reactor.selfDestruct">
  Click Me
</button>

When someone clicks on it, an object registered as “reactor” will have its “selfDestruct” property (presumably a function) called. If the controller object hasn’t been loaded, b8r’s event handler will store the event and replay it when the controller is registered.

Here’s an input:

<inpu type="range">

And now its value is bound to the fuel_rod_position of an object registered as “reactor”:

<input type="range" data-bind="value=reactor.fuel_rod_position">

And maybe we want to allow the user to edit the setting manually as well, so something like this:

<input type="range" data-bind="value=reactor.fuel_rod_position">
<input type="number" data-bind="value=reactor.fuel_rod_position">

…just works.

Suppose later we find ourselves wanting lots of sliders like this, so we want to turn it into a reusable component. We take that markup, and modify it slightly and add some setup to make it behave nicely:

<input type="range" data-bind="value=_component_.value">
<input type="number" data-bind="value=_component_.value">
<script>
 const slider = findOne('[type="range"]');
 slider.setAttribute('min', component.getAttribute('min') || 0);
 slider.setAttribute('max', component.getAttribute('max') || 10);
 register(data || {value: 0});
</script>

This is probably the least self-explanatory step. The script tag of a component executes in a private context where there are some useful local variables:

component is the element into which the component is loaded; find and findOne are syntax sugar for component.querySelector and component.querySelectorAll (converted to a proper array) respectively, and register is syntax sugar for registering the specified object as having the component’s unique id.

And save it as “slider-numeric.component.html”. We can invoke it thus:

<span 
  data-component="slider-numeric"
  data-bind="component(value)=reactor.fuel_rod_position"
></span>

And load it asynchronously thus:

const {component} = require('b8r');
component('slider-numeric');

To understand exactly what goes on under the hood, we can look at the resulting markup in (for example) the Chrome debugger:

Chrome debugger view of a simple b8r component

Some things to note: data-component-id is human-readable and tells you what kind of component it is. The binding mechanism (change and input event handlers) is explicit and self-documented in the DOM, and the binding has become concrete (_component_ has been replaced with the id of that component’s instance). No special debugging tools required.

Code Reuse

Bindinator makes it easy to separate presentation (and presentation logic) from business logic, making each individually reusable with little effort. Components are easily constructed from pieces of markup, making “componentization” much like ordinary refactoring.

A bindinator component looks like this:

<style>
  /* style rules go here */
</style>
<div>
  <!-- markup goes here -->
</div>
<script>
  /* component logic goes here */
</script>

All the parts are optional. E.g. a component need not have any actual

When a component is loaded, the HTML is rendered into DOM nodes, the script is converted into the body of a function, and the style sheet is inserted into the document head. When a component is instanced, the DOM elements are cloned and the factory function is executed in a private context.

Debugging

Bindinator is designed to have an incredibly short debug cycle, to add as little cognitive overhead as possible, and work well with debugging tools.

To put it another way, it’s designed not to slow down the debug cycle you’d have if you weren’t using it. Bindinator requires no transpilation, templating languages, parallel DOM implementations, it’s designed to leverage your existing knowledge of the browser’s behavior rather than subvert and complicate it, and if you inspect or debug code written with bindinator you’ll discover the markup and code you wrote where you expect to. You’ll be able to see what’s going on by looking at the DOM.

Maintenance

If you’re productive, write reusable (and hence DRY) code, and your code is easier to debug, your codebase is likely to be maintainable.

Scale

Bindinator is designed to make code scalable:

Code reuse is easy because views are cleanly separated from business logic.

Code is smaller because bindinator is small, bindinator code is small, and code reuse leads to less code being written, served, and executed.

Bindinator is designed for asynchrony, making optimization processes (like finessing when things are served, when they are loaded, and so forth) easy to employ without worrying about breaking stuff.

Core Concepts

Bindinator’s core concepts are event and data binding (built on the observation that data-binding is really just event-binding, assuming that changes to bound objects generate events) and object registration (named objects with properties accessed by path).

Bindinator provides a bunch of convenient toTargets — DOM properties to which you might want to write a value, in particular value, text, attr, style, class, and so forth. In most cases bindings are self-explanatory, e.g.

data-bind="style(fontFamily)=userPrefs.uiFont"

There are fewer fromTargets (value, text, and checked) which update bound properties based on user changes — for more complex cases you can always bind to methods by name and path.

Components are simply snippets of web content that get inserted the way you’d want and expect them to, with some syntax sugar for allowing each snippet to be bound to a uniquely named instance object.

And, finally, b8r provides a small number of convenience methods (which it needs to do what it does) to make it easier to work with ajax (json, jsonp), the DOM, and events.

The Future

I’m still working on implementing literate programming (allowing the programmer to mix documentation, examples, and tests into source code), providing b8r-specific lint tools, building out the standard control library (although mostly vanilla HTML elements work just fine), and adding more tests in general. I’m tracking progress publicly using Trello.