Programming: Moving Towards a Functional Paradigm
Early programmers often have to deal with the state of CPU registers, where they have to go into great details about how computers should behave. Then, once they get a hang of it, to save time, they'll implement low/mid-level languages to do all the boring stuff, so they could just allocate memory for data structure (later object) and move it around without spending time telling the computer how it should perform these operations. At this point, the compiler can figure it out automatically.
It has been ten years since CPU frequency stopped increasing. The progress of computation technology now features an increased focus on cores and power efficiency.
Writing multithreaded programs will let us take advantage of this. Languages and tools help us in that journey – creation of a thread in the operation system is a relatively long and expensive operation, but using virtual machines to execute code can keep few threads in the OS and reuse them. This approach is called “green threads”, and is supported by many current languages and VMs like Python, Ruby, PHP, and of course functional platforms – Haskell, Erlang, and Elexir.
Lightweight threads are great but we’d be back in the old paradigm again – developers must manually schedule work in different threads and think about synchronization, different memory optimization, deadlocks, and so on instead of focusing on features they want to implement.However, just making the creation of threads “lightweight” is not enough. This is why the next step in computer-handled software development is multithreaded functions.
Reactive extensions for many languages, which have become popular in recent years, help us with that problem, but it cannot be solved with a library; we need a new paradigm.
This is where functional languages come into play. The initial paradigm of immutability, pure/non pure functions and the declarative approach (as opposed to imperative) allows VMs to decide what parts of the program are independent and can be executed in different cores.
This should allow us to efficiently load all available computer resources. Then developers can implement business features in light of thread scheduling and not the other way around, the same way a Java programmer should know about memory allocation and how it works, but shouldn’t have to think about it all the time.
This is even more important when it comes to mobile programming. Mobile devices have two different CPU core types: little core – energy efficient, but slow, and big core – fast, but requires a lot of power and drains battery very fast. If we can share almost any task to any number of cores, we can do away with big cores,which will make possible devices that work both longer and faster!