Also, although a fold is not a control structure in the traditional sense, like the categories described by Niklas Wirth, it is a control structure with very precise and unambiguous meaning. Keep in mind Wirth was describing the minimum amount of control abstraction necessary.

Truly great advances in program architecture seem to occur because people are thinking about data flow, instead of merely data structures and especially instead of merely algorithms. Consider Wirth’s book Algorithms + Data Structures = Programs. He put the “Algorithms” part first, reflecting an emphasis on algorithms. Lately, we have reversed the phrase to say Data Structures & Algorithms, because the structure can determine the algorithms you implement. However, what really makes sense is to model the data flow and go from there.

Wuuuuurht?

The first rule of programming is ‘Figure out what you want to say before you figure out how to say it’. Talking down to imperative programming by making it a category within functional programming is incorrect. It treats imperative knowledge like it is part of the implementation, when it is more likely an artefact of the design requirements of the software you are building. Similarly, identifying declarative knowledge belongs in the phase of software development before implementation.

The ability to translate declarative knowledge and imperative knowledge into programmatic statements necessarily falls under control of the language and the skill of the programmer. Many people feel it’s important to make this separation apparent, with the belief that it contributes to quality assurance.

For this reason, pointing me to some Haskell examples does not mean much to me. I usually (not always) know when I am unnecessarily conflating different control structures in my implementation language, and when I can easily express an imperative thought because there is a convenient mechanism in the language to do so. At the same time, because I have this knowledge, I can usually (not always) translate the design requirements to any language.

Note that you said: “Note that all functional programming languages support imperative programming, since imperative programming is just a special type of functional programming.” This is an awkward statement. If imperative programming is a subset of a functional paradigm, then it is not certain that all functional programming languages support imperative programming. In other words, you are making an unsupported statement.

However, I think that the issue here is we are inadvertently talking past each other. If you only wish to say that you can express imperative knowledge in a functional program, then you are correct. However, procedural languages can do this too. That is why I huffed at the suggestion imperative programming is “just” a special type of functional programming. It’s more accurate to say that imperative thoughts can be expressed in a functional paradigm… as well as a procedural or even object-oriented paradigm.

Look at it this way: knowing what to believe without ever being able to grok how-to is an incomplete paradigm. Categorizing a scientific paradigm in such a way to suggest that you can’t convey certain knowledge types is an ill-defined paradigm. Being able to define various kinds of knowledge is just better science.

I’d like to correct this statement.

It is indeed true. One possible correction is, “This is not initially obvious to most intuitions”.

Next time you use Haskell, put *everything* inside IO and use IORef to emulate in-place updates i.e. imperative programming; the specific type of functional programming. Equational Reasoning is your friend

First, imperative knowledge generally describes “how to”. This is consistently how it is described in various CS disciplines.

In Expert Systems theory, imperative rules tell the knowledge system “how to” behave. A related declarative rule would tell the knowledge system what it could believe, but would leave how unspecified. (Most knowledge systems have rulesets that combine imperative and declarative knowledge, but also might include exclamatory knowledge and interrogative knowledge.)

In Programming Languages theory, imperative statements describe how the program will do something.

Second, a functional program can have a high degree of imperative expressiveness. I usually associate precise control structures with imperative expressiveness. foldl and foldr in Haskell are excellent examples of precise control structures. However, “expressiveness” is such a qualitative term that someone could view imprecise control structures like basic loops as more expressive because they are so adaptable.

Third, declarative expressiveness should be our goal when programming complex systems: Program to an interface, not an implementation.

Fourth, Google has a “Note It” feature on search results. If you find a PDF that is really good, then “Note It”. You will come to love this feature, because you will never misplace a journal article again.

Yes, I am possibly rephrasing the infamous Blub paradox.

However, Lisp does have a type system, just not a very good one (hence, it is quite low on the Blub spectrum itself). Note that all functional programming languages support imperative programming, since imperative programming is just a special type of functional programming.

I’ve been searching for the paper that helps support this point, since it was so good, that I forgot the name (and therefore, I am struggling to bring it up in Google). If anyone can point me to it, I’d most appreciate it! It was something about reasoning about imperative programs as referentially transparent functions.

Therefore, no.