3 ms·

We have two differing definitions of functional programming. I would argue that your code represents functional style in an imperative language. If function po

• rcfox 13y ago
  How about this for functional programming in C? https://github.com/cioc/functionalC https://github.com/cioc/functionalC It's got some of your primitives (map and filter but no fold, but I'm assuming that it's just a matter of getting bored before implementing it) and closures. It's not a serious project, but it serves as a counter-example.
  • jerf 13y ago
    I'm not sure what you're trying to say this is a counter-example to, exactly. wting said "represents functional style in an imperative language"; that's all this seems to be. And as the author of that code themselves all but says, you'd be crazy to use that in production code, so it's not a particularly "good" implementation either. Nobody's questioning that a map-like thingy can be implemented in any Turing-complete language you choose, the question is whether it's actually useful in the context of the rest of the language. I can in fact write a generic map function in Go, by using reflection, but it'll be very slow, and it will still absolutely require the user of the map function to cast the result into the proper type manually since the Go compiler can't do it for you. (You actually can do something like closures in C, though managing the lifetime of the closure data struct can be tricky. And that's actually the problem with functional programming in C; the functional style does not technically "require" GC to work properly, but it sure does encourage it awfully strongly. Or you need something like Rust, with strong support for explicit lifetime management. In C you're just begging for memory leaks with a functional style.)
    • kyllo 13y ago
      Is that because in C, you have to explicitly pass around your lexical scope as fields in a struct, and then you have to remember to explicitly deallocate the struct and null out any pointers to it later when it's no longer needed?
      • hderms 13y ago
        Pretty much, yeah. Closures can actually be a problem for memory deallocation in garbage collected languages. Someone I know was working on a common lisp app and eventually found some of their performance problems to be related to the amount of data held onto by closures.
  • AnthonyMouse 13y ago
    The thing about languages is that you can write other languages inside them. You can implement garbage collection in C. You can compile it to Java bytecode. You can convert Java bytecode to x86 assembly. You can write your own preprocessor to allow C++ style templates in Go. You can make a shim that will allow you to make calls to the Go networking library from a shell script. The question is not whether you can do something, it's how many hoops the language makes you jump through to do it.
• pekk 13y ago
  Can you be more precise about the difference between a program written in the functional style, and one which is written using functional programming?
  • wting 13y ago
    Well there is the "official" definition on Wikipedia.[0] Informally, my definition of a functional programming language is one that supports functional style as the default. (Hooray for using a recursive definition. :p) The language should strive for referential transparency and the language and compiler should be optimized for functional idioms. Let's define the sum of a list functionally[1]: # Python sum = lambda x: reduce(int.__add__, x, 0) # Haskell sum = foldl' (+) 0 You could write this same function in C using function pointers and arrays. However it's not very convenient to do so. You would need to write a reduce function, an add function, anonymous functions don't exist, and syntactically it would be very messy. On top of all this, the compiler is not optimized for reduce functions vs an imperative for loop.[2] More generally, functional style typically refers a style of programming where most functions are pure and side effects are contained specifically. This allows for easier reasoning of a program's correctness. John Carmack has a post about functional programming in C++: http://www.altdevblogaday.com/2012/04/26/functional-programming-in-c/ http://www.altdevblogaday.com/2012/04/26/functional-programm... Summed up, functional style is about containing side effects and functional programming has built-in support for common idioms. [0]: https://en.wikipedia.org/wiki/Functional_programming https://en.wikipedia.org/wiki/Functional_programming [1]: This ignores the fact that sum() is already provided in most functional languages. [2]: Python straddles my definition of functional programming and that's why it's awesome and frustrating at the same time. It supports many staple functional idioms but is not optimized for it. Function calls are very expensive, and thus recursive performance is also hurt tremendously. Plus Guido hates functional programming: http://python-history.blogspot.com/2009/04/origins-of-pythons-functional-features.html http://python-history.blogspot.com/2009/04/origins-of-python...