aaaashley

yes! i had this exact idea. i also thought about integrating geometric/clifford algebra using zig's type system so that you could have one mathematical multivector object instead of complex / quaternion types, etc.

Not GP, but I've written game engines and rendering engines. Vector operations are just common enough that having to write `.mul` every time is a huge pain, especially when you put many of them together for a large formula. Compare:

(physics_data.velocity + omega * change) * frame_delta_time

to

physics_data.velocity.add(omega.mul(change)).mul(frame_delta_time)

We learn to read and think about math a certain way, which is incompatible with Zig. Also, Zig's design philosophy of "reading code over writing code" is incompatible with the kind of small modification-test-cycles required when doing games, and creative programming in general. So Zig is sort of DOA anyway for that kind of thing.

But I've been using Zig for non-game projects and it's been fantastic, so definitely not "Blind leading the blind" for the overall language design, imo.

Except social media feeds are designed to addict. A smoker will spend their time smoking instead of not smoking. Does that mean that smoking is good? Why else would they do it, if not smoking was better? It's not that simple. When we blame the users, we forget tech monopolies are spending billions to engineer systems which are stealing our time.

I don't think that fashion trends are comparable. I think that fashion trends are fine in concept–things get old and we switch things up. It's the way the human superorganism is able to evolve new ideas. Unfortunately, capitalism accelerates these changes to an unreasonable pace, but even in Star Trek communism, people get bored. The cultural energy that birthed one style is no longer present, we always need something new that appeals to the current time.

But clothes still have to look nice. Fashion designers have a motivation to make clothes that serve their purpose elegantly. Inelegance would be adding metal rails to a skirt so that you could extend its length at will. Sure, the new object has a new function, and its designer might feel clever, but it is uglier. But ugly software and beautiful software often look the same. So software trends end up being ugly, because no one involved had an eye for beauty.

The "development time is more important than performance" motto treats bad performance as the problem with software, when in reality poor performance is a symptom of growing software complexity. I'm sure that each individual coder who has contributed to software bloat believed that their addition was reasonable. I'm sure everyone who has advocated for microservices fully believes they are solving a real-world problem. The issue is that we don't treat complexity as a problem in-and-of-itself.

In physical disciplines, like mechanical engineering, civil engineering, or even industrial design, there is a natural push towards simplicity. Each new revision is slimmer & more unified–more beautiful because it gets closer to being a perfect object that does exactly what it needs to do, and nothing extra. But in software, possibly because it's difficult to see into a computer, we don't have the drive for simplicity. Each new LLVM binary is bigger than the last, each new HTML spec longer, each new JavaScript framework more abstract, each new Windows revision more bloated.

The result is that it's hard to do basic things. It's hard to draw to the screen manually because the graphics standards have grown so complicated & splintered. So you build a web app, but it's hard to do that from scratch because the pure JS DOM APIs aren't designed for app design. So you adopt a framework, which itself is buried under years of cruft and legacy decisions. This is the situation in many areas of computer science–abstractions on top of abstractions and within abstractions, like some complexity fractal from hell. Yes, each layer fixes a problem. But all together, they create a new problem. Some software bloat is OK, but all software bloat is bad.

Security, accessibility, and robustness are great goals, but if we want to build great software, we can't just tack these features on. We need to solve the difficult problem of fitting in these requirements without making the software much more complex. As engineers, we need to build a culture around being disciplined about simplicity. As humans, we need to support engineering efforts that aren't bogged down by corporate politics.

Speaking of using custom CSS with YouTube, I do the following for my experience:

- Completely hide the recommended tab

- Make every thumbnail grayscale (to mitigate eye-catching thumbnails)

- Make every video title lowercase (to mitigate eye-catching titles)

Here's my code, although I have to update it every once and a while when YouTube changes:

  yt-thumbnail-view-model { filter: grayscale(); }
  h3[title] { text-transform: lowercase; }
  .ytd-watch-flexy #secondary { display: none !important; }

It's amazing how much a couple small changes can make on your browsing experience. The companies that own these products have a huge incentive to make every element purposefully addictive. I've also patched the iOS Instagram app to remove all Reels (using FLEXtool & Sideloadly), so I can keep up with my friends without falling into the traps. As developers, we have the ability to target these manipulative tactics and remove them, and I encourage you to do this as much as possible.

Unfortunately, no :( I was hoping someone would recognize the book and reply...

I think CSS tools like that appeal to people who learned web development in a kind of ad-hoc way. When I first started, I just wanted to make designs I had in my head. I kind of went from "header, text, and image on the page" to, "how do I center this?", "how do I change this color?", "how do I space these elements out?" It wasn't long before I had developed a toolkit of CSS ideas, but once you do that, you lose out on a lot of the finer details that make CSS work well. I knew how to work around weird issues using position: absolute and transform, but I wasn't familiar with block formatting contexts, or the intricacies of the box model. When all of your CSS knowledge is just band-aids placed on your other shoddy CSS knowledge, you're working on fumes. At that point, you could imagine the appeal of grabbing a prebuilt toolkit of composable styles that takes away your access a lot of the available CSS footguns.

What changed things for me was reading an short online book-style series about learning HTML/CSS from the ground up. It introduced everything from first principles, and had an approach where they explained why things were the way they were. They didn't just give you their "top 10 ways to center a div" and ask you to leave. I read the whole thing in an afternoon and it changed the way I think about web development. For the life of me, I can't remember what the book was called. If anyone's read something similar I'd love a reference, it was a while ago now and I'd still like to reference it. I specifically remember them saying "display: block is like a word document, and display: flex is like how you'd expect things to work," which illuminated a lot for me, not just about the display property, but generally about the way HTML & CSS were designed.

That's a really good way to think about it! (Bonus points for ASCII diagrams.) IIRC, I had some similar visualizations in the article but I cut them. And nice paper, interesting way to solve that problem.

JavaScript! It's not perfect, but it's the easiest language to run in the browser :)

Haha, I don't know why I didn't think to include a raycast scene, especially since that's what I was using the algorithm for!! Glad you liked it.