There's a bit of a terminology issue here with the word "imperative". There's a lot of inconsistency associated with this term. Check out this Wikipedia article:
I think what you're trying to express is the contrast between PROCEDURAL and functional.
Imperative programing has to do with viewing the computer as a Von Neumann model, where coding is based on mutating memory addresses. In that sense, Functional can be considered as distinct because, rather than mutating memory, in a pure functional language (like OCaml) you never change memory, but rather you create a new value based on another.
But in another sense, many "functional" languages are still very much imperative, because coding is about running a sequence of statements in order, and memory mutation is still allowed.
I think what you're comparing here is a structured programming / procedural approach vs a functional one. In the former you continuously mutate the same memory addresses, and in the second you use a more "pure" transformational approach without secondary effects (that presumably has advantages, especially in the face of concurrency and mathematical purity).
I rather think of the term "imperative" as opposed to "declarative". Declarative languages like SQL, Prolog, and Haskell don't necessarily execute "in order" or in a fixed way. In fact, we're encouraged to not even think about how its implemented.
In an imperative language such as Javascript or Java or Lisp or Clojure, the steps the system will take are obvious an transparent to the programmer (for better or for worse). But in a declarative language like SQL we state the problem and let the solver come up with the solution. The solution may be computed in any number of different ways.
So, I believe that a more consistent nomenclature is:
Imperative vs Declarative
Procedural vs OO vs Functional
Different dimensions discussing different things. But as I said, these terms are used a bit inconsistently.
In a practical sense, Functional programming "names your loops".. For example:
new_list = []
for elem in old_list :
.....new_list.append(xfer(elem))
In FP we call this MAPCAR, MAP or COLLECT.
REDUCE is a generalization of sums. REMOVE-IF-NOT, FILTER or SELECT is a generalization of filtering loops.
By thinking at a higher level of operations code is supposed to look more self-explanatory, and programmers are encouraged to think more globally. This is particularly useful for solving complex graph problems basing yourself on DFS and other algorithms, or for parallel programming as in OpenMPI's SCATTER, GATHER and COLLECT. And set theory gives us things such as UNION, INTERSECTION and DIFFERENCE.
Instead of focusing on the minor mechanics of a transformational operation, we can compose higher level transformations and express them more succinctly.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
There's a bit of a terminology issue here with the word "imperative". There's a lot of inconsistency associated with this term. Check out this Wikipedia article:
en.wikipedia.org/wiki/Imperative_p...
I think what you're trying to express is the contrast between PROCEDURAL and functional.
Imperative programing has to do with viewing the computer as a Von Neumann model, where coding is based on mutating memory addresses. In that sense, Functional can be considered as distinct because, rather than mutating memory, in a pure functional language (like OCaml) you never change memory, but rather you create a new value based on another.
But in another sense, many "functional" languages are still very much imperative, because coding is about running a sequence of statements in order, and memory mutation is still allowed.
I think what you're comparing here is a structured programming / procedural approach vs a functional one. In the former you continuously mutate the same memory addresses, and in the second you use a more "pure" transformational approach without secondary effects (that presumably has advantages, especially in the face of concurrency and mathematical purity).
I rather think of the term "imperative" as opposed to "declarative". Declarative languages like SQL, Prolog, and Haskell don't necessarily execute "in order" or in a fixed way. In fact, we're encouraged to not even think about how its implemented.
In an imperative language such as Javascript or Java or Lisp or Clojure, the steps the system will take are obvious an transparent to the programmer (for better or for worse). But in a declarative language like SQL we state the problem and let the solver come up with the solution. The solution may be computed in any number of different ways.
So, I believe that a more consistent nomenclature is:
Imperative vs Declarative
Procedural vs OO vs Functional
Different dimensions discussing different things. But as I said, these terms are used a bit inconsistently.
In a practical sense, Functional programming "names your loops".. For example:
new_list = []
for elem in old_list :
.....new_list.append(xfer(elem))
In FP we call this MAPCAR, MAP or COLLECT.
REDUCE is a generalization of sums. REMOVE-IF-NOT, FILTER or SELECT is a generalization of filtering loops.
By thinking at a higher level of operations code is supposed to look more self-explanatory, and programmers are encouraged to think more globally. This is particularly useful for solving complex graph problems basing yourself on DFS and other algorithms, or for parallel programming as in OpenMPI's SCATTER, GATHER and COLLECT. And set theory gives us things such as UNION, INTERSECTION and DIFFERENCE.
Instead of focusing on the minor mechanics of a transformational operation, we can compose higher level transformations and express them more succinctly.