RodgerTheGreat

Why not both? When you make tools that putrefy everything they touch, on the back of gigantic negative externalities, you share the responsibility for making the garbage with the people who choose to buy it. OpenAI et al. explicitly thrive on outpacing regulation and using their lobbying power to ensure that any possible regulations are built in their favor.

Looking forward to seeing all the slop enthusiasts pipe up with their own llm-oriented version of the age-old dril tweet:

"drunk driving may kill a lot of people, but it also helps a lot of people get to work on time, so, it;s impossible to say if its bad or not,"

There's still an obnoxious slop image front-and-center, full of nonsense typos. Not a good look for any educational resource.

You must sign in to view this post.

It's definitely far easier to emit a controlled, useful subset of PDF than it is to parse PDF documents. I wrote a small PDF library for the Decker ecosystem that just focuses on bitmaps and page layout; roughly 4kb and 135 LoC.

docs/demos: https://beyondloom.com/decker/pdf.html

browsable source: https://github.com/JohnEarnest/Decker/blob/main/examples/dec...

Glad to see you're aware of Decker. It addresses a number of the shortcomings of HyperCard that you specifically call out: basic sound editing and recording are built in and can be wired up without custom scripting, "Decks" are portable, and can be saved as standalone self-contained .html files, the script editor has mildly more powerful editing features like block indenting and a REPL, color is paletted, but a first-class feature, and fields can contain true hyperlinks (whose behavior can be freely overridden with scripts).

There's also quite a bit of novel functionality, like easy mechanisms for defining new brushes, new transitional visual effects, and even custom "widgets". Decker has grids and a SQL-like query language for working with bulk data, and a growing ecosystem of libraries and tools. Development is ongoing! The scripting language, Lil, is deliberately unlike HyperTalk, but tries to thread the needle between offering accessibility to beginners and power tools to experts. (It's secretly in the APL family.)

If you give it a chance, I hope you'll find that Decker is much more than a superficial imitation of HyperCard's look and feel.

If anything, Python programmers should be mortified that PSF leadership includes someone who seemingly spends all his free time and social capital trying to normalize slop and downplay the negative externalities of a bunch of companies that openly wish to undermine software authorship, depress programmer wages, and obliterate career opportunities for novice programmers.

He's a salesman pushing an entire industry who regularly receives special treatment and access from LLM vendors. The fact that he's open about getting these favors and subtle enough to sprinkle his salesmanship with a thin veneer of skepticism and plausible deniability doesn't make it any less of a grift.

It's rather disheartening to see new chip8-related projects which reference Octo, modern test ROMs written with Octo, and still see a citation for cowgod's egregiously incomplete and misleading documentation.

Yes. I consider Octo feature-complete, but I still address bug reports.

The New Yorker's primary editorial thrust has always been that the author is more important than the subject, and the journey is more important than having a thesis at all.

A sadly typical flavor of essay: a lisp enthusiast who believes that learning lisp has made them into a uniquely Very Smart Boy who can think thoughts denied from programmers who use other languages. The "blub" paper asserts that there exists a linear hierarchy of goodness and expressiveness in languages, where lisp, by virtue of its shapelessness, exemplifies the pinnacle of expressiveness.

This is a profound misapprehension of the nature of language design. Languages exist within contexts, and embody tradeoffs. It is possible- common, even- to fully grasp the capabilities of a language like lisp and still find it inappropriate or undesirable for a given task. Pick any given context- safety-critical medical applications, constrained programming for microcontrollers or GPUs, livecoding environments where saving keystrokes is king- and you can find specialized languages with novel tools, execution models, and affordances. Perhaps it never crossed Paul Graham's mind that lisp itself might be a "blub" to others, in other situations.

The idea of a linear hierarchy in languages is the true flatlander mindset.

The turtle/tortoise note is correct for UK English, but in the US (where Id software was headquartered during the development of Quake), tortoises are considered a subset of "turtles". Per Webster:

