> Since then, available memory has grown rapidly and I have
> heard of APL compilers. =A0I am curious as to the reaction
> of experts on APL =A0- to the book and the issues raised.
I have just read the pages you mentioned...
The guy basically talks about APL being bad at loops ( ;-)... which he
says is bad news for the finance-environment in which APL was used at
MS and UBS ... and then goes on to say we are a "cult" ;-)
He also mentions Arthur Whitney and A+ whilst talking about Morgan
Stanley and UBS APL shortfalls, saying that because APL is an
interpreter language, the loops ( needed for recursive swaps pricing
etc. ) cause code to be repeatedly "re"-interpreted, thus slowing up
the system considerably.
Strangely enough, A+ is actually a pseudo APL compiler and executes
loops (if needed) VERY quickly.
He mentioned that UBS lost 100's of millions by not being able to
price/hedge their swaps/options properly - due to APL's short-comings.
He actually blames the language rather than the application
programmers, which makes me suspect that he may have other motives ...
unknown to me.
AFAIK, Deutsche Bank has/had an excellent swaps system written in
Sharp APL, which functioned perfectly for ca. 20 years .. without all
the hitches he talked about !
Also, he said that due to a differences in the "Calendar"
functionality between their APL system and their back-office, certain
trades were simply "forgotten" and not executed. Well, if you ask me,
it sounds more like an application-programming problem rather than an
APL problem !
I'll be reading the whole book soon; interesting to see what else he
says !
;-)
FWIW
|
