Naresh Jain » Agile FAQs Blog » Managed Chaos » Functions Aren’t Procedures

Functions Aren’t Procedures

Most people seem to use these 2 terms interchangeably. The key difference between the two is that functions are Referentially Transparent. Which means I can safely replace the return value of the function with its method call.

Why is this important? This is very important because, functions by definition are safe and have no side-effects. No matter how many times you call that function, in any random order, its always guaranteed to return the same value. While procedures typically update the state of a class/global scope variable or interacts with an external sub-system. Hence they have side-effects which might not be very obvious by looking at the procedure’s definition.

Functional Interfaces make your code very readable and removes any order dependencies and related complexity. Also from a testing point of view and from a decoupling point of view, functions are always preferred over procedures.

One of the visual cues you can adopt to differentiate between functions and procedures is to have functions with a well defined return type, but procedures won’t have a return type. For Ex: In Java, if the return type of a method is “void”, then its a procedure.

Interesting when you have visual cues, most of your methods become functions and you have a very small set of methods (procedures) with side-effects. And procedures are very clearly highlighted and separated out.

No related posts.

This entry was posted on Tuesday, March 3rd, 2009 at 10:46 AM and is filed under Programming. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

http://developer-in-test.blogspot.com/ Sai

True and an interesting definition. I wanted to comment but seeing the statement “By definition” stopped me in the middle
http://developer-in-test.blogspot.com Sai

True and an interesting definition. I wanted to comment but seeing the statement “By definition” stopped me in the middle
http://agilefaqs.com/nareshjain.html Naresh Jain

Sai, I’m not sure if I understand you correctly. What about “By definition” stopped you?
http://agilefaqs.com/nareshjain.html Naresh Jain

Sai, I’m not sure if I understand you correctly. What about “By definition” stopped you?
http://developer-in-test.blogspot.com/ Sai

I could have argued that functions (May be a badly written) even though returning a value can still alter some global state. But as you take something by definition, it means you are trying to give an ideal case and in that case presenting this argument is not valid.

Am I trying to make any sense?
http://developer-in-test.blogspot.com Sai

I could have argued that functions (May be a badly written) even though returning a value can still alter some global state. But as you take something by definition, it means you are trying to give an ideal case and in that case presenting this argument is not valid.

Am I trying to make any sense?
http://agilefaqs.com/nareshjain.html Naresh Jain

I’ve updated the blog to focus less on the return value and focus more on the side-effect free or Referential Transparency aspect of functions.
http://agilefaqs.com/nareshjain.html Naresh Jain

I’ve updated the blog to focus less on the return value and focus more on the side-effect free or Referential Transparency aspect of functions.
http://developer-in-test.blogspot.com/ Sai

Cool dude. Thats much better . Working with functional languages for sometime I have started think as a natural way of writing code. Using side effect free functions makes life much easier.
http://developer-in-test.blogspot.com Sai

Cool dude. Thats much better . Working with functional languages for sometime I have started think as a natural way of writing code. Using side effect free functions makes life much easier.
Kalpesh

functions (that return value) can rely on state (even in object oriented programming). The function you are talking about seems to be like functions that don’t use the outside state. And, if they have to use the state from outside, it will be passed to them (as in everything is a function). Can’t this be done in structured programming where you pass things around rather than directly using the state/data from within a function?
Kalpesh

functions (that return value) can rely on state (even in object oriented programming). The function you are talking about seems to be like functions that don’t use the outside state. And, if they have to use the state from outside, it will be passed to them (as in everything is a function). Can’t this be done in structured programming where you pass things around rather than directly using the state/data from within a function?
http://agilefaqs.com/nareshjain.html Naresh Jain

Kalpesh, certainly it can be done. The concept of Functions and Procedures exist from the good old days of Pascal. However in Functional Programming, it is lot more easier because that’s the convention/style. Both in OO and Structured Programming, Functions are not the default way to do things.
http://agilefaqs.com/nareshjain.html Naresh Jain

Kalpesh, certainly it can be done. The concept of Functions and Procedures exist from the good old days of Pascal. However in Functional Programming, it is lot more easier because that’s the convention/style. Both in OO and Structured Programming, Functions are not the default way to do things.
http://www.toolsforagile.com/ Siddharta

Well I agree with the above, but the thing that many people miss out is that there is this big bad thing called the environment which can have an effect.

Lets say that I have a function to read a file, it has no dependence on state within my program, but it still depends on the environment. Between two calls, someone else might have changed the file and the returned value will be different.

Unless you are writing simple programs, you always have to deal with environmental state and that can get quite complex in a functional language.
http://www.toolsforagile.com Siddharta

Well I agree with the above, but the thing that many people miss out is that there is this big bad thing called the environment which can have an effect.

Lets say that I have a function to read a file, it has no dependence on state within my program, but it still depends on the environment. Between two calls, someone else might have changed the file and the returned value will be different.

Unless you are writing simple programs, you always have to deal with environmental state and that can get quite complex in a functional language.