Chapter 8: More robust, more compact, and more easily parallelizable; For an unlimited time offer, we present you: Functional Programming

This blog is about how functional programming has a lot of advantages over traditional programming, such as concurrent and parallel programming. One of the first things that pops out when using Lisp is its syntax; simple yet flexible nested lists. This data structure usage is one of the principal advantages of functional programming; it allows to generate and execute other Lisp code.



Now we have Clojure, which is a recent Lisp dialect that shines thanks to various features, one of which being their high optimized data structures, that offers extensive support for concurrency. A key concept in functional programming are abstractions, that expresses an algorithm in terms of concepts instead of operations.

These functional languages can be grouped together in a few groups, like “Clojure and the Lisp Family” and ML family, where Standard ML, OCaml and F# are included. The difference between this two groups are that ML is statically typed (Haven’t heard of F# yet, it feels like programming languages are starting to base their names on music).

Something interesting about functional languages is how they manage concurrency and how they maintain the data in a coherent state; the key here is that pure functional code has no variables, which leads to no data coherence issues or need for locking. If there are no variables to lock, then there are no way functions access these non-existent variables and change the way they behave.


This is one of the features I like the most, how these are managed with a very simple solution, remove the variables. Of course, many people aren’t used to this type of programming (like me, at the beginning of this course), but, as longer as I am getting involved with this class, the more aware I am of the advantages and disadvantages of how functional programming is a very powerful approach to common programming.

 References:
Hinsen Konrad (2009) The Promises of Functional Programming. Available on: http://webcem01.cem.itesm.mx:8005/s201713/tc2006/the_promises_of_functional_programming.pdf

Comments

Post a Comment

Popular posts from this blog

Chapter 10: Riding the… bear?

Image
Reverse engineering was the main topic of the video (or at least, the one I found most interesting). How the company was available to replicate the ROM BIOS through this concept is something fascinating, whatever was meant to be hidden and secret, was forever known and open to the public after the reverse engineering process. This process involved two different types of employees, the ones that know how the system works, and the so called “virgins”, which knowledge of the ROM BIOS was inexistent. The journey to get to a completed product no one knew how it worked (at least the engineers in charge of building the chip) is the thing I liked the most. And that’s how Compaq made a portable computer, compatible with IBM. This was the start of the dozens of rivals IBM started acquiring thanks to the easiness to build a clone. The thing in common every clone-builder had, was its operating system, acquired thanks to Microsoft. Finally, this way the balance worked out for Microsoft...
Read more

Chapter 7: Clojure Podcast with our beloved friend, Hickey, Rich Hickey

Image
So… Clojure by Rich Hickey is the podcast we are covering up in today’s blog. We have seen and read about the advantages of Clojure, however, there was an interesting point that was said during the first part of the podcast (13:21) that struck me; “At the core, for instance, Clojure, is much much simpler than Java… There are two different notions of simplicity, you could say that LISP is simple because it has a very simple syntax, only consisting of a couple of abstractions… but Java is simpler because I am guided more”. This argument made me realize which of both, Java or Clojure is more “simple”. Of course, Java is more guided through the coding process, however, it is hard to comprehend what happens in each line of the code. For experienced Java developers, they may see it as something trivial, but for novice programmers, some coding standards or abstractions are put in their codes because they are told to do so. Many don’t go beyond the understanding of the logic behind ...
Read more