The state of functional programming

[J.s]

As I am continuing my freshman year of college majoring in cs it seems
I stand alone with the view of abuse or at least over-use of OOP
concepts and the knowledge of functional programming in general. Of
the many people I have met who are currently or have recently
graduated with a cs degree, very few have ever learned any functional
programming or anything other than c# and java.

What recently got my attention though was an article I found on f#
from one of Microsoft developer's blogs [http://blogs.msdn.com/b/
dsyme/archive/2010/04/12/f-2-0-released-as-part-of-visual-
studio-2010.aspx]. In it Don Syme (a developer of f#) explains what
both f# is to other programmers, but the part that disturbed me was
where Syme implies functional programmers are not "focus(ed) on ...
the process of writing code":

"Q: What is functional programming?

Functional programming languages express ideas at a higher level and
allow users to focus on the challenge of problem solving instead of
the process of writing code. A programming language like F# provides a
‘tool bag’ of functions that users can pick from to solve their
problem. Functional programming includes concepts such as
immutability to reduce dependencies between components, generics to
express solutions that work over many different kinds of data, and
functions as values to make it easy to abstract units of a solution
into reusable pieces."



Does anyone have any thoughts on this?

[Georg Bauhaus]

Post by J.s
Functional programming languages express ideas at a higher level and
allow users to focus on the challenge of problem solving instead of
the process of writing code. A programming language like F# provides a
‘tool bag’ of functions that users can pick from to solve their
problem. Functional programming includes concepts such as
immutability to reduce dependencies between components, generics to
express solutions that work over many different kinds of data, and
functions as values to make it easy to abstract units of a solution
into reusable pieces."
Does anyone have any thoughts on this?

Yes, and Grady Booch has said a few things against functional
programming (hype) very recently no less substantiated than the above
collection of claims.

I haven't met anyone who thinks that knowing functional programming style,
in particular familiarity with the consequences of no mutable values
isn't a valuable experience. As is the experience of so called fusions,
and of mutable variables in functional programming languages (really
functional any longer?): the inevitable consequence of trying to
make a functional program meet the requirements of predictable
SPACE and TIME complexity.

To distinguish the above quote about F# from language marketing,
consider the questions:

"What is an idea at a higher level?"
(explaining "idea" and "height")

"When one assembles functions a la Hughes (point free style),
how is the thinking process different from that performed
by the OO-programmer assembling classes and their protocols?"

"Regarding OO vs functional, is one good without the other?"
(which one?)


Georg

[Kulin Remailer]

The main thing is to never respond to google groups posts. I didn't see his
troll until you guys quoted it ;-)

[deadlyhead]

This post might be inappropriate. Click to display it.

[Jeffrey R. Carter]

Post by J.s
Does anyone have any thoughts on this?

I think some relationship to Ada should be established when posting here.

[J.s]

On Jul 28, 12:31 pm, "Jeffrey R. Carter"

Post by Jeffrey R. Carter

Post by J.s
Does anyone have any thoughts on this?

I think some relationship to Ada should be established when posting here.
--
Jeff Carter
"The time has come to act, and act fast. I'm leaving."
Blazing Saddles
36

Sorry, I wanted to get opinions from other ada programmers about the
usage of functional programming versus oop as well as the development
of other imperative languages. I see now my post was not appropriate
and certainly didn't mean to "troll".

[Dmitry A. Kazakov]

Post by J.s
As I am continuing my freshman year of college majoring in cs it seems
I stand alone with the view of abuse or at least over-use of OOP
concepts and the knowledge of functional programming in general.

OOP is over-used? And knowledge of FP is what?

Post by J.s
Of the many people I have met who are currently or have recently
graduated with a cs degree, very few have ever learned any functional
programming or anything other than c# and java.

Maybe

