ThePromisesOfFunctionalProgramming.post

Man, is it hard to make blogs. It's easy to half-read an essay and splatter words that poorly mimic what was written on it. However, it's a whole different ballpark to dissect the essay, understand its historical context, make out what it's trying to communicate and discover the reason why we were forced to read it in the first place. 

Reading is such a passive action that even for an avid reader such as myself, the mere act of setting time aside to get some reading done often comes across as a hobby that takes place only during free time. So, unfortunately, when one's schedule is filled to the brim with homework, consistency with both the reading and it's subsequent interpretation via this blog falls by the wayside (I will cynically change the published date, yet I'm not cynical enough to not confess this).  I hope that the quality of my writing can compensate for how late they'll show up at the door. If not, I guess compromising the quality won't hurt (that much). Better late and (as) great (as possible).   

With that being said, let us begin with The Promises of Functional Programming: An Analysis by a mediocre Undergrad.

From the depths of Aachen, Germany, Konran Hinsen emerges, ready to educate the mortal imperative programmers in the art of functional programming. It's easy to assume that the stereotypical German excellence is very much present at the core of Hinsen, as he begins to, almost mathematically prove, the superiority of functional programming over conventional programming paradigms.

Certainly, his statement is quite persuasive. I must admit, aside from interpreting everything the person with the most boring Twitter feed I've ever seen says as a dogma, he does make a compelling argument. 

Bring mathematics into computation is comparable to bringing a gun to a knife fight, certainly, you'll most likely win, but everyone (computer geeks) will hate you for it. As I see it, stripping away the clutter of conventional programming by getting rid of variables and data storage is almost blasphemous as someone who was academically raised on that basis. Nonetheless, the functional approach guarantees that the side effects, as he mentions it, are greatly reduced thanks to tackling every problem with the use of functions. Real functions.

Any and every programmer can be tasked with a problem and after a quick analysis and a couple lines of sloppy code, they'll pop out a solution. More often than not it's probably a rather crummy solution. Mere duct tape on a pipe, ready to malfunction when you least expect it. This generates a program with a lot of side effects everywhere, and when it's debugging time, you're gonna have a hard time. So wouldn't it be better to use a language as efficient and elegant as mathematics itself? 

Ja, genau, Hinsen! Alright? I'm sold! Tell me more! 

And more he does tell. Now, I won't go into much detail about how functional programming works. You, the reader, have the essay for that (linked below). However, he does give us two very rich concepts that give functional programming its shine: recursion and its use in functions. Functions, as he mentions, are very mathematical and very efficient. Instead of spaghetti code and a whole mess, you have a simple function. One that, almost indescribably filled with potential. Pair it with recursion, that is, a function that repeats itself until it reaches a base case, and you got yourself a mighty fine programming language. The levels of optimization of the data structures are high enough so that they can make for a reliable base on which you can build your programs. 

He provides a few examples, which I won't feature on this blog entry, but they are good enough to indoctrinate its readers into functional programming (OK, maybe not that extreme) without overwhelming them with complexity (that's true, though). These serve as a good way to see what he's preaching in action.

Finally, he does disappoint a bit, unfortunately. Concurrency is probably the most attractive feature that FP has to offer, and he ends it on a low note (or maybe it's something to motivate the future generations), concurrency is still a feature that hasn't been properly implemented in an efficient way. Hopefully, he says, in the future, compilers will more adequately employ this feature. I sure hope so, especially with quantum computing although maybe by that point I'll be to old to care. 

That's enough blabbering from me, like I said, I'm sold. It was an easy sell, but eh, all this seems like a challenge and I'm up for one, we'll se how it goes.