There are a lot of pages on FunctionalProgramming on this wiki. Some have challenged FunctionalProgramming.
// helloexample.cpp // Example to show use of putting Hello World into a functional setting. #include <iostream> #include <string> // 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 <typename T> void do_it0(const T &t) { t(); } template <typename T, typename S> 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<void> 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<std::string,void> 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