It's not an evolution -- it is a devolution, because early programming languages could not reason effectively about functions.
So they ended up using algorithms (procedures that implement functions) instead, because they could reason about them in a mechanical sense.
Unfortunately when we reason about them in a mechanical sense it becomes very difficult to prove invariant relationships about them, so a lot of the work compilers do is to try to guess what function a procedure might implement, so that it can avoid implementing the procedure. :)
More recently we have programming languages which can reason effectively about functions, which is why functional programming is becoming more popular.
(Although a lot of what people call functional programming is just the use of higher order procedures)
Coding for 20 years | Working for startups for 10 years | Team leader and mentor | More information about me: https://thevaluable.dev/page/about/
Twitter: @Cneude_Matthieu
More recently we have programming languages which can reason effectively about functions, which is why functional programming is becoming more popular.
Do you think about Haskell? The only functional programming languages I used are Scheme and Clojure.
I think that Haskell is a good example, Miranda and Clean also.
Prolog and Mercury also, although things like the cut operator make it a bit more complicated.
Scheme and clojure are both procedural languages, with good support for function composition.
Clojure has good support for immutable data structures, but that's not quite what we're after here.
The ACL2 theorem prover is probably the closest in the lisp family.
C++ is gradually trying to get its toes wet with things like constexpr functions, and templates, but ... :)
Which is not to say that procedures and algorithms are bad, and functions are good -- it's just that procedures are easy to execute and functions involve harder proof-work -- there are good economic reasons for the bias toward procedures in programming languages.
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.
It's not an evolution -- it is a devolution, because early programming languages could not reason effectively about functions.
So they ended up using algorithms (procedures that implement functions) instead, because they could reason about them in a mechanical sense.
Unfortunately when we reason about them in a mechanical sense it becomes very difficult to prove invariant relationships about them, so a lot of the work compilers do is to try to guess what function a procedure might implement, so that it can avoid implementing the procedure. :)
More recently we have programming languages which can reason effectively about functions, which is why functional programming is becoming more popular.
(Although a lot of what people call functional programming is just the use of higher order procedures)
Do you think about Haskell? The only functional programming languages I used are Scheme and Clojure.
I think that Haskell is a good example, Miranda and Clean also.
Prolog and Mercury also, although things like the cut operator make it a bit more complicated.
Scheme and clojure are both procedural languages, with good support for function composition.
Clojure has good support for immutable data structures, but that's not quite what we're after here.
The ACL2 theorem prover is probably the closest in the lisp family.
C++ is gradually trying to get its toes wet with things like constexpr functions, and templates, but ... :)
Which is not to say that procedures and algorithms are bad, and functions are good -- it's just that procedures are easy to execute and functions involve harder proof-work -- there are good economic reasons for the bias toward procedures in programming languages.