Let's see. A functional programming language is one in which you define what you want the computer to do, rather than how to do it.
The only data they work on is functions - for example "X := x.x" isn't just an instruction saying 'double x whenever this is called' - it is an actual chunk of data. So if you call that functional A, then A(A) has a meaning. That meaning is the same as X := x.x.x.x This only applies if the operator (. here) is polymorphic.
So I'm just imagining the integers, strings and lists found in Lisp and ML, right?
Yup - it's nicest to think of them as handy notation for library functions. --Vitenka
The various languages all provide different ways of specifying functions. LISP calls them closures, ML calls then functionals. Given the mathematical style of the language, a common but non-essential feature of these languages is pattern matching (where a bunch of different input are specified and the closest matching one is used to decide which sub-function to apply) and polymorphism (where a function can operate on any type equally.)
It should also be noted that you don't ever 'run' a functional program, as such - you compile it to find the answer.
Equivalently, there is no time, no stepping (and, in the purest versions, no possibility of IO) Everything executes simultaneously, in effect. To those used to ProceduralProgramming?, this may take some time to bend their minds around.
Some further strangenesses are introduced when you realise that it is possible to write logic which is paradoxical. Such programs cannot ever complete their compilation. Avoid those ;) You can get infinite loops. Big deal. Any language in which you can't isn't TuringComplete.
Because, really, any non-infinite problem is Trivial, infinite problems can be specified. It is usual to use some form of lazy evaluation (where, although big chunks of the program are infinite, they are not expanded because they do not affect the answer) and thus shortcut the problem. And you thought the difference between & and && was hard to understand.
In closing - functional languages represent computer science's form of poetry. Unutterably pretty, hard to write, full of deep meaning - and completely impractical for most everything. --Vitenka
(PeterTaylor) You would be surprised. I was investigating a file synchronisation tool called Unison?, and they didn't have an OSX binary, so I had to build it myself. At that point I discovered it was written in OCAML?.
...and my editor and window manager are both written in Lisp.
Yes, I'll amend that. They have, in general, one very powerful use (obviously, being TuringComplete, they CAN do anything). When the problem field is large and it is non-obvious how to go about finding a solution. Whereas normal programming is "Do these steps and hope that they lead to the solution" functional programming is much better at describing a situation and then letting the user (or programmer) choose ways to alter it until they arrive at the solution. While I'm at it, I'll describe the third main type of programming - database search - epitomised by Prolog? - which can be described as "Here are all possible answers, and here are my criteria. Find what matches." Functional programmers would say that the real interesting bit is in how such a system is implemented - since just simple searching bogs down kinda quickly. Database programmers would say "It just works dammit" and get on with finding answers :) --Vitenka (I just.. I dunno. Given a particular task, unless it was blatantly a logic theorem prover, I have no idea what would cause me to choose ML over a c-style language. Though some jobs, yes, I'd choose a database searcher.)
![[Home]](/img/text_logo.jpg){kind=logo}
FunctionalProgrammingLanguage