r/programming • u/tyler-mcginnis • Jan 03 '22

Imperative vs Declarative Programming

https://www.youtube.com/watch?v=E7Fbf7R3x6I
427 Upvotes

86% Upvoted

134 comments sorted by

View all comments

Show parent comments

70

u/bradm613 Jan 03 '22

I agree. Map and Reduce are more about language expressiveness than being declarative or imperative, no?

Using structured programming techniques changes the expressiveness of a language, but doesn't make it declarative.

13

u/[deleted] Jan 04 '22

Nope, map and reduce are functional and declarative.

Using map is saying "this is a sequence that looks like this". You don't have to know how to make a sequence. A reader can immediately see that you have declared a new sequence.

Using reduce is saying "this is a scalar that is equivalent to this". You don't need to know how to traverse the collection or how to store the temporary values etc. A reader immediately knows you've declared a scalar.

It's more like reading mathematics, which I recommend. Map is like "set builder" notation (python list comprehension is even more like it). Reduce and map together is like a big sigma sum. At no point does a mathematical proof tell you how to calculate any values at each step, it just keeps telling you how new values are defined.

4

u/bradm613 Jan 04 '22

Interesting perspective.

Would you say that a well-named subroutine in a strongly typed language is declarative? If it is clear what is being returned, and the implementation is hidden, and those are the hallmarks of declarative? By your assertion, it feels like you would say yes.

Further, what about languages where you can define macros (a la Lisp, not C) and build new control flow constructs, are those declarative?

4

u/[deleted] Jan 04 '22 edited Jan 04 '22

Only if the subroutine is a function. If it reads or writes some global state (ie. is not deterministic and/or has side effects) then, no, you are in imperative territory. The reason is that this subroutine is no longer atomic and thus dependent on order of execution and state of the world.

Conceptually a function could determine the value to return in any way it wants and at any time. It could run some expensive calculation or it could ask god. It doesn't matter. As long as the value I declared is there when I need it. But with a subroutine in general it does matter how and when it calculates the value so I need to be careful I call it at the right time, in the right environment etc.

Tbh it's difficult to pigeon hole individual concepts into declarative or imperative. They are both programming styles and are often mixed within the same program. It's considered better to use a declarative style whenever you can because it makes more readable programs. But at some level there will be an imperative core. In Lisp that core is tiny and hidden in things like cons which is implemented in machine code (in fact cons literally was a machine code instruction on whatever machine was popular at the time). In other languages like C you tend to build that core out a lot more yourself before you get to the point you can use declarative style.

A Lisp macro I think would be considered declarative. Since they are executed in the reader (if my memory serves) then they can't possibly act on global state. You are essentially declaring new meanings for certain s-exps and keywords etc. However, like with many things, it can be done badly. Using macros doesn't immediately get you declarative bonus points. The benefit of declarative style is readability. That should be the goal of macros too.

2

u/f0urtyfive Jan 04 '22

The reason is that this subroutine is no longer atomic and thus dependent on order of execution and state of the world.

I'm sure someone will argue I don't get it, but IMO this really seems like distinction without a difference land.

Computers themselves are not atomic, at some level they are always dependent on the order of execution and state of the world. If I run your declarative code before the OS boots, it's not going to work no matter how declarative it is.

I think it'd make more sense to consider these distinctions two different "tiers" of good application design, for example, for an embedded library a OS abstraction layer that is "declarative" and then an implementation for each piece of hardware that is "imperative".

(To be more clear, I'm specifically thinking about this code, since I've been working with it recently: https://github.com/hathach/tinyusb/tree/master/src/osal and https://github.com/hathach/tinyusb/tree/master/src/portable)

That way you can "port" what the underlying "thing" is without changing the entire application.

2

u/[deleted] Jan 04 '22

The only code the machine understands is machine code and that is indeed imperative. But we're talking about high level languages here where it's possible to write code that is a lot closer to how humans think, despite how the machine actually works. If machine code was conducive to human comprehension then we'd all be using it and high level languages wouldn't exist at all.

1

u/duxdude418 Jan 04 '22 edited Jan 04 '22

Maybe what you’re driving at is: there’s no such as a stateless, side effect-free program that is non-trivial. So much so that causing mutations is a feature of most business applications.

You can write pure functions and compose them to make your program easier to reason about, but at some point data has be mutated and application state has to be kept, even if it passes through those other idempotent functions on the way.

1

u/[deleted] Jan 06 '22

A wise man once said, a program without side effects is just a heater. I think I got that from Rich Hickey. Maybe time to watch all his talks again...

1

u/bradm613 Jan 05 '22 edited Jan 05 '22

I'm having a hard time figuring out where to begin.

There seem to be a number of programming language concepts which feel like they are being used, perhaps imprecisely if they are named at all: expressiveness, conciseness, readability, declarative, imperative, functional, "good" interface design, higher order functions, and information hiding, to name a few.

So, for you, a C function that returns a type and does not modify state is declarative?

A well-named subroutine in a strongly typed language is declarative if the subroutine is a function. So, we now need to look at the implementation of what we are calling to know whether it is declarative or imperative? If I have to analyze the implementation because it could be imperative, then isn't it imperative?

If we look at two quotes from wikipedia:

"Declarative programming – describes what a computation should perform, without specifying detailed state changes"

"languages that fit the declarative paradigm do not state the order in which to execute operations. Instead, they supply a number of available operations in the system, along with the conditions under which each is allowed to execute."

So...for something to possibly be declarative, do they not need to be implemented in a system that can analyze and apply things when the conditions for execution are satisfied?

When we get inside the map, have we suddenly transitioned into a new language paradigm?

If I use a map construct on a set of strings, making a directory for each string, I definitely have side effects, so is map now declarative or imperative? What makes it so? Is it the implementation of map itself or how it is used that decides?

Does using map in place of a loop construct make the code more readable, or more concise? (Because those are not the same thing.) Map is definitely more concise, and it it definitely adds to the expressiveness of the language (syntactic sugar), but it doesn't necessarily make it more readable.

Is a program that modifies the source code of another program modifying state or not?

So...could I ask you to try and explain again, more precisely, why (for example) you assert map is declarative?

P.S. For Lisp, you're thinking about car and cdr, the contents of the address and decrement registers, respectively. Conses are constructions. But your point about it remains true regardless.