12 ms·

The paradigms of programming

319 points by godelmachine 9y ago

godelmachine 9y ago
Would someone kindly explain what paradigms do HDL's like VHDL & Verilog fall into? Has anyone done the enumeration of these paradigms, including a study of the deficiencies in programming caused by discouragement of unsupported paradigms? Any pointers would be highly appreciated. Thanks :)
- AlphaSite 9y ago
  My understanding is that traditional verily is declarative in the same sense that SQL is. Systems Verilog is that but also can be written as if it were C-like. Then the whole thing also has C++ templates bolted on as well. Its a complicated and messy language.
  - perlgeek 9y ago
    It's also more of a hardware design language than a programming language, so the paradigms of classical programming languages might simply not apply all that well.
- banachtarski 9y ago
  Think about composing a song (an orchestral piece to be exact). You have beats and there are measures. The entire work has parts that are played by various instruments. The functions you write are melodic lines that are played by individual instruments. However, they all need to be timed in such a way that the whole thing occurs in concert with each other. HDL programming has functional elements (combinatorial logic) that are reasonably declarative in nature. Given this combination of logic bits, produce this set of logical bits as output. There is also a timing sensitive imperative portion alluded to above. This would mirror your standard C programming (routines, finite state machines) but with additional constraints that timing must be accounted for. Imagine concurrent/parallel programming but instead of mutexes, you can control the program flow at a lower level to avoid read/write hazards as appropriate. Of course, verification/testbench software helps validate that the whole thing will operate well on various pieces of hardware (and even take things like temperature into account). There is a bit of knowledge regarding the underlying transistor logic that is helpful but not mandatory (for example, it would explain what metastability is or why a floating impedance consumes more power). It's a bit much for some, but I like it from a pure hobbyist standpoint.
- anewhnaccount2 9y ago
  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.
- TuringTest 9y ago
  For a more general analysis of programming paradigms, see the work of Peter Van Roy [2], which decomposes paradigms in the individual components [1] that are used or avoided in each particular paradigm. [1] https://commons.wikimedia.org/wiki/File:Programming_paradigms.svg https://commons.wikimedia.org/wiki/File:Programming_paradigm... [2] http://www.info.ucl.ac.be/~pvr/VanRoyChapter.pdf http://www.info.ucl.ac.be/~pvr/VanRoyChapter.pdf
sitkack 9y ago
This post itself is a prime example of programming is writing, and writing is thinking. Some of the best programmers I have known have been philosophers and lit majors. Constructing and argument, telling a story, they all have to be broken down into cohesive parts. How many times have you come across code that is modeled after the style of a child where it just says, "and then ___, and then ___, and then ___" at which point it stops and says its over? Until end users can construct their own languages, language designers have a long way to go.
- axiomofquality 9y ago
  I don't get it, wouldn't you want the child-like code that's easy to understand? That just sounds like a procedural language...
  - marklgr 9y ago
    It's ok for short code/stories, but how many pages of that would you read? There's often a point where there just are better structural choices than the crude linear approach -- hence, OOP, FP, RP and everything else.
  - hyperpallium 9y ago
    Great code, like great literature, should entertain, challenge and make you question your preconceptions and yourself.
    - imiric 9y ago
      Oh, the code I'm working with certainly does all that, but I wouldn't qualify it as good. :) I jest, but I agree with your statement.
    - NicoJuicy 9y ago
      Great code is understandable for all. So it's not the code from insert developers name here
      - 9y ago
mcqueenjordan 9y ago
I appreciate and have long agreed with the premise, but feel like the article could have fleshed it out a bit more.
- lebski88 9y ago
  Probably a bit of an impossibility with this format. Adrian writes one of these paper reviews a day on the train into work.
  - mcqueenjordan 9y ago
    Makes sense. Guess I’ll have to crack open the actual paper. :)
