Thoughts on Functional Programming
Functional programming comes back another time in recent year and not without momentum. Many imperative languages are adding functional capabilities, like Java, Python. Some, while proclaiming to be functional, are more procedural, and therefore confusing sometimes. Functional Thinking is a great book to understand what functional programming really is, especially after you have coded in some of them and have a first hand experience. Once I was to upgrade a legacy system I found that many java codes are written in C style with many parameters, no encapsulation, no interface design, etc. It happens too, in the FP scene. Many people, although writing FP codes, are thinking in a procedural or imperative way. But the way people think does not come out of thin air. The way people think in programming are heavily influenced by the programing language they write in. An aptly designed programming language can help people understand and write better FP codes. For example, as a high level interpretation language, R is not fast. So, instead to write your own functions with loops, procedures, you are compelled toi use vectorized functionals as many a possible. Each of them is an independent stage of the pipe.The logic involved is more easily to be sorted out and the refactoring and testing made easier as well. For the functionals to be independent, side-effects are to be avoid as much as possible. That is, the code should be more self-contained. In this way, R helps us shape our thinking in a functional way. The fundamental feature of functional programming is that, function, or functional, or operator mathematically a set of sets, second order object, is treated as first order object. They can be passed, reused, serialised, persisted. Mathematically it’s much more expressive than imperative languages like Java, which mathematically is first order. It seems just different way of thinking but actually reflects the deep understandings of computation, data, and algorithm.
