RodgerTheGreat

It's always a delight to read about your projects, Oscar. Every program is a jewel.

There's loads of slop and slop enthusiasm on lobste.rs; the only difference is that they have a moderation policy which forbids the most egregious forms of advertising and astroturfing.

Or being caught, but without sufficiently rigorous evidence to take to court.

Sounds fascinating. Is there anywhere we can read more about this preservation effort? Does the PB-2000C have an active user community today?

The standard problem with "just voting" to solve problems is that you can only vote for the options you're offered. If all the options on the market suck, voting for the lesser of the available evils will not address the fundamental source of your dissatisfaction, and may help entrench it. If you vote "with dollars" there's the additional problem that dollars are not uniformly distributed, and a few wealthy "voters" can and will disenfranchise everyone else.

Abstaining from buying from companies you disagree with can help, but it is only one part of the broader solution. When there aren't alternatives yet "on the market" you may be forced to hold your nose for a while and buy from the vendors you hate while advocating for change and working toward their replacement. You don't have to solve every problem in your world at once so long as you're building in the right direction.

I don't have an extremely high opinion of sdl2-compat specifically because my SDL2-based projects have had several bizarre bug reports which originated in downstream packages presuming they could use this "compatibility layer" instead of the actual dependency I develop and test against.

The changelog for this project dates back to 2019, well before SDL3 was available. SDL2 supports some older platforms that SDL3 has deprecated. If you value running on those deprecated platforms and/or you don't need any of the features introduced since SDL3, it's quite reasonable to stick with SDL2.

Not pictured: the walkman-sized box containing the rest of the TV that attached to the watch via a hefty umbilical cable.

The alert[] function prompts the user for input. The second "string" argument indicates the prompt will ask for a string, and return it. (alert[] can also ask for other datatypes, like a yes/no "boolean" prompt or a multi-choice selection from a list or dictionary of options.)

The colon (read aloud as "becomes" or "gets") is Lil's assignment operator. That single line,

    myname.text:alert["What is your name?" "string"]

prompts for input and then stores the result in a card field. If you wish, you could also write it as:

    on click do
     name:alert["What is your name?" "string"]
     myname.text:name
    end

Learning the syntax for calling functions is partially scaffolded by the "Action..." dialog that button widgets offer for constructing simple button scripts with a GUI:

    on click do
     go["Next" "BoxIn"]
     play["sosumi"]
    end

Users can rely on the system to write code for them initially, and then slowly dip their toes into more complex compositions. Whereas HyperTalk has custom syntax for almost every programming construct and built-in function or feature, the Lil grammar is simple and uniform. Where symbols appear, they have a single meaning. Decker's "Listener" REPL allows the user to have a back-and-forth "conversation" with the Lil interpreter and see responses juxtaposed with their questions, versus the HyperCard "message box" which shows only user input or a single system response.

Ultimately, every programming language does require some degree of handholding and learning, and that's why Decker comes with dozens of example decks to take apart and study. The user community has also furnished some truly fantastic interactive tutorials:

https://ahmwma.itch.io/phield-notes

In Decker, most of this example would be similar. The button's default script template would be:

    on click do
    
    end

And filling it in with an equivalent script would be something like:

    on click do
     myname.text:alert["What is your name?" "string"]
    end

There is slightly more "programming-language-like" punctuation to Lil than HyperTalk, but simple examples are still simple, and in my opinion having first-class collections (lists, dictionaries, tables) and a richer set of APL-like operators makes Lil scale up much better to more complex programs. As a child I recall struggling tremendously with HyperTalk's "almost-english" structure; it made scripts easy enough to read and understand, but provided very little help when it came to writing new scripts.

Decker has a similar Widget -> Card -> Deck event bubbling hierarchy to HyperCard, and in my opinion retains much of the same directness and simplicity for simple applications. The differences in approach won't please everyone, but they are all carefully considered, and have been refined over time based on feedback from the user community. Decker is a living, growing platform!

Decker heavily emphasizes the concept of "reified data", representing information as tangible entities within a deck.

You can create "contraptions" as specialized data containers/editors for specific applications:

http://beyondloom.com/decker/decker.html#customwidgets

For example, "WigglyKit" offers several contraptions which operate on a shared convention for representing animated images:

http://beyondloom.com/decker/wigglykit.html

You can also represent composite data as a series of cards in a deck, or use cards as encapsulated "objects" that you communicate with via events:

http://beyondloom.com/blog/sketchpad.html#cardsarerecords

In a pinch, you can also easily encode arbitrary data in fields as a JSON superset with their ".data" attribute.

I use personal applications written in Decker on a daily basis.

There are over 300 games, zines, visual novels, and toys built with Decker on itch.io: https://itch.io/games/tag-decker

Last month saw the first game made entirely in Decker published on Steam: https://store.steampowered.com/app/4693460/The_Dreams_in_the...

We are neither living in the past nor wasting our time.

Decker prefers integral upscaling. On most browsers, "Decker -> Fullscreen" in the menu (or "app.fullscreen:1" from a script) will enable "stretching", but this feature is not supported by Safari on iPhones last time I tested.

Decker fonts are composed of fixed-size bitmaps. The included example "fonts.deck" has a variety of additional fonts to choose from in various sizes, and an editor:

https://beyondloom.com/decker/fonts.html