> Turtle (noun): any of an order (Testudines synonym Chelonia) of terrestrial, freshwater, and marine reptiles that have a toothless horny beak and a shell of bony dermal plates usually covered with horny shields enclosing the trunk and into which the head, limbs, and tail usually may be withdrawn.

There are a number of dynamic languages to choose from where tables/dataframes are truly first-class datatypes: perhaps most notably Q[0]. There are also emerging languages like Rye[1] or my own Lil[2].

I suspect that in the fullness of time, mainstream languages will eventually fully incorporate tabular programming in much the same way they have slowly absorbed a variety of idioms traditionally seen as part of functional programming, like map/filter/reduce on collections.

[0] https://en.wikipedia.org/wiki/Q_(programming_language_from_K...

[1] https://ryelang.org/blog/posts/comparing_tables_to_python/

[2] http://beyondloom.com/tools/trylil.html

The value proposition for AWK is very different from Perl. AWK is a tiny language that can be learned quickly, and it's ubiquitous: a hard requirement for even the most bare-bones POSIX environment. AWK is on your machine already; Perl may not be. If you have to install Perl, you could just as easily install any one of hundreds of alternative scripting languages.

AWK scripts don't have any kind of dependency management features, so they naturally lend themselves toward being freestanding and self-contained. Perl, on the other hand, has a massive package ecosystem with transitive dependencies and widely varied quality and design aesthetic, amplified by the baroque design of the language. AWK is as close as a language can be to immune to dependency hell.

When Perl was new, perhaps many people saw it as "a better AWK", but I suspect most of the newcomers to AWK today don't see it in relation to Perl at all.

ngn/k is a performant FOSS implementation of k6, but it has many constraints and limitations that may make composing large programs difficult. It may be the best dialect for tinkering and learning the language. https://codeberg.org/ngn/k

oK is a slow browser-based FOSS implementation of k6, with fun bells and whistles like "iKe", a visual livecoding environment. ngn/k and oK have diverged a bit, but are largely similar: https://github.com/JohnEarnest/ok

