www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - functional

reply James Iry <jamesiry gmail.com> writes:
No, C does not support functional programming.  It is pretty much impossible to
write an interesting C program that does not mutate things.  That's not a
condemnation of C, I still have a soft spot in my heart for it, but it is a
recognition of how C is deeply tied to an imperative model of computation.

Still, I notice you haven't addressed the core of my argument: functional
programming languages and purely functional programming existed before there
were languages that could enforce the purity.  So insisting that language X is
not functional because it does not enforce purity is to redefine the phrase
"functional programming language" away from its historical roots in the Lisps
and the MLs.

There's a reason that Haskell is called a "purely functional programming
language" rather than just a "functional programming language" and that is
precisely to clarify one important dimension of difference from the ML family. 
(It's actually called a "non-strict purely functional programming language" to
talk about another important dimension of difference, but that's not what we're
talking about here.)

I don't disagree that it is possible, and even easy to write imperative code in
the (impure) functional languages in the Lisp and ML families.  But I do
disagree with the contention that that makes them anything but functional
languages since the phrase "functional programming language" was invented
precisely to talk about their ability to express purely functional code even if
there was no automated static proof of that purity.

Walter Bright Wrote:


 James Iry wrote:

 I'm going to assume you meant "enforce" rather than "support" because
 both languages support immutability and purity precisely to the
 extent that the programmers want to use them (although, of the two,
 Scala's standard library has far more support).


 
 So does C. The problem is, without compiler support, you have a very 
 difficult time telling by visual inspection if code is functional or not.
 
 It's like turning off type checking in your C compiler. It still works, 
 but it's really bug prone.
Mar 10 2010
next sibling parent reply Justin Johansson <no spam.com> writes:
James Iry Wrote:


 No, C does not support functional programming.  It is pretty much impossible
to write an interesting C program that does not mutate things.  That's not a
condemnation of C, I still have a soft spot in my heart for it, but it is a
recognition of how C is deeply tied to an imperative model of computation.


Impossible?  Tedious perhaps but certainly not (even close to) impossible.

Thinking of C++ as syntactic sugar over C, and given that most of my C++
development work
these days is functional in nature (emphasising the immutability aspect), I
contest that your
statement is false as a blanket, outright statement.  Certainly though, to code
C/C++ in a 
functional fashion requires a fair amount of experience and rethinking of
imperative coding habits.

There is no reason to think that D programming cannot also be approached with a
functional mindset.

Justin Johansson
Mar 10 2010
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Justin Johansson wrote:

 Certainly though, to code C/C++ in a 
 functional fashion requires a fair amount of experience and
 rethinking of imperative coding habits.


Ironically, my own use of C/C++ is tending more and more to adopt 
functional idioms.



 There is no reason to think that D programming cannot also be
 approached with a functional mindset.


My experience with traditional FP languages is limited to reading about 
them, and writing some very small programs in Lisp. But I think that D's 
support of immutability and purity go a long way to supporting FP 
idioms, a lot longer than C/C++.
Mar 10 2010
parent Justin Johansson <no spam.com> writes:
Walter Bright Wrote:


 Justin Johansson wrote:

 Certainly though, to code C/C++ in a 
 functional fashion requires a fair amount of experience and
 rethinking of imperative coding habits.


 
 Ironically, my own use of C/C++ is tending more and more to adopt 
 functional idioms.
 
 

 There is no reason to think that D programming cannot also be
 approached with a functional mindset.


 
 My experience with traditional FP languages is limited to reading about 
 them, and writing some very small programs in Lisp. But I think that D's 
 support of immutability and purity go a long way to supporting FP 
 idioms, a lot longer than C/C++.


No argument there and I would hope so! :-)
Mar 10 2010
prev sibling parent bearophile <bearophileHUGS lycos.com> writes:
Justin Johansson:

 There is no reason to think that D programming cannot also be approached with
a functional mindset.


In practice to program well in functional style:
- syntax sugar here and there helps, with some functional-handy features. For
example in Haskell some local type inference is not optional, you probably have
to waste too much time if you want to specify all data types manually.
- a good type system helps;
- a GC tuned for immutables, that's able to digest a very frequent disposal of
immutable data structures is very useful;
- A compiler able to perform some optimizations that are not usually done by
compilers of imperative languages. They have added LLVM as possible backend for
Haskell, but there is a middle end that performs complex transformations.
- a standard library with many immutable but efficient data structures (that
use finger trees, etc).
- a community of programmers that know some functional programming, because
programming in functional style along in a sea of imperative/oop programmers
that write imperative mutable libraries is not good.
- For example in a functional language you usually don't modules in the
standard library that use templates instead of delegates/function pointers.

So I think D2 is quite far from being a good&handy functional language, despite
it has some features very useful for functional programming (pure, closures,
transitive immutable/const).

----------------

Walter Bright:

My experience with traditional FP languages is limited to reading about them,
and writing some very small programs in Lisp.<


