Category: devtools

Indecent Proposal: Linux

Craig suggested a snarky Modest Proposal, start targeting Linux instead of Mac, if you recoil at Apple taking 30%.

It's really 15% for most people in Small Business Program. In the Olden Times Before Ye Appe Store, distributors only would take 50% or more cut, publishers would take 70-90% cut; the App Store was a ridiculously good deal when it came out. Assholes like Tim Sweeney at "Epic Games" are of course appalled at paying out a dime, and so after an epic court battle where they lost 9/10 claims, have now reduced it to 27%, and owe Apple $73M for legal fees.

But let's think about switching. I've been spending a few days arguing with Linux zealots on fediverse, and have come to some conclusions, aside from the obvious that Linux people are crazy.

THE GOALS

  1. Write software in tools and languages I don't hate.
  2. Keep the kind of software quality, taste, accessibility, etc. that I like.
  3. Ship it and GET PAID.

Not Goals

  1. End-user use. I don't have to inflict this on myself, just see what the dev environment's like.
  2. Server software, I have FreeBSD for that.
  3. Joining a cult and singing the Free Software Song - do not click, it's Stallman singing.

GUI APIs

This is the most visible, but shallowest problem. Craig suggests Gtk+ or QT.

  • Gtk:
    • Pro: It is easy to code against in C, and from there you can use anything you like with FFI; I could ship my Scheme programs with Gtk.
    • Con: Looks like ass everywhere, native to nothing.
    • Every version is incompatible and utterly different from the last.
    • Theming makes UI design very hard, or impossible.
  • QT:
    • Pro: Actually not terrible looking, sometimes almost passes for native.
    • Con: Have to work in C++, which is a HARD NO from me.
  • Gnome: Mostly this is just Gtk.
    • Con: Do everything in their awful IDE.
    • Sort of has design guidelines, but the child-like or Windows Vista-like icons, bubble aesthetic, is not appealing.
    • Requires Flatpak, which I'll get to in a minute.
  • KDE: Mostly this is just QT.
    • Pro: Can be worked in from Kate, which is an OK editor. Here's Mark, saying something almost positive about a Linux program! Kate is OK. It's no Vim, though.
    • Human Interface Guidelines are pretty consistent, professional-looking.
    • Con: Can also be worked in from KDevelop, which makes Eclipse look fun (Eclipse is not fun).
    • UI is mostly written in QML, which is YAML like Microsoft's XML layout stuff. Just horrible.
    • Mostly the loser in the Linux User Interface Wars.
    • Again, C++, no.
  • Android:
    • Pro: Is a platform with some aesthetics & user experience; not great, but it exists.
    • Has a paid store.
    • Con: Languages are Java or Kotlin, which are very silly.
    • IDEs for it are really spectacularly awful, either Eclipse or a bag-on-the-side mode of IntelliJ.
    • Security is F-tier, I don't like contributing to a platform that's all scams, piracy, and botnets.

I hate basically everything here, and more besides. Gtk has a bare winning edge that it's easier to use from a language I like.

System APIs

The deeper problem of Linux is everything in between 1970s terminal programs and trivial GUI programs that don't interact with anything. There's no real system integrations.

If you want to use the user's calendar, you have to research several calendaring systems, some of which may have an API and some don't. Again when you want to do messaging, oh, wait, that doesn't even exist on every system. Again when you want to do something with curated photo albums, not just shoving a png in some random directory.

Or dig deeper, and audio is the same fiasco that chased me off Linux desktop 20 years ago; you simply can't get multiple audio streams to sync & play, and the latency is often in the seconds for audio processing, I can get far under 10ms on Mac. Video is nonexistent other than calling out to VLC or mplayer; you don't want to try.

What you can get done on Linux is maybe a database and low-level networking. If that's not enough, you're in for a rough ride.

Taste

So I use this word a lot. "The only problem with Microsoft is, they just have no taste." —Steve Jobs - watch that whole clip from Triumph of the Nerds.