Q is a K-derived language built into kdb+; this is probably the most commercially viable dialect to learn, with the best educational materials (I recommend Nick Psaris' Q Tips), but it is proprietary, with (last I checked) free licenses available for personal use.

If you've seen Decker you may also have been exposed to Lil, which is similar in many ways to Q. It is more verbose and less expressive than Q or K, but I've generally heard people say they find it comparatively accessible: http://beyondloom.com/tools/trylil.html

I have experience working with large codebases in K. In practice, most of those codebases don't look dramatically different from any other garden-variety dynamic language. The high-level architectures are similar, and intrinsically-serial business logic still tends to have a lot of named function calls and conditionals. The algorithmic parts, where real work is happening, shrink down to little clusters of operators here and there. Prototypes of new systems and services can be written in a terse, brick-of-code style like some of the K you may find online, but as they get integrated into larger systems they tend to grow comments, descriptive identifier names, and shorter, more diff-friendly lines.

I've never found it hard to come back to reading K after long absences, in no small part because the set of primitives in K is a small fraction of the set in J (or uiua) and the notation, while terse, is more suggestive and legible to me than J's emphasis on digraphs and forks, or the "unicode-soup" of mismatched characters that some modern APL descendants reach for. K is an equally excellent notation for experimenting in a REPL or discussing ideas on a whiteboard.

For the sake of the patients, I hope there's a better long-term service plan than Second Sight Medical Products had:

https://en.wikipedia.org/wiki/Argus_retinal_prosthesis

very important things should have short names. locals you're immediately operating upon should have short names. short names should be used in a consistent way.

less important things can have longer names. variables in a broader scope can have longer names.

if you have a hundred different vectors, don't just dump them in a pile; put them in dictionaries, tables, namespaces, or scopes.

i'm a fan of

    t=\:t:!x

MATLAB doesn't have a FOSS implementation that runs in a browser.

A few more examples in K and Lil where pervasive implicit iteration is useful, and why their conforming behavior is not equivalent to a simple .map() or a flat comprehension: http://beyondloom.com/blog/conforming.html

Use your imagination a little; I'm sure you can come up with several variants that are an even viler and more exploitative/manipulative idea than the product as it stands.

Let your kid call a crude simulacrum of dead relatives, let religious folks call a crude simulacrum of $DEITY, make an "adult" version that crudely simulates a phone-sex hotline (charge extra to recharge the minutes on that one obviously), etc, etc.

The Birth & Death of JavaScript wasn't talking about WASM, it was talking about Asm.js, which crucially differs from WASM by being a backwards-compatible subset of JavaScript amenable to JIT compilation. The goals of these standards look similar if all you care about is transpiling c and running it on a browser, but Asm.js worked everywhere from day zero modulo performance; WASM continues to be a moving target.

For contrast, here's how I'd handle the example given on the front page in Lil[0]:

    i:"%j" parse shell["curl -s https://api.weather.gov/gridpoints/BOU/63,62/forecast"].out
    t:i.properties.periods..temperature
    o.average:(sum t)/count t
    o.minimum:min t
    o.maximum:max t
    show[o]

Lil doesn't have implicit parsing of .json arguments like Blots- certainly a nice feature for the niche Blots is aimed at. Lil also doesn't have an arithmetic average as a builtin like Blots, but in this case it's easy enough to do without.

The biggest difference here is how Lil handles indexing: The ".." in that second line can be read as "for every index"; a wildcard. I can follow the mapping that occurs in Blots' "via" expression, but I find it less clear in this example.

It can also be nice to treat lists-of-objects as proper SQL-like tables:

     select number name temperature windSpeed from table i.properties.periods
    +--------+-------------------+-------------+---------------+
    | number | name              | temperature | windSpeed     |
    +--------+-------------------+-------------+---------------+
    | 1      | "This Afternoon"  | 54          | "14 mph"      |
    | 2      | "Tonight"         | 46          | "3 to 12 mph" |
    | 3      | "Wednesday"       | 69          | "5 mph"       |
    | 4      | "Wednesday Night" | 45          | "3 mph"       |
    | 5      | "Thursday"        | 79          | "5 mph"       |
    | 6      | "Thursday Night"  | 49          | "5 mph"       |
    | 7      | "Friday"          | 83          | "2 to 6 mph"  |
    | 8      | "Friday Night"    | 52          | "6 mph"       |
    | 9      | "Saturday"        | 81          | "3 to 8 mph"  |
    | 10     | "Saturday Night"  | 53          | "3 to 8 mph"  |
    | 11     | "Sunday"          | 81          | "3 to 7 mph"  |
    | 12     | "Sunday Night"    | 54          | "3 to 7 mph"  |
    | 13     | "Monday"          | 77          | "3 to 7 mph"  |
    | 14     | "Monday Night"    | 53          | "3 to 7 mph"  |
    +--------+-------------------+-------------+---------------+

I hope you continue to tinker and evolve Blots; a personal scripting language guided by the use-cases you encounter naturally can be very rewarding and useful.

[0] http://beyondloom.com/tools/trylil.html

In contrast, Magnasanti: https://www.vice.com/en/article/the-totalitarian-buddhist-wh...

That's much longer than a quarterly earnings report away, which makes it "somebody else's problem" for the executives pushing these policies. There's no reason to expect these people to have a long-term strategy in mind as long as their short-term strategy gives them a golden parachute.

UV maps, especially for low-poly models, do not generally have a 1:1 geometric relationship with polygons in the original model. Areas with more significant detail will get more space on the UV map, mirrored or repeating areas will be overlapped, and of course UV maps will never include the tabs you'd need to physically glue parts together.

It's a version of the library of babel filtered only to the books which plausibly consist of prose. The set is still incomprehensibly vast, and all the more treacherous for generally being "readable".

Depending on how elaborate your GUI needs are, CardStock might be suitable: https://cardstock.run