Hypercard! The Software Tool of Tomorrow!

Encouraging people to write & submit new Hypercard stacks. Which, as a retro-tech challenge, I think is great. But. How about first having a decent modern Hypercard environment?

Why not? There's the classic John Gruber hit piece Why Hypercard Failed:

"Apple PR says it's a dead product so it doesn't matter if you like it! I like the Yankees who are also a bullshit PR project!"
—semantic analysis of all Gruber's posts produced this summary.

Stanislav (not a pleasant or generally useful person to me, but perhaps correct for once), had a different read of Why Hypercard Had to Die:

The reason for this is that HyperCard is an echo of a different world.  One where the distinction between the “use” and “programming” of a computer has been weakened and awaits near-total erasure.  A world where the personal computer is a mind-amplifier, and not merely an expensive video telephone.  A world in which Apple’s walled garden aesthetic has no place.

Apple did have a near-Hypercard tool, Dashcode, which was slightly more technical but not much; it auto-generated placeholder functions and you'd fill them in with JS and use local storage as your database. They never fully supported it, killed it, and pushed Xcode instead, which is like giving kids a backfiring nailgun with no safety instead of a plastic hammer. Now they're ludicrously trying to teach kids BDSM Swift with the lldb debugger repackaged as "Playgrounds". I feel so sad for a kid whose first experience of programming is 100s of "unable to satisfy template constraint" errors; that's some hard unyielding playground equipment there.

There's a few modern variants, but nothing I know of that works:

  • Uli Kusterer's Stacksmith is unfinished, has no binary download or web site, and the build instructions are very pro-dev. Last time I tried it I couldn't get it to build, so…
  • SuperCard is $180/$280. Ha ha… uh, no.
  • HyperNext Studio is based on RealBASIC, and is free, but rarely updated. Does not run classic Hypercard stacks.

So everyone just gives up and uses emulation, because making a new Hypercard is impossible. If you're going to do that, do it the easy way:

Debugging Pascal

Having a spare day to actually work on what I want, I get back into my Pascal adventure, and I'm blocked by inobvious bugs.

