Egregoros

as a toolmaker, there's an inherent tradeoff that I encountered years ago when I just started working at ChipFlow; what I was asked was essentially to develop Amaranth further as a way to de-skill the hardware design (RTL) field. I agreed because I don't really value the skill of knowing every one of the five hundred different ways in which SystemVerilog is out to fuck you over; I think we'd be better off with tooling that doesn't require you to spend years developing this skill, and that would be a lot more friendly to new RTL developers, and people for whom RTL isn't the primary area of work.

I also knew that ChipFlow was on the lookout for opportunities to shoehorn AI somewhere into the process. (at first this was limited to "test case generation"—frankly ill conceived idea but one I could hold my nose at and accept—nowadays they've laid off everyone and went all-Claude.) however, it was clear pretty early on that making hardware development more accessible to new people inherently means making it more accessible to new wielders of the wrong machine. benefiting everyone (who isn't a committed SystemVerilog developer) means benefitting everyone, right?

you can trace this trend in adjacent communities as well. Rust and TypeScript have rich type systems that generally help you write correct code—or bullshit your way towards something that looks more or less correct. I'm pretty sure it's a part of the reason Microsoft spent so much money on TypeScript.

so today I find myself between a rock and a hard place: every incremental improvement in tooling that I build that makes the field more accessible to new people also means there's less of a barrier to people who just want to extract value from it, squeezing it like Juicero (quite poorly but with an aggressively insulting amount of money behind it). so what do I do now?..

pov: you wake up to receive a package with a vacuum chamber and discover that the vendor is a crackhead and a menace to society

this is a vacuum chamber. the power supply that comes with it has a type-C connector and it puts 12V on Vbus unconditionally. the pump works off both 5V and 12V, so it can pull vacuum off a normal type-C power supply. but the solenoid release valve (that lets you open the chamber once you're done) requires their illegal type-C-shaped power supply. also, not only does the chamber not support PD negotiation, it does not even have a CC pulldown.

to add insult to injury, it's using a NEMA 1-15P plug.

@glyph with my protocol designer hat on i absolutely agree; i didn't put it in the original message because the point would be i think lost on most people, but i don't really have anything against json framing in this context. (sure, it's janky and poorly defined, so's irc's current text framing. xml is clearly not intended to be streamed like that though)

a big issue however is that people start with the idea that they'll make the most extensible protocol, the last protocol anybody'll ever need for anything, and this is what turns it from "json framing" into "json abomination". generally you end up with something that is not even extensible (because there are de-facto expected combinations of extensions and the complexity means only a few implementations dominate) and not that good for the end users' needs