thristian

There was a choose-your-own-adventure version of Paranoia on BSD Unix systems in the 1980s, looks like somebody's ported it to Python:

https://github.com/spkane/py-paranoia

It's not exactly a better Topaz, but I made Topaz Unicode to be more Topaz: https://gitlab.com/Screwtapello/topaz-unicode

Ah, it might be nice to mention that before the first code example, then. Or just use consistent case in the first example, to avoid distracting people with details that aren't the thing you're trying to demonstrate.

In the first code example in the readme ("First program"), there's `sdlcls`, `SDLinit`, and `SDLShow`. Is there some significance to the capitalisation?

In 1983, AT&T released the fifth version of Unix, called "System V". Part of the release was an ABI specification for how the different parts of the system would talk to one another. Notably, the main portion of the spec described portable things like the file-format of executables, and the details for each supported platform were described in appendixes.

The SysV ABI is still used to this day, although the specification itself has withered until only two chapters remain[1], and CPU vendors still publish "System V ABI appendix" documents for platforms that System V's authors could not have dreamed of[2].

C as an interface is going to be around for a very long time, like POSIX and OpenGL and the SysV ABI standard. C as an actual language might not - it might wind up as a set of variable types that other languages can map into and out of, like what happened to the rest of the SysV ABI specification.

[1]: https://www.sco.com/developers/gabi/latest/contents.html

[2]: https://wiki.osdev.org/System_V_ABI#Documents

I think it's from people reporting sports statistics for a player or team as "W:5 L:7" meaning "five wins and seven losses".

https://knowyourmeme.com/memes/l-and-w-slang

