RodgerTheGreat

I wrote a blog post some time ago which contrasts the "Schwartzian transform" with the slightly clearer alternative used by most APL-family languages and (in my opinion) an even cleaner approach which is possible in languages with a first-class table type: https://beyondloom.com/blog/rankingoffruits.html

Lil has a GUI "system" in the form of Decker, which can export programs as standalone single-file HTML documents: http://beyondloom.com/tools/trylil.html

...and plenty more folks who lost their shirts- or even just their pizza money- on crypto scams in order to subsidize those millionaires.

You're thinking of a discussion about a hypothetical variant of the radio button, a "one or more" UI element. Discussion here on Lobste.rs:

https://lobste.rs/s/v6mkz6/implementing_one_more_ui_componen...

The bitter lesson says more about medium-term success at publishable results than it does about genuine scientific progress or even success in the market.

The point is that every idiom beagle3 noted is a simple and straightforward combination of general building-blocks, whereas nearly all of your "equivalents" are a one-off special-cased feature or function that needs to be learned on its own. The power and expressiveness of APL-family languages comes from the fact that they have a very small number of well-chosen parts that can be combined in flexible ways. Those patterns of combination become a higher-level vocabulary that fluent programmers grasp at sight, much as experienced readers of English learn to recognize the shapes of entire words at a time. This type of visual pattern recognition is facilitated by brevity.

APL-style idioms are not at all comparable to functions on a class or within a library, because idioms are self-describing in their entirety, requiring only an understanding of the primitive operators of the language, whereas a named function obscures and subordinates detail.

Decker works like TiddlyWiki. I agree that a fully decentralized self-replicating approach is the ideal way to distribute this type of application/tool; even very restrictive environments would permit using and sharing single-file apps that run in a web browser.

CardStock[0] isn’t mentioned in this article, but seems broadly similar in goals and approach to Scrappy. Unlike Scrappy (so far as I can tell) CardStock is open-source and can be run locally.[1]

Decker[2] (which is also open-source) has answers to several of the things outlined on Scrappy’s roadmap, including facilities for representing and manipulating tabular data with its query language and grid widgets and the ability for users to abstract collections of parts into reusable "Contraptions".

[0] https://cardstock.run

[1] https://github.com/benjie-git/CardStock

[2] http://beyondloom.com/decker/index.html

You might find some interesting ideas in Lil, which is also a kdb+ descendant: http://beyondloom.com/tools/trylil.html

All four of your examples are situations where an LLM has potential to contaminate the structure or content of the text, so in all four cases it is clear-cut that the output poses the same essential hazards to training or consumption as something produced "whole cloth" from a minimal prompt; post-hoc human supervision will at best reduce the severity of these risks.

Freedom to modify any part of your environment live in an Image is wonderful when your changes work perfectly, and horrific if you make any low-level mistakes; you can easily destroy the tools necessary to back out changes to your tools. It gets even worse in a world where you might run code from someone else with malicious intent!

I think it's generally better to aim for what the old C2 wiki called "Alternate-Hard-And-Soft-Layers": substrates that are less malleable with dynamic layers floating on top. We can do much better in terms of malleability than mainstream operating systems without descending into the complete insecurity and fragility of a classical Lisp Machine or Smalltalk environment.

Decker has a range of primitive UI widgets like buttons, fields, sliders, spinners, and grids. Decker's font editor[0] is a moderately complex application which uses a variety of widgets.

It's also possible to build new widgets with arbitrary appearances and behaviors like date pickers, radio buttons, or tab-bars via "Contraptions"[1]. The community forum has a collection[2] of Contraptions to suit various applications; sharing or re-using them across decks is as simple as copying and pasting a widget.

[0] https://beyondloom.com/decker/fonts.html#font

[1] http://beyondloom.com/decker/decker.html#contraptions

[2] https://itch.io/t/2690007/the-contraption-bazaar

A similar tool I wrote several years ago: http://beyondloom.com/tools/dith.html

Some programs, games, and zines made with Decker: https://itch.io/games/tag-decker

