Anyway, he seems like a very nice fellow and I wish him and almost all T-shirt designers well. That bash script just gave me a lot of pause. (And even that seems possibly downstream of him being nice and doing it himself to spare his team from what he called a "FrankenProject".)

{ Also, it was my own Py version which I mostly did in case anyone wanted to actually run the thing after such interest was expressed on this thread. :-) }

I already said regular devs and LLMs can both gen copy-pasta. That said, being "mostly" a Python dev, asking some LLM to translate to bash for him seems even more likely to me. Only he or those close to him knows for sure. You & I cannot settle it here conclusively (as also said).

I also noted from the video that the ♥s (hearts) worked on whatever version of bash he tested with though it failed for me (which is why I wrote that Python). And his terminal title bar is switching between `tput` and `bc` and such meaning that what he was demoing was not some Python script. ¯\_(ツ)_/¯

EDIT: Ah..another resolution of the hearts is to not run in an LC_ALL=C environment. Oops! `LC_ALL=en_US.UTF-8 bash ..` fixed it. Oh well, I think the Python script is nicer in almost every way. E.g., you could |head -n60 and send it to a line printer/dot matrix reminiscent of the 1980s computers he shows in the video, although your printer driver would have to strip the color escapes with a `sed` or maybe https://github.com/c-blake/bu/blob/main/noc.nim. ;-)

    #!/usr/bin/env python3
    from os   import environ; E = environ.get
    from math import sin
    from time import sleep
    text = "♥PEACE♥FOR♥ALL" # The text to sine-scroll animate
    nText  = len(text)      # Number of utf8 chars
    freq   = 0.2            # Frequency scaling factor
    color0 = 12             # xt256 Color cube segment 12..<208
    color1 = 208; nColor = color1 - color0
    (w, h) = (int(E("COLUMNS", 80)), int(E("LINES", 24)))
    t = 0
    while True:
        x = (w/2) + (w/4)*sin(t*freq)           # x pos via sine value
        x = max(0, min(w - 1, int(x + 0.5)))    # bound to tty width
        color = color0 + ((nColor*t)//h)%nColor # cycle colors
        ch = text[t%nText]  # Get char & Use xterm-256 color escs
        print("%*s\033[38;5;%sm%s\033[m\n" % (x, "", color, ch))
        t += 1
        sleep(0.1)   # original used bc shell outs to rate-limit

The AI not handling the output relates to the final base64 output on the T-shirt (which other comments in this thread mention manually keying in or TFA discusses in the context of OCR). So, that is just not relevant to the question.

What made me start to wonder, personally, was that the output seems identical if you use "♥PEACE♥FOR♥ALL" instead of the version with internal repeats. IF there is any point to that "manual expansion of the cycles", IMO that deserves a comment much more so than "# Calculate length of text; text_length=".

Also, that `echo -n ...` followed by `echo ""` instead of just plain `echo` in the first place seems like the kind of copy-pasta code LLMs generate. Then again, regular devs also write pretty bad copy-pasta code.

There is also this the weirdly "broken down" calculation with 3 `bc` invocations not 1 as if it was translated from a language with more arithmetic/special function power than bash.

There is also the color scale stuff done in the loop instead of outside (except the one color=$(..)) which seems very unnatural and also very like machine translation.

Also, at least for me, on my bash-5.3.15(1), `char="${text:t % text_length:1}"` does not work to slice out the multi-byte UTF8 heart symbols, but it sure does look like the kind of thing an LLM would do translating from a python3 script (such as something like https://news.ycombinator.com/item?id=48830669) into bash.

Another thing is, as others here have observed, there is nothing "gradual" about the xterm-256 color cube. So, "gradient" is a misnomer and exactly the kind of weird things LLMs do when they cobble text together.

Finally, all the tput stuff the script does instead of just "print x spaces" really smells like a human description of the side scroll in the video game graphic he shows inspired him somehow LLM-corrupted/complexified into the vertical scroll terminals do.

None of this is conclusive, but the video mentions 2023..2025 as when he did it and given that he was a designer and his concerns more visual than code-oriented, I'd have to say I disagree with your sincere doubt and I do strongly suspect the decoded script was very likely LLM-circa2024-generated, possibly with light post-edits by hand.

One issue with that relative to RSS is permissions. Historically, all procs could see the RSS used by procs of all other users (at least if they could see the PIDs at all). So, RSS requires no special permissions, but the Linux kernel team decided PSS should not be as promiscuous for whatever reasons (I didn't do a deep dive). So, I'm always having to do (the equivalent of) `sudo pu`.

However, it does inspire me to write.. The kernel of all this terminology confusion is under-exposure of industrial programmers to not just academic terminology, but also the very design space you mention (which has always been nicely covered by Jones' outstanding book). Just to take an example from the root of this thread:

>widespread common usage of the term “garbage collected programming language” which specifically contrasts manual languages like C++ or Rust against garbage collected ones

Boehm-Wiser conservative collection for C, among the most manual languages of all, pre-dates its very first ANSI 1989 standard.

This underexposure itself is downstream of the kinds of oversimplifications/lies of marketing and in this particular case came from Java. The evolution I witnessed was roughly 1) linking Boehm with -lgc and deleting (or #define'ing away) all your `free()` calls is conservative - to be precise you need compiler aid and a lot of programmers are "not perfect==awful" personality types, 2) Sun Microsystems wants to leverage a lot of reliability issues with C code and become The Platform and spends gobs of money to win hearts & minds, partly succeeding, 3) part of its ad-warfare against the then WIntel hegemony and/or tutorials/introductory material for Junior Programmers (often the target of "be more reliable" material) plays fast & loose with GC terminology because marketing plays fast & loose structurally for fun but mostly profit, 4) because human language really does == language usage a la Quine, everyone in the industry re-defines what "GC" means to bind it to a programming language instead of to a specific run-time, 5) industry & academics use different language, confusion ensues and so here we are.

This is not even the 100th time that either explicit or implicit forces of marketing have achieved confusion analogously to this. If you believe most people don't need much of what they spend on then confusion is arguably intrinsic to marketing of ideas/products. The highly misleading but suggestive metaphorical language used all over "AI" in both research and in product-lines is a more current case of this, leading anyone who knows much to have to qualify "not AGI" or other such junk just to have a conversation.

So, what is my point? Basically just that the larger problem here will persist as long as there is money to be made/attention to be garnered by sowing confusion/having people talk past each other/think some product is more than it really is. I have no meta-strategy in my back pocket to block these successful confusions, but it does seem worth being aware of it.

FWIW, CPUs/hardware structurally do not have quite as much luxury for dynamism/monotyped things. So, all this does connect with how tight/abstract a bridge to the hardware world one cares about (which just varies). That naturally connects to performance, but that also becomes tricky once one moves to pragmatic problem decomposition over purity (e.g. NOT "pure" Python or "pure" Ruby). In my experience, people tend to overvalue purity as much as they tend to over-simplify. :-)

The entire concept of the "performance of a PLang" in terms of the run-time of programs written "mostly in it" is rather seriously under-specified, TBH. This is (or should be) uncontentious in spite of the slew of articles with titles like the one for this thread.

The estimate of "The Internet" connecting 800,000 computers is probably also pretty surgically date-identifying (at least to isolate 1992 to 1998 given how fast it was growing at the time, though estimation error might cause a little trouble!). For example, https://web.mit.edu/people/mkgray/net/internet-growth-summar... also suggests 1994 (although that estimate was 0.6 million) while 1992 would be more like 200,000 although as per my scare quotes (and that MIT link) "The Internet" was also a somewhat vague term at the time. And by 1998 it was surely over 10 million which makes the @karel-3d quite likely incorrect, although who knows - maybe that's when the EFF first put it up on their web site?

EDIT: I mostly think it matters since observations that might have seemed quite prescient in 1992 (like also-Mormon Orson Scott Card's even more prescient ideas in 1985 Ender's Game with Locke & Demosthenes political chat personas based on 1980s BBS/UUCP network activity) were very much things everyone was saying by 1998.

So, sure, this "4th dimension" (for normals) might be as simple as "candelas" - truly orthogonal, but one does hear an awful lot about "ambient" or "candela contrastive" (a term I just made up) kinds of effects. (EDIT: e.g. in color calibration of projectors in dark rooms vs. living rooms, for example, but I'm sure there are many.) I am just one person, but it feels like candela brightness matters for color perception. So, maybe luminous intensity is not actually exactly orthogonal. Maybe this is all covered in the 1931 CIE documents, though.

Unmentioned so far is that defaults for max live memory maps are usually much higher than defaults for max open files. So, if you are careful about closing files after mapping, you can usually get more "range" before having to move from OS/distro defaults. (E.g. for `program foo*`-style work where you want to keep the foo open for some reason, like binding them to many read-only NumPy array variables.)

If it helps anyone explain the SkiFire point any better, I like to analogize it to an I-bar cursor vs. a block cursor for text entry. An I-bar is unambiguously "between characters" while a block cursor is not. So, there are questions that arise for block cursors that basically never arise for I-bar cursors. When just looking at an integer like 2 or 3, there is no cursor at all. So, we must instead rely on names/conventions/assumptions with their attendant issues.

To be clear, I liked the SkiFire explanation, but having multiple ways to describe/think about a problem is usually helpful.

For many years (decades?) now, I've been using "index" for 0-based and "number" for 1-based as in "column index" for a C/Python style [ix] vs. "column number" for a shell/awk/etc. style $1 $2. Not sure this is the best terminology, but it is nice to have something consistent. E.g., "offset" for 0-based indices means "off" and even the letter "o" in some case becomes "the zero of some range". So, "offset" might be better than "index" for 0-based.

[^1]: https://news.ycombinator.com/item?id=47100056