This excerpt tries to characterize the continuum
between an imperative and a functional programming approach,
in the context of object based languages.
it is important not to confuse this axis with
the difference between procedural and declarative.
The characteristic of a function in a narrow sense is that it can
only have an output value, in this sense it is not permitted
to change anything in the system:
//function with side effect: var a; func = { a = 69 + 5 }; func.value; //function without side effect: var a; func = { 69 + 5 }; a = func.value;
In an Object oriented system there is a compromise as an Object may change
its own data but often not directly other object's data. Instead, a message is
passed to that Object. Of course side effects are possible and frequently used.
Examples of functional approaches in sc is the pattern system and the ugen network.
imperative approach: data is modified by functions (like C) | |
object oriented imperative approach: there is a mixture between language constructs that are fuctions themselves and data.(like Java) | |
object oriented imperative approach 2: the data gets further wrapped and escapes the direct access by encapsulation | |
purely object oriented approach: no data is accessible. There is only functions in functions. (ok, ok. objects in objects...) 'Everything is an Object' (like SuperCollider/Squeak) |
Object orientation is often characterized as opposed to the so called 'Spaghetti Code', that makes the control move all around the code. Usually it is connected with the use of the GOTO command, for example in BASIC. This command makes any line of code accessible at any time, so one has to read fore and back over the text to understand what is going on. Nevertheless this seems very much true also for object based languages, as it is often hard to understand where something happens. Also here the control flow moves all over the place and the more fractioned the language is the more places control can move to. Of course there are other major differences, but 'Spaghetti Code' seems to be a universal language property somehow.
"The special characteristics and advantages of functional programming are
often summed up more or less as follows. Functional programs contain no
assignment statements, so variables, once given a value, never change. More
generally, functional programs contain no side-effects at all. A function call can
have no effect other than to compute its result. This eliminates a major source
of bugs, and also makes the order of execution irrelevant - since no side-effect
can change the value of an expression, it can be evaluated at any time. This
relieves the programmer of the burden of prescribing the flow of control. Since
expressions can be evaluated at any time, one can freely replace variables by
their values and vice versa - that is, programs are “referentially transparent”.
This freedom helps make functional programs more tractable mathematically
than their conventional counterparts." (Why Functional Programming Matters
John Hughes, Institutionen f¨ or Datavetenskap)
Links:
from A-Z:information about:
- Why Functional Programming Matters : http://www.cs.chalmers.se/~rjmh/Papers/whyfp.html
- Formal Methods
- Functional Programming Languages in Education
- guide to functional programming (Philip Wadler, '96)
- The Drops Juggling Animator
- Philip Wadler's Homepage
also see:
- http://bruce.edmonds.name/logreas/logreas_7.html
- http://cs.wwc.edu/~aabyan/221_2/PLBOOK/ ( a very good survey on different language designs)
- what is a Stream?
- evaluation dynamics of functions
.