xelxebar

> I think this works in simple domains.

Business incentives are aligned around incremental delivery, not around efficient encoding of the target domain. The latter generally requires deep architectural iteration, meaning multiple complete system overhauls and/or rewrites, which by now are even vilified as a trope.

Mostly, though, I think there is just availability bias here. The simple, solid systems operating at scale and handled by a 3-person team are hard to notice over the noise that naturally arises from a 1,000-person suborganization churning on the same problem. Naturally, more devs will only experience the latter, and due to network effects, funding is also easier to come by.

The growth of BB is certainly mind-boggling; however, I personally find its growth rate so untouchable as obviate any attempt at understanding. There's nothing to gain purchase on.

The fast growing hierarchy, on the other hand, provides oodles of structure for us to explore, and we can construct numbers that are vastly larger than anything BB(6) is likely to hit. In fact, this is why we use the fast growing hierarchy to approximate really big numbers all the time!

When we take something like f_Γ_0 and try to unpack even just the barest surface of its size, I get a feeling of vastness similar to those videos of diving endlessly into fractals.

Frustratingly, attempts to discretize space invariably run into problems with relativity, since they effectively impose a preferred frame of reference. I.e. you can impose a minimum distance, but relativistic length contraction means that observers measure different minima and in different directions.

Apparently, under some of these models, this implies that the speed of light ends up depending on wavelength, lending them to empirical tests. My understanding is that these discrete space models have failed to line up with experiment, at least within the limits of measurement.

In my years of reading and writing bash as well as Python for sysops tasks, I'd say that bash is the more reliable workhorse of the two. Python tends to encourage a kind of overengineering, resulting in more bugs overall. Many times I've seen hundreds of lines of Python or Typescript result from the attempt to replace just a few lines of bash!

The senselessness I object to is not the conscientious choice of tooling or discussion of the failings thereof; it's the fact that every single bash article on here sees the same religious refrain, "Python is better than bash. Period." It's like if every article about vim saw a flood of comments claiming that vim is okay for light editing, but for any real programming we should use a real editor like emacs.

If you open vim expecting emacs but with a few different bindings, then it might just explode in you face. If you use bash expecting to be able to program just like Python but with slightly different syntax, then it's not surprising to feel friction.

IME, bash works exceptionally well using a data-oriented, text-first design to program architecture. It's just unfortunate that very little of the industry is even aware of this style of programming.

Indeed! Funnily enough, there seems to be something similar going on between defining large finite numbers and defining large countable cardinals.

I kind of feel like set -o errexit (i.e. set -e) provides enough unexpected semantics that explicit error handling makes more sense. One thing that often trips people up is this:

    set -e
    [ -f nonexistent ] && do_something
    echo 'this line runs'

but

    set -e
    f(){ [ -f nonexistent ] && do_something; }
    f
    echo 'This line does not run'

modulo some version differences.

Permit me to vent just a bit:

> Python is a great scripting language, and won't blow your foot off if you try to iterate through an array.

I kind of hate that every time the topic of shell scripting comes up, we get a troop of comments touting this mindless nonsense. Python has footguns, too. Heck, it's absolutely terrible and hacky if you try to do concatenative programming with it. Does that mean it should never be used?

Instead of bashing the language, why not learn bash the language? IME, most of the industry has just absorbed shell programming haphazardly through osmosis, and almost always tries to shove the square pegs of OOP and FP into the round hole that is bash. No wonder people are having a bad time.

In contrast, a data-first design that heavily normalizes data into line-oriented tables and passes information around in pipes results in simple, direct code IME. Stop trying to use arrays and embrace data normalization and text. Also, a lot of pain comes from simply not learning the facilities, e.g. the set builtin obviates most uses of string munging and exec:

    set -- "$@" --file 'filename with spaces.pdf'
    set -- "$@" 'data|blob with "dangerous" characters'
    set -- "$@" "$etc"
    some_command "$@"

Anyway, the senseless bash hate is somewhat of a pet peeve of mine. Exunt.

Pentation? How quaint. For other Large Number fans, David Metzler has a wonderful playlist that goes way down the rabbit hole of the fast growing hierarchy:

