Trustworthiness It provides the means of constructing systems that can be reasoned about, in which the risks of mistakes can be assessed, in which concurrency can be exploited without compromising those properties. I once sat on a plane with a guy who ran a company that made software to move money around markets, he was really pleased that they could handle up to 60 transactions a second. They would take a money moment (say $5B) split it into 'maximum risk units' and engage in the conversion between the two currencies. Given the nature of the distributed transaction, the way in which the commitment process operated what was *really* important was managing the overall risk of currency fluctuation in the partially completed distributed transactions. His typical employee at the time (this was about 8-10 years ago) was a good PhD in quantum chromodynamics - they had the ability to think about the 'all possible futures' that the code had to handle. (yes I did my FP evangelisation bit) That company, with today's Haskell, could start from a simple, obviously correct, description of the issues and evolve a solution - knowing that, with equational reasoning, referential transparency and other properties, the transformations were 'safe'. Doesn't mean you don't test - does mean you can do more with your good staff. I've used some of the techniques that are in the haskell libraries (esp. iteratee's and dsl's) in developing s/w for intrustion detection companies in the past - granted they were not actually running GHC code - but specialised C coming out of a DSL Neil On 25 Mar 2011, at 07:08, Vasili I. Galchin wrote:

Hello,

I am very curious about the readiness of trading and banking industries to adopt FPLs like Haskell: http://talenteze.catsone.com/careers/index.php?m=portal&a=details&jobOrderID=466095 .... I currently work in the computer security(intrusion detection). My colleagues are totally ignorant concerning the foundations/motivations of FPLs. (Ironically http://www.galois.com participates in the computer security arena!). Why are are trading/ banking diving into FPLs?

Regards,

Vasili _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

"Vasili I. Galchin" writes:

I am very curious about the readiness of trading and banking industries to adopt FPLs like Haskell:

Yes, I've noticed that, too. And it goes both ways - it's an industry of which the computer science crowd tends to be unaware as well. Some hypotheses, off the top of my head, and with no particular knowledge about the industry as such: * The financial business is very competitive, and a small advantage (like making a transaction a minute before your competitors) makes a big difference. In a more conservative industry, nobody got fired for buying IBM. * The financial business are developing mathematical models which map more easily to functional languages. (And have math-savvy people who are able to understand them). OTOH, engineers ought to understand math, too. * Culturally, engineers tend to hire people like themselves, which imposes a lot of inertia. Perhaps the financials have a more enlightened world view? * Mistakes are very expensive, and financials thus value correctness more than other industries, since actual money is at stake, not just less tangible values like customer relations (which can be remedied by other means). * Trends - perhaps an institution is doing particularly well, and it incidentally is using an FPL. The financial sector being no smarter than other sectors, other businesses might pick up FPLs for what is basically cargo-cult reasons. * Financials have the financial elbowroom to pay high salaries. Thus they get smarter people, who as we all know are more likely to choose functional languages. -k -- If I haven't seen further, it is by standing in the footprints of giants