https://futureofcoding.org/ logo
#thinking-together
Title
# thinking-together
p

Personal Dynamic Media

06/20/2022, 6:16 PM
Is it possible that in our efforts to find alternatives to imperative programming, we have failed to promulgate knowledge about how to program imperatively? Back in the day, folks like Dijkstra, Hoare, Wirth, Knuth, and Naur did a lot of work on figuring out how to write imperative programs that did what they were intended to do. However, nowadays, I get the impression that much of the energy being spent on making programs better is focused on alternative ways to structure programs, like object oriented design, distributed and/or parallel and/or concurrent, event driven, reactive, etc. However, most of these design disciplines still involve executing chunks of imperative code, they just involve new and different ways of deciding which imperative code runs when. This may be a dull and boring idea, but is it possible that part of what we need in order to improve software is wider distribution and study of the old ways of writing correct imperative programs, so that more of the little chunks of imperative code that get executed during an object oriented or event driven program will do what they are supposed to do?
a

Alex Cruise

06/20/2022, 6:31 PM
the old ways of writing correct imperative programs
Not sure how well this ever worked šŸ˜‰
k

Kartik Agaram

06/20/2022, 9:29 PM
I notice you didn't mention functional in your list. Was that deliberate? šŸ™‚ I don't think it involves chunks of imperative code, or orchestration of when each step runs. Dijkstra's A Discipline of Programming is one of the top 10 books on my bookshelf, and highly recommended no matter what paradigm you program in.
amiga tick 1
p

Personal Dynamic Media

06/20/2022, 9:34 PM
Yes, I left out purely functional programming and logic programming on purpose, both because they are not especially popular and because it requires some twisted thinking to fit them into the viewpoint I am taking. However, I would argue that mostly functional programming, like in Scheme, ML, or Clojure would still fit into this worldview of programs still containing small chunks of imperative code that need to be written correctly.
r

Ryo Hirayama

06/21/2022, 12:54 AM
Rust does the things. To write imperative programming correctly today, we will need Rust or better.
j

Jan Ruzicka

06/21/2022, 5:53 AM
Iā€™m not sure I agree with that bits of imperative code always get run (I mean: obviously it does; but is this a good viewpoint?). However, what certainly happens in all paradigms (even functional and logic) is that inbetween ā€œcybernetical partsā€ (parts that do stuff: function applications, rules, statements, message sends, ā€¦) you get to play with lexical variables containing state. These arenā€™t easily analyzed, even when the state is ā€œimmutableā€ (immutability doesnā€™t imply discoverability or predictability). So what is needed, in my view, is better handling of lexical variables (what they contain w.r.t. cybernetic elements of the program) and their evolution through control flow (imperative control flow, but also repeated message receives / function applications). One can imagine that a better understanding of imperative programs might lead to this handling of variables and control flow, since both are present in almost all paradigms in the form they had in imperative languages (an exception I can think of is constraint-solving).
y

Yusuke Shinyama

06/21/2022, 10:55 PM
I don't think imperative style is necessarily inherent or ideal for computer programs. It was rather born out of the limitation of early computer architectures (single ALU, single memory bus, everything has to be synchronized, etc.) When multiple operations are happening in multiple places, imperative programming will no longer be suitable. Another thing to consider is that modern software needs to take care of thousands of different conditions (hardware configurations, user preferences, access controls, GUI events, network inputs and concurrency!). In a purely imperative style, it will blow up if-thens. We somehow needed to "abstract away" those conditionals. Programming styles don't evolve in vacuum. It's constantly reacting to ever changing needs from external forces like these.
šŸ’— 2
w

wtaysom

06/23/2022, 4:41 AM
Think about it this way. Though an imperative, interactive, step-by-step process may be the domain of a program, it doesn't mean a language with imperative semantics is going to be a good fit for the domain. Often the process semantics and the imperative semantics have a big mismatch, take event driven UIs as an example.
šŸ° 1
3 Views