I have only briefly touched FPGAs in college, but to me writing Verilog/VHDL is akin to writing C for baremetal MCU. In both cases it is not too difficult to wr

I have only briefly touched FPGAs in college, but to me writing Verilog/VHDL is akin to writing C for baremetal MCU. In both cases it is not too difficult to write correct code that simply does not work, or more appropriately makes no sense, on given hardware. As for the tooling, to me it looked too low level with too many knobs for a beginner without significant domain knowledge to grasp. Maybe that or [Footnote] was what intimidated GP. I understand the reasons why high level building blocks in high level programming are easy to use self contained modules while high level modules in HDL have that many twists and knobs to twiddle with. I guess software developers are so much used to taking prebuilt modules and something-something-fudge-fudge-rinse-repeat-until-works'ing them together (not meant as an insult in any way; I am myself guilty of that), that we sometimes forget that `x if y else z` actually moves the magic smoke and pixies in ICs. So I think I can sum up your comment on traditional developer sloppiness and GP's comment on atrociousness of tooling in one sentence: too often we forget that HDL programs must be formally correct. [Footnote]: I remember some fragments of my fights with FPGA when things worked intermittently because my signals were not stable (race conditions, dear past me) or whatever have I written did not even make sense on given hardware (probably no hardware would support such weird trigger conditions, but there I was staring at the screen with blank eyes and only beginning to seriously consider actually thinking), yet the tooling happily synthesised my code.