cnees 9y ago
“Then I look for a general rule for attacking similar problems, that would have led me to approach the given problem in the most efficient way the first time. Often, such a rule is of permanent value.“ I like this. It’s a rule for finding useful rules. I wonder if I can get good at this kind of analysis.
mpweiher 9y ago
Neat! Was just looking at this last week, currently writing a paper on the problems our current mono-culture is causing, with almost everything being a variant of the call/return architectural style. "In evaluating each year’s crop of new programming languages, it is helpful to classify them by the extent to which they permit and encourage the use of effective programming paradigms." Well, currently the answer to this is very Fordian: you can have any effective paradigm as long as it is call/return. And we will make all other paradigms ineffective, so that works out. :-) "When we make our paradigms explicit, we find that there are a vast number of them." And that's the issue: when our languages only support a single paradigm, we then have to encode every other paradigm in such a manner that it becomes implicit in the patterns that are used. In fact, even OO isn't really supported by current languages: the crux of OO is the connections between the objects, but you generally cannot write down connected objects, you must write procedures that build the connected objects. I've always felt that the people who want to make "object construction" special were on to something, but then completely missed the point. "Often our programming languages give us no help, or even thwart us, in using even the familiar and low level paradigms." Hear hear. Anyway, my take on bringing in language support for appropriate paradigms is setting "paradigm = architectural style", noticing that "architectural style ~= "language metasystem" (start with MOP in OO and generalize), then make all these bits flexible and provide enough syntactic room to make the resulting adaptations as trivially usable as possible. Yep, it's hard and it's a lot, not least because of this: "To persuade me of the merit of your language, you must show me how to construct programs in it. I don’t want to discourage the design of new languages; I want to encourage the language designer to become a serious student of the details of the design process." So there are three levels: 1. Write programs with certain paradigms 2. Create language support for those paradigms 3. Create meta-language support for writing language support for those paradigms. Slugging away at it: http://objective.st/ http://objective.st/
kesor 9y ago
What a horrible post. If the author loves Floyd so much, then why ruin his quotes with empty words that just distract and annoy the reader? Opened the post expecting to learn about paradigms of programming, all I got was a very annoying collection of quotes that were hard to read because of the way they were presented.
klmr 9y ago
> We have an unfortunate obsession with form over content I partially agree with this observation but I also think that it’s a bit misleading: especially if used, as here, to refer to the distinction between programming languages (and their grammars), rather than paradigms. In truth, different programming languages are highly coupled to different (classes of) paradigms, and the grammar of a programming language often prescribes or at least culturally supports a given set of paradigms. There might not be as much difference between, say, Pascal and FORTRAN, to use Floyd’s example. But if you asked a professor whether they taught Lisp, Java, Python or Haskell in their introductory programming course would tell you a lot about the paradigms they teach.
- posterboy 9y ago
  In High School, I didn't get to see a computer until after the introductory computer science course. And so I would assume that the basics are trivially the same, no matter which compiler is chosen to go along with it. e.g. Stanford switched from Scheme to Python, using the same work book anyway. Does that tell you anything? Probably that there's a Lisp in every language.
- nerpderp83 9y ago
  I think verbosity occurs when the language can't easily represent the paradigm. And rather than use the proper paradigm, programmers do what is easy to represent. Lightpost fallacy of hammer utilization. When we have better language creation tools we will get more outsiders, who will bring more paradigms. One thing I wished was addressed in general in all of education was in the style and analysis on the ways of solving problems. Something like solution formulation aesthetics.
jlebrech 9y ago
I thought those were called design patterns.
tzhenghao 9y ago
Semi-related talk by Scott Meyers on designing good interfaces [1]. This applies at the programming/implementation level as well. "Make interfaces easy to use correctly, and Hard to Use Incorrectly" [1] - https://www.youtube.com/watch?v=5tg1ONG18H8 https://www.youtube.com/watch?v=5tg1ONG18H8
kruhft 9y ago
What's your paradigm?
keymone 9y ago
whenever i see the phrase "programming paradigm" i recall this really interesting breakdown: http://wiki.c2.com/?ThereAreExactlyThreeParadigms http://wiki.c2.com/?ThereAreExactlyThreeParadigms and especially interesting section "The Missing Paradigm"

