3 ms·
I think reactive/synchronous languages [1] deserve a category of their own. They share little/no overlap with any of the others. My background in electrical e
by colanderman 3y ago
I think reactive/synchronous languages [1] deserve a category of their own. They share little/no overlap with any of the others. My background in electrical engineering biases me to Verilog, VHDL, and LabVIEW as exemplars, but there are many others. The distinguishing characteristic of the category is that programs are effectively declarative functions of time and can be composed as such, much like electronic circuits.
(I categorized the temporal declarative language TLA+ into the Prolog family in another comment -- a main distinction here is, though one can express reactive relationships in TLA+, the intent of the language and design of the TLC model checker is that such relationships are only usable for verification code, whereas implementation code must be written as state-succession pairs. A true reactive language permits and encourages both styles of coding for implementation code -- e.g. Verilog's = and <= operators. Vice-versa, a true logic language includes nondeterminism as a core construct, whereas reactive languages typically do not.)
[1] https://en.wikipedia.org/wiki/Synchronous_programming_language https://en.wikipedia.org/wiki/Synchronous_programming_langua...
- eschneider 3y agoVerilog/VHDL isn't so much a programming language as a hardware definition language and woe to anyone who conflates the two. Verilog/VHDL is it's own class of thing and sits outside of software languages.
- dgacmu 3y agoWithout weighing in on exactly if it is or isn't a "language", I think VHDL/verilog absolutely have a place in the list and are a fantastic thing for (some, particularly lower-level interested) programmers to learn precisely because it's such a different way of thinking about programming and huge piles of heterogeneous behavior happening concurrently. It really cooked my head for the first week or two and I think I came out the other side better. (I hated writing VHDL with a passion. It was painful medicine for a software person used to algol-style languages. But I'm really glad I did.)
- denotational 3y agoThis is an overly simplistic take in my opinion. From a PLT perspective they are programming languages just like any other, and one can analyse them using the same machinery (formal semantics, typically of the operational style) as any other programming language. Just because they are not even close to an imperative paradigm doesn’t make them any less of a programming language. They are reasonably close to process-calculus/message-passing languages in the sense that you can treat a Verilog process as a receiver listening to channels that contain messages generated when nets/variables are driven. I agree that a software developer who tries to write Verilog as if it were C will very quickly run into trouble, but that isn’t because it’s not a programming language; it’s because it’s a programming language with a similar syntax to C but with drastically different semantics.
- colanderman 3y agoThey're languages for descriptions of reactive dataflow. That they happen to specialize in dataflow which is synthesizable as hardware doesn't change that they're programming languages. (Yes, it's easy to accidentally write unsynthesizable code in them -- but similar issues hold true for many declarative languages.)
- bee_rider 3y agoMy education was in EE but I switched over to programming ASAP. So my take on Verilog/VHDL is, like, super uninformed/perpetual honeymoon/starry-eyed. But it always seemed to me that these HDLs, since they fundamentally are pretty low-level and asynchronous, if translated to assembly somehow, ought to expose a ton of instruction level parallelism.
- colonwqbang 3y ago"Asynchronous" not the right word since "synchronous" in hardware typically refers to clock signals. The parallelism in hardware is indeed extreme. Like if every line in your program ran at once, and then repeating every clock cycle.
- daxfohl 3y agoParadigm-wise I find these the most interesting. All the others (maybe except prolog) are really just different ways to write a sequence of instructions. HW definition is fundamentally different. It does everything all the time and you have to figure out how to make it do what you want. Lots of opportunities for tricks to sneak in some calculations on temporarily unused wires, etc.