3 ms·

They belong to the category of synchronous programming languages. The terms synchronous dataflow, dataflow, and synchronous reactive are also variously used. Se

They belong to the category of synchronous programming languages. The terms synchronous dataflow, dataflow, and synchronous reactive are also variously used. See: https://en.wikipedia.org/wiki/Synchronous_programming_language https://en.wikipedia.org/wiki/Synchronous_programming_langua... . This paradigm has also been used in a embedded and real time software. The recently deceased Eve programming language combined the synchronous and relational paradigms. I think it's a neglected approach to concurrency, and I was sad to see Eve run out of money because it seemed like the first time a synchronous programming language for software and "for the masses" was being developed. If you want a detailed systematic account of programming paradigms, (without detailed study of what applications they are good and bad for I'm afraid) I would highly recommend Concepts, Techniques, and Models of Computer Programming by Roy and Haridi (this book leans towards dataflow oriented paradigms, explaining a few other paradigms using the idea).

pgt 9y ago
By “recently deceased Eve programming language,” are you referring to witheve.com? Where do you see it has been abandoned? Edit: Ah, found it. https://groups.google.com/forum/m/#!topic/eve-talk/YFguOGkNrBo https://groups.google.com/forum/m/#!topic/eve-talk/YFguOGkNr...
- def- 9y ago
  https://groups.google.com/forum/#!topic/eve-talk/YFguOGkNrBo https://groups.google.com/forum/#!topic/eve-talk/YFguOGkNrBo
  - nielsbot 9y ago
    Too bad. I had high hopes for these guys... Seems like selling programming paradigms is a tough business...
    - mpweiher 9y ago
      I think one of the issues is that most sellers of "new" programming paradigms try to sell theirs as "the one". As Floyd pointed out, there's tons, and putting on my conservative hat, there is probably a reason, at least partially good, that the currently dominant paradigm became dominant. In fact, if I only had one paradigm to play with, I'd probably also want the current one, despite its limitations. So what we then do is take the current paradigm and try to conservatively extend it. That also doesn't seem to work because you can't just bolt paradigms on top of each other. So putting on my revolutionary hat, we have to blow it all up. I think the solution is generalization ("refactor to abstract superclass"): do something more general, then reproduce the dominant as well as other paradigms from within that generalization.
banachtarski 9y ago
From the wiki article: > The synchronous abstraction makes reasoning about time in a synchronous program a lot easier, thanks to the notion of logical ticks: a synchronous program reacts to its environment in a sequence of ticks, and computations within a tick are assumed to be instantaneous, I wouldn't classify HDLs as synchronous or reactive programming explicitly because the last assumption in the quote (instantaneous ticks) is emphatically false when doing HDL programming. Synchronous programming (as with FRP systems in haskell, usage of mobx or Vue in javascript, or other such libraries) affords the programmer this tick based Excel-like approach to expressing cause-effect chains. You really can't do this in, say, Verilog if you want a functioning program.
- anewhnaccount2 9y ago
  You can definitely argue the toss about paradigms, since things tend to kind of overlap and blur into each other unless you're careful. It's true, if you want a synthesisable design you need to meet timing. However, once you meet timing you can assume your ticks are instantaneous. I would argue that for me, there is still a somewhat similar feel to the parts of HDL that don't feel like hardware design e.g. creating pipelines. This is a limitation of hardware rather than the programming language per-se. This type of imprecision seems common when talking of programming (language) paradigms: are they based on languages in an idealised world, execution environments, language ecosystems, APIs exposed by the operating system? We can only really talk about them in an exact sense when we work in an artificial environment as in Roy and Haridi. Given the inherent imprecision, I don't see why when we deal with real systems, we shouldn't bend definitions a little bit and say a language "sort-of" or "mostly" exhibits a certain paradigm.
  - banachtarski 9y ago
    Maybe "pipeline programming" is a pretty apt description. But to your point, you could argue that VHDL and Verilog are just bad synchronous programming languages haha.

pgt 9y ago

By “recently deceased Eve programming language,” are you referring to witheve.com? Where do you see it has been abandoned? Edit: Ah, found it. https://groups.google.com/forum/m/#!topic/eve-talk/YFguOGkNrBo https://groups.google.com/forum/m/#!topic/eve-talk/YFguOGkNr...

def- 9y ago
https://groups.google.com/forum/#!topic/eve-talk/YFguOGkNrBo https://groups.google.com/forum/#!topic/eve-talk/YFguOGkNrBo
- nielsbot 9y ago
  Too bad. I had high hopes for these guys... Seems like selling programming paradigms is a tough business...
  - mpweiher 9y ago
    I think one of the issues is that most sellers of "new" programming paradigms try to sell theirs as "the one". As Floyd pointed out, there's tons, and putting on my conservative hat, there is probably a reason, at least partially good, that the currently dominant paradigm became dominant. In fact, if I only had one paradigm to play with, I'd probably also want the current one, despite its limitations. So what we then do is take the current paradigm and try to conservatively extend it. That also doesn't seem to work because you can't just bolt paradigms on top of each other. So putting on my revolutionary hat, we have to blow it all up. I think the solution is generalization ("refactor to abstract superclass"): do something more general, then reproduce the dominant as well as other paradigms from within that generalization.

banachtarski 9y ago

From the wiki article: > The synchronous abstraction makes reasoning about time in a synchronous program a lot easier, thanks to the notion of logical ticks: a synchronous program reacts to its environment in a sequence of ticks, and computations within a tick are assumed to be instantaneous, I wouldn't classify HDLs as synchronous or reactive programming explicitly because the last assumption in the quote (instantaneous ticks) is emphatically false when doing HDL programming. Synchronous programming (as with FRP systems in haskell, usage of mobx or Vue in javascript, or other such libraries) affords the programmer this tick based Excel-like approach to expressing cause-effect chains. You really can't do this in, say, Verilog if you want a functioning program.

anewhnaccount2 9y ago
You can definitely argue the toss about paradigms, since things tend to kind of overlap and blur into each other unless you're careful. It's true, if you want a synthesisable design you need to meet timing. However, once you meet timing you can assume your ticks are instantaneous. I would argue that for me, there is still a somewhat similar feel to the parts of HDL that don't feel like hardware design e.g. creating pipelines. This is a limitation of hardware rather than the programming language per-se. This type of imprecision seems common when talking of programming (language) paradigms: are they based on languages in an idealised world, execution environments, language ecosystems, APIs exposed by the operating system? We can only really talk about them in an exact sense when we work in an artificial environment as in Roy and Haridi. Given the inherent imprecision, I don't see why when we deal with real systems, we shouldn't bend definitions a little bit and say a language "sort-of" or "mostly" exhibits a certain paradigm.
- banachtarski 9y ago
  Maybe "pipeline programming" is a pretty apt description. But to your point, you could argue that VHDL and Verilog are just bad synchronous programming languages haha.