
The paradigms of programming - godelmachine
https://blog.acolyer.org/2018/01/29/the-paradigms-of-programming/
======
sitkack
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
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...

~~~
hyperpallium
Great code, like great literature, should entertain, challenge and make you
question your preconceptions and yourself.

~~~
saltedmd5
I hope this comment is ironic.

Great code should be predictable, obvious and easy to change.

~~~
akvadrako
If it's predictable and obvious it'll be so boring, I won't even want to read
it. A good program needs conflict and moral ambiguity!

~~~
bryanrasmussen
No, it needs lyrical beauty!

~~~
ogdoad
In C, everything rhymes in ';'.

~~~
52-6F-62
LOL! I almost spit out my lunch. Which wouldn't be good because I'm sitting at
my desk, in front of my station, in a very quiet office.

Bravo.

------
klmr
> 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.

~~~
nerpderp83
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.

------
cnees
“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.

------
godelmachine
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 :)

~~~
anewhnaccount2
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_langua...](https://en.wikipedia.org/wiki/Synchronous_programming_language)
. 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).

~~~
banachtarski
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
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
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.

------
mpweiher
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/)

------
keymone
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"

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

~~~
lebski88
Probably a bit of an impossibility with this format. Adrian writes one of
these paper reviews a day on the train into work.

~~~
mcqueenjordan
Makes sense. Guess I’ll have to crack open the actual paper. :)

------
tzhenghao
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)

------
kesor
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.

------
kruhft
What's your paradigm?

------
jlebrech
I thought those were called design patterns.