https://www.youtube.com/playlist?list=PL3A50BB9C34AB36B3

Highly recommended.

Almost all of these mind-bogglingly large numbers are built around recursion, like the Ackermann function, which effectively has an argument for the number of Knuth up arrows to use. Then you can start thinking about feeding the Ackermann function into that slot and enjoy the sense of vertigo at how insane that becomes.

I find it fascinating how quickly the machinery of specifying large numbers probes the limits of what's definable within the mathematical systems we use.

> Number of monospaced font character blocks this string will take up on the screen

Even this has to deal with the halfwidth/fullwidth split in CJK. Even worse, Devanagari has complex rendering rules that actually depend on font choices. AFAIU, the only globally meaningful category here is rendered bounding box, which is obviously font-dependent.

But I agree with the general sentiment. What we really about how much space these text blobs take up, whether that be in a DB, in memory, or on the screen.

That's pretty reductive of horseshoe crabs. Foraging bipeds have evolved many times, equally good at human things.

Metallurgy? Spaceflight? Particle physics? Those are clearly unnaturally contrived reference classes. Why can't humans HorseshoeCrabTermA (i.e. scan the ocean floor upside down at a 30 degree for optimal benthic foraging and conspecific mingling?) Why hasn't HorseshoeCrabTermB (lunar-synchronized mass spawning timed with satellite male mating patterns)? Why can't other animals properly molt and feed with gnathobase ginding like horseshoe crabs do?

Don't get me wrong, I love chrome on cars and rockets and human intellectual curiosity. No other species has invented Python 2.7, but so what?

I think you did a good job delineating top complaints people have about shell, but I have to reject the pro/con framing.

Shell operates quite naturally under stream-oriented data-centric design patterns. But that's an architectural familiar to almost nobody in our OOP- and FP-happy industry these days. Try using Python like a relational database language (e.g. SQL), and complex stuff gets messy, the syntax starts feeling hostile, logic becomes obscure, etc. The purported ickyness of shell stems not from shell per se but from trying to force it into a foreign design space.

Principles that work well with shell: Heavily normalize your data; Organize it into line-oriented tables with whitespace-separated fields; Use the filesystem as a blob store; Filenames can be structured data as well; positional parameters form a bona fide list.

> hard to escape everything correctly

IME, all of the really painful escape patterns can always be avoided. You see these a lot when people try to build commands and pass them off to exec. That's mostly unnecessary when you can just shove the arguments in the positional parameters via the set builtin: e.g.

    set -- "$@" --file 'filename with spaces.pdf'
    set -- "$@" 'data|blob with "dangerous" characters'
    set -- "$@" "$etc"
    some_command "$@"

which is functionally equivalent to

    some_command "$@" --file 'filename with spaces.pdf' \
        'data|blob with "dangerous" characters' \
        "$etc"

It also helps to rtfm and internalize the parsing steps that happen between line of input and the eventual execve call.

Calling something as exceptional or special entails a value judgement; it's not particularly surprising, IMHO, for the things humans care about to align around human traits. Heck, even the act of making judgements about human exceptionalism is an arguably human-specific trait.

Consider, horseshoe crabs are undeniably the best at doing all things horseshoe crab. No other animal comes close to behaving like a horseshoe crab!

IMHO, the almost tautological nature of this judgement is what makes it uninteresting at best and actively harmful at worst. It's just a stone's throw away from individual, group, and racial exceptionalism.

It's not so much a matter of exhaustively listing pros and cons, but more a matter of appropriateness to the desired goal or goals IME. I seriously doubt that a comprehensive pro/con list can even be coherent. Is dynamic typing a pro or a con? Depends on to whom and even in what decade you ask. List comprehensions? Interpreted language? First class OOP? Any cost-benefit anaylsis will be highly context-dependent.

> I'm not here to defend tiresome strawmen.

I won't point out that you already tried to (contradiction intended). Perhaps a more interesting discussion would result if we defaulted to a more collaborative[0] stance here?

[0]:https://en.wikipedia.org/wiki/Cooperative_principle

> That it does get a lot of love strongly suggests that there are reasons for that.

Reasons, sure, but whether those reasons correlate with things that matter is a different question altogether.

