There are numerous attempts at fixing the problem, but all of them ring hollow as the big ASIC design shops basically are all relying on ancient languages.
Another thing that IMO has dealt a grave blow to the whole scene is a cultural one: people in the hardware business still haven't understood and digested the lessons of open source and sharing. The whole industry still operates on notions of "industrial secrets" and spends tremendous amounts of energy trying to hide how what they build works.
I mean if you need a example of how bad it still is, the dominant word still used to describe a chunk of functionality in that world is "IP".
Who in their right mind in the software industry would call a piece of code they wrote "intellectual property", as in "just download my IP and use it in your project" ?
My point is that it's a little silly to evaluate hardware engineering through the lense of software engineering.
In hardware engineering the part that looks like "software" (what a HW engineer may refer to as the behavioral RTL) is a small component of the total design effort. The tradeoffs are all completely different.
Computer hardware engineering is much closer to designing a bridge than it is to writing a software application. Debating the best hardware-descriptor language is similar to debating whether bridge designers should use No. 1 or No. 2 pencils.
Perhaps you’re an FPGA guy? The tradeoffs are different in that world.
You have also entirely ignored my second point :)
Again this is evaluating HW through a SW prism. Where’s github for bridge designers? rocket scientists? brain surgeons?
HW engineers share info in pretty much the same way that every other industry in the world does (except SW). The concepts are made available through patents, conferences, journals, and press releases. More detailed info is often made available through purchaseable IP.
Maybe it could be better, but there are good reasons that HW IP can’t be shared as easily as SW source code.
I mean, it wasn't even made for chip synthesis.
(I had trouble with the continuous math once we reached steady-state analysis. Besides, I wanted to just get through all that to the fun stuff: discrete math, logic design, and programming.)