Thanks to Sierra breaking gdb (unless you disable SIP entirely, which I'm not going to do), Lazarus can't run ggdb, so forget about GUI debugging. I've tried all the code-signing, rebooting suggestions, none of that works.

I'm not a giant fan of the debugger, but even caveman Mark needs a backtrace sometimes. Happily, lldb works from the command line:

lldb -o "breakpoint set -n fpc_raiseexception" -o run foo.app

Then at the lldb prompt after a crash, type 'bt' for backtrace, 'cont' to carry on with the usual exception handling. Most of the lldb tutorial works the same.

The Future of Programming is Text

You can't grep or diff binary trees. You can't get a Smalltalk IDE on your iPad. You can't write an operating system or a big application in Scratch or the Mindstorms IDE. And even a small program in these won't work in the next version.

But you can edit plain text with any text editor, whether that's ed, nano, Vim, emacs, BBEdit, Atom, Textastic, Editorial, Eclipse, AppCode, whatever. You can save it safely and easily in any source control system. You can run an awk or sed script over your entire codebase and it just works.

See also:

If your language (or non-linguistic programming environment in some cases) is only usable from a single IDE, you've cut yourself off from every other analysis and editing tool in the world, you're dependent on that one tool to do everything you want.

I have old Mac and iPhone NIB files which can't be read with any current version of Xcode/Interface Builder, the file format was only supported by one dev tool and it's changed, and the old tools don't run on modern OS X. These NIB files "work", in that they deserialize into objects, but there's no way to edit them. Where possible, I now do most UI work in code; this isn't great fun, I end up with a ton of builder functions to avoid repetitive code blocks, but it'll still compile and work in 10 years.

This is also why I don't use a WYSIWYG word processor, I use MultiMarkdown. I've lost documents to proprietary WPs, and of course there's no way to run tools over them (except, sort of, MS Word with BASIC).

None of this has stopped people from making new non-text environments, or weird experiments. Experiments can be useful even when they fail, telling us what doesn't work. But they don't catch on because the tools aren't as good as text, and won't work in the future when the experimenter gets bored and quits.

Spatial Xcode

Checking my projects for building against iOS 11/iPhone X, and wanting to ship a new utility app (more on that later), I had to use Xcode again. And I screamed in rage, and cried, and this is why Mark drinks.

Filed a "suggestion" in Radar:

Open a project in Xcode. Double-click a file in the Project Navigator to open it in a window, resize & place it somewhere to work, then close. Repeat. Note that sometimes it'll keep the same size, but never the same position as previously, but after a few files it returns to a window sized like the main project window, randomly placed.

There's a concept called "spatial memory", which both the Finder and Xcode actively sabotage now, an old but still valid complaint: About the Finder…, by John Siracusa

Suggestion: Record the position & size of each file's window, and reuse that when opening a window. When switching to an alternate file, change the window size & position, do not destroy the current file's position. Maybe make this a preference setting, called "Project Builder Mode".

Using Atom

"Have you tried Atom?" #RuinADateInFourWords

Have gone to the dark side temporarily: Atom handles my ES6 better than BBEdit currently. 😭

But it's not quite right, so I fix. Atom configuration is a bit of a mess, but everything-is-a-plugin is a good philosophy.

  • One Dark UI & One Dark syntax themes are OK. But for crazy-go-nuts, install ubik-neon-syntax, and atom-material-ui. Goddamn this makes me want a bottle of Jolt Cola and an Information Society CD blasting on endless repeat.
  • install logo-file-icons, garish but the more popular file-icons is bland and ugly.
  • install symbols-list, because the default symbols tool doesn't find new-style classes.
  • install eslint, because nobody writes JavaScript good, even me after 20 years of it.
  • install atom-mac-terminal, gives you an "Open in Terminal" right-click.

  • packages, linter, settings, turn off "Lint On Change", because that slows down an already slow editor.

  • packages, autocomplete-plus, settings, turn off "Show Suggestions On Keystroke". Ctrl-Space is fine. I learned to touch-type on an IBM Selectric, so I type faster than JS can autocomplete anything but a very long constant.

  • % atom ~/.atom/styles.less and add:

    /* scroll bars should be grabbable */
    .scrollbars-visible-always {
        /deep/ ::-webkit-scrollbar {
            width: 20px;
            height: 20px;
    /* turn off all that folding folderol */
    atom-text-editor.editor .icon-right {
        width: 0 !important;
    /* make the gutters different from text so I can see indentation */
    atom-text-editor.editor .gutter {
        border-right: #222222 1px solid;
        background-color: #111111;
    /* ubik-hackerman-syntax has overly dark functions, was #133460 */
    .theme-ubik-hackerman-syntax .syntax--entity.syntax--name.syntax--function, .theme-ubik-hackerman-syntax .syntax--support.syntax--function {
        color: #4f6db4;
        font-weight: bold;
    /* ubik-hackerman-syntax recolors the semantic class of arguments to functions; I want types to be colored the same in or out of a function call. */
    .theme-ubik-hackerman-syntax .syntax--arguments, .theme-ubik-hackerman-syntax .syntax--meta.syntax--function-call {
        color: unset;
  • (new 2017-06-10) % atom ~/.atom/keymap.cson (why is there no UI for keymapping?!) and add:
    # I hate editors & other long-term applications closing by instinctive Cmd-Q
        'cmd-alt-ctrl-shift-q': 'application:quit'
        'cmd-q': 'pane:close'
  • (new 2017-06-10) % atom ~/.atom/snippets.cson (why is there no UI for snippets?!) and add:
            'prefix': 'me'
            'body': '''module.exports = {

Open issues:

  • I can't find a package to get rid of tabs and only badge/color open files in the tree view.
  • Regex field is unbearably small. I often copy over to BBEdit, do a big regex there, copy back.
  • To figure out any style element to customize, you have to open developer mode ⌘⌥I and pick the element and find the exact right style from a mess of styles. A lifetime writing HTML & CSS pays off in customizing a fucking editor; if you're not me, you're probably stuck with it. BBEdit lets you customize styles right there in Preferences. At least atom-material-ui has a couple choices for accent colors.
  • I wrote this post in BBEdit. Atom has a Markdown preview, but it's awkward and far slower.


Swift amazes me. A beta language that breaks your code every 6 months, a type system so totalitarian and inescapable it makes BDSM Haskell look like a vacation (and apparently nobody's read Gödel's paper), the founder abandoned it to go work on cars, Apple won't ship production code in it, compiling burns your fucking CPU to the ground for 10s of minutes for code C can do in seconds, and after 3 years Xcode still can't refactor it.

And stupid motherfuckers write their production apps in it. 😦

I know Objective-C is hard. It's C plus Smalltalk, both of which are subtle and take a year or two to learn. [brackets scare:theNoobs] && dot.syntax.isOverloaded;
But the tools fucking work. Dynamic code makes programmers efficient. A more elegant weapon for a more civilized age.


My editing weapon of choice is BBEdit: It Doesn't Suck™. Why? I want you to read the typical release notes:
Attention to fucking detail. Best $100 I ever spent (it's cheaper now).

On iPad I use Textastic (has regexp) or Editorial (has scripting filters), but they're amateur hour in comparison.

If I have to shell in and can't edit remotely & upload with BBEdit, I'll use vi, which I used for ~20 years (actual vi, STeVIe, Elvis, & Vim).

Oh, and for iOS/Mac apps with a ton of UI/framework shit, I use AppCode. BBEdit for clean C/Obj-C and I can just xcodebuild from Terminal. As the avatar says, STOP Xcode!

It's a hell of a thing. Apple had a reasonable but limited Project Builder/Interface Builder pair of apps from NeXT. PB could set an external editor (BBEdit) so I was happy. Then Xcode combined them and lost the external editors, and every version since has been worse, slower, crashier, renders ASCII text as Russian, less capable of even simple refactors. Now it just shoves fucking Swift (C++ for masochists) down your throat and shits 10k messages into Console so you can't debug.