Tag: devtools

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

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: #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
'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.