Having worked a bit with KDB, my experience is totally different. The investment bank I worked at had a large and thriving KDB community of developers. In one particular project, we were able to replace a system consisting of 10's of thousands of fairly good but heavily abstracted java code reduce it to a few hundred lines of Q. The java application at took 7 hours to run its worst case query and the Q code that ran the same query in less than a second. The Q code was solved the business case better, it was more readable mainly because there were no unnecessary abstractions. There was still a OOP middle tier, but it was mainly pass through. Calling any technology a "pile of shite" should be done with great care. Most solutions solve a use case and KDB/K solves its use case exceptionally well. To be honest, understanding what the 'Rank' error means is not that hard. For the project I referenced earlier I personally found it much easier to debug Q than trying to find out what an an AbstractCalculationFactorybuilder was doing. There are very few poor languages, just poor developers.