The Promises of Functional Programming (Commentary)

Functional programming is the chinese of programming paradigms_ it's complicated, a lot of people speak it, you don't actually know anyone who speaks it, and everyone keeps telling you you should learn it because "it'll be useful in the near future."

As I've said time and time again in this blog, functional programming has its beauty, just like my unborn child will be beautiful to my eyes even if it's born with three ears. We have its elegant way of solving problems, its simple yet effective way of implementing loops and repeated processes, and its timeless support of concurrent and parallel programming.

It is important to learn chinese, maybe not for actually communicating with chinese people, or for simple bragging rights, but because by learning it, we may actually get some insight on how other languages work. This applies to functional programming too, we may gain some insight on how languages like Java or those languages that support recursion work.

I have praised LISP's ease of maintainability before, for it not containning a hell ton of code in its scripts or variables to worry about, which is great, because renaming variables takes about 75% of my "code-embelishment" time.

Revenge of the nerds (Commentary)

IT industry problems almost always start with a classic case of "blind leading the blind", specially when testing new features. Inspiration is not something very valued by IT companies these days (unless you're thinking of companies of gargantuan size, or teeny tiny forgetable startups), the boss will always go for whatever is safest, and "safest" in most cases translates to "cheapest". Every once in a while, the boss will think to themselves "Hey, look, <hip programming platform here> <version number here> is out, let's all move our processes to that.", without really knowing what <hip programming platform here> truely is or what <version number here> implements.

There are so many other options beside what's "hip" or "standarized" that can do a better job at not crashing everything within a company's system, and were actually built for those specific task you're trying so desperately to write out in Java (oh, crap, what are you doing?). Take for instance LISP, there's only so many ways one can nail down a nail, you don't need a mechanical drill, or a hydraulic press, you don't even need a hammer (if you're brave enough). So, why try to over complicate things?

One of the few things I've come to cherish about LISP is it's elegant no-nonsense design thought for the solution of simple one-way problems, and it can also be used for a world of complex tasks for a swift, easily manageable and maintainable solution. It is said that most modern programming languages are created with LISP simmilarities in mind, and, though I cannot find any actual true simmilarities between Python and LISP (for Python is not mind-numbingly complicated), I agree that this shift is not necessarily a bad thing.

Unless you make me (write (like this)).