New trading systems platform

[Richard A. O'Keefe]

James Hague <james.hague@REDACTED> wrote:
	Much financial work like this is done in array languages, like K
	(http://www.kx.com) and J (http://www.jsoftware.com).  They're
	designed to churn through large data sets quickly.  J is free, so one
	conceivable option is to communicate with a J process from Erlang, but
	that may be too roundabout.  J will make your head explode.
	
For an open source array language which is pretty good at number
crunching and superb at graphical presentation of results, has an
extremely active user community, lots of books, *and* use in econometrics
amongst other disciplines, you can't go past R (http://www.r-project.org).

	Honestly, I'd like to see some basic tuple math added to Erlang, but
	this clashes with the sensibilities of some people.  For example:
	
	   1 + {1,2,3} -> {3,4,5}
	   {1,2,3} + 1 -> {3,4,5}
	   {1,2,3} + {10,20,30} -> {11,22,33}
	   2 * {1,2,3} -> {2,4,6}
	
What should {1,2} + {10,20,30} do, and why?

	I don't think this would be that hard to hack into the emulator.
	
Erlang is a language with run-time types, not compile-time types.
In such a language, *in*compatibilities between built-in types and
operators are to be cherished, not discarded, lest errors go unreported.
The difficulty of hacking a feature into the emulator is not the real
issue, but conceptual integrity and the effect on other uses of the language.
It might, for example, be better to introduce a whole new "array" data type;
that would be much more work, but it could yield better performance (using
long-known techniques from APL) without sacrificing any of the run-time
type checking we now have.