Post by J.s
What recently got my attention though was an article I found on f#
from one of Microsoft developer's blogs [http://blogs.msdn.com/b/
dsyme/archive/2010/04/12/f-2-0-released-as-part-of-visual-
studio-2010.aspx]. In it Don Syme (a developer of f#) explains what
both f# is to other programmers, but the part that disturbed me was
where Syme implies functional programmers are not "focus(ed) on ...
"Q: What is functional programming?
Functional programming languages express ideas at a higher level and
allow users to focus on the challenge of problem solving instead of
the process of writing code.

This claim was made for each and every programming paradigm. It need to be
substantiated, and especially for FP, which does not look very promising at
all.

Post by J.s
A programming language like F# provides a
‘tool bag’ of functions that users can pick from to solve their
problem.

I.e. the decomposition is procedural, welcome back in 60's...

Post by J.s
Functional programming includes concepts such as
immutability to reduce dependencies between components,

How is immutability to reduce dependence? An immutable argument must be
taken from somewhere. And immutable results does not even exist. He
probably meant side effects. It is to be shown that procedural
decomposition to reduce need in side effects. I doubt it does. And the
whole computing is about side effects. Programming is how side effects can
be engineered.

Post by J.s
generics to
express solutions that work over many different kinds of data,

Different kinds of data? He probably meant types. Ah, but types smell OOP,
right? I hope it is not about passing integer where real expected?

GP is about dealing with sets of types. To substantiate the claim it is to
show how types and their sets can be described and manipulated within FP,
easier, quicker, safer, more maintainable etc.

Post by J.s
and
functions as values to make it easy to abstract units of a solution
into reusable pieces.

Function as a value of what? And what is the difference? Maybe a side
effect of the call? Anyway I don't see how values can be reusable.

Post by J.s
Does anyone have any thoughts on this?

FP is yet another attempt to make programming declarative. That won't
happen until last programmer dies.

[(see below)]

This post might be inappropriate. Click to display it.

[Dmitry A. Kazakov]

Post by (see below)
I was at a short talk given by one of the leading FP propagandists.
He drew an S-curve depicting technological penetration against time, and
admitted that FP was still at the bottom left, far from lift-off. After 50
years! (McCarthy's "Recursive functions of symbolic expressions and their
computation by machine, Part I" was published in 1960. We still seem to be
waiting for Part II: "real-world relevance".)

It is an interesting topic actually. There is a never ending struggle for
another computational platform. Any declarative framework is in the end an
attempt to replace our machines with something else. So were RDBMS, the 5GL
project (prolog etc, if anybody still remember that), modeling languages
like UML, and ones like Simulink. FP is very much alike. So far all these
attempts failed. I mean technically, RDMS and modeling tools are
commercially quite successful [*]. It is interesting to see what happens
when the platform indeed changes. The candidates might be quantum,
molecular machines, massively parallel systems.

-------------------
* To the OP, if you want to make FP successful, here is a simple recipe.
Make a tool chain. Name it functional-whatever. Advertise it for C and
Java. Managers like tools. They honestly believe that tools produce
software. I mean literally, you buy the tool X and the project Y is
advanced two weeks ahead. The more expensive the tool is greater is the
advance. Who would buy it otherwise? If you buy many most expensive ones,
you would need no these lazy overpaid guys, the programmers...

[Randy Brukardt]

On 28/07/2010 17:40, in article

...

Post by Dmitry A. Kazakov
This claim was made for each and every programming paradigm. It need to be
substantiated, and especially for FP, which does not look very promising at
all.

Indeed, it has been "promising", but not delivering, for a very long time.

No kidding. FP was an "old" technique when I studied it as an undergraduate
at the University of Wisconsin. In 1978.

I think it appeals to those that are very mathematically inclined. But they
tend to forget that there is a lot more to programming than just creating
functions and stringing them together. (Not to say that there isn't value to
some of the ideas, but only in a larger framework that deals with typing,
problem mapping, and the like.)

Randy.

[(see below)]

Post by Randy Brukardt

On 28/07/2010 17:40, in article

...

Post by Dmitry A. Kazakov
This claim was made for each and every programming paradigm. It need to be
substantiated, and especially for FP, which does not look very promising at
all.

Indeed, it has been "promising", but not delivering, for a very long time.

No kidding. FP was an "old" technique when I studied it as an undergraduate
at the University of Wisconsin. In 1978.
I think it appeals to those that are very mathematically inclined. But they
tend to forget that there is a lot more to programming than just creating
functions and stringing them together.

The fetishization of "concision" in FP, as though that had great intrinsic
value, rather that being (as it actually is) a barrier to comprehension, is
undoubtedly part of that: mathematics envy writ small.

Post by Randy Brukardt
(Not to say that there isn't value to
some of the ideas, but only in a larger framework that deals with typing,
problem mapping, and the like.)

Exactly so.

[Warren]

..

Post by Dmitry A. Kazakov

Post by J.s
and
functions as values to make it easy to abstract units of a solution
into reusable pieces.

Function as a value of what? And what is the difference? Maybe a side
effect of the call? Anyway I don't see how values can be reusable.

Post by J.s
Does anyone have any thoughts on this?

I think FP and procedural languages are like opposite ends
of a fourier tranform. In one system, one set of languages
are very effective at solutions in that domain, while the \
other set of languages (FP) struggles.

Do the transform into the other system, and then the other
(FP) languages provide simple answers to some problems,
while the traditional ones struggle.

Each collection of languages best solve problems in their
domain of applicability.

For my money, FP still is less generally effective because
it relies on special tricks/algorithms to narrow down the
huge number of paths for a solution. If the tricks/algorithms
do apply, then it works. For all other situations it is either
wrong or impractical (takes too long etc.)

Warren

[Dmitry A. Kazakov]

Post by Warren
Each collection of languages best solve problems in their
domain of applicability.

That reminds me someone's saying about 5GL in early 90's: "if 5GL is an
answer what was the question?"

What are the domains of poor languages? Since they must exist, but cannot
be observed, then in some outer dimension. Which is another proof that the
Universe must be multidimensional... (:-))