Taste is about picking one aesthetic, one set of user experiences, and saying no to all the others. You have to choose. And most people can't choose, or they just end up dumpster-diving a bunch of junk that doesn't go together, and can't understand why they're unhappy (or maybe they're Grouches who like garbage).

If the platform creator has an aesthetic, it has behavior guidelines, you follow it, so users will feel comfortable, they won't feel surprised: Law of Least Astonishment.

This is impossible on Linux. Gnome users hate KDE, KDE users hate Gnome. Some of them like Electron shit, others think it's as bad as Flash (it's actually worse). Until one of them becomes a One True Catholic Linux and puts the rest to conversion or death at swordpoint, there won't be any unified UI.

So now you have to do QA testing on design as well as functionality on multiple distros, many different configurations, and you'll probably need testers familiar with those setups. It's an impossible QA task.

Suppose I want a file open box with custom file previews. On Mac OS X, I can use NSOpenPanel, customize the accessory view, watch notifications and update the preview. Gnome & KDE will deal with even having icons differently, and you can't override anything without bringing in their code and hacking on it.

Ship It

You have several choices here.

Gnome people say Flatpak, which bundles all the libraries and support for a program into a bundle, explicitly copied from NeXTstep/Mac OS X/iOS .app bundles (the word "app" is only valid for these platforms! This is where it comes from!)

Which is theoretically fine, but runs into the problem that Linux doesn't have a consistent OS base, so Flatpaks are a LOT bigger than Mac app bundles. They run "cross-distro" by some kind of linking hackery and translation layers, so your Gnome program includes all of Gnome, and looks like ass on KDE, but runs. As noted under Taste, that's not an acceptable way to ship, you'd have to test on everything.

npm, deb, & nix are distro-specific bundles, but at least they can check dependencies and install only what's needed. They don't help you at all with translation layers. While there's a UI for these, you really only do them from command line.

"Free Software" is an incredible pain in the ass here, you have to carefully check what libraries you use, and if they're LGPL or BSD/MIT, so you can use them with some qualifications, or GPL or AGPL, in which case you can't (unless you like shipping all your source and having 100% piracy).

Get Paid

Releasing free software is useless. As Harlan Ellison said, cross my palm with silver.

Universally, every Linux I've spoken to hates paying for software, they would never do it, think I'm an immoral monster for suggesting it, I should be happy someone might put a penny in a tip jar.

This is a backwards, shit-covered, medieval religious dogma. It's appalling in the 21st Century that Rape Apologist Richard Stallman is still Pope of the FSF, eater of toejam, owner of abortion jokes in fortune. And his devotees are carrying out The Faith, regardless of the sins of their leader.

There's no good software stores. Elementary has one, which is defunct or close to it, from what I can tell. Ubuntu shut theirs down years ago.

Google Play for Android isn't on every device, and it's widely pirated. I also morally object to letting Google have money, but any port in a storm if it wasn't for that?

itch.io works fine for games. I suspect the Linux paid users are the tiniest most shrivelled-up sliver of the demographics. 20-30 years ago, I actually had minor success with shareware on Linux, but that dropped off and never recovered.

Otherwise, I dunno, try to run my own e-commerce site and sell binaries which will instantly get pirated because nobody on Linux has any money?

So instead of paying Apple 15-30%, pay whatever hosting, bandwidth, & e-commerce costs you, and you get nothin' in return. Let's see, 30% of nothin' is…

Conclusion

It appears that eating babies will not actually solve the overpopulation or hunger problems at this time, Mr Swift (no relation).

Apple Destroys App Store History

Note, currently all my old apps like Perilar, DungeonDice, etc. are off the store. They all still work. Apple wants me to pay $100 extortion, recompile a bunch of old code that maybe takes minutes, maybe hours or days of catching up to "modern" APIs, before I can resubmit.

