Mastodawn

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

Show thread

David Chisnall (*Now with 50% more sarcasm!*)Apr 1

@whitequark

This is very close to where I parted ways with the FSF. There's always a tension between enabling people to create the desirable thing and enabling people to make the undesirable. Their view is that it should be very hard to make the undesirable thing, and slightly easier to make the desirable thing. My view is that you should make it so easy to make the desirable thing that people always have a choice and then, once the desirable thing exists, you can apply other pressures to get rid of the undesirable thing.

I don't think deskilling is the right framing for a lot of these things, it's about where you focus cognitive load. There's a line from the Stantec ZEBRA's manual (1956) that says that the 150-instruction limit is not a real problem because no one could possibly write a working program that complex. Small children write programs more complex than that now. That's not a loss to the world, the fact that you don't have to think about certain things means you can think about other things, such as good algorithm and data structure design.

There was research 20ish years ago comparing C and Java programs and found that the Java programs tended to be more efficient for the same amount of developer effort, because Java programmers would spend more time refining data structure and algorithmic choices and improve entire complexity classes, whereas C programmers spend the time tracking down annoying bug classes that are impossible in Java and doing microoptimisations. Of course, under time pressure, Java developers will simply ship the first thing that works and move onto new features rather than doing that optimisation. C programmers would take longer to get to the MVP level and their poorly optimised code was often faster than poorly optimised Java.

I see LLMs as very different because they don't provide consistent abstractions. A programmer in a high-level language has a set of well-defined constraints on how their language is lowered to the target hardware and can reason about things, while allowing their run-time environment to make choices within those constraints. Vibe coding does not do this, it delegates thinking to a machine, which then generates code that is not working within a well-defined specification. This really is deskilling because it's not giving you a more abstract reasoning framework, it's removing your ability to reason.

Letting people accomplish more with less effort, in an environment where their requirements are finite, ends up shifting power to individuals, because it reduces the value of economies of scale.

Show thread

dram🎀Apr 1

@david_chisnall @whitequark "[...] the purpose of abstracting is not to be vague, but to create a new semantic level in which one can be absolutely precise." - Edsger W. Dijkstra, 1972, "The Humble Programmer" https://www.cs.utexas.edu/~EWD/transcriptions/EWD03xx/EWD340.html

E.W.Dijkstra Archive: The Humble Programmer (EWD 340)

Show thread

dram🎀Apr 1

@david_chisnall @whitequark i think to me this is the key part. a (digital) hdl provides a model that you can think about bits and gates in. a better hdl provides you with the better model.

llms on the other hand promise to let you avoid all the thinking. if i may philosophizd a bit - llms promise to let you avoid expressing yourself in terms of mental labor. maybe some like this, but i know i don't. [cont'd]

Show thread

dram🎀Apr 1

@david_chisnall @whitequark one analogy i think is that it would be preposterous to think that learning and using modern algebra and category theory is deskilling to a mathematician.

maybe it's not a perfect match, but i don't think writing in a higher level language is a "deskilled" way to draw gates or write instruction bits. it produces a different *kind* of product, that is itself amenable to various different processes, some manual and some automatic. it's not just "bits with extra steps".

Show thread

✧✦Catherine✦✧Apr 1

@dramforever @david_chisnall but Amaranth and SystemVerilog are more-or-less the same kind of product (Amaranth is slightly lower-level but that's not important here). it's just that using Amaranth takes, trivially, less skill than using SystemVerilog, for the same quality of result

Show thread

David Chisnall (*Now with 50% more sarcasm!*)

@whitequark @dramforever

Thinking more, I think the issue here is regarding 'skill' as a one-dimensional axis.

To do hardware design well, you need to think about critical-path lengths for combinatorial logic, you need to think about interactions between state machines, how and when to pipeline things, what software interfaces to expose, and so on. All of those are skills.

To do this in SystemVerilog, you also need to remember the baroque consensus semantics of a batshit insane (technical term) language. That's a completely unrelated skill, much closer to playing a complex board game with weird rules than to hardware design.

Amaranth deskills hardware design in the same way that tricycles deskill cycling. Riding a bicycle requires a bunch of things that riding a tricycle requires, plus good balance (in a very specific context that isn't very closely related to balancing in any other setting: people who can stand on one leg for a long time can't automatically balance on a bicycle, for example). The tricycle removes this as a requirement, but is it a key skill for being able to get around a radius of a few miles / tens of miles under your own power at a reasonable speed? I would argue that it's a largely orthogonal skill that, if you have it, lets you do the same thing with a slightly lighter machine. I certainly wouldn't consider someone who rides a tricycle to be less skilled in any meaningful sense. Also, tricycles are cool.

Show thread

HJVT Apr 2

@david_chisnall @whitequark @dramforever
This is similar to "quality of life vs making thing casual" discussion in gaming.
In Counter-Strike precisely throwing grenades across the map is a significant part of the game.
In CSGO this was a bit random, for the trickiest throws you needed frame perfect inputs as well as luck.

When CS2 released, Valve implemented a mechanic, wherein if your inputs are "close enough", the game just pretends that you did it perfectly, eliminating randomness.

Some still argue that this was deskilling, but the reality is that the actual skill has always been in finding possible lineups and recalling the ones strategically suited for the moment in the tense action of the game, not in pressing two buttons with an exactly 42 millisecond window between them.