Post by Warren
For my money, FP still is less generally effective because
it relies on special tricks/algorithms to narrow down the
huge number of paths for a solution.

This universally applies to all declarative languages.

Post by Warren
If the tricks/algorithms
do apply, then it works. For all other situations it is either
wrong or impractical (takes too long etc.)

The problem is that any real system never belongs to a narrow domain. The
domain specific schism leads to the components in different paradigms
unable to talk to each other. Any gain one might get through applying
domain specific solutions is quickly spent on developing tons of software
needed to hold the mess together.

[Warren]

Post by Dmitry A. Kazakov

Post by Warren
Each collection of languages best solve problems in their
domain of applicability.

That reminds me someone's saying about 5GL in early 90's: "if 5GL is
an answer what was the question?"
What are the domains of poor languages? Since they must exist,

Perl ;-)

Post by Dmitry A. Kazakov

Post by Warren
For my money, FP still is less generally effective because
it relies on special tricks/algorithms to narrow down the
huge number of paths for a solution.

This universally applies to all declarative languages.

I think you missed my point - perhaps it wasn't expressed
clearly.

As I understand it, a FP tries to determine conclusions
from a universe of facts, given some inputs. For smaller
problems this can be _exhaustively_ analyzed and results
obtained.

However for more "practical" sized problems (we could argue
what "practical" sized problems are), the number of "things"
that must be analyzed becomes huge - taking 'forever' to
solve. To counter this, existing FP technologies use
special tricks for reducing the number of "things" to be
considered.

The problem with this approach is that some problems
then won't lead to a solution because some of the paths
that may have lead to a solution were eliminated. Another
side effect of this is that it may lead to suboptimal
conclusions (the better possibilities were eliminated).

The "problem set size" issue, as I understand it, is still
the main area of intense research in FP. But as it sits
presently, the issue is still essentially unsolved.

Some big improvements (special algorithms) have been
developed over the years to make FP more practical,
but in essence that same basic problem still exists.

Warren

[Dmitry A. Kazakov]

Post by Warren

Post by Dmitry A. Kazakov

Post by Warren
Each collection of languages best solve problems in their
domain of applicability.

That reminds me someone's saying about 5GL in early 90's: "if 5GL is
an answer what was the question?"
What are the domains of poor languages? Since they must exist,

Perl ;-)

Post by Dmitry A. Kazakov

Post by Warren
For my money, FP still is less generally effective because
it relies on special tricks/algorithms to narrow down the
huge number of paths for a solution.

This universally applies to all declarative languages.