I think that having a bit of practice with FP languages can help you design
D2/Phobos2 to be a little more functional-friendly.
Given that background I suggest you to write few small programs in Clojure:
http://clojure.org/
It's a modern Lisp dialect that's based on the JavaVM, that is mostly
immutables-based and is nice with concurrency too. It has also uses the idea of
"transients", that is functions that locally usually modify a newly created
data structure, this allows the JVM to use such functions to build such data
structures in a much more efficient way, then such data structures are returned
as immutable.


its IDE, because it has already solved some of the problems D2 has still (you


Bye,
bearophile
Mar 10 2010
prev sibling next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
James Iry wrote:

 No, C does not support functional programming.  It is pretty much
 impossible to write an interesting C program that does not mutate
 things.  That's not a condemnation of C, I still have a soft spot in
 my heart for it, but it is a recognition of how C is deeply tied to
 an imperative model of computation.
 
 Still, I notice you haven't addressed the core of my argument:
 functional programming languages and purely functional programming
 existed before there were languages that could enforce the purity.
 So insisting that language X is not functional because it does not
 enforce purity is to redefine the phrase "functional programming
 language" away from its historical roots in the Lisps and the MLs.


I thought Andrei's reply addressed it better than I could have.



 There's a reason that Haskell is called a "purely functional
 programming language" rather than just a "functional programming
 language" and that is precisely to clarify one important dimension of
 difference from the ML family.  (It's actually called a "non-strict
 purely functional programming language" to talk about another
 important dimension of difference, but that's not what we're talking
 about here.)
 
 I don't disagree that it is possible, and even easy to write
 imperative code in the (impure) functional languages in the Lisp and
 ML families.  But I do disagree with the contention that that makes
 them anything but functional languages since the phrase "functional
 programming language" was invented precisely to talk about their
 ability to express purely functional code even if there was no
 automated static proof of that purity.


I don't understand why C programs cannot be written that don't mutate 
things (other than for initialization - even pure functional programs 
initialize things).
Mar 10 2010
prev sibling parent reply Michal Minich <michal.minich gmail.com> writes:
what mostly functional programmers think about it:

What are the properties of "Functional Programming Languages"?
http://lambda-the-ultimate.org/node/2539

What are the real benefits of FP?
http://lambda-the-ultimate.org/node/1578

from the discussion it seems there may be no straight answer.

it might be interesting to see discussion to second question about D on 
this group - if it did't already happened?
Mar 11 2010
parent reply Justin Johansson <no spam.com> writes:
Michal Minich Wrote:


 what mostly functional programmers think about it:
 
 What are the properties of "Functional Programming Languages"?
 http://lambda-the-ultimate.org/node/2539
 
 What are the real benefits of FP?
 http://lambda-the-ultimate.org/node/1578
 
 from the discussion it seems there may be no straight answer.
 
 it might be interesting to see discussion to second question about D on 
 this group - if it did't already happened?


As we all note there are endless discussions about FP vs IP all over the net.

And while the links posted above lead to some interesting discussion, it's all
"pubtalk".  (Brits and Aussie know what a pub is .. in your neck of the woods it
might be called a bar .. where you hang out, drink beer and discuss footy,
baseball, gridiron, soccer, politics, religion and, if you are a nerd, computer
crap).

My tenet is simply this.  Functional Programming (FP) and Imperative
Programming (IP)
are both tools like a kind of hammer in search of a nail to hit.  What, though,
is the purpose
of just finding a nail to hit?  In any case, you could hit a nail with a tennis
racket or a golf club
or whatever but what's the objective?

If the objective is to join to material objects together, a nail and a hammer
might be
one solution.  Super glue might also work.

Now I don't know if this story is urban myth or what but supposedly there was
once a very
successful hardware salesperson who said 

"I don't sell drill-bits.  I sell solutions to make holes."

What it boils down to is this: the problem has to be defined and then you need
to find the
solution.

The salesperson was successful because she identified the problem.

If the problem is ill-defined, you have a moving target, endless discussions
about the
right tool are a sure thing and the quality of the discussion ends up amounting
to
"pubtalk" along the lines "my hammer is better than your hammer".

The most challenging problem of all in computer science (and most other fields
of
endeavour) is to "define the problem".  From there, we can do about finding the
best solution.

With kind regards to all and especially Michal for posting the LtU contribution,

Justin Johansson
Mar 11 2010
parent reply Justin Johansson <no spam.com> writes:
Justin Johansson Wrote:


 The most challenging problem of all in computer science (and most other fields
of
 endeavour) is to "define the problem".  From there, we can do about finding the
 best solution.


Correction:  From there, we can *go* about finding the best solution.

(Also hope my rant did not sound too pontifical.)

Cheers,
Justin Johansson
Mar 11 2010
parent Bane <branimir.milosavljevic gmail.com> writes:
Justin Johansson Wrote:


 Justin Johansson Wrote:
 

 The most challenging problem of all in computer science (and most other fields
of
 endeavour) is to "define the problem".  From there, we can do about finding the
 best solution.


 
 Correction:  From there, we can *go* about finding the best solution.
 
 (Also hope my rant did not sound too pontifical.)
 
 Cheers,
 Justin Johansson
 


I liked the part with beer. And I still havent found a problem to solve with
FP. Other than that. this article hits the nail in the head.
Mar 11 2010