cb321

You're welcome.

Another lesser known wrinkle along these lines is that if more of Aristarchus of Samos' work on heliocentricity had been developed into a "calculational framework" for planetary motion by a contemporaneous Ptolemy competitor (a la Copernicus in 1543), various relativity ideas might well have started in 270BC instead of 1600 AD.

Aristarchus was already WAY ahead of a few games - making a guess that "absolute rest" was illusory and tiny stars were similar to giant Sol. If not for Archimedes' serious star power, we might not even know of Aristarchus' heliocentric ideas! Relativity ideas of various kinds are short intellectual hops from "the absolute rest of your intuition is illusory".

Aristarchus and his supporters just had to assert The Stars were very distant -- far enough for there to be NO PARALLAX! Various "coincidences" all conspired to suppress Aristarchus' plausibility, like: A) Just HOW DISTANT stars are/local galactic stellar density &| B) poor human VISUAL ACUITY relative to C) Earth ORBIT vs. Sun LUMINOSITY (parallax baseline) & maybe existence of Moon to vent atmo &| D) VERY SLOW (3 millennium) development from near prehistoric glass (1500BC) to grinding lenses for human eyes in the 1300s AD leading to Galileo's telescopes & etc. If ANY of (A)..(D) were about ~10x better (ALL of which are imaginably so), the day that universe changed could've been much earlier. Heck, even if Aristarchus just had a really good spin doctor like a major religion pushing the plausibility of "Sun=A close Star", that might've been enough.

Archimedes almost invented the underlying ideas of integration and limits and all that, too. Close but no cigar, but (had that been in hand) analytic geometry and differential equations are short steps away. I mean, Newton surely noted the equivalence of gravitational and inertial "mass" (charge vs. kinematics) which is the weak principle of equivalence of GR, after all. Like I said - "littered". ;-) There are probably whole books written on the topic (or adjacent topics) of "All the Things Humanity Nearly Figured Out Earlier" that have a more historical bent than the usual "sci-fi tilt".

Yeah. My point was mostly to expand upon your original post - sorry if it sounded like I disagreed. You say the same in your original "iteration of speculation and observation". Everything else is about what "derive" and "knowledge" might mean (I agree "medieval" usually means pre-Renaissance and Galileo is modern-era), how much empirical "proof" is in "derive", etc. However, all you need for "possible" is "the idea", some "consequences", and ways to test.

So, to push back a tad on your more recent "only thing that I am aware of" and to maybe explain my above point better, I do think there was enough information/ideas in the abstract in Galileo/Newton/Leibniz' times to suggest the idea. Leibniz himself pushed back hard on Newton's absolute space/time (long before Mach). For Leibniz, it would have been counterintuitive space/time vs. counterintuitive fixed speed. So, that pushback itself could have been enough of a "clue" in your terms -- in some alternate timeline -- to drive a speculation-observation cycle starting from different inertial concepts - with Galilean moon eclipses then enough a clue that fast speeds existed to fool our slow-speed intuitions. (And all this in the "modern era".)

So, I continue to think it "not impossible" that the relativity principle could have arisen before any EM theory at all -- it just didn't. That matters for these kinds of speculative questions about what information horizons support what developments. A single "fast enough" fixed speed is is not that wild & crazy. The modern world has a zillion obscure physics theories like that (mostly just because so many more people work on that stuff, but that's a probability thing, not a possibility thing, and I suppose also partly inspired by how physics turned out - so not truly independent). History is littered with things that could have happened, but didn't.

P.S.: and apologies for "mistakes a fundamental error". I of course meant "makes a", if you wanted any evidence that I was not an LLM. ;-)

This is something of an aside on your first paragraph and lh712's. The theory of special relativity (and field theory in general) can be "derived" (as done in e.g., Landau, Lifshitz _Classical Theory Of Fields_) without empirical observation using concepts known to Galileo/Newton (if they count as "Medieval") - just with different assumptions/ideas about inertial frames. If you assume there is any phenomenon with a fixed observed speed in all "inertial frames" then you get special relativity with Einstein's gestalt-switch. After that it is, like so much in physics, a matter of thinking of an experiment to distinguish what matches capital-N Nature best.