319 points by godelmachine 9y ago

Would someone kindly explain what paradigms do HDL's like VHDL & Verilog fall into? Has anyone done the enumeration of these paradigms, including a study of the deficiencies in programming caused by discouragement of unsupported paradigms? Any pointers would be highly appreciated. Thanks :)

AlphaSite 9y ago
My understanding is that traditional verily is declarative in the same sense that SQL is. Systems Verilog is that but also can be written as if it were C-like. Then the whole thing also has C++ templates bolted on as well. Its a complicated and messy language.
- perlgeek 9y ago
  It's also more of a hardware design language than a programming language, so the paradigms of classical programming languages might simply not apply all that well.
banachtarski 9y ago
Think about composing a song (an orchestral piece to be exact). You have beats and there are measures. The entire work has parts that are played by various instruments. The functions you write are melodic lines that are played by individual instruments. However, they all need to be timed in such a way that the whole thing occurs in concert with each other. HDL programming has functional elements (combinatorial logic) that are reasonably declarative in nature. Given this combination of logic bits, produce this set of logical bits as output. There is also a timing sensitive imperative portion alluded to above. This would mirror your standard C programming (routines, finite state machines) but with additional constraints that timing must be accounted for. Imagine concurrent/parallel programming but instead of mutexes, you can control the program flow at a lower level to avoid read/write hazards as appropriate. Of course, verification/testbench software helps validate that the whole thing will operate well on various pieces of hardware (and even take things like temperature into account). There is a bit of knowledge regarding the underlying transistor logic that is helpful but not mandatory (for example, it would explain what metastability is or why a floating impedance consumes more power). It's a bit much for some, but I like it from a pure hobbyist standpoint.
anewhnaccount2 9y ago
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.
TuringTest 9y ago
For a more general analysis of programming paradigms, see the work of Peter Van Roy [2], which decomposes paradigms in the individual components [1] that are used or avoided in each particular paradigm. [1] https://commons.wikimedia.org/wiki/File:Programming_paradigms.svg https://commons.wikimedia.org/wiki/File:Programming_paradigm... [2] http://www.info.ucl.ac.be/~pvr/VanRoyChapter.pdf http://www.info.ucl.ac.be/~pvr/VanRoyChapter.pdf

sitkack 9y ago

This post itself is a prime example of programming is writing, and writing is thinking. Some of the best programmers I have known have been philosophers and lit majors. Constructing and argument, telling a story, they all have to be broken down into cohesive parts. How many times have you come across code that is modeled after the style of a child where it just says, "and then ___, and then ___, and then ___" at which point it stops and says its over? Until end users can construct their own languages, language designers have a long way to go.

axiomofquality 9y ago
I don't get it, wouldn't you want the child-like code that's easy to understand? That just sounds like a procedural language...
- marklgr 9y ago
  It's ok for short code/stories, but how many pages of that would you read? There's often a point where there just are better structural choices than the crude linear approach -- hence, OOP, FP, RP and everything else.
- hyperpallium 9y ago
  Great code, like great literature, should entertain, challenge and make you question your preconceptions and yourself.
  - imiric 9y ago
    Oh, the code I'm working with certainly does all that, but I wouldn't qualify it as good. :) I jest, but I agree with your statement.
  - NicoJuicy 9y ago
    Great code is understandable for all. So it's not the code from insert developers name here
    - 9y ago

mcqueenjordan 9y ago

I appreciate and have long agreed with the premise, but feel like the article could have fleshed it out a bit more.

lebski88 9y ago
Probably a bit of an impossibility with this format. Adrian writes one of these paper reviews a day on the train into work.
- mcqueenjordan 9y ago
  Makes sense. Guess I’ll have to crack open the actual paper. :)

cnees 9y ago

“Then I look for a general rule for attacking similar problems, that would have led me to approach the given problem in the most efficient way the first time. Often, such a rule is of permanent value.“ I like this. It’s a rule for finding useful rules. I wonder if I can get good at this kind of analysis.

