This article conflates OO and strong typing a little too much. These are too very different things, but agree that the combination can cause problems, not to mention that so many Java architectures are pathological in terms of struggling to find the code that actually does something.
Clojure at a Bank – Moving from Java (2012)
51–60 of 68 posts
Re: Clojure at a Bank – Moving from Java (2012)
#52I always thought critical applications like banking needed compile time type checking. Clojure is neat and all, but it's dynamic.
I know at least 3 of the largest banks hevily use Python http://www.reddit.com/r/Python/comments/1ohpyt/how_and_why_b... Not to say they don't use Java as well various other languages, but right tool for the job...
Interesting.
Bank of America was supposed to have gotten heavily into Python a couple of years (or more) ago. I had blogged about it here at the time:
http://jugad2.blogspot.in/2013/10/bank-of-america-to-rebuild...
and Niall O'Connor from the bank (who spoke at PyCon IE 2013 - http://python.ie/pycon/2013/speakers/niall_oconnor/ ) confirmed via a comment on my post, that they were not "beginning" to do it, but that it had "already happened".
Edit: The reddit thread quoted by the parent comment, also mentions BoA and Niall.
Re: Clojure at a Bank – Moving from Java (2012)
#53Earlier quoted context omitted.
I know at least 3 of the largest banks hevily use Python http://www.reddit.com/r/Python/comments/1ohpyt/how_and_why_b... Not to say they don't use Java as well various other languages, but right tool for the job...
Interesting. Bank of America was supposed to have gotten heavily into Python a couple of years (or more) ago. I had blogged about it here at the time: http://jugad2.blogspot.in/2013/10/bank-of-america-to-rebuild... and Niall O'Connor from the bank (who spoke at PyCon IE 2013 - http://python.ie/pycon/2013/speakers/niall_oconnor/ ) confirmed via a comment on my post, that they were not "beginning" to do it, but that it…
Goldman's core risk management system (SecDB) is written in python, as is JPMorgan's Athena and BofAs Quartz. I believe the main people responsible for SecDB implemented Athena at JP and then Quartz at BofA.
Re: Clojure at a Bank – Moving from Java (2012)
#54One of the reasons I went with Scala instead of Clojure is that you don't "just have to make a jump". You can write one class, in code that clearly corresponds 1:1 to what you'd write in Java, and the interop is smooth enough that other classes don't notice that this class is in Scala. Later on you (hopefully) are writing a very different style of code, more declarative and immutable and putting much more of the busi…
I think you missed the overall point of the author, which was that in order make a significant improvement at all, you need to make a radical shift in the modelling of the system. One of the problems mentioned was the inherent complexity of using a type system for modelling data. Scala is very type oriented and so as a result you will end up with a lot of types for everything there as well. Yes it's certainly easier…
As I read the article, though, it's not just types. The fundamental problem was that nobody there had a good idea how to architect a Java application that large. So they threw out the Java, and replaced it with Clojure, which they had even less experience architecting. Sure, Clojure may have resulted in 100,000 lines instead of a million, but that's still a large enough system that architecture matters. Did they create another large mess? It seems reasonably likely that they did.
Java's types aren't broken enough to force you into a terrible architecture. Trying to use them badly (that is, in the way that everybody seems to think that you're supposed to use them for enterprise apps) seems to be the actual culprit.
Re: Clojure at a Bank – Moving from Java (2012)
#55Earlier quoted context omitted.
Interesting. Bank of America was supposed to have gotten heavily into Python a couple of years (or more) ago. I had blogged about it here at the time: http://jugad2.blogspot.in/2013/10/bank-of-america-to-rebuild... and Niall O'Connor from the bank (who spoke at PyCon IE 2013 - http://python.ie/pycon/2013/speakers/niall_oconnor/ ) confirmed via a comment on my post, that they were not "beginning" to do it, but that it…
Goldman's core risk management system (SecDB) is written in python, as is JPMorgan's Athena and BofAs Quartz. I believe the main people responsible for SecDB implemented Athena at JP and then Quartz at BofA.
SecDB is not written in Python (unless things have changed recently). However both Athena and Quartz are heavily influenced by SecDB.
Re: Clojure at a Bank – Moving from Java (2012)
#56I always thought critical applications like banking needed compile time type checking. Clojure is neat and all, but it's dynamic.
Clojure supports strong typing if you want it: https://github.com/Prismatic/schema https://github.com/clojure/core.typed These are both libraries that you can choose to use. Both Typed Clojure and Schema are more powerful than Java's type system. By powerful I mean you can declare types and constraints that aren't expressible in most type systems (eg: an object can not be NULL, or a Map or Array must have specific ke…
By powerful I mean you can declare types and constraints that aren't expressible in most type systems (eg: an object can not be NULL, or a Map or Array must have specific keys or type'd values)
Hmm. Can it do anything better than that?
Java has optional nullity annotations that tools like Findbugs and (more usefully) IntelliJ can use to highlight nullity bugs. Kotlin has nullity integrated into the language's type system in a much better way. Stating that a Map or Array must have specific types in it is the whole purpose of generics, which Java had since 1.5, no?
Don't get me wrong. The Java type system is not that strong and has some frustrating holes in it. But typed arrays and nullity tracking doesn't seem like some advanced Clojure-only tech, to me.
Re: Clojure at a Bank – Moving from Java (2012)
#57I always thought critical applications like banking needed compile time type checking. Clojure is neat and all, but it's dynamic.
I always thought this was what SPARK/Ada was for, along with one of the real-time OSes. But it turns out that languages with the stick that far up their backsides are only used for actually critical applications, like air-traffic control, medical implants, crypto libraries, and spacecraft/satellites.
If a banking program fails, they can just ask for a mulligan from the central bank/government. They're just playing with people's life savings, not any actual lives, right?
If they're going to suck up all the best brains in the industry anyway, they ought to be able to do SPARK/Ada.
If I were making banking/trading software, I'd start with an OS that combined the security paranoia of OpenBSD with the deterministic performance of LynxOS, build some tools that validate source code by automated proof rather than testing, and hire a bunch of people smarter than me to build software that is secure, reliable, and profitable, in that order. No bank in existence would be crazy enough to pay me to try.
Re: Clojure at a Bank – Moving from Java (2012)
#58I always thought critical applications like banking needed compile time type checking. Clojure is neat and all, but it's dynamic.
I've been trying to come up with a common definition for language safety, and in scoring both C# and Clojure, Clojure came out a much more "safe by default" language.
It's incomplete, but here is where I'm gathering the data: https://github.com/steveshogren/blog-source/blob/master/sour...
Re: Clojure at a Bank – Moving from Java (2012)
#59It would be great to see examples of the design/modeling of the system. I really like functional languages have done since my university days, but there seems to be a dearth of examples on how to actually lay such large projects out in Clojure/Scala etc.
Having something like the J2EE Petstore (for all its sins) would go a long way to allowing more projects to make the switch than more articles on how great things are.
Re: Clojure at a Bank – Moving from Java (2012)
#60I always thought critical applications like banking needed compile time type checking. Clojure is neat and all, but it's dynamic.
Note that one of the largest and reliable systems -- smart phone to internet gateways often run Erlang, another functional and language with dynamic (but strong) typing. So when you watch cat videos on your smart phone, there is about 50% some non-statically compiled functional code has done its job in setting up the necessary signaling. WhatsApp has also recently been the poster child for running a successful distri…
I think the WhatsApp Erlang angle is a bit overblown.
While they may have a small number of engineers (20 or max 20?), their engineers are probably laser focus in delivering the product (re: no web-app for the longest of time, no RoR vs Django vs Clojure vs Java vs PHP, no React vs Backbone vs etc etc), just back-end: Erlang, front-end: various phones that needed to be supported.
I would attribute their success at their skill set and experience. If you watch Rick Reed presentation in MeetBSD, a few key points to note: Rick Reed is very smart and knows full-stack (minus the browser): from the OS (internal, driver, etc) up all the way to Erlang VM and the WhatsApp backend.
The team had to modify FreeBSD and patch Erlang VM whenever necessary. How many companies have _that_ kind of talent? (e.g.: modify Linux and JVM to make them run faster? or Ruby implementation and PostgreSQL/MySQL while supporting the actual product?). Rick himself has tons of experience writing distributed systems at Yahoo! (using C++ nonetheless...).
While Erlang helps them but in reality, their skill + experience matter more.