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. Time ago I have suggested you to write few small programs in C#3.5 too using its IDE, because it has already solved some of the problems D2 has still (you can use C# with mono if you don't want to install dotnet). 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