Unlike LiveCode (or so far as I am aware HyperNext), Decker is free and open-source: https://github.com/JohnEarnest/Decker

HyperNext doesn't appear to be actively developed; the most recent updates I see are from last year, and it can't be used on modern computers. Decker's most recent release was yesterday morning.

I'd be happy to go into more detail if you like.

A closer comparison than Pico-8 might Bitsy or PuzzleScript, but with all the power (and complexity) of arbitrary JavaScript code underneath.

Since you already seem to be a fan of Python, how about CardStock? https://cardstock.run

There's also Decker, which by default is tightly sandboxed but has opt-in APIs for filesystem IO, invoking external processes, etc: http://beyondloom.com/decker/

At least when you mentor an actual junior developer they often learn, and you can take satisfaction in aiding the growth of a human being. All the time and effort spent coaxing an LLM to "do better" either disappears in a puff of smoke the next time it goes schizoid and needs to have its context cleared or- at best- is recorded to help a for-profit company train their next generation of products.

Like everything else about the "GenAI" fad, it boils down to extractively exploiting goodwill and despoiling the commons in order to convert VC dollars into penny-shavings.

if and only if a piece of eval'd code has the ability to produce harmful (let alone observable) side effects, which in a functional language will in turn largely be a consequence of what is imported into the code's scope.

Many practical applications of eval() boil down to accessing (and perhaps manipulating) scopes in a manner which the host language does not normally allow. Likewise, many potential dangers or pitfalls of eval() relate to how it allows (or does not allow) dynamically-assembled code to inherit access to some spatial or temporal scope of variables, definitions, "unsafe" libraries, and so forth. The interaction of eval() with scope is much a much more interesting design question than whether it accepts an AST, a string, or something in-between, except to the extent that non-stringy "programs" represent some form of reified closure.

The 1971 Willy Wonka & the Chocolate Factory adaptation seems to strongly hint at the interpretation that Wonka planted the golden tickets deliberately, rather than distributing them randomly, which is of course why "Arthur Slugworth" is always right around the corner when a ticket is discovered.

APL arrays are values in the same sense as value types in any functional language. You don't explicitly modify arrays in-place; if they happen to have a refcount of 1 operations may happen in-place as an optimization, but not in a manner which observably alters program behavior.

Worth noting: TinkerCAD is capable of parametric modeling in "CodeBlocks" mode. I prefer writing OpenSCAD (by hand, rather than via a warmed-over markov chain), but having the option within something as inviting as TinkerCAD seems great for beginners.

Ending a paragraph with "/s" is a moderately common convention for conveying a sarcastic tone through text.

Mini vMac runs wonderfully on an OLPC XO-1 if you build it from source.

How about the ZeroWriter Ink? https://www.crowdsupply.com/zerowriter/zerowriter-ink

The focus on the bundled firmware is word processing, but it's open-source and built around the popular ESP32 microcontroller family.

Plenty of LTR languages to choose from, especially concatenative languages like Forth, Joy, or Factor.

The APL family is similarly consistent, except RTL.

Sure! But many, many useful programs will never need to grow to millions of LoC or thousands of developers.

"What's good for Milo Minderbinder is good for the world."

In practice most of those APIs are also gated behind a user's informed consent to e.g. enable access to a webcam or some other sensitive kind of I/O. I'd argue that the HTTPS delivery side of the requirements is superfluous theater pushed by "HTTPS Everywhere" ideologues and doesn't actually enhance the real security and privacy benefits already afforded by requiring manual user interaction.

The application package you're looking for is a single HTML file with no external dependencies, especially if it avoids minification, obfuscation, or the use of technologies like WASM blobs which require complex external toolchains to disassemble or modify. This is very achievable right now! See tools like TiddlyWiki or Decker, for example.

The primary barrier to an entirely server-free or server-agnostic webapp ecosystem is browser vendors choosing to seal the newest JavaScript APIs behind "secure contexts" which are only available to documents served over HTTPS.