Over the last 4 or so months I have drifted away from technologies and focused heavily on compiler theory and design as well as data structures and algorithms.
You may of noticed that F# has become a fairly recurrent theme on this blog - that's because functional languages have a great deal to offer, especially in terms of lexical analysis and working with abstract syntax tree's, there is no better language paradigm to use when working with recursively defined data structures like trees.
Anyway, the focus of this blog will probably become 100% focused on the aforementioned subjects...this should be really interesting for the reader, not many people get excited by compiler theory and implementation...whether that is a good thing or bad thing I'm not sure! :-)
This means that code on this blog will probably be in one of the following languages:
Why? The first and last are obvious choices, two popular imperative languages with the latter exposing a little more control over the OS's resources. F# I've explained already it's uses in such an area.
On this blog I will try my best to explain things as best I can without throwing a load of formal methods at you, although avoiding it is impossible in such an area. Sorry if you have no knowledge of formal methods, but I happen to really like it.
Hopefully future blog posts will not only educate, but also invoke ideas on your part about how we can help languages evolve to encompass issues like parallelism, and so on. On the latter should the onus be on the developer? or should it be on the compiler writer? I'm not going to answer this now, but imperative languages are going to be immensely hard for the compiler writers to natively support mappings to code that is deemed safe for parallel execution - unfortunately for the majority of developers around the world these languages (C, C++, C#, Java and so on) are the most widely used commercially. To their credit Microsoft are working on introducing functional constructs into the likes of C# and VB.NET to address this, LINQ was the first major step - looking further ahead PLINQ will enable the developer to further abstract away from imperatives to support easier multi core/CPU friendly code to improve performance by many factors.
I kind of went on a tangent on the end there, sorry. I hope you will find what I have to say informative and at the same time exciting.