help undertsanding functional programing

[happycow2]

Hi, I first want to start off by saying that I’m not a programmer but rather a 3-D animation/ special effects student, however there are allot of concepts that i come across that are some what program related. I have no desire to actually learn programming, but i usually like to get an understanding of how certain programming types work. Right now I’m sort of reading about functional programming, and i want to see if my understanding is correct.

- A functional language is based of lambda, which basically represents everything as functions.

-Lambda calculus is like a "fundamental" math, where we can build a mathematical system from, equal to what a turning machine does, but more math related

- In a functional language everything is a function, including data, like numbers

-we can think of a function as a black box of data, data enters the black box, the black box performs an operation, then spit out a result to other black boxes.

- A programmer can "connect" these functions (or black boxes) together to form another function, which the can be stored in a library and use as any other function

-a pure functional language doesn’t use state

-a state has to do with change, i guess with variables in other languages. for example, if "car = wheel +frame", and later on "car = horse + carriage" that is a state change? while with a functional language, a "car" function will always be "wheel + frame"

-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?

-there are to ways to evaluate functional code, strict, which i guess looks at every function gieven, and lazy, which updates only those functions that need to be updated. Fo instance, if there are ten functions connected together and the 7 function is given a new value that has nothing to do with the other 6 functions, only the 3 function that its output is connected to will update.

[Valmont]

Right now I’m sort of reading about functional programming, <...>

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.
Furthermore, in most cases you are right. Only a few additions/changes follow:

-a pure functional language doesn’t use state

Absolutely true. It doesn't have "properties" (earlier called "attributes") either!

a state has to do with change, i guess with variables in other languages. for example, if "car = wheel +frame", and later on "car = horse + carriage" that is a state change?

No. The definition of a car has changed! So your example has to do with definition of the "car", not state

Here is an example of a state-change:
First: car_age_in_months = 100
Second: car_age_in_month = 500
As you can see, this car ALWAYS has an age and the age can vary. In case of "age" it can only grow. But take the income of a person: it can grow or schrink.
Here's another example:
First: car_has_antigravity_suspenders = TRUE
Second: car_has_antigravity_suspenders = FALSE
So this futuristic car may or may not have antigravity-technology built in, but the phenomena of "anti-gravity-suspendors" ALWAYS is an issue and can change in TRUE or FALSE (after an upgrade for example).

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?

This a way to do it, but by no means a must.
In object oriented languages (and object based languages like Visual Basic 6, or VBA) a state is usually protected (we call it "hidden"). To see the state the programmer needs to write a function (=method) to view the state as read-only. Call this system a "black-box system" if you will.

here are to ways to evaluate functional code, strict, which i guess looks at every function gieven, and lazy, which updates only those functions that need to be updated. Fo instance, if there are ten functions connected together and the 7 function is given a new value that has nothing to do with the other 6 functions, only the 3 function that its output is connected to will update.

Yes, an important aspect in programming effciently these days for very large projects.

[teknomage1]

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.

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).

[Valmont]

* 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.

How does this make my statement not fair? All I wrote was the old-fashioned name and that pure functional programming didn't meet industry-strength requirements. Exactly that's why "C" was developed, and later C++, C#, modern Java, Visual Basic etc.

[teknomage1]

Right, but to look at functional programming as being a synonym for structured programming and rather than a branch that grew out of structured programming is I think the unfair part. You highlighted the post-structured programming object oriented languages, but have ignored the developments in functional programming that happycow2 is asking about. Post-C languages such as ML, Haskell, Scala, and Erlang.

[Valmont]

These are all highly specialized programming languages that grew out of structured programming languages - partially that is. Take Lisp and Mathematica as I used to program with it and know their strenghts and weaknesses very well. Lisp is certainly not a post C language!

Scala, Haskell and Erlang, I never worked with it but I dare to bet they are the same: specialized languages.

[teknomage1]

They are just as "specialized" as C .

[teknomage1]

I think Wikipedia actually does a much better job at explaining this than I have

• Functional programming - Wikipedia, the free encyclopedia
• List of functional programming topics - Wikipedia, the free encyclopedia

[Valmont]

Thanks for your directions to wiki, but I don't need it as I was in the middle of most of these languages and their transitions.

They are just as "specialized" as C .

I'm affraid such is not the case. C is a direct result of the shortcomings of procedural languages and is ment to be a multipurpose (multiparadigm) language. As opposed to Lisp, Forth, Cobol. These three languages have all their special skills, but are weak for general programming and very weak when it comes to industry strength design.

I appreciate your input, teknomage. It's always good to go back to the basics. But like I mentioned, no matter what WiKi has to say, or anyone else for that matter, I have worked with these languages intensively and know their strength and weaknesses by heart.

[redhead]

I can't help it, whenever I hear someone mention C, I have to pay attention.
In this matter I have to support Valmont.

[teknomage1]

Out Voted - I slink back to lamba the ultimate in defeat...

[teknomage1]

Though I admit defeat in this discussion at least in terms of this audience, I can't resist posting a really interesting video from google video discussing faith based decisions about programming languages and the foundations of functional programming. Philip Wadler's tech talk