Functional Programming: A present solution for future problems

If you read the past entry, you can be thinking by now that I will develop another sociological analysis. Nevertheless, Hinsen, K made such a concise and straight-forward article that the only thing I could add to its discussion is an objective opinion.

The promises of functional programming, (2009) [1]  presents to the reader an easy-to-understand approach to one of the toughest, yet simple topics I've ever faced as a computer science student: Functional Programming. When I started to program back in 2018, I never imagined the different tastes of problem-solving strategies used in the technological industry. I was happy as ever solving problems with  Python's functions and thinking that my whole career would be about using these procedure differently to solve any kind of situations Nonetheless, I was brutally taught that I was wrong when I began to study the Object-Oriented programming paradigm... god those were really tough times. Classes, Objects, Inheritance, Relations. and much more concepts that my young mind couldn't comprehend and, to be fair, that I still do not understand completely. 

You may be thinking: How is your experience related to the lecture since Python did not teach us functional programming? Firstly, I must agree with that statement. Yes, we did not learn functional programming during our first semester, but Python, as multi-paradigm as it is, unconsciously introduced us to a new way to code. And that is all that is needed to relate my experience with the main purpose of the article. As Hinsen, K hinted, different functional-oriented languages, and the methodology itself, allow us as developers to think more as mathematicians than as computer-geeks, thus creating new and more effective ways to interact not only with the machine but with science.  As professionals we have the responsibility to create better solutions for the present as well as for the future, regardless of the technology used. But, it wouldn't be easier to use and expand the already available specialized tools rather than trying to accommodate all of our workflow to a specific antique yet popular technique?

Although it may be perceive that I'm being to harsh with OOP due to my personal experience with it, trust that I'm not. I can personally tell you that I have developed more things using OOP than functional programming. Nevertheless, as a conclusion, I must state that due to the needs of the most influential technologies today (machine learning, cloud computing, data science, mobile computation, among others), our coding solutions should be backed-up with the easiest, universally efficient  and more capable paradigm available and as Hinsen, K said: Functional programming is frequently cited as a promising technique [that certainly, if improved, will revolutionize computing]. 


Bibliography

1. Hinsen, K. (2009). The promises of functional programming. Computing in Science & Engineering. pp.86-90 


Comentarios

Publicar un comentario

Entradas populares de este blog

Chat with Russ Olsen

Personally, it was a long ago since I had the pleasure to met the author of a book in person and I have never met the writer of any technical book. After this conversation with Russ Olsen, I must say that I'm very fortunate to be one of the persons who have had the chance to share the same, although digital, space as this programmer and for having Russ as the first of its kind.  Although we only shared with him an hour of the class, he had the chance to talked us about a bunch of things, technical and personal alike. I would love to summarize every one of them since I personally think that every word that was shared has a unique value. Nonetheless, as one of the focal pintos that he mentioned, simplicity is key and in order to keep it within this post, I will only highlight those aspects that I found more interesting in three sections: 1. About his life:  Hobbies are everything and, as he hinted, they somehow help us to achieve better opportunities as well as to prepare us for new
Leer más

Rich Hickey: "Clojure, I'm your father"

In the episode  Rich Hickey on Clojure we get to know the Clojure's creator, Rich Hickey. As an introduction as well as a personal statement, I would like to highlight the basic idea in which Clojure was formed: Frustration.  The discussion starts with a brief explanation of the author's decision to create a Lisp-like language in 2009, same year where well-established technologies, such as Java, C++ or even Python, were becoming  mainstream tools throughout the industry. As Hickey mentions, although these programmable utensils were popular, all of them lacked the power of adding macros or different processes to run under compilation time. Furthermore, they all share a relatively chunky syntax, making them suitable for lazy in addition to unprepared programmers for unhanded data manipulation.  After 30 minutes, he roasted the entire tool-set I've been trying to completely master during the last 3 years... but he's right. As an entry-level programmer I have not met nor us
Leer más