Learn 2 JS

Almost the simplest possible tool for coding in Javascript, slightly above Hello, World!, I packaged up how I did my Advent of Code 2017 entries (up to the point I quit for lack of time/sleep). I start with something like this in every JS project, and now you can have it.

  • Setup

Download learn2js

Unzip it to Documents (or wherever you like).

Open Terminal on a Mac; or xterm on Linux; or I have no idea what the terminal/shell situation is on Windows, feel free to enlighten me.

% cd Documents/learn2js
% ls
run.sh  src
% ./run.sh
Serving HTTP on 127.0.0.1 port 8000 (http://127.0.0.1:8000/) ...

This will require you have Python3 on your system to use as a simple web server, since a browser can't open multiple local files without a web server, but there's no other Python in this.

Right-click that URL (the part in parentheses!) and open it in your browser, or copy-paste it, and you should see a simple page with an Input: box. Anything you type is uppercased, that means it's working!

  • Coding

Now edit src/main.js with your editor of choice, like BBEdit on a Mac; or Atom anywhere. Please don't use Notepad on Windows, even if it handles correct line endings now.

Should be pretty self-explanatory, the TODOs tell you where to start.

Anytime you make a change to the source, just reload the page and hit Run again. Just like hacking on BASIC code back in 1980, dudes & dudettes!

  • Exercises for the Student:
    • I didn't make a favicon for this, and you should, which will introduce you to the horrible world of W3C/WhatWG specifications.
    • You might want to move inputTable below the output div in index.html, but then it scrolls down all the time, so now you need to anchor it at the bottom and make output fixed in place and scrollable, as I do in Mainmenu… I may add that option later, but it complicates a very simple page.
    • I didn't set up eslint for this, configuring it is somewhat annoying; probably will next time I update it.
    • Setting up Node is even more of an advanced topic, and 90% of the interesting work is in front end JS like this.
  • Troubleshooting: If a change isn't appearing, you may need to empty your web cache: In Safari, turn on Develop menu from Preferences>Advanced, then Develop>Empty Caches; in Chrome, Chrome>Clear Browsing Data and then only select "Cached images and files"; I have no idea what you do in Edge on Windows. I can't easily fix that, and users would never see it, but you will.
  • License: I put all the code under BSD license, the documents under Creative Commons Share-Alike. You can keep your code more or less private (except in practice, you have to let everyone see your page to let it load!), but if you make changes, share them and link back to me. Don't be a Stallman. Note in particular, you cannot relicense this under a restrictive license like GPL, and don't just put it on github unmodified. Sorry to have to preach about this, but some people need to be told where the lines are.
  • Shipping: To let others see your masterpiece, just change DEBUG to false, upload everything in src somewhere, your own site or something like Neocities, and you're done! You only need run.sh & Python on your local system.

Tower of Babel

Ugly shit from my package.json:

 "scripts": {
    "start": "electron .",
    "build": "rm -rf build && babel app -d build/app && cp -R assets package.json build && cp app/*.html build/app && cd build && npm install --only=prod && cd ..",
    "dist-mac": "electron-packager build --out=dist --asar --overwrite --icon './assets/i/appicon.icns' --platform=darwin",
    "dist-linux": "electron-packager build --out=dist --asar --overwrite --icon './assets/i/appicon-256.png' --platform=linux",
    "dist-windows": "electron-packager build --out=dist --asar --overwrite --icon './assets/i/appicon.ico' --platform=win32",
    "dist-all": "npm run dist-mac && npm run dist-linux && npm run dist-windows",
    "dist-help": "electron-packager --help 2>&1 |less"
  },

So I wanted to filter my source through babel-minify.

Build out to a "build" dir… and everything breaks. Copy in assets, package, HTML files… "Missing module". Turns out known issue, closed but I don't see an actual solution: Nuking & reinstalling my node_modules did nothing, and I have latest stable versions (maybe "stable" is the problem?) of everything.

As a brute-force Hulk-smash solution, shoving that "npm install" in the build script works, and is easier than figuring out what I should change.

Xcode is Flawed

"So, yes, Xcode is flawed. But is it fundamentally flawed? Is there some core concept — its multi-paned single window UI, its scriptable build system, the nature of app bundles and code signing — that makes it impossible for Xcode to ever be good? I don’t believe anyone is making this argument. The closest you get to this is storyboard haters who build their UIs in code. I disagree with that camp, but even if I didn’t, that alone is not enough to relegate all of Xcode to junk status."
Chris Adamson about his new book, Xcode Treasures

I like @invalidname, but wow do we ever not agree about this. I diatribed a bit yesterday, but let's look at just these claims.

The build system is basically a shell script but with a custom editor that's harder to use than typing. Did you know that most programmers are pretty good at typing? Most of my projects, in fact, just had a shell script "phase", and then I'd write everything in bash (I hadn't switched to zsh yet). It is no better than an old-fashioned Makefile or nmake, and for many projects a build shell script is enough. But, sure, this isn't the worst thing in Xcode.

Code signing is Hell, and Xcode's original version on iPhone SDK launch was appallingly hard, but it worked. Now they've automated it, which means you have 512 bogus auto-generated configurations on your ADC profile, and if the signing server is down (which happens… well, it's not even two 9s of uptime…), you can't do anything until some hours later when Apple plugs the server back in. Entitlements and services you turn on/off can permanently burden your app's configuration, until you go to the website and houseclean all the junk configurations and make a new one with just what you need. And that'll get replaced with an auto-generated configuration again.

Xcode does have a dozen or so color themes now, but you can't change the UI chrome from generic Mac gray, so it'll always be unpleasant to view dark-background themes, you can't choose different icons, can't script the goddamned thing. Meanwhile, here's Atom's 7556 packages including 2579 themes, and you can just hack on all of the editor in JS & CSS, live-updating your own tools.

I quit using storyboards except for nearly-blank launch screens, and XIBs (NIBs! We called them NIBs!) except as maximized view holders, because the corpse of Interface Builder trapped in Xcode's belly punishes you for using them; if you touch anything, your autolayout constraints go crazy. And you can't delete constraints in the view where you edit them, only in the tree view which isn't even visible normally, and is organized totally differently from the editor on the right. After a few versions, Xcode just can't edit an old project's XIBs anymore, and then you're FUCKED. Have fun recreating that entire UI, OR you can put it in code. And if you're writing code, why not just leave the walled garden and write HTML/CSS/JS like I do?

The one-window thing doesn't bother me, but the lack of functioning tabs is infuriating and stupid. Open three files. In BBEdit, all three appear in the sidebar, and you can switch with the top-left file selector or the bottom-left list of "Currently Open Documents", or other navigations; I prefer tabs, but it's entirely acceptable. In Atom or AppCode, all three appear as tabs at the top of the editor pane, and you can drag to reorder the tabs as you like; each tab is a unique single view into that file. In Xcode, you can open them in separate windows, or in separate "tabs", but the same file can be open in multiple places, but if you close it in one, it closes in all of them. WHY WOULD YOU DO THAT? If you click a file in the tree view, it replaces the contents of the current tab/window, it doesn't just open it in a new tab. So the process is click, double-click to get a window, then on the first view hit back and hope it goes to the right file. Flames on the side of my face!

Snippets. OH NO, I had a PTSD flashback to Xcode's Snippets. You write a piece of text you want to reuse. Select the text and drag it onto the Snippet area; you can't right-click or menu it there. No, you clicked on the background, now it's deselected. You have to reselect, click on the stroke of a letter in the text. Maybe zoom the screen in with ctrl-mousewheel, now you must grab a SINGLE MOTHERFUCKING PIXEL!!! Calm, deep breaths… and drag it to the Snippet area. 😡🔪🔪🔪 In Atom, you either copy-paste it into a config file, or install snippet-generator-plus, select text and hit a key.

Xcode isn't just accidentally hateful and awful. It must be the work of a malevolent intelligence to be this horrible. I've found a recording of the original design meeting for Xcode.

Spend a few days working in an IDE that doesn't hate you like AM hates Humans, and you'd kill anyone who tried taking you back.

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