We also recently gained a library for working with vector-based text:

https://beyondloom.com/decker/hershey.html

Asking for good-faith compliance, and failing that, simply waiting for slop enthusiasts to publicly brag about using LLMs to break the rules. All evidence suggests that it is impossible for slop enthusiasts to resist outing themselves for any significant span of time.

LLMs are in essence an attack on the concept of written language, harvesting and dissolving the social contract that underpins it; it is no longer safe to assume that text has intent, let alone content, simply because it is grammatically well-formed.

Perhaps the most darkly amusing consequence of this particular mania is that by poisoning the majority of our information environment with hallucinated slop, we have likely crippled the next several generations of machine-learning techniques before they're even invented! Small, locally-hostable LLMs will rattle along spewing spam long after the broader "genai bubble" pops, and building clean training datasets will permanently be more difficult and expensive.

A Quadra 700 could run A/UX 3.0 or higher, which would make it relatively pleasant for the macs and unix workstations to interoperate (provided you spared no expense).

The articles you publish are, in principle, a celebration of the cleverness in programming and hardware design behind video games; a vehicle for appreciating human craftsmanship and artistry.

LLMs are the product of taking the creative output of countless millions of people and turning it into a statistical model which completely erases the attribution for all that material. They can regurgitate interpolated, plagiarized copies of someone else's code, divorced from its original context, but they are structurally incapable of showing where that code came from, who wrote it, or why.

Using these tools, and using your public profile to contribute to the normalization of these tools, is profoundly disrespectful to the programmers, artists, and writers whose work was strip-mined by megacorporations to build those LLMs. You are prioritizing your personal convenience while enriching bad actors who are bent on obliterating the open web, open-source culture, and the craft of programming. It's dissonant.

It's tremendously disappointing to see Fabien stoop to using slop for his research; completely antithetical to the love for software craftsmanship I had inferred from his previous work.

How many places do you have Bash, but not AWK?

I'd like to know more about how this is built. A stripped-down mac emulator? Does it leverage any of the existing libraries for decoding the HyperCard stack format, or something novel?

Lisa and early MacOS are tremendously different in their details than the Alto operating system. While there was clearly a transfer of inspiration, Apple engineers like Bill Atkinson made countless small and large innovations to simplify the Xerox GUI model and improve its usability based on extensive in-house R&D and user testing (and in some cases implement features that the Apple team presumed Xerox had but actually didn't exist on the Alto). It is simply ahistoric to build narratives around Apple stealing Xerox ideas wholesale.

For more details on Apple's early UI evolution, Atkinson kept polaroids of a variety of prototypes and mockups: https://www.youtube.com/watch?v=Qg0mHFcB510

I think the key thing is that nothing about Decker or Lil was specifically designed or tweaked for this use case; Everything I needed to build the hershey module and make it reasonably efficient was already at my fingertips. I considered bundling up some of the patterns I describe in this article as a library, but I think it's much better to view them as transparent idioms to adapt to wherever they're needed, letting the abstraction live in your head instead of the source file.

As I wrote about two years ago in "The Benefits of Conforming", Lil's approach to handling mismatched dimensions for conforming arose from a need to plug the semantic gap left by K and Q, since Lil doesn't believe in runtime errors. While evaluating my options I made a series of pleasant idiomatic discoveries that ended up also being useful for "hershey". There is perhaps an argument that if I'd "preferred" the length of the right argument instead of the left some expressions would require fewer parentheses, but I suspect it's a wash either way.

The design of heading/mag/unit were influenced by my work with oK and iKe, particularly my annoyance at the clunkiness of writing things like {(cos x;sin x)}' or wrangling with atan2[;]. The Lil primitives help expressions "flow" together nicely, with few intermediate variables and minimal nesting. I think I spent more time agonizing over reasonably intuitive names for them than I did puzzling over semantics. I'm quite pleased with these primitives as some of Lil's hidden pearls, and I hope I can inspire other arraylangs to incorporate something similar.

Here's another 8-page zine maker, built with Decker: https://micpp.itch.io/hybrid-zine-template-for-decker

Measuring education in dollars spent is rather consistent with measuring the productivity of LLMs in lines of code excreted.

The point is that https-everywhere people have successfully pushed the majority of the sites that could previously be served over vanilla http to require https anyway. Now if you're on and old device you need an https proxy or else you're out of luck.

"Accessibility" is an open-ended set of functionality, not a checkbox; it is never "complete", there is always room for improvement. Colorblind support (which ones)? High-Contrast mode? Adjustable text size? Screenreader integration? Localization? IME support? Keyboard navigation? Keyboard remapping? Functional entirely without a keyboard? Touch support? Pen support? Dyslexia-aiding typefaces? The list goes on and on.

Not especially. Depending on where you set your standards for "holding a conversation" you can satisfy the requirement with a classical markov chatterbot, a well-trained parrot, a copy of Eliza, or a telemarketer flowchart drawn on a sheet of paper. Only the markov bot is made out of "weights" in the sense of a statistical model.

Parrots are intelligent animals, albeit with a limited capacity for vocabulary and syntax compared to a human, and Eliza and the flowchart are made out of explicitly encoded rules and conversational tactics.

If you want to use a REPL as a pleasant calculator you really want an APL-family language or a modern concatenative language like Factor. Sexprs are horrendously verbose in comparison.