Steve Wozniak was incredibly foresighted when designing the Apple II, to make sure that expansion cards could disable the default ROMs and even disable the CPU, making this kind of thing possible. The article mentions a chunk of memory "used by peripheral devices"; every expansion card got its own slice of the address space, so you could plug a card in any slot and it would Just Work (maybe you'd have to tell software what slot the card was in). I was very disappointed when I "upgraded" to a 386 and suddenly cards had to be manually configured to non-conflicting IRQs and I/O addresses.

Pretty much, yeah! The difference is that in Python the function that calculates a single value looks like:

    foo(x)

...while the function that calculates a batch of values looks like:

    [foo(x) for x in somelist]

Meanwhile in Lil (and I'd guess APL and K), the one function works in both situations.

You can get some nice speed-ups in Python by pushing iteration into a list comprehension, because it's more specialised in the byte-code than a for loop. It's a lot easier in Lil, since it often Just Works.

APL and K are still pretty daunting, but I've recently been dabbling in Lil[1], which is something like a cross between K and Lua. I can fall back on regular procedural code when I need to, but I appreciate being able to do things like:

    127 * sin (range sample_rate)*2*pi*freq_hz/sample_rate

This produces one second audio-clip of a "freq_hz" sine-wave, at the given sample-rate. The "range sample_rate" produces a list of integers from 0 to sample_rate, and all the other multiplications and divisions vectorise to apply to every item in the list. Even the "sin" operator transparently works on a list.

It also took me a little while to get used to the operator precedence (always right-to-left, no matter what), but it does indeed make expressions (and the compiler) simpler. The other thing that impresses me is being able to say:

    maximum:if x > y x else y end

...without grouping symbols around the condition or the statements. Well, I guess "end" is kind of a grouping symbol, but the language feels very clean and concise and fluent.

[1]: https://beyondloom.com/decker/lil.html

It isn't really related to the Infocom that released the Zork games, except in a legal sense. Infocom was sold to Activision in 1986, and shut down as a studio in 1989. Circuit's Edge was published in 1990, labelled "Infocom" but just because that's the brand Activision chose to market it under.

You might be interested in YTree (https://www.han.de/~werner/ytree.html), UnixTree (https://www.unixtree.org/), or linuXtree (https://stahlke.org/dan/lxt/).

Brøderbund was the publisher of "Stunts", but not the developer. The developer was Distinctive Software Inc. who had previously developed the hit games Test Drive and Test Drive II: The Duel for Accolade. For whatever reason, Accolade developed Test Drive III in-house, and DSI developed Stunts on their own.

After Stunts, DSI got bought by Electronic Arts. They were briefly "Pioneer Productions" (or at least, people from DSI were part of that group within EA) and made the original Need For Speed, but eventually became just a part of EA Canada.

From the PuTTY FAQ: https://www.chiark.greenend.org.uk/~sgtatham/putty/faq.html#...

Would you like me to register you a nicer domain name?

No, thank you. Even if you can find one (most of them seem to have been registered already, by people who didn't ask whether we actually wanted it before they applied), we're happy with the PuTTY web site being exactly where it is. It's not hard to find (just type ‘putty’ into google.com and we're the first link returned), and we don't believe the administrative hassle of moving the site would be worth the benefit.

I wonder if they changed their mind because Google ceased to be a reliable way to find them.

The old 68k Macs are emulated with Basilisk II, which shims the mouse driver so it can just take mouse events from the host OS and move the cursor to the corresponding pixel on screen. The PowerPC Macs and NeXT boxes are emulated with a lower-level emulator that wants to get raw deltas from the mouse, not an absolute pixel position. If you just wave the mouse over the emulator, you'll get something approximating the expected movement (but much slower); once you click on the emulator it captures the mouse and you can use it as intended.

I agree it would be nice to have an "untransformed" view of the screen; I suspect the site might have been designed with the expectation of a high-DPI screen.

It took me a while to figure out that the nice product shots of Mac computers were actually live, interactive copies of the relevant operating system, running under emulation. Even the laptops with the screen at a weird angle from the camera.

And the emulator tracks whether you've done the things mentioned in the article, like open a particular control panel or tried a particular menu option.

This is amazing.

For some context about why a portable, user-friendly, hardware-level emulator for classic Mac systems is such a big deal, see this blog post from 2020: https://invisibleup.com/articles/30/

For game consoles, we've had emulators like Nestopia and bsnes and Dolphin and Duckstation for years.

For PCs, virtualisation systems like VMWare and VirtualBox have covered most people's needs, and recently there's been high-fidelity emulators like 86Box and MartyPC.

The C64 has VICE, the Amiga has WinUAE, even the Apple II has had high-quality emulators like KEGS and AppleWin, but the Mac has mostly been limited to high-level and approximate emulators like Basilisk II.

SimpleX is cool, but it has VC investors, so a lot of people won't trust it long-term (for exactly the same reasons we're talking about replacing WhatsApp now).

You can make a chat backup, but it's an encrypted binary blob, not a mailbox file or a JSON file or some other more accessible format.

I think I understand why they do that (if you send someone a message on Signal, they try very hard to make it difficult for anyone but the recipient to read it, whether that's by intercepting traffic or reading data stored on your device, or rummaging through your backups) but it does make it a bit of a pain.

It replaces the "list of short shell-scripts" aspect of Make, but it doesn't replace the "only execute rules that need to be re-executed" part, which is the actually useful bit.

No, Python's current type annotation syntax was added in Python 3.0 as a generic annotation syntax, in the hope that somebody else might come along and build a type-checker or other tooling on top:

https://peps.python.org/pep-3107/

MyPy was one such tool, and I think it had conventions for adding type annotations in comments, in places where Python didn't yet support them (such as variable assignment), but I'm pretty sure it was never a TypeScript-style pre-processor - type-annotated programs always ran directly in the unmodified CPython interpreter.

I can recommend The Further Adventures of Nick Danger as a decent introduction to Firesign Theater (It's on YouTube). A lot of the other stuff I've heard is chaotic to the point of confusion, but Nick Danger does have an actual story that resolves in the traditional way.

If you're wondering what a 32-bit descendant of the 6502 might have looked like, especially one that incorporated the "radical simplicity" ideas of RISC alongside the radical simplicity of the original 6502, there's already an era-appropriate design you can study: the original 32-bit ARM.

In an 2014 interview¹ with the Computer History Museum, Bill Mensch said:

> We think of ARM as our prodigal son. Got to do what they got to do, and it's not something I want to do, but I'm proud of them. They started with my technology, and I wish them well.

¹: https://archive.computerhistory.org/resources/access/text/20...

Icelandic names follow that pattern. Björk's full name is "Björk Guðmundsdóttir" because she is the daughter of Guðmundur Gunnarsson.

English-speaking countries generally don't do that. For a long time people had only first-names, and disambiguated with nicknames or patronymic names where necessary. Eventually as society got larger and more complicated, governments started legally requiring people to have surnames, and they more or less stuck. If you meet a John Williamson today, his father probably isn't called William, but he's probably descended from a William who lived in the late medieval/early modern era.

VisiCalc, the first computerised spreadsheet, was released in 1979. Presumably there were non-computerised spreadsheets, actual large sheets of paper, used for calculations before that.

The fact that U+D800-U+DFFF are reserved means that it's generally pretty easy to distinguish UTF-16 text from UCS-2 text - if you spot even one 16-bit value in that reserved range, it should be UTF-16.

This property is not true of UTF-8 - if you get a byte-string with bytes between 0x80 and 0xFF, it might be UTF-8, or it might be one of a bunch of other encodings, you need to do a more involved check to be sure.

Granted, the presence of a value between 0xD800 and 0xDFFF does not guarantee that the text is UTF-16, that's why this "WTF-8" encoding exists. But confusion would be a whole lot more likely if the U+D800-U+DFFF range were not reserved.

The robustness principle is really just another way of stating the Golden Rule.

Today I learned that, like Windows NT, the first version of Apple DOS was numbered 3.1.

Since POSIX 2024, `set -o pipefail` is no longer a bashism!

Pretty sure it just means "touching grass", as in "step away from the computer, walk outside, put your hand on a patch of grass". Previous generations might say "stop and smell the roses", although that idiom is generally less literal.

As long as humans are writing things, they will try to come up with new things to differentiate themselves from the humans who'd gone before, those things will be written down, and we'll probably need new code points to express them properly.

The alternative to "a new version of Unicode every year" is not stasis, but rather new and incompatible encoding schemes frothing like JavaScript frameworks.