Okay, so a function is a bit of code that takes an input, does some things, and outputs a value.
I think this is the crux of what makes things confusing. :)
A function is a mapping between arguments and results -- it doesn't do anything.
A procedure is a sequence of operations that happen over time.
Where it gets confusing is that we usually implement functions with procedures, because most programming languages can't express functions, and so people got into the habit of confusing the names, and so in many systems we ended up calling procedures functions.
Which ends up with a 'pure function' being a procedure which implements a function, as opposed to a procedure which doesn't implement a function, which people now call an 'impure function' in contrast.
Personally, I try to talk about functions and procedures, which makes it all straight-forward. :)
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
It's a good definition for the function in mathematics (mapping), but the sense in programming evolved beyond that. Now, a function is not only a mapping but a series of instruction.
Many different concepts in programming have now the same name (for example encapsulation and information hiding, which are normally different concepts), and I'm not sure it's a good thing. We lose a lot of nuance.
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.
I think this is the crux of what makes things confusing. :)
A function is a mapping between arguments and results -- it doesn't do anything.
A procedure is a sequence of operations that happen over time.
Where it gets confusing is that we usually implement functions with procedures, because most programming languages can't express functions, and so people got into the habit of confusing the names, and so in many systems we ended up calling procedures functions.
Which ends up with a 'pure function' being a procedure which implements a function, as opposed to a procedure which doesn't implement a function, which people now call an 'impure function' in contrast.
Personally, I try to talk about functions and procedures, which makes it all straight-forward. :)
That's a very good point.
It's a good definition for the function in mathematics (mapping), but the sense in programming evolved beyond that. Now, a function is not only a mapping but a series of instruction.
Many different concepts in programming have now the same name (for example encapsulation and information hiding, which are normally different concepts), and I'm not sure it's a good thing. We lose a lot of nuance.
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.