Hacker News new | ask | show | jobs
by arduinomancer 1951 days ago
Hardware description languages such as VHDL/Verilog feel very similar to Factorio in that "everything is happening at the same time in parallel". Definately takes a while to wrap your head around it coming from procedural languages.

The "compilers" for these languages have very sophisticated "routing" algorithms which synthesize efficient physical layouts of circuits.

Programs like Quartus even let you edit your description visually as an abstract block diagram by dragging around wires/placing blocks.

1 comments

As an (technically) EE who studied mostly CS courses (and worked in software engineering since), that's something that's really (occasionally) bugged me with software, especially when deliberately choosing asynchronous (in the broadest concurrency-inclusive sense) patterns and syntax. It just seems so... much harder?

Electronics is just inherently 'parallelised', and software generally isn't, I get that. But some how we built up from parallel hardware to procedural synchronous (I know it isn't all but let's be honest it ~~all is) software, then built up further to sometimes wanting parallel again, and it's just sort of hard (er than it seems it should need to be) to use?

I challenge anyone who's used exclusively procedural languages to try an HDL (like Verilog or VHDL) or at least a high level declarative language (like Prolog or HCL/Terraform, as long as you view it as a language rather than config files) and not feel refreshed.

> Programs like Quartus

Egh, if I have nightmares tonight I'll know why!

Most folks will have used a least a little declarative programming if they're ever interacting with a DB - you can drop out into procedural land using cursors and functions but SQL really shines when you tell your DBMS what you want and let it figure out the details itself.

Building complex logic ins declarative languages is one of the most rewarding things I've ever done. I tend to prefer a strong focus on type transformation when approaching a problem in any paradigm (I'd tend to read "Get the user's name" as "Create a transformation from a User ID to the User's Name and then cast the value") but just putting all the blocks for declarative programming together and then saying "Now, go!" is quite satisfying.

If you use a language that lets you program in terms of data rather than operations this principle can be applied to programs - it's a hard problem, however.

Clock signals do seem like a very useful abstraction (when I have my software-hat on) - not sure how you'd do it for a general purpose CPU however.