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.

Y C?

C has the great virtue that most computers have a C compiler installed or can get one from the vendor, and by typing:

% clang -o thing thing.c # or gcc if you must.

You get a binary that'll run on that platform. If you wrote your code sanely, you can recompile it on every major platform with no changes. If you find a place where a platform's different, you can add #if to fix that.

Contrast with every other systems language:

  • Do you have a compiler installed?
  • Is it portable?
  • Can you even fix non-portable areas?
  • Can you make a binary an end-user can run?
  • Can you call other libraries?

In C, the answer is always yes. In any other, it's "probably not, or only with great effort".

Someone was recommending Ada. It's not in standard gcc. You have to install something called "GNAT":

% sudo port install gnat-gcc
#  Ada is self hosted (http://en.wikipedia.org/wiki/Self-hosting)  #
#  You need to install an existing Ada compiler and then choose    #
#  an appropiate variant. For more info use:                       #
#  port variants gnat-gcc                                          #
% sudo port variants gnat-gcc
gnat-gcc has the variants:
   ada: Uses the MacPorts Ada (https://www.macports.org/) compiler to bootstrap!
   gnatgpl: Uses GNAT/GPL compiler (http://libre.adacore.com) to bootstrap!
   gnuada: Uses the GnuAda (http://gnuada.sourceforge.net/) compiler to
           bootstrap!
   macada: Uses MacAda compiler (http://www.macada.org) to bootstrap!
   odcctools: Use the odcctools instead of the system provided ones - does not
              work for x64 currently!

I dunno what to do here. MacAda hasn't been updated since OS X 10.4, which was 2005. I don't see any other ada in MacPorts. At this point I gave up and uninstalled everything. It's not a working language.

Go is fine except that it's a statically-compiled Java owned by Google, and every part of that is evil and wrong. The Rust Evangelism Task Force's constant whining has made me unwilling to even give all those &'s a chance, they're like digital Mormons. There's nothing really wrong with D Language except that it's not installed anywhere, and it's no safer than C for a lot of extra typing.

C isn't safe, but it's fast. It's pretty hard to use safely on large projects, but for small tools with static data buffers it's fine. You take some tradeoffs for any language.

For high-level programming, I love Scheme and JavaScript, and there's a ton of other good high-level languages. But if you need to write at the lowest level, and make it work everywhere, C's the only rational choice.

Fall of Visual Basic, Rise of QuickBasic?

There was simply no other tool that a developer could use to sketch out a complete user interface and get coding as quickly as VB.

Except Smalltalk on the Xerox Star (1981), ResEdit on Classic Mac (1984), RCS and ORCS on Atari ST (1985), Hypercard (1986), Interface Builder on NeXTstep (1988), and others; Visual Basic came out in 1991, Delphi came out in 1995. Maybe there was no other tool on brain-damaged DOS/Windows systems before VB, I can buy that, but real computers were doing RAD a long time ago.

Alan Cooper, the "father" of Visual Basic, has done some really interesting work with interaction design and user experience, but he didn't invent RAD. VB started life as his project "Tripod", a shell creation tool, basically a user-customizable program launcher or "wizard". Then Microsoft bought it and turned it into "Visual Basic", as a kind of ugly Hypercard (is BASIC a worse language than HyperTalk? Eh.)

VB became famous for a legendary feature called edit-and-continue, which allowed developers to run their programs, find problems, fix them, and then keep going with the new code. This was a sharp difference from almost every other programming environment known to humanity, which force developers to recompile their work and start over after every change.

This is, of course, utterly wrong. Every language with a REPL can do this: You write some code in the REPL, run it, it crashes or produces wrong results, you change the one offending function and resume. All global objects are still present, no recompile necessary.


#;2> (define (hello name) (error 'hello "Unimplemented")) #;3> (define (greetings) (for-each hello '(Cthulhu YogSothoth ShubNiggurath))) #;4> (greetings) Error: (hello) Unimplemented #;4> (define (hello name) (printf "Ia ia, ~A fhtagn!\n" name)) #;5> (greetings) Ia ia, Cthulhu fhtagn! Ia ia, YogSothoth fhtagn! Ia ia, ShubNiggurath fhtagn!

The one difference is that to save state, you have to copy-paste out of .csi_history or whatever. IDLE lets you save off your session history directly, but you still have to edit it into a working script. VB did have the virtue of staying in the live editor, but you're still just coding behind buttons, you have no access to a history or REPL.

(This is why I dislike DrRacket so much: If you edit code, it does destroy your global REPL state! Why even have a fake-REPL there, man?! Command-line Racket doesn't have this problem, but it's still not a great Scheme.)

Just as VB acquired the same power as C#, C# picked up the same conveniences as Visual Basic. For example, .NET’s type safety and memory management features meant that C# developers never needed to worry about memory leaks, just like VB developers.
In other words, C# now had the guardrails to protect hobbyists, students, and new programmers without surrendering its power. All of a sudden, VB was no longer something special. It was just another tool in a capable programmer’s toolkit.

Every part of that is… well, not correct.

  1. My understanding is VB.NET was a mess interacting with .NET resources, so if you used it you were still stuck in the VB gulag or had to learn so much C# or C you might as well move up.
  2. C# is a hard language to start up in, you would never give it to a newbie and say "good luck!"; although that's what Unity does, and most Unity code is nightmarish as a result.
  3. C# is certainly not "never need to worry about memory leaks"; it's a Java ripoff with more native libraries, many of which have dangerous C++ based memory management, and in any case you can over-retain things and fill up memory very quickly.
  4. No capable programmer is going to say "this project is best in… Visual Basic dot Net!" Except on broadcast TV-for-morons.

The one good thing from all this:

An innovative project called QB64 has created a modern QuickBASIC replica. It runs on Windows, MacOS, and Linux, with no emulator required.

OK, this is interesting. Terrible domain name www.portal.qb64.org though, what is happening there? Just qb64.org redirects to that mess.

Once you run the setup_osx.command, it has a qb64 binary, which opens a DOS-like window with the old DOS qbasic.exe UI. Huh. This isn't bad, though the font is small and the only way to change it is with a custom font. It ships with a cyberbit.ttf font which is pretty but very W I D E.

Writing something and hitting Run|Start dumps an untitled binary in the main directory. Saving (to the programs folder in this package) and then hitting the Run|Output EXE to Source Folder toggle does something more reasonable: hello.bas, hello, hello_start.command. A trivial program is 1186K, which is excessive, but it does work, opens a terminal and shows some text.

There's a ton of sample code in program/samples, including a lot of 3D stuff.

This is a pretty credible BASIC environment.

Pro:

  • Structured BASIC, if you want it.
  • You can just recompile on every platform.

Con:

  • No interactive REPL (that was one of the few things classic line-oriented BASIC, or hybrids like ST BASIC, had going for them).
  • Slow compile.
  • Ugly editor, though probably playing with fonts and colors would improve this.

You'll always be better off just giving a newbie Python, but some people may have old code or nostalgia.

  • Chipmunk BASIC is certainly nicer as an interactive environment, but probably hundreds of times slower.

Catalina Scripting

In particular:

Quartz Composer
Deprecations
Starting in macOS 10.15, the Quartz Composer framework is deprecated and remains present for compatibility purposes. Transition to frameworks such as Core Image, SceneKit, or Metal. (50911608)

Tragic but unsurprising. None of those are even remotely a replacement, being machine-level programming tools, not a graphical tool for assembling a graphics or sound workflow. But there's probably almost nobody using QC anymore, because Apple neglects it and won't promote any dev tools except horrible goddamned walking abomination Xcode.

Script Editor
Known Issues
Script Editor might quit unexpectedly when saving or executing scripts. (50470730)
Scripting Language Runtimes
Deprecations
Scripting language runtimes such as Python, Ruby, and Perl are included in macOS for compatibility with legacy software. Future versions of macOS won’t include scripting language runtimes by default, and might require you to install additional packages. If your software depends on scripting languages, it’s recommended that you bundle the runtime within the app. (49764202)
Use of Python 2.7 isn’t recommended as this version is included in macOS for compatibility with legacy software. Future versions of macOS won’t include Python 2.7. Instead, it’s recommended that you run python3 from within Terminal. (51097165)

More of the same, increasingly neglected non-Xcode tools.

Killing python2 is great. It's not clear if python3 will be included standard, or if you have to find that somewhere else.

On my old blog, I had a post "Macs Make Programmers", where I talked about all the great scripting languages and tools included in OS X, including Xcode back when it wasn't broken junk. Timmy Cook's Apple is making that very difficult.

So basically the first thing you need to do on a Mac is install MacPorts, sudo port install python3 and so on.


On the bright side:

This is a massive step up in security and usability. I was a long-time ksh user on HP-UX, Atari ST MiNT, and OS/2, switched to bash for Linux back in '95-ish, and went along with bash on OS X, even though the original default was tcsh. I switched to zsh in 2014, after the bash shellshock bug; and it was long overdue. Apple can't follow the current bash versions because they're under poisonous GPLv3, so even with shellshock patched it's still not safe. zsh is reasonably current and MIT-licensed so it can stay current.

You want one reason to switch right now?

F="foo bar"
rm $F

In bash, that removes two files, "foo" and "bar". In zsh, it removes one file, "foo bar" (you can get the Bash-like behavior of expanding args by rm $(echo $F), probably some other ways).

Terminal Condition

I spend half my time, easily, in a command-line terminal running zsh. So a new one, even one on an OS I don't run, is interesting:

There are some modern, nice conveniences in this. It's a little ways behind Mac Terminal.app (based on the NeXTstep Terminal from 1990), and vastly far behind iTerm2, but it's more advanced than the usual Linux terminals like rxvt, urxvt, or cross-platform Alacritty or Hyper.

Between this and WSL2 being a full Linux, it's plausible that the best Linux dev environment now (well, this summer when it's released) is Windows. The Year of the Linux Desktop is 2019, and it is owned by Microsoft®. Can you hear the tiny, distant screams of the FSF cultists?

Comparison based on code, reviews, and reddit thread with MS devs involved:

  • Scrollback: The single most important thing a terminal can do. MS does this, but doesn't have logging.

    Surprisingly, a lot of them only support a few pages. I keep mine at 10,000 lines or so, which is probably wasteful but so handy; I don't bother logging since my .zhistory keeps everything I typed, and I have Terminal.app and iTerm2 set to not close tabs automatically.

    Alacritty only just added scrollback last year.

  • Prompt Marking: Nope.

    This is a feature it's hard to live without once you've had it, no more paging up trying to see prompt lines (I have a red ANSI-colored prompt and it's still hard to see). In Terminal.app, Edit, Marks, Automatically Mark Prompt Lines, and then ⌘↑ and ⌘↓ move between them. iTerm2 has it enabled by default, and ⇑⌘↑ ⇑⌘↓ are the keys, which took me some re-learning.

    Nothing else has this, as far as I've seen.

  • Fonts: MS has programming ligatures and displays emoji, finally. Does not support RTL languages.

    I use Fira Code in all my editors and shells, and it's enormously helpful, more readable, and catches bugs: I look for === as a fat-equals symbol in JS, etc.

    Hyper, urxvt, Alacritty support Unicode fonts. rxvt stopped development almost 20 years ago so it barely shows 8-bit fonts correctly.

  • Tabs: MS has tabs! They're currently invisible until you add a second tab, same shit Terminal.app does, which annoys the hell out of me; I don't like UI that reshapes itself, reminds me of T-1000 Terminators (also makes it hard to tile my windows up correctly when they get resized).

    It's not clear if you can drag Windows Terminal tabs around to different windows.

    In iTerm2, I normally keep: First window with tabs for home shell, ssh into my server (running screen, so that has many open shells). Second window with 2 tabs for REPL, editor/running/compiling tasks, and sometimes a third tab for reading local docs. If I need more shells, I usually open them on the first window. I rarely open a third window for monitoring some long-running task; I just drag a tab out to its own window. All terminal windows are stacked on the left side of my screen, because there's no icons under that side of the Desktop.

    urxvt has tabs, but they're kind of a hack, not fully usable.

    Hyper has tabs, but they replace the title bar. Which is cool but also awful like a lot of things it does.

    rxvt and Alacritty don't do tabs, because they insist you use screen or tmux. Which sucks if you want to move a process from one window to another.

  • Profiles: MS supports multiple profiles, so you can use different ones for each task.

    So does Terminal.app, iTerm2, urxvt (but it's buried in a text file config).

    Alacritty, rxvt, and Hyper have a single profile and no UI for changing anything, hope you like editing text files and reloading.

    As far as I can tell, nothing else does automatic profile switching like iTerm2; when I cd to my ~/Code/CodeScheme folder, iTerm2 switches to my dark red transparent profile, including Scheme-specific triggers and copy/paste filtering.

    You can probably do that in urxvt's Perl(!) scripting, but it's not normal or easy.

  • Copy/Paste Filtering: Nope.

    iTerm2 and urxvt both let you set a bunch of regexp to run over lines to get selections correctly matching boundaries, not just space-delimited.

  • URL Highlighting: Nope.

    iTerm2, Hyper, and urxvt notice URLs and filenames, and let you click on them. In iTerm2, hold down ⌘ and click on any URL or path (like in an ls or find result!) and it does some useful action: Opens the URL in your browser or file path in your editor, by default, but you can configure that in the profile.

  • Custom Keybindings: Sorta? Doesn't seem complete, no idea if there's UI for it, but it does exist in their config.

    Most terminals can do this, but most can only remap a few actions. I like iTerm2's, as usual, which lets you bind any action, menu, or run a program on any keybinding. I mostly just use it to launch different profiles with starting paths & scripts.

    Terminal.app only lets you send specific text for a key.

  • Images: Sorta? Only if they're embedded in fonts.

    This is a neat trick in iTerm2: images. I use imgls all the time to see a thumbnail of every file with details (protip: I changed ls -ld in the script to ls -1Fskd for a more concise listing), and then ⌘-click to open what I want in Acorn; it's better than opening Finder and trying to read a long filename under a thumbnail.

    I'm unaware of anyone else being able to do this.

Tower of Babble

Programmers almost compulsively make new languages; within just a few years of there being computers, multiple competing languages appeared:

It proliferated from there into millions; probably half of all programmers with 10+ years of experience have written one or more.

I've written several, as scripting systems or toys. I really liked my Minimal script in Hephaestus 1.0, which was like BASIC+LISP, but implemented as it was in Java the performance was shitty and I had better options to replace it. My XML game schemas in GameScroll and Aiee! were half programmer humor, but very usable if you had a good XML editor. Multiple apps have shipped with my tiny lisp interpreter Aspic, despite the fruit company's ban on such things at the time. A Brainfuck/FORTH-like Stream, working-but-incomplete tbasic, and a couple PILOT variants (I think PILOT is hilariously on the border of "almost useful").

Almost every new language is invented as marketing bullshit based on a few Ur-languages:

  • C++: Swift
  • Java: Javascript (sorta), C#, Go
  • Awk: Perl, Python, PHP, Julia
  • C: Rust
  • Smalltalk: Objective-C
  • Prolog: Erlang, Elixir
  • ALGOL: C, Pascal, PL/1, Simula, Smalltalk, Java
  • LISP: Scheme, ML, Haskell, Clojure, Racket
  • BASIC: None, other than more dialects of BASIC.
  • FORTRAN: None in decades, but is the direct ancestor of ALGOL & BASIC.
  • COBOL: None in decades.

A few of these improve on their ancestors in some useful way, often performance is better, but most do nothing new; it's plausible that ALGOL 68 is a better language than any of its descendants, it just has mediocre compiler support these days.

Certainly I've made it clear I think Swift is a major regression, less capable, stable, fast, or even readable than C++, a feat I would've called impossible except as a practical joke a decade ago. When Marzipan comes out, I'll be able to rebuild all my 15 years of Objective-C code and it'll work on 2 platforms. The Swift 1.0 app I wrote and painfully ported to 2.0 is dead as a doornail, and current Swift apps will be uncompilable in 1-2 years; and be lost when Apple abandons Swift.

When I want to move my Scheme code to a new version or any other Scheme, it's pretty simple, I made only a handful of changes other than library importing from MIT Scheme to Chez to Chicken 4 to Chicken 5. When I tested it in Racket (which I won't be using) I had to make a handful of aliases. Probably even CLISP (which is the Swift of LISPs, except it fossilized in 1994) would be 20 or 30 aliases; their broken do iterator would be hard but the rest is just naming.

Javascript is a pernicious Herpes-virus-like infection of browsers and desktops, and nothing can ever kill it, so where it fits the problem, there's no reason not to use it. But there's a lot it doesn't do well.

I was leery of using FreePascal because it has a single implementation (technically Delphi still exists, but it's $X,000 per seat on Windows) and minimal libraries, and in fact when it broke on OS X Mojave, I was disappointed but I-told-you-so.

I'm not saying we should quit making new Brainfuck and LOLCODE things, I don't think it's possible for programmers to stop without radical brain surgery. But when you're evaluating a language for a real-world problem, try moving backwards until you find the oldest and most stable thing that works and will continue to work, not piling more crap into a rickety new framework.

The Biblical reference in the title amuses me, because we know now that it requires no malevolent genocidal war deity scared of us invading Heaven to magically confuse our languages and make us work at cross purposes; anyone who can write and think splinters their thought into a unique language and then argues about it.