No subject

Thu Jul 5 12:38:43 CEST 2012

supposed to be spread out over several days or weeks, but were spread over
hours instead. So, if that were true, no type system would be of any help.

The US Navy had a similar problem on a propulsion control system back in
1995/96, where all consoles went into blue screens of death and the cruiser
in question had to be towed back to port from ~15 nautical miles off shore.
In the root cause analysis, it turned out that a particular form field
should never have been allowed to take on the value zero, which ended up
causing a NT kernel crash in a control system driver. Moreover, the bad
value was replicated across all control system machines, thereby crashing
the entire control system.

Job number one in a US Navy engineering department: keep the props
rotating. If the ship has propulsion, it can do things, like get out of the
way of danger.

Faults occur for a variety of reasons.


On Sat, Aug 4, 2012 at 12:14 PM, Steve Severance
<sseverance at>wrote:

> Actually Haskell is used in a surprising number of trading groups. However
> most people involved are contractually obligated to never talk about the
> technology in use at their firm. We make no secret that we use Haskell as
> our primary language in building trading systems. Other functional
> languages, notably F#, have seen significant uptake as well.
> As to whether Haskell should/must/could be used an a particular system
> much of this choice (non-technology influences aside) is going to be bound
> by speed. As Knight is a market maker I would expect that the stock choice
> for rapidly evolving software is c++ on the intel compiler with a
> significant amount of strategies running on ASIC and FPGA. The reason being
> is that many strategies are relying on latency as a primary input to their
> success.
> We have the advantage of not being latency bound and we place a great
> amount of emphasis on correctness. We accept the fact that if we want to
> run latency bound strategies most of our runtime stack would be useless. If
> they had been using Haskell would they have still had whatever problem it
> was? At this point completely unknown. However the real world is a messy
> place and sometimes even haskell code has bugs.
> Steve
> On Sat, Aug 4, 2012 at 3:06 AM, Ketil Malde <ketil at> wrote:
>> "Vasili I. Galchin" <vigalchin at> writes:
>> >     I am going to make an assumption .... except for Jane Street
>> > Capital all/most "Wall Street" software is written in an imperative
>> > language.
>> Tsuru Captial and Standard Chartered are also known to hire functional
>> programmers.
>> >     Assuming this why is Wall Street not awaken to the dangers.
>> As an explanation, this is a bit simplistic, I think. But I think the
>> reason these companies are willing to use experimental technology (as
>> Haskell is considered to be in industry), is that the consequences of
>> error can be so high.  For most mainstream software, users have been
>> trained to accept unreliability, and/or are not willing to pay the
>> costs.
>> Other examples of expensive software faults is the Ariane 5 launch and
>> the Sleipner A oil rig (that collapsed and sunk when in tow due to a
>> mistake
>> in FEA strength calculations).
>> The space (and defense) industry have a long history of working towards
>> software security, but I think they have focused more on the software
>> process than on technology - ADA notwithstanding.  And probably rightly
>> so, even though technology can help you write correct code, there is
>> still plenty of rope.
>> -k
>> --
>> If I haven't seen further, it is by standing in the footprints of giants
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at

Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

More information about the Haskell-Cafe mailing list