Re: The state of functional programming

Re: The state of functional programming

[Georg Bauhaus]

On 28.07.10 17:24, J.s wrote:

> 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

Re: The state of functional programming

[Jeffrey R. Carter]

On 07/28/2010 08:24 AM, J.s wrote:
>
> 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

Re: The state of functional programming

[Dmitry A. Kazakov]

On Wed, 28 Jul 2010 08:24:08 -0700 (PDT), J.s wrote:

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

> 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

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

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.

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

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

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

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

> Does anyone have any thoughts on this?

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

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: The state of functional programming

[(see below)]

On 28/07/2010 17:40, in article g24nvegdi17t$.1azxwn1rwjixi$.dlg@40tude.net,
"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote:

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

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

>> 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. ... And the
> whole computing is about side effects. Programming is how side effects can
> be engineered.

Precisely. Except that it is about *effects*, just plain *effects*.
The "side" is propagandistic scare-language added by the FP fundamentalists.
(I originally spelled that "fundamnetalists" -- Freudian slip 8-).

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

8-)

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

-- 
Bill Findlay
<surname><forename> chez blueyonder.co.uk

Re: The state of functional programming

[Dmitry A. Kazakov]

On Wed, 28 Jul 2010 18:47:40 +0100, (see below) wrote:

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

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: The state of functional programming

[Warren]

Dmitry A. Kazakov expounded in
news:g24nvegdi17t$.1azxwn1rwjixi$.dlg@40tude.net: 
> On Wed, 28 Jul 2010 08:24:08 -0700 (PDT), J.s wrote:
..
>> 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.
> 
>> 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

Re: The state of functional programming

[Dmitry A. Kazakov]

On Wed, 28 Jul 2010 19:09:17 +0000 (UTC), Warren wrote:

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

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

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

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: The state of functional programming

[Kulin Remailer]

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

Re: The state of functional programming

[deadlyhead]

Wow.  I feel completely out of place here.

I regularly code in functional, imperative and use OOP strategies side-
by-side.

When I want to hack, I use Scheme (specifically Guile).  I naturally
gravitate to doing everything in a functional style in Scheme because
it's so _natural_, but when a situation calls for it, I load up GOOPS
and get some OOP going.  There's absolutely nothing wrong with using
the right tools for the job.  Heck, I'll even write some functions in
Ada that never assign a variable, but instead construct a return
statement from a series of sub-functions.

My total perspective is thus: both functional programming and
imperative/OOP as implemented by Ada are designed for safety,
expressiveness and cleanliness/maintainability. Ada accomplishes this
via type safety, clear syntax and a host of other design decisions
that I don't particularly feel like ticking off.  Functional languages
achieve much of the same safety, even with dynamic typing, by simply
doing away with assignment, and thus abusing conversion rules between
types.  Perhaps I look at it as with Ada we must be deliberate with
each of our actions, but with functional languages we must be
deliberate with our _intentions_.

Call me crazy, but building a solid system in Ada and embedding a
powerful Scheme for extension seems like the beautiful middle way to
me.

Re: The state of functional programming

[J.s]

On Jul 28, 12:31 pm, "Jeffrey R. Carter"
<spam.jrcarter....@spam.acm.org> wrote:
> On 07/28/2010 08:24 AM, J.s wrote:
>
>
>
> > 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".

Re: The state of functional programming

[Warren]

Dmitry A. Kazakov expounded in
news:1oubrlamjqe8q$.bdwkb9i7ys6b$.dlg@40tude.net: 

> On Wed, 28 Jul 2010 19:09:17 +0000 (UTC), Warren wrote:
> 
>> 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 ;-)

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

Re: The state of functional programming

[Dmitry A. Kazakov]

On Thu, 29 Jul 2010 15:20:48 +0000 (UTC), Warren wrote:

> Dmitry A. Kazakov expounded in
> news:1oubrlamjqe8q$.bdwkb9i7ys6b$.dlg@40tude.net: 
> 
>> On Wed, 28 Jul 2010 19:09:17 +0000 (UTC), Warren wrote:
>> 
>>> 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 ;-)
> 
>>> 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.

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

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

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: The state of functional programming

[Warren]

Dmitry A. Kazakov expounded in
news:a3iznu9uq49d$.1m9cupr81yhut$.dlg@40tude.net: 

