Databases are bloated

http://martinfowler.com/bliki/MemoryImage.html

No database, no filesystem, single-level store with database-like characteristics is the ideal computer model. Look at the System/38 and its descendents the AS/400 / iSeries / i for one of the best computers ever designed. "Files" could be accessed from assembly language as easily as any other memory space. Instructions were extremely high-level, late-binding, type-generic and translated ahead of time from a template. But even in 1978, these technologies weren't exactly new. It's only because the PC-compatible world is 40 years behind the mainframe/minicomputer/high-end workstation world in terms of technologies, its growth stunted by combining the worst operating system of all time with the worst CPU architecture of all time.

>>2
Lisp was shit.

http://martinfowler.com/articles/lmax.html
This is a more interesting read. About 1Kclk per transaction, or several hundred instructions per transaction. For a Java program.

It also uses event handling reminiscent of how interrupt handlers are written for low latencies.

Cool story bro.

Basing a trading system on JVM is like basing a web site on PHP.

>>6
Common practice?

>>7
Creating a world of pain and shit

>>8

Yeah, I mean, like why would a trading system need to be multiplatform? LOL

>>9
I hope you're not being sarcastic. A trading system doesn't need to be multiplatform, as it runs on the servers, not the clients.

>>10
it was two layers of sarcasm.

>>11
It's like ROT13, you need to apply at least two layers or it's not effective!

>>9
It's less of a pain to switch to a less shitty OS.

Assume your TS devs are faggots and insist on Solaris. You'll forever be found to Solaris, even though $otherOS has far better network I/O handling or something like that.

Additionally, Java is known to most developers in an ENTERPRISE environment, and given that today's developers are worthless, it's best to do something they're familiar with.

>>12
dats right!