If you’ve been developing software for a few years you might have noticed an increase in the need of parallel programming and it’s no wonder in these day and time when most computers have at least 2 cores that can run two actions at the same time.
Along with the need comes the solution - tools and languages that would make parallel programming easier – because “it’s way too hard to understand multi-threaded code” .
Right now I can see two distinct groups of products that aim in making our job (development) easier:
The first group try to solve a fundamental problem with the way a programmer write code in C++/C#/Java or whatever language you’re currently using. Instead why not use a language that has been able to completely (or mostly) eliminate deadlocks and race conditions – either by using message passing for interaction between objects(Erlang, Axum) or by having immutable objects (F#).
The second group combines of (amazing) tools that by using statistics or plain brute force discover if your code has multi threaded problems (again race conditions and deadlocks).
Have we gotten to multi-threading heaven or are we just lacking the right tool that will make development not quite so hard.
I believe that in the upcoming years we will see some more tools and languages aimed at helping us write better multi threaded code faster, I do believe that no tool will free us from understanding what our software actually does. Just like the fact that we still need to know a bit of logic to write the simplest application (other then Hell-o-world) we will forever need to understand how our code behaves when run on several processors at the same time.
I believe that multi-threading application development does not need to wait for the right tool just for the right developer.
Labels: Multi-threading, Tools