Thinking otherwise mistakes a fundamental error that the only way for something to happen is how it historically happened. Reconciling observations forced relativity historically, but it could have been sussed out without those. That there were very fast but finite speed phenomena (which could motivate relativity reducing to Newtonian models) was seen in 1676 by Rømer with the speed of light and eclipses of Io, a Galilean moon of Jupiter. It probably could have been done with Galileo's telescopes in 1610. (That is just one example of a phenomenon with a very fast yet finite speed to suggest other experiments to test that "hypothetical relativity".)

TBH, this all relates to teaching "physics without calculus" and that sort of thing. Is the most clear presentation/derivation that which mirrors the history of our muddled yet ever demuddling ideas or that which starts from our most thoroughly demuddled ideas, best notations, etc.? The momentum is certainly the historical approach, yet there are notable exceptions.

Something Dan does not observe in his article (perhaps Jamie does elsewhere? edit: or even Dan elsewhere) is that the same problem which makes the memory latency benchmark unrealistic (or at least misleading) often impacts hash table lookup benchmarks as mentioned at https://github.com/c-blake/bu/blob/main/doc/memlat.md and probably many other benchmarks. Essentially, CPU work prediction/speculative execution has become so good that much care is often required to measure latency rather than reciprocal throughput. This all started in the 1990s (or probably earlier with Cray), but I guess there's been an ongoing educational failure/oversimplification tendency.

Of course, throughput at one "level of work" is often latency at a higher level (like command-to-command execution, for example). So, "what matters" might be throughput or "latency". It all depends. :-) People often fiddle with such semantics to market methods, products, ideas, ... and marketing is often at cross purposes with understanding.

Agreed! Relatedly: https://news.ycombinator.com/item?id=49599953