I think you missed my point - perhaps it wasn't expressed
clearly.
As I understand it, a FP tries to determine conclusions
from a universe of facts, given some inputs. For smaller
problems this can be _exhaustively_ analyzed and results
obtained.

And so does any declarative language. You declare some facts in whatever
form (as relations, as connections of blocks etc, for that matter, as types
in a strongly typed languages like Ada). The system infers from them some
executable code.

Post by Warren
However for more "practical" sized problems (we could argue
what "practical" sized problems are), the number of "things"
that must be analyzed becomes huge - taking 'forever' to
solve. To counter this, existing FP technologies use
special tricks for reducing the number of "things" to be
considered.

Same with all others.

Post by Warren
The problem with this approach is that some problems
then won't lead to a solution because some of the paths
that may have lead to a solution were eliminated. Another
side effect of this is that it may lead to suboptimal
conclusions (the better possibilities were eliminated).

Furthermore some declarative frameworks are weaker than TM. I.e. whatever
corpus of facts you take you would be unable to infer what you can using an
imperative language.

Post by Warren
The "problem set size" issue, as I understand it, is still
the main area of intense research in FP. But as it sits
presently, the issue is still essentially unsolved.
Some big improvements (special algorithms) have been
developed over the years to make FP more practical,
but in essence that same basic problem still exists.

I think that the main problem of all domain-specific languages is that, in
contrast to the acclaim, they aren't built around a domain. They are about
a class of some well studied methods. This class is them promoted as the
"domain."

[Warren]

..

Post by Dmitry A. Kazakov

Post by Warren
I think you missed my point - perhaps it wasn't expressed
clearly.
As I understand it, a FP tries to determine conclusions
from a universe of facts, given some inputs. For smaller
problems this can be _exhaustively_ analyzed and results
obtained.

And so does any declarative language. You declare some facts in
whatever form (as relations, as connections of blocks etc, for that
matter, as types in a strongly typed languages like Ada). The system
infers from them some executable code.

No, there is a big difference here.

In a non-FP language (Ada), you can solve _any_ problem so long
as you code it (you are coding the "how"). IOW, you have
solved the problem and specified it in code.

In FP, you define the "problem" (instead) and require from
it a solution. But FP cannot always solve that "problem".

A huge difference, that.

Warren

[Dmitry A. Kazakov]

Post by Warren
..

Post by Dmitry A. Kazakov

Post by Warren
I think you missed my point - perhaps it wasn't expressed
clearly.
As I understand it, a FP tries to determine conclusions
from a universe of facts, given some inputs. For smaller
problems this can be _exhaustively_ analyzed and results
obtained.

And so does any declarative language. You declare some facts in
whatever form (as relations, as connections of blocks etc, for that
matter, as types in a strongly typed languages like Ada). The system
infers from them some executable code.

No, there is a big difference here.
In a non-FP language (Ada), you can solve _any_ problem so long
as you code it (you are coding the "how").

Not quite. "How" need to be translated into the Ada code first. In some
cases it is not simple or even impossible.

Post by Warren
IOW, you have solved the problem and specified it in code.

No difference here. Any code is a language (Ada language, machine language,
the language of differential equations and so on). The FP code is as code
as Ada code is. The actual problem is that Ada code can be in most cases
effectively translated into machine code (and later into electrical
signals), while for FP code it is much more difficult. There are also other
problems related to maintainability. To be readable and maintainable the
code must be easily translated back into "how". I.e. the programmer must
understand what the code does. Arguably, FP code is farther removed from
programmer's "how" than Ada code.

Post by Warren
In FP, you define the "problem" (instead) and require from
it a solution.

Rather you declare a solution. This is how declarative paradigm works.

(Don't forget that Ada has a declarative parts as well. You declare types
for example, and ask the compiler to solve "range 0..100".)

Post by Warren
But FP cannot always solve that "problem".

Same in Ada. Not every legal Ada program is compilable. I doubt that there
is a higher language where any legal program is compilable. The difference
is in relation, not in principle. Non-compilable Ada programs are less
interesting and numerous than their FP counterparts.