Python has a really strong on-ramp and, these days, lots of network effects that make it a common default choice, like Java but for individual projects. The rub is that those same properties—ones that make a language or codebase friendly to beginners—also add friction to expert usage and work.

> Failure to understand something is not a virtue.

This is what I want to say to all the Bash-haters that knee-jerk a "you should use a real language like Python" in the comments to every article that shows any Bash at all. It's a pet peeve of mine.

Honestly, I read this a just a case of somewhat sloppy terminology choice:

- Positive → AI Boomerist

- Negative → AI Doomerist

Still not great, IMHO, but at the very least the referenced article is certainly not AI Boomerist, so by process of elimination... probably more ambivalent? How does one quickly characterize "not boomerist and not really doomerist either, but somewhat ambivalent on that axis but definitely pushing against boomerism" without belaboring the point? Seems reasonable read that as some degree of negative pressure.

In a particular sense, division and subtraction are more general than their supposedly more primitive inverse operations.

For example, we can take the "difference" of two points to get a vector, i.e. the grocery store is in that direction, while it doesn't make much sense to add two points---this location plus the grocery store? Similarly with temperature (of a given scale), today can be 5 degrees hotter than yesterday, but saying "the total temperature between yesterday and today is 57 degrees" doesn't have a clear meaning.

So, in that vein, what operation transforms one 3D vector into another?

Well a combination of rotation and scaling, of course! There is some freedom in how you want to represent this scaling+rotation operation; we could use 3x3 matrices, meaning that the quotient of 3D vectors is reasonably described by a matrix. However, 3x3 matrices have 9 degrees of freedom, which is way overkill, since we just need 4 numbers: an axis (2 params), an angle, and a scale factor. For this reason, quaternions are a particularly natural representation of 3D vector division.

The general concept of division that we're getting at here has the terrible name "g-torsor". If you're not familiar with abstract algebra, though, the definition is not very enlightening. However, John Baez has a really accessible article[0] that comes to the rescue!

Side note: notice that in general, the results of division are different objects than the things doing the division. As such, it's somewhat unfortunate that we use the same units for both in many cases, e.g. temperature and temperature differences are really different things. Talking about units quickly turns into type theory, though, so I'll stop there.

[0]:https://math.ucr.edu/home/baez/torsors.html

Also, "double" rotations, which have no analogue in 3D space. The extra degree of freedom in 4D lets you perform 2 orthogonal rotations. This means that you can rotate around in 4D space, leaving only the origin fixed. In 3D rotations always fix some axis.

Trying to think about this stuff can be mind-bending, since it's natural to try to visualize things. So to give a little intuition, consider the coordinates of a 4D vector (x,y,z,w) and notice that we can spin around in both the x-y and z-w planes at the same time without interfering with each other!

Personally, I have only run 9front on VMs, but my understanding is that 9front will boot on most x86/x86_64 machines. There is also explicit work to keep it running well on RPi hardware, which is what adventuresin9 runs.

For a bit more nitty-gritty, the 9front FQA[0] is worth running through.

[0]:https://fqa.9front.org/fqa3.html

Note that Guix also runs on the Hurd and has first class support for running a Hurd VM service if you just want to play around.

https://guix.gnu.org/blog/2024/hurd-on-thinkpad/

I use 9front heavily.

Latency is never a problem in my experience unless you're mounting in resources from a different continent, where ssh is slow anyway. Even in those cases, the UX is closer to mosh, since rio remains local.

In general, plan 9 is fast. Compiling all of userspace and the kernel tanker just a couple minutes on my 11th gen Framework. Grepping a large repo also feels closer to ripgrep than gnu grep.

One well-known user runs his home network and automation system all as a 9grid. He even frequently shares details on his YouTube channel adventuresin9[0]. It's binge-worthy IMHO.

It's hard to convey how cohesive the whole system is. It's ridiculous how many things are reduced to trivial shell scripts, and the source code is so darn grokkable, greppable, and small that treating it as documention is actually sensible. Granted, this is almost necessary to become proficient in Plan 9 since there are so few network effects producing StackOverflow answers, blog tutorials etc.

Anyway, I hope you do end up jumping in!

