Imperative: Your expressions are statements of how to mutate your program’s state. Declarative: Your expressions are statements of what exactly your program must accomplish in terms of logic. Procedural: Your expressions call procedures-in which the state of your program is changed in a more local and controlled manner. Functional: Your expressions are pure functions-they directly map input to output with no side effects. All procedural code is imperative. It can be thought of as a subset of imperative code that allows for code reuse. All functional code is declarative. Since you map input directly to output, this requires you to declare-explicitly or implicitly-what exact logical transformation will occur. Suppose we were making a small video game. Every frame in the game, we poll for input, determine the virtual representation of all the game’s entities, and draw those entities to the screen. The main difference in paradigm is the “virtual representation” part. How do we manage state-or lack of state? Imperatively, we would store our game’s state in some arbitrary way, and would mutate that state in some arbitrary way by specifying the exact steps. Our input would just be considered another element of the state. Declaratively, we would arbitrarily define what exactly our game must exist as in a universally applicable manner. Unlike imperative programming, we have no concept of state-only an explicit, logical goal of our program. Procedurally, we would mutate our game’s state using reusable procedures. We might have a procedure to move entities, to add new entities, or remove entities. If some of our procedures had zero side effects, then they would be both imperative and functional. Strictly speaking, that specific procedure would no longer be procedural, just an implicitly-defined declarative and functional expression. Functionally, we would reproduce the entire game every frame. Our highest level function would take in the previous game state and the current input. Then, it would return an entirely new game state. Our first input is nil, and our last input is end game. Our first game state is purely declarative. Our highest level function might be allowed to call other functions, but those functions would not change the previous game state or input, keeping us functional. Even though I’m calling it “game state”, the program would be stateless. Rust programmers would probably call the type “Game”. The functional implementation would always be declarative, but-since it cannot change state-will never be imperative or procedural. Functional sucks because none of the hardware manufacturers or compiler developers optimize for it. Also, writing code with zero side effects is annoying. Complex systems have large amounts of state, and being able to abstract that state out into an input-output map is not something anyone is capable of. Declarative sucks because it has all the downsides of functional while also being the vaguest thing to ever exist. Imperative sucks because it’s too vague. Brainf*** is imperative. No one cares. Procedural…well that one’s alright. Humans seem to naturally conceptualize things as state machines, and procedural code has been optimized for over sixty years. As a programmer you’ll probably end up using a procedural “paradigm” 60-70% of the time. Occasionally you’ll write a procedure that happens to be functional. Occasionally you’ll cause a data race or de-reference a pointer to freed memory, and all the Rust programmers will make fun of you. Ask them about unsafe, inline assembly, the fact they haven’t made an operating system with wifi support and hardware-accelerated graphics, or whether they finally convinced their boss to migrate the team from javascript to typescript.
![Procedural Programming: It’s Back? It Never Went Away - Kevlin Henney [ACCU 2018]](http://i.ytimg.com/vi/mrY6xrWp3Gs/mqdefault.jpg)
I'm a beginner and this helped me to visualize how to structure things. Thank you.
Thank you for this very useful video!
functional programming vs procedural programming ?
Functional vs Imperative programming.
Imperative:
Your expressions are statements of how to mutate your program’s state.
Declarative:
Your expressions are statements of what exactly your program must accomplish in terms of logic.
Procedural:
Your expressions call procedures-in which the state of your program is changed in a more local and controlled manner.
Functional:
Your expressions are pure functions-they directly map input to output with no side effects.
All procedural code is imperative. It can be thought of as a subset of imperative code that allows for code reuse.
All functional code is declarative. Since you map input directly to output, this requires you to declare-explicitly or implicitly-what exact logical transformation will occur.
Suppose we were making a small video game. Every frame in the game, we poll for input, determine the virtual representation of all the game’s entities, and draw those entities to the screen. The main difference in paradigm is the “virtual representation” part. How do we manage state-or lack of state?
Imperatively, we would store our game’s state in some arbitrary way, and would mutate that state in some arbitrary way by specifying the exact steps. Our input would just be considered another element of the state.
Declaratively, we would arbitrarily define what exactly our game must exist as in a universally applicable manner. Unlike imperative programming, we have no concept of state-only an explicit, logical goal of our program.
Procedurally, we would mutate our game’s state using reusable procedures. We might have a procedure to move entities, to add new entities, or remove entities. If some of our procedures had zero side effects, then they would be both imperative and functional. Strictly speaking, that specific procedure would no longer be procedural, just an implicitly-defined declarative and functional expression.
Functionally, we would reproduce the entire game every frame. Our highest level function would take in the previous game state and the current input. Then, it would return an entirely new game state. Our first input is nil, and our last input is end game. Our first game state is purely declarative. Our highest level function might be allowed to call other functions, but those functions would not change the previous game state or input, keeping us functional. Even though I’m calling it “game state”, the program would be stateless. Rust programmers would probably call the type “Game”. The functional implementation would always be declarative, but-since it cannot change state-will never be imperative or procedural.
Functional sucks because none of the hardware manufacturers or compiler developers optimize for it. Also, writing code with zero side effects is annoying. Complex systems have large amounts of state, and being able to abstract that state out into an input-output map is not something anyone is capable of.
Declarative sucks because it has all the downsides of functional while also being the vaguest thing to ever exist.
Imperative sucks because it’s too vague. Brainf*** is imperative. No one cares.
Procedural…well that one’s alright. Humans seem to naturally conceptualize things as state machines, and procedural code has been optimized for over sixty years.
As a programmer you’ll probably end up using a procedural “paradigm” 60-70% of the time. Occasionally you’ll write a procedure that happens to be functional. Occasionally you’ll cause a data race or de-reference a pointer to freed memory, and all the Rust programmers will make fun of you. Ask them about unsafe, inline assembly, the fact they haven’t made an operating system with wifi support and hardware-accelerated graphics, or whether they finally convinced their boss to migrate the team from javascript to typescript.
Who else trying to unlearn the OOP dogma?