But my point was that this is characteristic for *all* declarative
languages. I think that no language can be 100% declarative. You can have
some well defined parts declarative, as in Ada, but making everything
declarative is like flying faster than light, or going beyond Turing
completeness, name it. Even if that were possible, we wound not be able to
understand what these programs do.

[Warren]

Post by Dmitry A. Kazakov

Post by Warren
..

Post by Dmitry A. Kazakov

Post by Warren
I think you missed my point - perhaps it wasn't expressed
clearly.
As I understand it, a FP tries to determine conclusions
from a universe of facts, given some inputs. For smaller
problems this can be _exhaustively_ analyzed and results
obtained.

And so does any declarative language. You declare some facts in
whatever form (as relations, as connections of blocks etc, for that
matter, as types in a strongly typed languages like Ada). The system
infers from them some executable code.

No, there is a big difference here.
In a non-FP language (Ada), you can solve _any_ problem so long
as you code it (you are coding the "how").

Not quite. "How" need to be translated into the Ada code first. In
some cases it is not simple or even impossible.

It doesn't matter. You've expressed the solution "in Ada".
"You" solved the problem to begin with (i.e. "the how").

Post by Dmitry A. Kazakov

Post by Warren
IOW, you have solved the problem and specified it in code.

No difference here. Any code is a language (Ada language, machine
language, the language of differential equations and so on). The FP
code is as code as Ada code is.

Code in the sense that it is the "specification". One
language specifies the "how", and the other specifies the
"problem". Surely you see that.

Post by Dmitry A. Kazakov

Post by Warren
In FP, you define the "problem" (instead) and require from
it a solution.

Rather you declare a solution. This is how declarative paradigm works.

Again, in Ada you "declare" the "how". In FP, you "declare"
the "problem" to be solved. In FP, you don't about the
how, beyond how long will it take.

Post by Dmitry A. Kazakov
(Don't forget that Ada has a declarative parts as well. You declare
types for example, and ask the compiler to solve "range 0..100".)

This is a pre-solved problem- that you re-apply in a
larger solution. The solution has been worked out by
the compiler/library writers. This is not "finding a
solution" in the present tense.

Post by Dmitry A. Kazakov

Post by Warren
But FP cannot always solve that "problem".

Same in Ada. Not every legal Ada program is compilable.

If an Ada program doesn't compile, then the programmer
hasn't spelled out the "how" correctly has he?

A well formed FP OTOH, can yield a suboptimal or missing
result. This is due to no fault in the input "program",
but in the way FP was implemented.

Anyway, I'm done here. I'm starting to feel like
a parrot.

Warren

[Georg Bauhaus]

Post by Warren
Again, in Ada you "declare" the "how". In FP, you "declare"
the "problem" to be solved.
Anyway, I'm done here. I'm starting to feel like
a parrot.

I guess, then, you will ignore my chatter through the cage's wires. ;)

Is there anything non-FP in

let input = float_of_string Sys.argv.(1) in
let output = print_float in
let square x = x *. x in
output (square input) ;;


I really don't know how it is possible to "declare" the "problem" in FP
without thinking about "how" some functions establish the "what" of the
solution. Even in Prolog.
To me FP always boils down to assembling a solution from "more primitive"
functions. These are ultimately composed of initial functions.

The process of arranging functions properly will establish the "how" part
of FP. I *have* to write the proper equations, choosing the correct
functions; I *have* to write expressions involving the correct
functions. These are not pre-solved. I do *not* in general instruct
an Ada compiler how to chose a sequence of processor instructions
for my Ada program.

The only difference I see is that in true FP there is no explicit
state manipulation. Has there been a true FPL other than inference
engines before the point when Haskell introduced monads?


Georg

[Dmitry A. Kazakov]

Post by Warren

Post by Dmitry A. Kazakov

Post by Warren
But FP cannot always solve that "problem".

Same in Ada. Not every legal Ada program is compilable.

If an Ada program doesn't compile, then the programmer
hasn't spelled out the "how" correctly has he?

X : constant := 2**(2**(2**(2**9999_9999))) + 1:

is pretty much clear "how", legal, but not compilable.

[Niklas Holsti]

Post by Dmitry A. Kazakov

Post by Warren

Post by Dmitry A. Kazakov

Post by Warren
But FP cannot always solve that "problem".