[0]:https://www.youtube.com/channel/UC7qFfPYl0t8Cq7auyblZqxA

> Do you mean that repeated measurements on different systems might not be independent because they come from the same source?

More that the measurement settings could be correlated somehow. So called "cosmic Bell tests" try to push back how far said correlations would have to be, though, by determining measurement settings from distant antipodal astronomical objects, e.g. see the famous Rauch paper [0].

On the surface it seems a bit absurd to consider conspiracies from 7 billion years ago, but that's the whole deal with conservation laws, which introduce correlations between otherwise free parameters and constrain the state space to some submanifold.

[0]:https://journals.aps.org/prl/abstract/10.1103/PhysRevLett.12...

I feel like one of the lucky 10,000 today! Thanks for asking.

Jump up an abstraction layer.

Multiplication and addition are each commutative, but performing multiplication followed by addition is not the same as addition followed by multiplication (in the real numbers), so they don't commute. Said another way, the operation of composing multiplication with addition isn't commutative.

Similarly, we can perform various operations on random variables, one being expectation value and another being multiplication (or conjunction): E(X•Y) ≠ E(x)•E(y) unless x and y are independent, so E and • don't commute.

When we say "commute" we often are directly or indirectly thinking of commutative diagrams, which capture a very general which of commutativity and allows us to precisely write down all the above.

Fun fact: associativity is also just commutativity of binary operator composition.

> either locality fails of realism fails

Or statistical independence fails, no? The CHSH derivation, for example, requires commuting expectation value with conjunction and similar for other Bell-like's that I'm aware of.

This always gets pooh-poohed away with with vague appeals to absurdism, "Alice and Bob's free will blah blah", but I don't really know of a priori reasons why the global state space needs to be Hilbert instead of a more complicated manifold with some Bell-induced metric. If you know of prior art here, I'd love some pointers.

> how can we build a product that saves local affiliate stations money

Let's bring back those supposed good 'ol days!

What are some valid business models that could successfully fund local affiliates? Knowing nothing of the industry, some initial questions come to mind:

- Is there value in cross-affiliate connections and referrals where a broadcasting association could work?

- Direct donations seems like a filled market, but what about donation pooling?

- Does private equity have an interest in these affiliates and why or why not?

- Is there a product in marketing and branding local stations that appeases YouTube and related algorithms? Would this fundamentally work against the mission?

One of my better ideas recently was to name files like CVS rows, which allows ls output be directly piped into database processing pipelines etc.

> But what do you do when you discover you don't have similar values?

Look deeper? Explicitly held beliefs are just a sliver of the tip of the iceberg that constitutes our experience as humans. The US, in particular, seems particularly fond of declarations of identity, so it helps to understand that such things are about as fundamental as the health of your pancreas.

IMHO, polarizing reactions, whether in others or yourself, look like obvious fear responses, which often respond to empathy and understanding.

More than fear, certainty smells like the mind killer to me.

I don't think you can avoid risks and be vulnerable at the same time. It's a bit of a catch-22, I'll admit; oversharing can push people away, but the only way I know to figure it out is to fall, get back up, rinse, and repeat.

It's certainly a solid improvement in the space of VCS UI, but beware that jj has some current limitations which might prohibit switching, especially for the git power users.

Lack of gitattributes support precludes git-crypt and git-lfs usage or anything that needs filters; line ending settings will get ignored, making Windows interop a little less smooth; etc.

Also note that auxillary tooling, such as git-annex and git-bug, becomes second class, i.e. no oplog integration and they might mess up your log with internal-use commits and heads.

Or right? Reminds me of the Skroderider species of sentient seaweed from Vernor Vinge's "A Fire Upon the Deep".

This couldn't have come at a more opportune time. My 11th gen Framework just gave up the magic smoke last night, which was a frightening experience.

The Framework has given me a bewildering litany of issues over the years, and I now just want something solid, light, and reasonable battery life, so just I threw down for an M4 Air today.

Having used Linux exclusively for 25 years and an unaBashed CLI junkie, I'm a bit nervous about workflow friction.

How does experience with nixos-darwin compare against just VMing on top of MacOS?

Also, is there any reason for mucking about with Apple's bootloader etc?