Clojure

I couldn't decide what to write about the Promises of Functional Programming, that is, until I found the blog entries by my partners. In first instance, and I quote, I found Estaban's synthesis fell short.

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. 

Really man? This is your 8th entry on your clojure blog, and you are still using innmutability as a good resource to judge Clojure? Specially when one of the best topics to get out of the article is the subtle way where he jabs functional programming on the back?

Of course, the answer is no: the pure functional programs I’ve described to this point will just heat up your computer. You need side effects if you want your programto have any interaction with the realworld. But you can and should limit side effects to very few places.

This seems minor, but just amplifying this, we can see that other sides of the class are equally as pale. Josep's analisis is also lackluster.

The principal funcionality  of functional programming is that you compute by composing functions. A function in a mathematical is something that always return the same output to the same input without any change.  To solve these we cant use variable in our functions instead we use loops that evaluate a function with different parameters over each turn or lap.

Josep here tries to explain the eval and apply loop in a lackluster way. Sadly, Rick and Dick had already told us about the computability of lisp as eval and apply methods of functionality. You could have talked about the interesting transformation of dialetic programming with concurrency as it base.

Another example of more of the same is Luis Espinoza's analysis of a functional language. SAD.

Other of the pure programs’ benefits is the capability to receive a function as an input or produce a function as an output. As weird as it sounds, it is an amazing capability that helps to execute programs inside other programs without the need of stores values (yet again) and produce a faction that produces the expected value over and over 

Hinsen, Konrad. The Promises of Functional Programming (2009) Consulted on Octuber 15, 2017. Retrieved from: http://webcem01.cem.itesm.mx:8005/s201713/tc2006/the_promises_of_functional_programming.pdf