New Electron Dance

No, wait, that's the Neutron Dance, I get those confused.

Electron

Since abandoning any hope of the iOS App Store paying my bills, I've had to look back at the web or desktop. My current available time-at-computer and energy these days isn't sufficient for a day job or even contracts, much to everyone's dismay. So time for another hard look at the situation.

I like working on my Mac, but Mac isn't that big a market. I also want to ship on Windows (and Linux, I suppose). Objective-C is one of my favorite languages ever, Cocoa & UIKit (on iOS) were great APIs, AppKit on the Mac much less so, but since Apple's killed Obj-C and it's not portable, my happy years of typing [ ] are over.

WHAT HAVE YOU DONE?!

Swift might be the worst mental disorder to strike programmers in decades. Swift is orders of magnitude slower than Objective-C, crashes constantly, the moving-target "spec" creates incompatible changes every year, and because they're too stupid to standardize a binary interface, every program has a 20MB+ blob of Swift runtime. For a single-platform joke language perpetrated by a C++ bozo who fucked off after a year to play with cars. So I'm all too happy to say good riddance to that bullshit. I mean exactly this: If you're using Swift, you either don't know better (it's OK to say you don't know!), or are defrauding your employer for hours, or have something wrong inside.

13 years ago, Project Builder/Interface Builder was a pretty good dev toolkit since I could use a real editor (BBEdit) with it, but Xcode locked that out, and then as Apple sucked in more tools over time, it sucked harder and harder; I can't stand the rickety deathtrap these days. I was getting by in JetBrains' AppCode, but still had to use Xcode for Interface Builder (RIP) and to get builds onto a device half the time. Xcode is a crashy, substandard pile of shit with maybe the worst editor in any IDE in history. Syntax highlighting stops working at random, for most of a decade it has code-completed "nss" as "NSStreamDelegate" rather than the slightly more useful "NSString" (before that it couldn't code-complete at all!), I could go on for hours or days about how Xcode kicks you in the input/output ports every time.

And the worst part is you can't fix the fucking thing, no user-serviceable parts inside, Radar is a black hole, no scripting or plugins. Just bend over and take what Apple Developer gives you good and hard. It's kind of a relief that current Xcode doesn't run on the last stable MacOS version (Sierra).

I'll stick with BBEdit for text and Atom for code, thanks. If I'm angry at Atom I can fix it myself or file a publicly-trackable ticket; I'm rarely angry at BBEdit but I can ask Rich to fix it.

So I'm writing web-type software in Javascript, with Node or Electron behind it. Javascript aka ECMAScript has become a good language in the last 5-10 years, and the V8 runtime in Node/Electron runs close enough to native now for most needs. I love that I can just write UI in HTML again. No fucking around with Apple's bullshit of deprecating APIs out from under me (I "get" to rewrite alert/menu code again?!), or promising to support SpriteKit/SceneKit across iOS & Mac and then doing fuck-all on either. WebGL (or Three.js, anyway) isn't fast enough for complex scene-graphs, but 2D work in Canvas is mostly fine (and it gets better every year, instead of bit-rotting like unused S*Kit APIs). localstorage in a web page isn't enough for any real program, thus Node is needed to reach the filesystem.

I slander Swift for leaving a giant runtime turd in every program, but Electron's the same way: It has to contain a browser, Node, and system APIs. But I'm not at the mercy of Apple's marketing-driven dev tools.

Certain Mac nerds obsess about Purity of Essence, insisting that everyone should love Xcode, Swift, and AppKit, and that use of any other technology is an abomination to the end-users, whom they clearly love more than me. Can you hear that slurping sound? That's someone fellating Apple marketing. Roughly 4 billion more people are familiar with web pages and will find a web-like UI more comfortable.

I intend to keep up my experiments in Scheme and Pascal when I have time, I'd far rather have small, fast, native binaries on every platform, but shipping beats purity.

Progress is being made:

tile-20180426-map

tile-20180426-view

(the + road texture there will get replaced soonish)

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".

Installers

Indie game dev leads you to some dark and terrible places.

I so miss the App Store being an endless payout slot machine without spending $10M on advertising, and miss the 6-figure jobs for fixing peoples' apps because nobody knew Objective-C (even less know it now, but they're stupidly trying to rewrite code they don't understand into Swift, which will break again in 6 months).

Now I'm a poor but honest pixel farmer, forced to shovel shit to get to market.

Making a Mac binary for Reaper's Crypt was trivial (on a Mac, probably impossible elsewhere), and produced 1 file: "Reaper's Crypt.app" (a Mac application bundle, hiding all the mess so you don't see it).

Making a Linux binary was not much harder, and produced 17 files and directories, with libraries and data scattered all over, with the binary sitting in the middle where nobody could see it. So I'll have to make a little script to go launch that untidy mess. When I did Linux, there were at least 3 standards for icons, and by now I'm sure there are 13 more, so they get a raw image file.

Making a Windows binary required me to install WINE with MacPorts, which took hours, and the binary is in the middle of a similar mess of 20 files and directories. So for this I need an installer to make a .msi file, which nobody I know has done this decade; I think I have a handle on this. But now I don't know if I need 32-bit "win32" or 64-bit "win32" (what.); there's no fat binaries in Windows, so it's one or the other.

I am not Hercules, and these Augean stables are filthy.

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: ;
    }
    
    /* 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
    'body':
        '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:
    '.source.js':
        'module.exports':
            'prefix': 'me'
            'body': '''module.exports = {
                $1
            };
            '''
    

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

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.