Quote:
Originally Posted by Valmont
Beware, "functional programming" is modern slang for the original "procedural programming". Sometimes also called "structured programming". Compared to these days the term "structured" is overdone, but 25 years ago it was the best thing, though it was soon clear that this alone doesn't suffice for industry-strength programming.
|
I don't think that's entirely fair, Valmont. Functional programming has probably three key aspects:
- As happycow2 states, mutable state is not allowed by the language (in a purely functional setting). This is enforced by single assignement variables. A value can never be updated once declared.
- Functions are available as first class values. This means that anonymous functions can be declared and a function's value can be passed the same way as any other value type.
- In return for giving up mutable state a program is easier to make provably correct.
I think the emphasis on doing away with state and a focus on higher order functions sets the functional style apart from 70's structured programming. I think there are some other things being conflated in this post due to the nature of the current crop of functional languages. Lazy versus strict evaluation can apply in any langage functional or not though lazy evaluation is most conspicuous in the functional programming language Haskell.
Quote:
|
Originally Posted by happycow2
-a pure language has to deal with state when it is getting info from hardware or some where eles. to keep this state from "inpurefying" the language, these states are kept in black boxes as well and return a value that will ultimately convert to a function when to is connected to other functions?
|
What you are describing is the concept of a monad which does two things. Firstly, for a lazy language it explicitly sequences operations so that a read for data happens after the user is prompted rather than the other way around. The second thing the monad does is to pass the data it acquires through side effects such as I/O to pure functions as arguments so that they retain the benefits of referential transparency (any specific input will produce a specific output across multiple calls).