mpweiher 9y ago

Neat! Was just looking at this last week, currently writing a paper on the problems our current mono-culture is causing, with almost everything being a variant of the call/return architectural style. "In evaluating each year’s crop of new programming languages, it is helpful to classify them by the extent to which they permit and encourage the use of effective programming paradigms." Well, currently the answer to this is very Fordian: you can have any effective paradigm as long as it is call/return. And we will make all other paradigms ineffective, so that works out. :-) "When we make our paradigms explicit, we find that there are a vast number of them." And that's the issue: when our languages only support a single paradigm, we then have to encode every other paradigm in such a manner that it becomes implicit in the patterns that are used. In fact, even OO isn't really supported by current languages: the crux of OO is the connections between the objects, but you generally cannot write down connected objects, you must write procedures that build the connected objects. I've always felt that the people who want to make "object construction" special were on to something, but then completely missed the point. "Often our programming languages give us no help, or even thwart us, in using even the familiar and low level paradigms." Hear hear. Anyway, my take on bringing in language support for appropriate paradigms is setting "paradigm = architectural style", noticing that "architectural style ~= "language metasystem" (start with MOP in OO and generalize), then make all these bits flexible and provide enough syntactic room to make the resulting adaptations as trivially usable as possible. Yep, it's hard and it's a lot, not least because of this: "To persuade me of the merit of your language, you must show me how to construct programs in it. I don’t want to discourage the design of new languages; I want to encourage the language designer to become a serious student of the details of the design process." So there are three levels: 1. Write programs with certain paradigms 2. Create language support for those paradigms 3. Create meta-language support for writing language support for those paradigms. Slugging away at it: http://objective.st/ http://objective.st/

kesor 9y ago

What a horrible post. If the author loves Floyd so much, then why ruin his quotes with empty words that just distract and annoy the reader? Opened the post expecting to learn about paradigms of programming, all I got was a very annoying collection of quotes that were hard to read because of the way they were presented.

klmr 9y ago

> We have an unfortunate obsession with form over content I partially agree with this observation but I also think that it’s a bit misleading: especially if used, as here, to refer to the distinction between programming languages (and their grammars), rather than paradigms. In truth, different programming languages are highly coupled to different (classes of) paradigms, and the grammar of a programming language often prescribes or at least culturally supports a given set of paradigms. There might not be as much difference between, say, Pascal and FORTRAN, to use Floyd’s example. But if you asked a professor whether they taught Lisp, Java, Python or Haskell in their introductory programming course would tell you a lot about the paradigms they teach.

posterboy 9y ago
In High School, I didn't get to see a computer until after the introductory computer science course. And so I would assume that the basics are trivially the same, no matter which compiler is chosen to go along with it. e.g. Stanford switched from Scheme to Python, using the same work book anyway. Does that tell you anything? Probably that there's a Lisp in every language.
nerpderp83 9y ago
I think verbosity occurs when the language can't easily represent the paradigm. And rather than use the proper paradigm, programmers do what is easy to represent. Lightpost fallacy of hammer utilization. When we have better language creation tools we will get more outsiders, who will bring more paradigms. One thing I wished was addressed in general in all of education was in the style and analysis on the ways of solving problems. Something like solution formulation aesthetics.

jlebrech 9y ago

I thought those were called design patterns.

tzhenghao 9y ago

Semi-related talk by Scott Meyers on designing good interfaces [1]. This applies at the programming/implementation level as well. "Make interfaces easy to use correctly, and Hard to Use Incorrectly" [1] - https://www.youtube.com/watch?v=5tg1ONG18H8 https://www.youtube.com/watch?v=5tg1ONG18H8

kruhft 9y ago

What's your paradigm?

keymone 9y ago

whenever i see the phrase "programming paradigm" i recall this really interesting breakdown: http://wiki.c2.com/?ThereAreExactlyThreeParadigms http://wiki.c2.com/?ThereAreExactlyThreeParadigms and especially interesting section "The Missing Paradigm"