Stubsack: weekly thread for sneers not worth an entire post, week ending 4th January 2026 - awful.systems
awful.systems
Want to wade into the snowy surf of the abyss? Have a sneer percolating in your system but not enough time/energy to make a whole post about it? Go forth and be mid: Welcome to the Stubsack, your first port of call for learning fresh Awful you’ll near-instantly regret. Any awful.systems sub may be subsneered in this subthread, techtakes or no. If your sneer seems higher quality than you thought, feel free to cut’n’paste it into its own post — there’s no quota for posting and the bar really isn’t that high. > The post Xitter web has spawned soo many “esoteric” right wing freaks, but there’s no appropriate sneer-space for them. I’m talking redscare-ish, reality challenged “culture critics” who write about everything but understand nothing. I’m talking about reply-guys who make the same 6 tweets about the same 3 subjects. They’re inescapable at this point, yet I don’t see them mocked (as much as they should be) > > Like, there was one dude a while back who insisted that women couldn’t be surgeons because they didn’t believe in the moon or in stars? I think each and every one of these guys is uniquely fucked up and if I can’t escape them, I would love to sneer at them. (Last substack for 2025 - may 2026 bring better tidings. Credit and/or blame to David Gerard for starting this.)

Want to wade into the snowy surf of the abyss? Have a sneer percolating in your system but not enough time/energy to make a whole post about it? Go forth and be mid: Welcome to the Stubsack, your first port of call for learning fresh Awful you’ll near-instantly regret.

Any awful.systems sub may be subsneered in this subthread, techtakes or no.

If your sneer seems higher quality than you thought, feel free to cut’n’paste it into its own post — there’s no quota for posting and the bar really isn’t that high.

The post Xitter web has spawned soo many “esoteric” right wing freaks, but there’s no appropriate sneer-space for them. I’m talking redscare-ish, reality challenged “culture critics” who write about everything but understand nothing. I’m talking about reply-guys who make the same 6 tweets about the same 3 subjects. They’re inescapable at this point, yet I don’t see them mocked (as much as they should be)

Like, there was one dude a while back who insisted that women couldn’t be surgeons because they didn’t believe in the moon or in stars? I think each and every one of these guys is uniquely fucked up and if I can’t escape them, I would love to sneer at them.

(2026 is off to a great start, isn’t it? Credit and/or blame to David Gerard for starting this.)

  • JFranek@awful.systemsEnglish
    0·
    3 days ago

    Against my better judgement I got into an argument with a promptfan on Bluesky. To his credit, aside from the usual boring arguments (“models are getting better, and better”, “have you tried model xyz”, “everyone not using chatbots will be left in the dust” he provided an actual example.

    https://github.com/dfed/SafeDI/issues/183 It’s a bug that’s supposedly easy to test, but hard to reason about. Took the chatbot half an hour while it would take him several (allegedly).

    Now, my first thought was: “If a clanker could do it (something that famously can’t reason) then it couldn’t be that hard to reason about.”

    But I was curious so I looked. Unfortunately it is an area I’m not familiar with and in a language (Swift) I don’t know at all.

    Probably should file the claim under “not true or false” and touch grass or something, but it’s bugging me.

    Any one y’all who could say if there’s something interesting in there?

    • corbin@awful.systemsEnglish
      0·
      2 days ago

      Complementing sibling comments: Swift requires an enormous amount of syntactic ceremony in order to get things done and it lacks a powerful standard library to abbreviate common tasks. The generative tooling does so well here because Swift is designed for an IDE which provides generative tools of the sort invented in the 80s and 90s; when their editor already generates most of their boilerplate, predicts their types, and tab-completes their very long method/class names, they are already on auto-pilot.

      The actual underlying algorithm should be a topological sort with either Kahn’s algorithm or Tarjan’s algorithm. It should take fewer than twenty lines total when ceremony is kept to a minimum; here is the same algorithm for roughly the same purpose in my Monte-in-Monte compiler, sorting modules based on their dependencies in fifteen lines. Also, a good standard library should have a routine or module implementing topological sorting and other common graph algorithms; for example, Python’s graphlib.TopologicalSorter was added in 2020 and POSIX tsort dates back to 1979. I would expect students to immediately memorize this algorithm upon grokking it during third-year undergrad as part of a larger goal of grokking graph-traversal algorithms; the idea of both Kahn and Tarjan is merely to look for vertices with no incoming edges and error if none can be found, not an easy concept to forget or to fail to rediscover when needed. Congrats, the LLM can do your homework.

      If there’s any Swifties here: Hi! I love Taytay; I too was born in the late 80s and have trouble with my love life. Anyway, the nosology here is pretty easy; Swift’s standard library doesn’t include algorithms in general, only algorithms associated to data structures, which themselves are associated to standardized types. Since Swift descends from Smalltalk, its data structures include Collections, so a reasonable fix here would be to add a Graph collection and make topological sorting a method; see Python’s approach for an example. Another possibility is to abuse the builtin sort routine, but this will cost O(n lg n) path lookups and is much more expensive; it’s not a long-term solution.

      • JFranek@awful.systemsEnglish
        0·
        2 days ago

        Thanks! I’ll definitely check out Python graphlib sometime. That’s more in my wheelhouse.

    • swlabr@awful.systemsEnglish
      0·
      3 days ago

      Doesn’t look interesting to me. NB I’m not a Swifty. If you’re someone looking to make a compile-time dependency injection validation framework, cycle detection seems like an early feature to add, and feels like a pretty early unit test to implement.

      • BurgersMcSlopshot@awful.systemsEnglish
        0·
        3 days ago

        DI frameworks are tricky beasts. Either they sacrifice flexibility for simplicity (I’ve seen this done in Go and in Scala, where the DI essentially generates basic instantiation and more advanced resolution is left to the app developer) or they can get really complex but do some handy things (.Net 4.x DI frameworks like Castle Windsor provided some neat lifecycle management tools but was internally very complex).

        Cycle detection gets a little hairer the more complex a dependency/ class of dependencies gets. The process itself doesn’t change but the internal representation of the graph needs to be sufficiently abstract enough to illustrate a cycle for all possible resolution scenarios.

        Based on the commit to fix the particular bug, it looks like the change will address a specific scenario but will probably fail to address similar issues.

        All this to say “the problem isn’t too hard to think about but the solution isn’t straight-forward”, also “this is a fine short- term fix but longer-term would involve redefining the internal representation of a dependency graph”, and finally " An LLM-provided solution is at best a band-aid, in the most generous light.’