I started coding C++ about 15 years ago, since then there has always been a language about to overthrow it. It has never been the same language for long, but there has always been one. I lean towards the idea that the languages of the future are C and C++, just like the languages of the past.

Every failure of Agile I have experience happened because someone high enough up the chain of command, kept a spreadsheet with all deliverables and deadlines for when they are supposed to be done. In other words Agile fails because development organisations fail to commit to the methodology, and try to keep a waterfall approach in management while letting the project participants to be "Agile".

Thanks to everyone who helped out! Especially Finn The Human for efforts above and beyond.

I have spent a while working on a set of C++ tools for easy development of multi-threaded, distributed data analysis. The code was developed on FreeBSD, but contains the ifdefs to compile on Linux as well. I don't have time for a Windows version and I haven't tested it on OSX in a while but if it does not compile it should require very few modifications to do so.

The tools consist of an analysis engine, which helps structure development of individual calculations arranged as nodes in a DAG. A server, which functions as a network wrapper around the analysis engine, and finally a client template which allows easy development of interfaces with the server.

All the tools are built for asynchronous, push based communication and will spawn threads in the back ground.

I hope someone finds it useful. Constructive criticism is welcome, patches doubly so.

The right tool for the job. OOP is very helpful for expressing business logic. If you are writing a fixed set of instructions, something like take this string and send it via SMTP, then you might as well stay with C.

You can easily emulate OOP in C, but nobody wants to write all that extra code.

Yes, you can write that because you have a description of the rules of FizzBuzz. Given only the name FizzBuzz you could not have implemented it. It is certainly an extreme example, but we all have a tendency to think that what we know is common knowledge.

I write multi-threaded C++ for a living and the first time I was asked to solve the FizzBuzz problem I could not do it. Not because the intricacies of modulo are beyond me, but because I come from a country where we don't play FizzBuzz and had no idea what the problem was. Before you blame the programmer, make sure your specification doesn't suck!

Having said that, an amazing number of people seem to think they can bs their way through quantitative development job.