why are trading/banking industries seriously adopting FPLs???

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

why are trading/banking industries seriously adopting FPLs???

Vasili I. Galchin
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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: why are trading/banking industries seriously adopting FPLs???

Erik de Castro Lopo-34
Vasili I. Galchin wrote:

>      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).

I worked in that area myself at one time. I found the security field
full of snake oil merchants, poor engineering practices, poor
methodlogy and shoddy products.

> My
> colleagues are totally ignorant concerning the foundations/motivations of
> FPLs. (Ironically http://www.galois.com participates in the computer
> security arena!).

Galois is likely a notable exception to my earlier statement.

> Why are are trading/banking diving into FPLs?

The best explanation I know of is by Yaron Minsky of Jane Street
Capital. Find it in the The Monad Reader issue 7:

    http://www.haskell.org/wikiupload/0/03/TMR-Issue7.pdf

Erik
--
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: why are trading/banking industries seriously adopting FPLs???

Neil Davies
In reply to this post by Vasili I. Galchin
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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: why are trading/banking industries seriously adopting FPLs???

Ketil Malde-5
In reply to this post by Vasili I. Galchin
"Vasili I. Galchin" <[hidden email]> 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

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: why are trading/banking industries seriouslyadopting FPLs???

Claus Reinke
In reply to this post by Vasili I. Galchin
>     I am very curious about the readiness of trading and banking
> industries to adopt FPLs like Haskell:
> .. Why are are trading/banking diving into FPLs?

Some possible reasons have been given, but to keep things
in perspective, you might want to consider that it isn't just
FPLs. Smalltalk, for instance, got some mileage out of finance
sector success stories. Happily, there is at least one showcase
with some documentation:

    http://www.cincomsmalltalk.com/main/successes/financial-services/jpmorgan/

if you don't see the pdf there, it is

     JPMorgan Derives Clear Benefits From Cincom SmalltalkT
    http://www.cincom.com/pdf/CS040819-1.pdf

Comparing the claims in there (attributed to Dr. Colin Lewis,
Vice President, JPMorgan) with similar ones in Haskell success
stories might yield some clues:

"With such a high productivity factor
that Smalltalk gives us, reaction times to
market changes have enabled us to
beat most of our competitors."

"We have estimated that if we had built
Kapital in another language such as
Java, we would require at least three
times the amount of resources."

"The key is that our development
resources do not have to be Smalltalk
experts."

Now a benchmark game comparing financial success of
Haskell, Smalltalk, Java, .. -backed companies, that would
be something. But it would still not account for the quality
of programmers that came with the language.

Claus
 


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: why are trading/banking industries seriously adopting FPLs???

Vasili I. Galchin
In reply to this post by Neil Davies
Hi Neil,

    Can you go into more detail about the intrusion detection software you wrote, e..g how it used iteratees and DSLs(even not directly impl. in Haskell)??

Thanks,

Vasili

On Fri, Mar 25, 2011 at 3:09 AM, Neil Davies <[hidden email]> wrote:
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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe



_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: why are trading/banking industries seriously adopting FPLs???

Albert Y. C. Lai
In reply to this post by Vasili I. Galchin
On 11-03-25 03:08 AM, Vasili I. Galchin wrote:
>       I am very curious about the readiness of trading and banking
> industries to adopt FPLs like Haskell:

Not only FPL and not only Haskell, but also descendents of APL such as
J. Generally also any innovation.

Why are they willing to try out innovations? Because they can assess the
risk and the probable benefits of trying out another innovation, and
they can contain that risk. They know how to be prudent without being
overly conservative.

Why can they assess the risk and the probable benefits of trying out
another innovation and can contain the risk? Because they can do that of
almost anything. They are surviving investors. Trying out another
innovation is just another investment, not unlike trying out another
stock, another bond, another estate.

Why can the computer security people not do the same? Because they are
debuggers, not investors.

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: why are trading/banking industries seriously adopting FPLs???

amindfv
Why can they assess the risk and the probable benefits of trying out another innovation and can contain the risk? Because they can do that of almost anything. They are surviving investors. Trying out another innovation is just another investment, not unlike trying out another stock, another bond, another estate.

Why can the computer security people not do the same? Because they are debuggers, not investors.


I agree with this point, but I think it could be said to have as much or more to do with the qualities of the field, as the qualities of people in the field.

     Finance and trading are extremely quantifiable fields. An increase in speed of execution can fairly accurately be assigned a dollar value in ways that a field like compute security can't. 

     Reasoning about the payoff of switching to another technology becomes harder. Even after a technology has been successfully adopted, it's hard to say what the payoffs were! A political climate, where ideas are more assailable, arises, and people huddle under the shelter of what's commonly accepted. "Quant" people might do the same, if they were in that type of climate.

     In finance, you hear a lot more of "Don't believe me? Fine. The results will speak for themselves." 

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: why are trading/banking industries seriouslyadopting FPLs???

Richard A. O'Keefe
In reply to this post by Claus Reinke
Smalltalk and Haskell share an interesting property:
they support integer and rational calculations without arbitrary limits.
Recording money in cents, 32 bits gives you ±$21,474,836.47, which is
not a large sum of money to the industries in question.  OK, 64 bits
effectively solves that problem, but 64-bit arithmetic hasn't been
available in "mainstream" languages all _that_ long.

Of course Java provides BigInteger, but not using the same notation as
ordinary integer arithmetic.  If you are keen on code review, code that
you *can* review is important.

Smalltalk and Haskell share another property:
higher order functions.  I was profiling some Smalltalk code the other
day and the call stack was regularly about 28 levels deep, thanks to
lots of reusable control structures with little lambdas plugged in.

It's not _that_ much of a stretch to see Haskell as a strongly typed
version of Smalltalk, without the pervasive mutability.

There's one enormous difference between Haskell and Smalltalk.
If you push hard on a Smalltalk library, whether it's a free
Smalltalk like GNU Smalltalk or Squeak, or a commercial one like
[I'd better not say], you will find code designed for the *usual*
case that doesn't actually work in all the cases you might expect.
For example, try
        h := Heap withAll: #(3 1 4 1 5 9).
        h addAll: h.
There's nothing inherent in Smalltalk that means this _couldn't_
work; in my Smalltalk it does.  But that's because I thought about
it, instead of taking the usual view "the programmer ought to know
better than to try that."

I'd expect big-money companies that liked Smalltalk to like
stricter/safer functional languages even better, given a good
development environment.



_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe