So I often think that Steve Yegge is 1/2 full of it – sorta like I think about Joel Spolsky, but I just read Steve’s latest here and I think there is some good wisdom in it. It is a diatribe against big codebases. I agree wholeheartedly. Turning a big codebase is a problem, and code grows and grows unless you make it not.

I have been doing toy projects and random scripting tasks for real work for the past 3 or so years with ruby – and less often – python. I also started off doing javascript on the server and client in the later 90’s – wrote lots of apps that way. I have also done a lot of C# programming, a good bit Java programming, some C/C++ programming, tons of SQL, little perl, little VB, VB script – niche languages like TradeStations scripting language, etc, etc. I must admit – I want to like python more – I do like it – but I am drawn – as I think many are – to ruby. I still think JavaScript is viable – but I believe ruby wins in the elegance and zen departments.

Dynamic languages and VMs solve many issues

With all of this behind my past ~10 odd years of programming – I have reached the code bloat conclusion like Steve and the other folks he speculates that have (Gates, Fowler, etc.). I think dynamic languages have a lot to offer in this space. I also agree – as many have that the virtual machine thing makes sense (use the CLRs, JVMs and other VMs of the world).

So – I want dynamic languages to reduce code sizes – and I want VMs. I also NEED to deliver business value because I am focused on delivering software in the trading/ automated trading domain. THIS is the real focus. So – how do we make steps today in an investment bank to get there. We NEED VERY VERY interactive/ performant, highly integrated apps for trader desktops. Our server applications need to be astoundingly performant. We have many C++ server side apps – but there are also lots of java apps – likely more. Our clients are windows clients and we must have desktop apps – still – in my opinion due to the integration, performance and interactivity demands of our users.

WPF and IronRuby on the client

WPF does seem like a step forward from windows forms. The new idioms work, XAML is better than procedural ‘designer generated’ code. GDI drawn works vs N-zillion window handles/ native controls. C# is a good language – but it does suffer from static typing constraints – and it suffers from the drive to bloat. IronPython is moving on – and it is real. IronRuby is what I want to be ready – with the Microsoft.Scripting DLR. So – I think that IronRuby over WPF is honestly a step forward. I have been ‘trying to get off the XML’ for a year and a half I think. XAML is still bettern, despite the desire to get off the XML

JRuby on the server

So – there is my honest view on the client. Now – JRuby is close. Real server apps in Ruby on the JVM is a step in the right direction – if we can get the performance up where it needs to be. We get all the reuse of the well spent years building java componentry and we get to still author 100% interoprable components in Java where we need/ are forced to (yes we will be forced to at times).
This gives us ruby on the server and the client. This reduces our code bloat issue. This can also homogenizes the language on the server and the client. It is a shame that Java desktop apps did not take off as much as MS’s own – but I honestly believe WPF adds the most business value. Best possible user experience, least code.

Compiled – Interpreted ?

If we have the option to compile or run interpreted – we would also have some big wins. Sometimes – I will want to compile (and pre-jit compile) my code – sometimes I want dynamic. These options will allow us to do what we need when we need. This is a benefit of running in the VMs of the world that allow it.

Missing Links

1. It will REALLY be all about the unit/ integration tests. If we do not get ‘compile time safety’ – we WILL rely on MUCH higher levels of unit tests. Unit tests are better than ‘it compiles’ anyhow – but we will RELY on unit tests.
2. Developer skills gaps. In the forms of learning unit testing better, learning ruby, learning WPF, learning how to program in languages that are not C++, Java and C#.
3. The things we still do in C++ because speed REALLY matters. Fast message speeds, compute farms, lots and lots of data per millisecond, real time systems, etc. These areas are VERY important. The still do not represent the lions share of software that has to be written. UIs do not need to be written like this – only small parts. Many server apps do not need extreme real-time capabilities/ capacity. For the ones that do – we need to still have extreme interoperability.
4. Not enough REAL 3rd party componentry in WPF yet. Winforms and MS’s prior MFC/ Active X worlds have eons of components. WPF must – and will mature here.
5. DLR ain’t done. IronRuby ain’t done.
6. JRuby performance just gettin’ there.
7. There will always be less componentry/ tooling for non-mainstream programming languages.
8. IDEs are just not there yet for Ruby + WPF.

Conclusions

There you go – I really believe the above model will let us deliver more business value. That is what it is all about. This is where we need to go. I hope that I am able to execute this vision soon and bypass a lot of the prices we need to pay to play NOT in this model. This can actually be a legitimate edge.

-Chris

You can leave a response, or trackback from your own site.

US market killed yesterday after FOMC

Greenspan rocks and the Bush administration is bad

The Age of Turbulence: Adventures in a New World – excellent book

Netbeans Ruby IDE is nice as can be

I think I like it more than the IntelliJ Ruby plugin. I think development with JRuby and Netbeans is very compelling!

F# feels almost real in Visual Studio

Empirical Market Microstructure: The Institutions, Economics, and Econometrics of Securities Trading is a fantastic book

A Demon of Our Own Design: Markets, Hedge Funds, and the Perils of Financial Innovation was also a fantastic book

You can leave a response, or trackback from your own site.