Equational

I had a magical insight recently about something that was bugging me almost two years. The question was: why the hell was I so unproductive creating type classes! So here is the deal: when you develop, you combine invariants and transformation properties of your  different pieces to make something new. If you are someone like me, you live your code, and that means that the relations between the different concepts throughout the code drive me "emotionaly". Yesterday, it occured to me that what is special with type classes is that they are "open".  They are open because their properties are not always obvious from the definitions. Worse, new type classes often have unambiguous properties. I say open because by contrast if I avoid type classes by explictly defining type specific functions or if I create encapsulating types to replace the functional polymorphism by data variants, then I am in effect "closing" the desi...

A market making and brokerage firm, Knight Capital Group,  lost all their money (~400M$)  when their automated trading system went crazy and it seems repeatedly bought high and sold low, as fast as it could, across many instruments. My guess is that they turned on a test app on the live market. This would explain why they were not feeding the trades into their portfolios. An algo to buy the spread makes sense if it is used to act as a counterparty to test other algos such as a market making application. Then again, a test app normally has hard coded detections of the live market that turn it off. So who knows?! This event is interesting in a few different ways: What fail-safe code do you want to include in your algo system? What fail-safe development management process do you implement to try to guarantee that those failsafe coding standards are met? Trading is really about keeping your profits, not about making them! Organic systems are assymetric...