And once they start requiring Monterey instead of Big Sur, I have to buy new hardware to even do that, my iMac just misses the deadline for support (but they still give me a notification a couple times a month to "upgrade" to Monterey, so smart & classy).

And my reaction these days is basically "fuck you, App Store". I could pay them nothing, and spend that effort on my Mystic Dungeon Club Javascript games, or my Scheme games (shipping real soon now!), and then I'm the only one who can disappoint me. Most of my JS stuff works on an iPad just fine; I'm not really inclined to try resizing for iPhone or Android, but in theory they'd work, too.

My little Glitch.app, full of mostly-not-allowed tools which I don't distribute but sideload, doesn't currently run, and I think I can get it to reload on the free account. If not, I guess I don't glitch. I could probably rewrite a lot of it in Pythonista, assuming that survives the App Store-pocalypse.

I have no problem with Apple's 30% cut, 15% would be better but hey, whatever. It was a nice storefront for a few years there, anything less than the 50% cut retail takes was warranted.

But every other part of the App Store policy is so noxious, all that's left are shovelware predatory gacha games from China, "social" (masturbatory pictures of yourself) network garbage, and AAA studio teaser games, but not the real games. And now they're just gonna make it impossible to get anything from the good era.

I literally use my iPhone now as a, uh, phone. It's almost back to the 2007 release set of Apple apps, because nothing else is any better. The iPad has several more useful tools, and I worry that they'll be removed by this policy.

Android fanatics, note that you are not helpful:

Earlier this month, the Google Play Store similarly announced it would begin limiting the visibility of apps that
“don’t target an API level within two years of the latest major Android release version.”

FreePascal Building

I went to do a little code maintenance on a couple utils I'd written in FreePascal, and they wouldn't build. For a couple years, FPC just didn't work on 64-bit Mac OS, but they finally fixed that. Current fpc 3.2.0 is in MacPorts, I'm not sure what the state of Lazarus is, I quit using it. But the core Pascal is fine for many tasks, and I may do some things in CP/M Pascal when I get my SpecNext (longest wait ever until fall/whenever).

Anyway, the error I got was ld: library not found for -lc and nobody on the Internet has ever posted with that error, that I can find.

And eventually I tracked it down to the SDK not being linked at all. So here's an updated fpc.cfg which goes in your $PPC_CONFIG_PATH, note the DARWIN section. Also that's x86_64 only, I need to add an ARM64 branch at some point.

#IFDEF DEBUG
    #WRITE DEBUG
    -gl
    -Crtoi
#ELSE
    # Strip debuginfo
    -O2
    -Xs
#ENDIF

#IFDEF DARWIN
    #WRITE DARWIN
    # use pipes instead of temporary files for assembling
    -ap
    #DEFINE CPUX86_64
    -Px86_64
    -FD/Library/Developer/CommandLineTools/usr/bin
    -XR/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
#ENDIF

#IFDEF OBJFPC
    #WRITE OBJFPC
    -Mobjfpc
#ELSE
    #WRITE FPC
    -Mfpc
#ENDIF

# use ansistrings
-Sh

# stop after warnings
-Sew

# don't show Hint: (5023) Unit "X" not used in Y
-vm5023
# don't show Hint: (5024) Parameter "name" not used
-vm5024

#-Fl/usr/X11/lib
#-Fl/usr/local/lib

