A program in Lisp:
(print "Hello World")
In this program, we are printing to the screen. Printing is an action or something that we do.
This is procedural. There is no "returning" a result in the program. Printing is a procedure and this is "doing something", not "returning" anything. It is sending off the hello world text and letting it go forever.. not returned to yourself for analysis.
One could argue that it is "returning hello world to the screen" which is like arguing that when I take out the garbage I'm actually returning the garbage to Jesus the savior.
One could argue that "the function returns its just that but if but jimmy dimmy jimmy jimmy donuts!!!!!".
Yeah, you're dumb. Just like all the OOP purists, pure functional programmers are effing clueless.
Note: I said pure, not all.
At some point, the program has to do something... and that is an action or procedure. At some point, we also have to organize our code into different files.. and those are modules.
Functional is Also Modular
Do functional Lisp programmers organize their code into (function (files)) instead of text files (i.e. they wrap their stuff in brackets instead of putting it in a separate text file module)? Rhetorical question, meant for insult and humor. Most languages support some form of modular and procedural programming, even if they haven't a clue that what they are doing involves modular and procedural programming at some point.
Even the C language supports .C files which are very sad forms of modules, and even the C language supports VOID functions, which are very sad forms of procedures (void is kind of like NULL.. not so clear as to WHY and WHAT it is therefore.. why not be clear and call it a proc or pro or procedure. Pro, is even shorter then the four letter "void". I won't get in to the brain damaged TYPEDEF instead of just TYP or TYPE as that is another topic.
Back on topic: the "print" activity in Lisp is just a procedure.. no matter how many functional arguments you come up with. And at some point, your lisp code is separated into modules.. no matter how many arguments you come up with about how the modules are actually just functions returning something.
As for Monads (especially used in Haskell), it is just an escape and a way to include side effects.. into the non side effect language. It is hypocrisy.. but, it may work for your needs. If it works.. then great.
My point is not that functional programming completely sucks hairy bottom.. but rather that it is fraudulent to think in a purist perfectionism no side effect manner . The entire purpose of a program is to eventually have some side effect. Programming is about doing stuff and getting stuff done.
In addition the Haskell wiki is full of nonsensical fanboyism and goes way too far with ridiculous claims. It claims that Haskell is basically the holy grail and solves every single world problem, blah blah.
Dijkstra had an interesting view on functional programming.. and said humorously that functional programming required massaging stuff into more functions to get the program working instead of getting work done using state. I.e. at some point one must have a side effect, and the continual massaging of more and more functions gets kind of ridiculous.
It is nice that functional programming offers us a different view on programming, but I don't think the purism should be followed to the point of insanity. Any trivial even hello world program requires a procedural print call at some point or another to the screen.
Remember, too, that Paul Graham, the Lisp weenie.. eventually had to print his shopping cart on to the screen. I wonder if he considered it a side effect, when for example HTML was produced and output on the web server.. and such horrible procedural stuff.. like sending a socket over TCP/IP.
See also: http://c2.com/cgi/wiki?FraudulentMindset
|
