TSSJS Day 2

I want to cover 3 sessions on the secion day

Languages-Oriented Programming: Shifting Paradigms
Computer languages evolution enables us to pave over disturbing problems (e.g. GC as a mechanism to pave over error-prone memory allocation, Neal Ford introduced a very important observation.. One of the most powerful aspects in Java platform is the community and the amount of open source frameworks. This creates a new problem to pave over. Each framework has its own jargon and adapting this to the java language leads to a complicated syntax which usually is very wet (not DRY – Don’t Repeat Yourself). Niel offer the use of DSLs to approach this problem. In other words frameworks will be transformed to a carefully designed DSL. AntLR as a lexical analyzer and environments like Jetbrains MPS can help reaching this with less efforts.


Extreme Transaction Processing, Low latency and performance
John Davis a banking expert gave a startling session on design criteria in the online trading arena. In this world a 1ms delay in processing a message can lead to losses of $100M. As a result for example banks try to locate the trading infrastructure as close as possible the trading backbone (usually in London) in order to reduce latency. In addition GC can be a real problem we are used to think of GC taking 200ms as something reasonable but again it is x200 from the 1ms threshold. You do not want to loose money on GC. This leads to weird solutions such as restarting the VM before the first GC and redirecting to a different cluster member in the meanwhile. Another point mentioned is that traditional RDBMS are not capable of handling tens of thousands of transaction on a reasonable price. The solutions will be to use in memory databases or caching mechanisms (e.g. GigaSpaces, Oracle Coherence, Terracotta etc… )

Concurrency and High Performance
Kirk Pepperdine session had an important punch-line. Processors clock speed is stuck at the 3Ghz boundary and this situation is not likely to change in the near future. CPU vendors are going to achieve Moore’s law by doubling the number of cores every 18 months. This is a fact developers can’t afford to ignore. Leading to the inevitable conclusion (punch-line ahead) Is your application ready to double it’s concurrency in the next 18 months?