> On Thu, 29 Jul 2010 15:20:48 +0000 (UTC), Warren wrote:
..
>> 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

Re: The state of functional programming

[Dmitry A. Kazakov]

On Thu, 29 Jul 2010 19:19:49 +0000 (UTC), Warren wrote:

> Dmitry A. Kazakov expounded in
> news:a3iznu9uq49d$.1m9cupr81yhut$.dlg@40tude.net: 
> 
>> On Thu, 29 Jul 2010 15:20:48 +0000 (UTC), Warren wrote:
> ..
>>> 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.

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

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

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

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: The state of functional programming

[Niklas Holsti]

Warren wrote:
> Dmitry A. Kazakov expounded in
> news:a3iznu9uq49d$.1m9cupr81yhut$.dlg@40tude.net: 
> 
>> On Thu, 29 Jul 2010 15:20:48 +0000 (UTC), Warren wrote:
> ..
>>> 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.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: The state of functional programming

[Warren]

Dmitry A. Kazakov expounded in
news:17hhchqy1a2si.1akul43vk1sd9.dlg@40tude.net: 

> On Thu, 29 Jul 2010 19:19:49 +0000 (UTC), Warren wrote:
>> Dmitry A. Kazakov expounded in
>> news:a3iznu9uq49d$.1m9cupr81yhut$.dlg@40tude.net: 
>>> On Thu, 29 Jul 2010 15:20:48 +0000 (UTC), Warren wrote:
>> ..
>>>> 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").

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

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

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

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

Re: The state of functional programming

[Georg Bauhaus]

On 7/29/10 11:01 PM, Warren wrote:

> 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

Re: The state of functional programming

[Dmitry A. Kazakov]

On Thu, 29 Jul 2010 21:01:35 +0000 (UTC), Warren wrote:

> Dmitry A. Kazakov expounded in
> news:17hhchqy1a2si.1akul43vk1sd9.dlg@40tude.net: 
> 
>> On Thu, 29 Jul 2010 19:19:49 +0000 (UTC), Warren wrote:

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

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: The state of functional programming

[Niklas Holsti]

Dmitry A. Kazakov wrote:
> On Thu, 29 Jul 2010 21:01:35 +0000 (UTC), Warren wrote:
> 
>> Dmitry A. Kazakov expounded in
>> news:17hhchqy1a2si.1akul43vk1sd9.dlg@40tude.net: 
>>
>>> On Thu, 29 Jul 2010 19:19:49 +0000 (UTC), Warren wrote:
> 
>>>> 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.

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

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: The state of functional programming

[Dmitry A. Kazakov]

On Fri, 30 Jul 2010 12:17:29 +0300, Niklas Holsti wrote:

> Dmitry A. Kazakov wrote:
>> On Thu, 29 Jul 2010 21:01:35 +0000 (UTC), Warren wrote:
>> 
>>> Dmitry A. Kazakov expounded in
>>> news:17hhchqy1a2si.1akul43vk1sd9.dlg@40tude.net: 
>>>
>>>> On Thu, 29 Jul 2010 19:19:49 +0000 (UTC), Warren wrote:
>> 
>>>>> 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.
> 
> ... 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;

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

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: The state of functional programming

[Warren]

Niklas Holsti expounded in news:8be7luFbvaU1@mid.individual.net:
> Warren wrote:
>> 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..

> 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

Re: The state of functional programming

[Randy Brukardt]

"(see below)" <yaldnif.w@blueyonder.co.uk> wrote in message 
news:C8762BCC.14B84F%yaldnif.w@blueyonder.co.uk...
> On 28/07/2010 17:40, in article 
> g24nvegdi17t$.1azxwn1rwjixi$.dlg@40tude.net,
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote:
...
>> 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.

Re: The state of functional programming

[(see below)]

On 03/08/2010 04:15, in article i381k9$dcf$1@munin.nbi.dk, "Randy Brukardt"
<randy@rrsoftware.com> wrote:

> "(see below)" <yaldnif.w@blueyonder.co.uk> wrote in message
> news:C8762BCC.14B84F%yaldnif.w@blueyonder.co.uk...
>> On 28/07/2010 17:40, in article
>> g24nvegdi17t$.1azxwn1rwjixi$.dlg@40tude.net,
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote:
> ...
> 
>>> 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.

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

-- 
Bill Findlay
<surname><forename> chez blueyonder.co.uk