-Fu/opt/local/libexec/fpc/lib/fpc/$fpcversion/units/$fpctarget
-Fu/opt/local/libexec/fpc/lib/fpc/$fpcversion/units/$fpctarget/*

And a quick hello world/Unicode tester:

{ hello.pas
    Copyright ©2017 by Mark Damon Hughes. Do what thou wilt.
}

program hello;

uses crt, sysutils;

var
    name: utf8string;
    c: widechar;
    i: integer;
begin
    write('What is your name? ');
    readln(name);
    writeln('Hello, ', name, ' from code page ', stringCodePage(name), '!');
    for i := 1 to length(name) do begin
        c := name[i];
        writeln(i, ': ', c, '(', ord(c), ')');
    end;
    readkey();
end.

fpc -dDEBUG hello.pas produces a couple dozen warnings like: ld: warning: object file (/opt/local/libexec/fpc/lib/fpc/3.2.0/units/x86_64-darwin/rtl/baseunix.o) was built for newer macOS version (11.0) than being linked (10.8) and I'd love it if someone could tell me how to get FPC to tell ld to make that STFU.

But it works:

% ./hello
What is your name? Mark
Hello, Mark from code page 65001!
1: M(77)
2: a(97)
3: r(114)
4: k(107)
5: �(239)
6: �(163)
7: �(191)

LISP Machines

I really wish we had a front-end to software even half as useful as this in the 21st C, but technology has regressed massively since the '80s and '90s. Some of the old IDEs, before they became bloated "enterprise" software (because giant mega-corporations paid for them, not individual programmers, so the IDE makers serve their paymasters), started to slouch towards this kind of usefulness but fast and small. CodeWarrior, Project Builder/Interface Builder, Borland's Turbo Whatever.

emacs isn't the answer, it's an abandonment of the question; "modern" emacs turned away from the LM zmacs model, it's now just a terrible LISP interpreter with a bad text-only-editor front end; you can make tools in it, but nobody sane will want to use them. I'm perfectly comfortable with the emacs editing keys (well, obviously, Macs use emacs keys for all text areas), but the machinery in it is just broken.

I get excited about Chez Scheme having a nice REPL, with history and can edit multi-line blocks in the REPL, unlike the crappy readline almost every other Scheme uses. But it doesn't do hypertext, it doesn't do graphics, it barely has tab completion (procedure names only), it doesn't have any inline documentation & source inspector; all of those were in the LISP Machine.

When I'm working, I have my text editor (BBEdit or Atom mostly), a terminal with the REPL running and I copy-paste to it, 3-4 PDFs open (R6RS, R6RS-lib, CSUG, sometimes TSPL), and a web browser pointed at the SRFIs. If the Internet connection went down, I'd have to search the SRFI sources to figure out what's in there. I really need a better tool for this.

DrRacket can do some graphics inline, and the tab completion shows documentation hints in the top right corner, but as I note every time, it doesn't really have a REPL because it destroys the interactive environment every time you edit code; utterly useless for code exploration. And in practice, Racket is really horrifyingly slow; it does fine in focused benchmarks but real-world use it just falls over drooling.

The graphics part's sort of irrelevant, and sort of not; the way the LISP Machine worked was getting a "presentation" form for an object, which would render as text or drawings or images, and interacting with it sent messages back to that object. That's probably out of scope for anything except a complete new OS and terminal. A simplistic number-tagged hypertext would be good enough and orders of magnitude easier.

So. I'm not sure what to do here, I don't want to just complain about tools and not do anything about them. I could try to extract the docs to make a hypertext doc system; a lot of text processing on TeX source sounds painful, and a one-off job, I want a more universal solution. It may be possible to hook into Chez's completion to call a help system. Or it could be a standalone program that you feed several doc sources into, and it lets you search against them. Dash does that, but it's Mac and C/Objective-C primarily, and does poorly at other docsets.

Programming on Your Phone

Pythonista lets you use your pocket UNIX workstation as a workstation. I use Pythonista, if not every day, very heavily on the days I use it. As always it's crippling of Apple that there's no upgrade pricing, so I can't give him more money every year that I keep using it. The new keyboard module is an interesting script launcher, but I already wrap a bunch of utilities in a main menu program.

There should really be more of these mobile programming environments. In the early days, Apple severely restricted you from shipping one; you could kind of cheat with JavaScript, and a few games snuck in some bytecode interpreters, but scripting was right out. They loosened up eventually, but are still dicks about you saving code anywhere it could be shared, so for example I have to keep my Pythonista stuff in iCloud, not DropBox where it'd make more sense.

  • Panic's Coda and Coda for iOS (née "Code Editor" WTF) is the only other one that's really functional; I've built real web sites out of it, but I mostly use it for ssh. Sweet baby Cthulhu, I hate Panic's crooked-text "designer" sites, I hit Reader view on those instantly. Designers shouldn't be allowed access to CSS or JS.
  • Hotpaw BASIC still works (as does his Chipmunk BASIC on the Mac), but hasn't been updated in 2 years. Not that I want to program in BASIC, but it's better than no programming at all.
  • The iPad used to have a very nice "BASIC!" (with a structured BASIC and a bunch of system functionality), and a very limited "iSkeme" (scheme interpreter, R5RS-ish? with nothing but text I/O), but they were killed in the 64-bit-pocalypse. Update 2020-09: miSoft Basic! has been updated. Searching for this is utterly impossible!
  • Workflow (née Apple Shortcuts) is great for putting a few tasks in a row but you'd go insane trying to write anything complex from drag-and-drop clicky boxes.
  • Apple's Swift Playgrounds on iPad is a tutorial, not really usable for applications AIUI.
  • There's a bunch of "kids learn to code!" apps that are mostly ripoffs charging $60/year to play robot tanks. Do not buy anything like this.

I dunno if the 'droids have anything comparable, I'm sure they can root their phone and try to use vi in a busybox shell, but that's not a reasonable work environment for a thumb-sized on-screen keyboard.

SwiftUI, SceneKit, AR, and Facebook's React are the new JavaFX

That is all.

OK, will clarify for those who don't know about JavaFX: It was a new UI metaphor/declarative model on top of Java Swing, which is a giant bloated mess on top of Java AWT, which was a thin, minimally-functional shim on top of native platform UI, usually just CPU-bound drawing in a canvas. It came out just as Java applets became the most common virus vector, and Java on the desktop was dying off (aside from Minecraft, which uses LWJGL). JavaFX was not inherently bad, but limited by its underlying tech stack. Only a few people used it seriously, and their software is now broken because it's EOL by an uncaring corporate owner.

Don't tie yourself to hot marketing garbage APIs pushed by evil mega-corporations.

Programming the Atari 8-bit

My programming started in 1979 with the TRS-80 Model I, but in late 1981? early 1982?, I got my Atari 800, and later a 1200XL, then Atari ST. Those are what I consider "my computers".

Last few weeks for hobby time, I've taken up playing with an Atari 8-bit emulator, and may soon buy an old machine (130XE? I guess?) and a modern SD-card reader, and HDMI adapter unless I want to set up my old CRT… Yes, this is "pointless", but it's the most emotionally rewarding programming I've done in some time.

Had to do a lot of setup to get to this point, though. Follows are my excessive notes, which will hopefully be useful to others.

The keyboard mapping in AtariMacX is weird, I finally figured out:

Mac Key Atari Key
` Break
F2 Option
F3 Select
F4 Start
F5 Reset
Sh-F5 Cold Boot
Opt-F5 Insert Char (be REAL DAMN CAREFUL not to miss the Opt key!)
Sh-Opt-F5 Insert Line (same, DANGER WILL ROBINSON DANGER)
Home / Opt-F7 Clear
End Atari/Inverse
PgDn / Opt-F10 Help (XL/XE)
Opt-F1 F1 (1200XL)
Opt-F2 F2 (1200XL)
Opt-F3 F3 (1200XL)
Opt-F4 F4 (1200XL)
Capslock Cycle caps, may take several tries of caps A backspace repeat until you get lowercase, not graphics or uppercase.
Sh-Capslock Uppercase, almost always works

Typing on a real Atari keyboard is probably the #1 reason to get real hardware instead of emulation.

Immediately it comes rushing back, how much I didn't like the default environment of blue screen, clicky keyboard, inset margins. Easy to fix with a few pokes, but I don't want to do that every time I reboot, so I need a startup program.

  • First, configure Atari800MacX with the subdirectories next to it. It comes with all these folders in user space, but it's actually mapped to somewhere in /var, which is awful.
  • Make a boot disk. Media -> Disk Image Conversions -> XFD to ATR, pick the DOS25.XFD image in OSRoms, and call that boot.atr, store it in Disks, Load it in D1 Cmd-1 and pick boot.atr.
  • Reboot into DOS, by Control -> Disable BASIC. Bask in the glory of Atari DOS 2.5.
  • Make a data disk, Media -> New Floppy Image, I went with Medium Density (130K) since almost everything can read that, assign to Drive 2, and call that disk2.atr or whatever.
    • From Atari DOS, Format: I <return> D2: <return> Y <return>
    • Preferences -> Boot Media -> Set to Current Media, Save Configuration
  • My Atari BASIC project on Gitlab
    • Based on what I remember of my old main menu, I had a ton more stuff but I'm slowly adding routines as I need them. This can also be a shell for new programs, delete 11-9998 and use the subroutines. I wrote Draw to test joystick & function key scanning, not to be a good paint program, typed in a Music demo to make sure I had sound working.
      • Digression: This is not an efficient structure, because high line numbers take longer to find; an optimizing Poindexter would put the subroutines tightly packed at 1-999 and the program at 1000+, but it's massively easier to read & work with this way. I won't be in BASIC that much anyway, it's just for utility work.
    • Download AUTO.LST, convert Unix newlines (char 10) to the ATASCII newline (char 155 õ), and drop it in the HardDrive1 folder.
    • % LANG=C tr '\233' '\n' <AUTO.LST.TXT >AUTO.LST
    • Or you can just Media -> Edit an .ATR disk image, import file, and that has a newline conversion.
    • From BASIC, E."H1:AUTO.LST" <return> RUN <return>, pick Y. (Script AUTORUN.SYS), and enter:
      • ?"MAINMENU"
      • E."H1:AUTO.LST"
      • RUN
      • .
    • Change H1 to D1 if you saved it in your boot.atr.
    • Now it'll do that on every bootup from that floppy. Reboot to be sure it works.
    • If you make changes to your main menu, remember to LIST "H1:AUTO.LST". I use LIST/ENTER (text LST format) instead of SAVE/LOAD (tokenized BAS format) so I can read it from the Mac; BAS is slightly smaller and much faster to load/save, but it doesn't matter with emulation or an SD-card.

    • Atari-autorunsys

  • BASIC set up and tested, and it's a convenient place for little utilities, but now for real programming.

  • Atari Macro Assembler and Program Text Editor

    • Download this, read the fine manuals; more for MEDIT than the assembler unless you're really hardcore. I will probably do little or no assembly, even tho back in the '80s I could hand-assemble short programs directly into ATASCII codes to run from BASIC; bug-eating freak that I was.
    • Read the MEDIT manual. It's quite a respectable full-screen editor with command mode for search/replace, block editing, etc.
    • Open the Atari Macro Assembler and Program Text Editor.atx (ATX is write-protected or encrypted or something; you can't use them directly, and have to disable the SIO speedup hack in emulator) disk in drive 2 of your Atari (Cmd-2), Control -> Disable BASIC (which will reboot to DOS). So you want the program files off that:
      • DOS: C <return> D2:MEDIT,D1:MEDIT <return>
      • DOS: C <return> D2:MEDITCM.BAS,D1:MEDITCM.BAS <return>
      • DOS: C <return> D2:AMAC,D1:AMAC <return> (skip if you'll never write ASM)
      • DOS: C <return> D2:SYSTEXT,D1:SYSTEXT <return> (I think only needed for AMAC?)
      • Eject: Ctrl-Cmd-2
      • Reload your data disk, Cmd-1, disk2.atr.
    • Control -> Enable BASIC, LOAD "D1:MEDITCM.BAS" <return> RUN <return> and configure MEDIT however you like.
      • Language: PAS
      • Tabstops: Set at 5 and +4 after the existing ones, because 8-wide tabs are crazy in a 40-column screen. Yes, I'm a tabs not spaces guy, OBVIOUSLY.
      • Margins: 1,40
      • Colors: 12,4,14 (sadly can't be 0 or 2 background luminance, because the cursor is black)
      • Flags: Tabs: Expand, Shift-Lock: No (starts in lowercase).
      • Save & Return to DOS.
      • You can just copy the MEDITPAS.ECF to MEDITTXT.ECF, etc., you don't need to run the tool for each language, but it doesn't have a default mode. Note you also have to copy these to each disk you're editing on, or it switches back to the stupid defaults:
      • DOS: C <return> D1:*.ECF,D2: <return>
      • DOS: L <return> MEDIT <return>, filename D2:HELLO.PAS, and enter: 
        program hello;
var c: char;
begin
  writeln('Hello, Atari!');
  read(c);
end.
      • <option> exit <start> to save & exit. Note return doesn't execute commands in MEDIT, start does. Kids Today™ have some meme about how hard it is to exit vi? Ha ha, they have no idea. RTFM.

  • Finally ready to program in Action! or Pascal, which is what I mainly did back in the day.

    • Deep Blue C: Tragically underpowered version of Small-C. I loved it as an intro to C, but didn't use C for real until the Atari ST. It did produce standalone binaries and the compiler was easy to use, IIRC. 
      UNSUPPORTED FEATURES
  Features in C not supported in DEEP BLUE C are:
  1) structures, unions
  2) multidimension arrays
  3) Floating point numbers
  4) Functions returning anything but int
  5) Unary operators: sizeof
  6) Binary operators: typecasting
DIFFERENCES FROM STANDARD C
  THE DEEP BLUE C language has the  following nonstandard features:
  1. The last clause of a "switch" statement, either "case" or "default", must
be terminated with a "break", a "continue" or a "return" statement.
  2. The ancient =<op> construct has been removed. Use <op>= instead.
  3. Characters are unsigned. Chars range in value from 0 to 255.
  4. Strings can not be continued on the next logical line.
  5. C source code lines can be a maximum of 79 characters long.
  6. Functions can have a maximum of 126 arguments.
SPECIAL SYNTAX
  C uses several ASCII characters not available on the ATARI computer's
keyboard. In particular the braces have been replaced by to two-letter
combinations $( and $), and the tilde has been replaced by $-.  The $ character
is not used in C, so your editor's find and replace command can be used to
convert standard c programs into a format acceptable to DEEP BLUE C.
    • Action!: Custom language on cart for Atari, fantastic built-in editor (later the basis for the Paperclip word processor!), had a disk runtime system so you could distribute programs (also on AtariMania). But it came out a little later than my Pascal adventures, and it's a weird super-low-level language, and I think I'm in no mood to relearn it right now. Super goddamned fast, tho. May get into this if I'm frustrated later.

    • APX Pascal: Excessively complex process with a disk swap for every compile, compiles & links into PCode, no explanation of how to boot it. This is a very user-hostile compiler.
    • Kyan Pascal: Maze of command line tools. Doesn't work, at least for me, on emulation. It cycles through the tools, but never actually builds anything, eventually crashes and corrupts video. Makes a big deal of being usable from RAMDisk, but that doesn't matter on modern hardware.
    • Draper Pascal: Which I used in the '80s. Hilariously bad editor (but I can use MEDIT, so fuck that), compiler just fucking works, but only produces PCode (.PCD), so has to start from bootdisk or run Draper's menu then your program, ick. But this was no trouble to get running, so it wins.
      • Insert drpascal.atr in drive 1, reboot, boots into a menu.
      • 3 Compile program: D2:HELLO.PAS
      • 1 Run program: D2:HELLO
      • Total success! \o/ Hit any key to exit the program.
      • Drive 1, boot.atr, Drive 2, drpascal.atr, reboot
      • DOS: C <return> D2:AUTORUN.SYS,D1:PASCAL.COM <return>
      • DOS: C <return> D2:INIT.PCD,D1:INIT.PCD <return>
      • Cmd-2, disk2.atr
      • So now I can: DOS: L <return> PASCAL.COM <return>
      • And run Pascal programs. I could make a more focused runtime menu for it, maybe dir & list all the PCD files, the INIT.PAS source is included. If I ask it to compile, it prompts to insert drpascal.atr, and then I can switch back, which is reasonable.
      • Standard library is small but effective, seems like it has all the BASIC equivalent commands, and enough POKE/PEEK/ADDR stuff to let me do everything, including Player-Missile Graphics.
      • I can presumably now move all my source and disk2.atr contents to H1, so they can be managed & edited on the Mac, but I just wanted to get things running first.
      • Probably make another gitlab project (and actually sync it from git) when I get somewhere with that.

This took quite a lot of my hobby time doing something harder than actual work, to be honest. But I'm in a good place with it now.

OS Compatibility and the Web

OK, not EOL yet, but soon. Long before any rational person would switch to an untested, incompatible new OS version. Among other things, anyone using Adobe software can't go to Catalina.

The policy I like is to support the last two or three major OS releases. There are good techniques in Objective-C to support testing for new features and falling back if you don't have them; I don't think most of those work in Swift, because Swift's an amateur hour language.

Happily, I use Feedbin to sync my RSS feeds rather than keep them all local, so when NNW stops updating I can just go back to a working web interface. Sad that Brent keeps resurrecting and killing his app, but that's what he gets for chasing Apple's tail.

This is why the web beats native applications. You can indeed make a better interface in native code; you can't maintain it, and you can't port it. The native dev is constantly chasing a new API that breaks everything past, and fighting with garbage tools like Xcode. The web dev just needs ed or another text editor, and only has to target the browser, which is a moving target but has backfills and a compatibility policy, and native browsers generally work on the last two major OS releases. Firefox is a UI shitshow, but still supports OS X 10.9 Mavericks (2013); Safari obviously is part of the OS, and the last few changes are making me strongly consider moving off it, but this Mojave version will keep browsing the web just fine long after Catalina is released.

The ideal of cross-platform languages ever since UCSD Pascal is to get the best of both worlds, write code once and have it compile and run everywhere, and ignore underlying OS changes.

BBEdit 13

The "Pattern Playground"
Added the Grep Cheat Sheet.

I've been doing regexp for 35 years, and still don't remember every pattern (especially all the ?= stuff). So what chance do normal people have?

BBEdit allows you to make rectangular selections in documents for which "Soft Wrap Text" is turned on.

Woo! I use this all the time in my MultiMarkdown tables (sadly, "Columns" doesn't recognize them) and it was annoying having to switch to hard wrap (where I can't read any paragraphs), wait for it to reflow, edit table, switch back to soft wrap, wait for it to reflow.

The "Deploy Site" command for configured web projects will now:
Generate and upload HTML for Markdown (and Textile, if any such are in use) files.
Perform placeholder and include processing on HTML documents (including HTML generated from Markdown and Textile, if applicable).

Interesting, now you don't even need a static site generator. I could rebuild my neocities site with this…

Big changes to the way appearance and color schemes are managed. Settle in for the read:

Thank goodness! I'd had a couple serious color scheme bugs over the last version, and now it seems like I don't have to constantly resave my color scheme if I tweak it. In addition, I see it's leaving saves of my color scheme in ~/Documents/BBEdit Backups (maybe too many, if I screw around with sliders instead of typing hex RGB).

And tons more, these are just the ones that affect me daily.