There are a lot of pages on FunctionalProgramming on this wiki. Some have challenged FunctionalProgramming. * ''Functional programming is pure nonsense.. the print("hello world") is still a procedure in any language (it affects the state and modifies the screen too). It's actually just a big SyntaxGame and a form of different procedural programming. Eventually the program does something.'' Here is an example using the methods to be found on FunctoidsInCpp to show one way in which printing out ''Hello World'' can be made into an object which can be passed as a parameter to other functions. The various techniques employed are part of '''FC++''', a library for C++. // helloexample.cpp // Example to show use of putting Hello World into a functional setting. #include #include // First a simple function. void printHelloWorld () { std::cout << "Hello World" << std::endl; } void printString (std::string s) { std::cout << s << std::endl; } // Now some FC++ stuff #include "fcpp/prelude.h" template void do_it0(const T &t) { t(); } template void do_it1(const T &t,const S &s) { t(s); } int main(int argc, char ** argv) { std::string hello_world("Hello World"); printHelloWorld(); // Turn in into a functoid by taking its address fcpp::Fun0 pHelloWorld = fcpp::ptr_to_fun(&printHelloWorld); // and then call that. pHelloWorld(); // pass as an argument do_it0(pHelloWorld); printString(hello_world); // Turn in into a functoid by taking its address fcpp::Fun1 pString = fcpp::ptr_to_fun(&printString); // and then call that. pString(hello_world); // pass as an argument do_it1(pString,hello_world); } The output is multiple copies of ''Hello World''. -- JohnFletcher ---- '''Right Tool for the Job''' It's my opinion that FunctionalProgramming is of better use in SystemsSoftware than application software. While kicking around ideas for MaspBrainstorming, I can find far more possible uses for FP in terms of using Masp to build domain-specific languages and idioms, such as building one's own control structure (loops, conditionals, etc.) Some have claimed that I simply don't have enough experience using FP for apps (ChallengeSixVersusFpDiscussion), but the real problem is that engineers are far more willing to stick with and tolerate higher-level abstractions than most customers for applications; they want what they want when they want it, clean abstractions be damned. In a world where the "user" cares about and understands the value of abstractions and "buys into" them, it's easier to use, keep, and maintain abstractions in code. Procedural programming is less abstract for the most part, but it's also more flexible because of that. --top ---- ''One must not forget also the phrase "right fool for the job." '' i.e.: Right person/individual for the job. How, specifically, does this relate to the above? ''I gave a name to this sort of thing a long time ago. I call it a ParkingTicket. It is a contribution to noise. I suggest ignoring it and moving on, which I know has its difficulties. There are one or more contributors who think FunctionalProgramming a waste of time and those who use it foolish. That is their opinion.'' -- JohnFletcher ---- CategoryFunctionalProgramming