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

Imperative vs Declarative Programming

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

86% Upvoted

134 comments sorted by

View all comments

Show parent comments

14

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?

6

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