Functional Programming Discussion

There are a lot of pages on FunctionalProgramming on this wiki. Some have challenged FunctionalProgramming.

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 <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


CategoryFunctionalProgramming


EditText of this page (last edited July 20, 2011) or FindPage with title or text search