Same in Ada. Not every legal Ada program is compilable.

If an Ada program doesn't compile, then the programmer
hasn't spelled out the "how" correctly has he?

is pretty much clear "how", legal, but not compilable.

... because the binary representation of the value of X needs too many
bits, you mean? But I don't think that a compiler is required to
represent the value in binary form *at compile time*; it could use a
formulaic representation, which needs only a small amount of memory, as
shown by your source line. Depending on how X is used in the rest of the
program, this could make it possible to compile the program.

Of course I agree that a normal Ada compiler will not be able to compile
such things.

[Dmitry A. Kazakov]

Post by Niklas Holsti

Post by Dmitry A. Kazakov

Post by Warren

Post by Dmitry A. Kazakov

Post by Warren
But FP cannot always solve that "problem".

Same in Ada. Not every legal Ada program is compilable.

If an Ada program doesn't compile, then the programmer
hasn't spelled out the "how" correctly has he?

is pretty much clear "how", legal, but not compilable.

... because the binary representation of the value of X needs too many
bits, you mean? But I don't think that a compiler is required to
represent the value in binary form *at compile time*; it could use a
formulaic representation, which needs only a small amount of memory, as
shown by your source line. Depending on how X is used in the rest of the
program, this could make it possible to compile the program.

Yes, but you cannot find a representation which would work for any legal
expression. I.e. whatever representation the compiler uses, it is always
possible to write a legal program that would break it. E.g:

X : constant := 2**(3**(2**(3**9999_9999))) + 1:
Y : constant := 3**(2**(5**(2**8999_9979))) - 1:
C : constant Boolean := X > Y;

Post by Niklas Holsti
Of course I agree that a normal Ada compiler will not be able to compile
such things.

The above expression is supposed to break representations used by "normal
compilers".

[Niklas Holsti]

Post by Warren
..

Post by Dmitry A. Kazakov

Post by Warren
I think you missed my point - perhaps it wasn't expressed
clearly.
As I understand it, a FP tries to determine conclusions
from a universe of facts, given some inputs. For smaller
problems this can be _exhaustively_ analyzed and results
obtained.

And so does any declarative language. You declare some facts in
whatever form (as relations, as connections of blocks etc, for that
matter, as types in a strongly typed languages like Ada). The system
infers from them some executable code.

No, there is a big difference here.
In a non-FP language (Ada), you can solve _any_ problem so long
as you code it (you are coding the "how"). IOW, you have
solved the problem and specified it in code.
In FP, you define the "problem" (instead) and require from
it a solution. But FP cannot always solve that "problem".

Warren, I think your description or understanding of FP matches "logic
programming" or "constraint programming" rather than "functional
programming".

FP programs do specify "how" to compute a solution, although the FP
compiler or interpreter may have to transform the "how" in smart ways to
make it computable on resource-limited machines -- for example, by
converting tail recursion to iteration, or by using lazy evaluation to
avoid infinitely large intermediate results. Proving termination of
functional programs is similar to proving termination of recursive
imperative programs.

It is in logic programming and constraint programming that the
programmer enters facts, rules, and a goal, and the program searches for
solutions (proofs or realisations of the goal) in some way that is not
explicitly encoded in the program.

[Warren]

Post by Niklas Holsti

Post by Warren
In a non-FP language (Ada), you can solve _any_ problem so long
as you code it (you are coding the "how"). IOW, you have
solved the problem and specified it in code.
In FP, you define the "problem" (instead) and require from
it a solution. But FP cannot always solve that "problem".

Warren, I think your description or understanding of FP matches "logic
programming" or "constraint programming" rather than "functional
programming".

Now that you mention the words "logic programming", I feel
a twinge in the back of my mind..

Post by Niklas Holsti
It is in logic programming and constraint programming that the
programmer enters facts, rules, and a goal, and the program searches for
solutions (proofs or realisations of the goal) in some way that is not
explicitly encoded in the program.

I did start off with "if I understand correctly" - obviously
I mixed these up! This is _exactly_ what I was discussing.

The problem with age is the ever increasing number of memory
parity errors that go uncorrected. ;-)

Apologies to the thread for the confusion.

Warren