I just tried a tar file of a git clone of the linux kernel sources where the most recent commit is 72c395024dac5e215136cbff793455f065603b06 (early Feb of this year). zstd -19 got a slightly smaller size (3582930348 bytes vs bz3 -b 511's 3597411687 bytes or 0.4% advantage to zstd). More significantly 4-core zstd decompression was 2.05 seconds vs a whopping 297 seconds for bzip3 -dj4 - 145x or over 2 orders of magnitude slower (about as much time to decode as to encode in the first place). bzip3 1.5.3 compiled with gcc-16.1.0. Granted, the .git objects are all compressed already and uncompressed tar-ball was only 5426667520 bytes, but even so...A lot of people care about fast(-ish) decompression. Maybe I did something wrong? Maybe `rm -rf .git` first would be a better benchmark?

The "scatter line plot" in TFA is all same shade of red on white with no year labels. This seems like a missed visualization opportunity. Using some kind of color scheme/gradient to represent the 1979-2026 years in a way that can show long-term "trend". (A 50 frame movie at, say, 5 fps with same axes or maybe "all years" as faded background as the current year pops around in bold is another possibility, but a scientific paper format doesn't let people do .mp4s.) I know I've seen multi-colored "scatter lines" in IPCC reports. Seemed worth asking rather than doing it myself.

Don't forget head, tail, mount, strip, touch, etc.

My GF when I was first learning these names was convinced the Unix principals did all this quite deliberately and "finger" was her headliner argument. Evidently, even in 1971 someone complained: https://blog.robertelder.org/intro-to-pinky-command/ (relevant to that source, Usenet/Net News/mailing lists may be another social network which never exactly died and even today LKML, zsh-workers, etc. are main communication avenues).

I only said anything at all because the implication was not "missing minor nits about whatever your favorite proxy for 'will rely' is" but rather "nothing at all". FWIW, the keyword was "index" and the result was adix, and I only meant the package system & "a" directory were discoverable. Exact keyword search systems indeed make discovery harder, but that is some whole other complaint. There are always many complaints.

There are a million ways to define both "top 10 language" and "weak std lib", but the C stdlib is not great and C++'s was bad enough to spawn Boost. And I'm sure many firms all but say "do not use" parts of many top10 stdlibs. In any event, we don't disagree that Nim's stdlib being stronger would be better or that poor delegation or unconsolidated discussion are problems. We disagree on very little, including I'm sure that there is more to a PLang than its stdlib.

What is present/missing in any stdlib (or really in almost anything period) is also often much more subtle and subjective than simple sales pitches one hears. To be concrete, there are "useful" (to someone) things in the Nim stdlib not in either Python's or Go's like std/critbits, std/pegs, ropes, packedsets, intsets, editdistance, etc. Nim stdlib substring search behind "xyz".find() is layered to let you, if you want, pre-build a `SkipTable` (the way regex engines let you pre-"compile" regexes). Subtle in diversity of both kind and granularity and subjective as in "who cares?"

Yes, all that and more is all available in all the ecosystems of anything "popular", but that brings you back to "trust proxies", like "prerelease" numbers, a very weak one, IMO. E.g., I have never used a neovim with a version >0.13, but it's been a trooper; one man's 0.7 is another's 7.0. TRUST IS TRICKY! A count of distinct reliers for some values of "distinct" and "rely" or various update patterns would be better (have their own issues, of course, but at least measures "company" as in "what misery loves", LOL).

I don't know what @winding means, exactly, but at best this seems highly misleading. Nim had babel packages by around 2010 (when it was called Nimrod and there was a Tower of Babel name scheme) and then nimble packages since 2014 or so. Also, literally 30 seconds on https://nim-lang.org (click on Documentation) and you get to https://nimble.directory/ , search for index and get to adix which has all sorts of efficient Table variants.

There has never been much prog.lang. benefit from being "in the stdlib/core" in Nim (unlike Python or Go, say). The benefit is more "software distribution" for the dependency allergic, but the Nim culture is much less micro-deps than seems in vogue lately. All that said, I think having a more batteries core distribution is valuable - just less than you might guess - and practically that needs delegation.

There is a python3 variant in this thread [1], but if that is not "standard enough" (as someone else may have mentioned bash itself is not POSIX), this awk would also work { Warning - this awk is 1000s of times faster than the bash. So, you really probably want that sleep { and sure 100s of times faster yet may be possible. } }:

    #!/usr/bin/awk -f
    BEGIN {
      # Split on spaces so multi-byte utf8 works
      nText  = split("♥ P E A C E ♥ F O R ♥ A L L", tmp, " ")
      for (i = 0; i < nText; i++) text[i] = tmp[i + 1]
      color0 = 12; color1 = 208  # xterm-256 color cube range
      nColor = color1 - color0   # Could be a pretty gradient
      w = ENVIRON["COLUMNS"]; if (w == "") w = 80
      h = ENVIRON["LINES"];   if (h == "") h = 24
      freq = 0.2
      for (t = 0; 1; t++) {
        x     = int(w/2 + w/4*sin(t*freq) + 0.5)  # x pos ~ sine
        color = color0 + int((nColor*t)/h)%nColor # cycle colors
        ch    = text[t % nText]                   # cycle chars
        printf("%*s\033[38;5;%dm%s\033[m\n", x, "", color, ch)
        fflush()
      # system("sleep 0.1") # awk has no builtin sleep
      }
    }

As to "bug reports", the T-shirt published script also fails with LC_ALL=C for me as mentioned else-thread.

FWIW, I think ancient practice to reach for `bc` instead of `awk` or even the arithmetic built into shells often annoys. The only reason I keep `bc` installed at all is to compile Linux kernels. Someone had some patch set to Linux to eliminate this very dependency many years ago now.

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

That Matrix visual was actually specifically mentioned as an inspiration in the video by the designer being linked to/discussed elsethread (e.g. https://news.ycombinator.com/item?id=48830326 )

FWIW, his screens looked a lot like OSX to me (which tracks with graphic design users in my experience).

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".)

Yeah. The Flask web-page prototype was indeed in Python. (The prequel shirt was Go.)

{ 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. ;-)

For anyone that cares, this is a slightly less stupid Python version:

    #!/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

As mentioned in https://news.ycombinator.com/item?id=48830634 , the heart symbols did not otherwise even work for my bash and some have commented on liking the screen saver.

I watched that whole video link - thank you for that - and he doesn't really say. In fact, he spends much more time on the beige color harkening to computer case plastics of the 80s & 90s.

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.

That is a good list. While I'm sure many companies could be added, I only post to include DEC https://en.wikipedia.org/wiki/Digital_Equipment_Corporation whose `vt50/vt100/vtXX` ideas may be with us, in software, for perpetuity unless something like Arcan (https://arcan-fe.com/) ever takes off.

`procs display` (mentioned elsethread https://news.ycombinator.com/item?id=48788167 ) supports PSS via its %M format code.

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`.

A different usage paradigm from *top that I have come to like better is to do differential ps-like reports and system-wide (like vmstat) reports which leaves everything in your terminal scrollback buffer as in: https://github.com/c-blake/procs { written in the uncommonly efficient, expressive Nim programming language }.

I don't really disagree much with what you said. My favored PLang Nim (https://nim-lang.org/ -- it has both `ref` and `ptr` styles of pointer, one auto-managed, one manually managed) even changed a while back it's `nim c --gc=x` command-line language to `nim c --mm=x`, and I was in favor of said change.

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.

For those new to the topic and less patient than "full conference" levels of attention, it doesn't cover things like UFCS/command-call, user-defined operators, or many other details, but for its incredibly short run-time, this video might give you a tiny taste of the flavor: https://www.youtube.com/watch?v=WHyOHQ_GkNo

This may seem like a modern conflict, but what I like about your post is its more general human cognitive orientation. Since to each new generation everything is new, people tend to forget that this kind of tension goes back to the dawn of programming with Fortran and Lisp, or even earlier if you count various notations for math.

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. :-)

You can see all the details at: https://github.com/mratsim/constantine , but to answer your "how" question briefly here, something Nim shares with most (all?) "systems programming languages" is "easy" integration with assembly languages -- whatever the backend for "most" compiled code is (whatever that "most" even is - weighted by any number of measures of static source size or dynamic instruction counts). Of course, hand-rolled assembly can cost you a lot in portability/effort to port to new platforms/etc.

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.

Ah. Good searching! So, maybe the 800,000 computers was "in DNS but un-pingable IP hosts" (dial-up was a big then then) or maybe included non-IP "networked" hosts or who knows.. Anyway, I agree that your finds make it more likely to be 1992/3 than 1994. Thanks!

I am unfamiliar with the history of the piece. Many things are possible. He may have "mostly wrote" it in 1992 and then "polished it" for a 1994 Oita conference, but was somewhat sloppy in internally updating everything date-dependent like the coup part. People also can be very flowery/metaphorical about using the word "coup". Not sure if they even have attendee/speaker lists online for those Oita conferences anymore, but that might also help if he wasn't at all of them. Bitrot / entropy can corrupt the digital world as well as the physical, just with more checksums if the referents still exist. ;-)

That's what I thought, too, but the top of the article says "For the Conference on HyperNetworking, Oita, Japan" which was in '94. So, I thought maybe "last summer" was internally even off by a couple years? I'm really not sure, but someone around these parts probably knows. Worth mentioning that also in the early 90s people did refer to the Russian Federation as the Soviet Union sometimes as a shortening of "the former Soviet Union".

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.

I think this was written in 1994 for this conference https://seclists.org/interesting-people/1994/Mar/64 , but I'm not 100% sure. It refers to "last summer's coup in the Soviet Union" which may also date it. Maybe it should have a (1994) in the title. Or, I don't know, maybe it's from even earlier? Some of the other pieces have nice dates at the bottom, like the Declaration of Independence for Cyberspace a bit over 30 years ago. EDIT: @karel-3d elsethread seems to think this one is (1998).

In fact, to support your point, it is perhaps questionable from first principles if 3 dimensions not 4 is right. Leaving out tetra chromats and the (partially) color blind, normal human light perception is 1 kind of rod and 3 kinds of cones (i.e. 4 photo receptors, plus some light sensitive ganglia that don't seem to participate in vision, but diurnal regulation).

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.

To support your point, it's also used in basically every shared library / DLL system. While usually used "for code", a "shared pure data library" has many applications. There are also 3rd party tools to make this convenient from many PLangs like HDF5, https://github.com/c-blake/nio with its FileArray for Nim, Apache Arrow, etc.

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.