Live data from Hacker News

Clojure at a Bank – Moving from Java (2012)

pitheringabout.com

61–68 of 68 posts

Re: Clojure at a Bank – Moving from Java (2012)

#61

UBS has a bit of a reputation for this. Same thing happened with their US Equities tech in the mid 2000s: 1) Bring in new blood to improve a legacy platform 2) The new blood decides to throw out everything and do a complete rewrite 3) The new system is super successful because it can focus on a much smaller subset of problems 4) The bank runs into profitability issues and can no longer pay developers well 5) The good…

6a) .. because instead of using a language designed in part to address turnover and difficulty of keeping avant garde coders in banal and soul sucking jobs, the management passed the business decision of "what tools do we use?" to the said workers.

On the other hand, the language chosen might ensure high turnover of the sorts of coders you'd really like to keep, assuming you could ever attract them in the first place.

Management has choices here, including simply making the best business will stay good enough, or even if it doesn't, prioritizing keeping an essential core of its technology people short of anything but completely closing down the unit.

One thing I've noticed that's very common in the long term success or failure of high tech companies is whether they kept their core technologists. Compare Microsoft to Lotus and perhaps Ashton-Tate (dBase). Companies like banks may not appear to be "high tech companies", but their "production" is done with computer systems so....

Re: Clojure at a Bank – Moving from Java (2012)

#62
post #53

Earlier quoted context omitted.

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.

It's written in their own Slang language: http://stackoverflow.com/questions/3392636/slang-goldman-sac...

And the whole system is in part credited with helping them survive the recent financial crisis ... although simply listening to their risk people was more important. But it's all intertwingled, I'm sure, because good risk people would want a system like SecDB so they know the company's positions in quasi-real time with a great deal of assurance vs. hours and days and through e.g. scraping spreadsheets, often manually, etc.

Re: Clojure at a Bank – Moving from Java (2012)

#63
post #15

I love this quote in the comments: > when you have REPL you are TDD’ing in a different way as opposed to constructing persistent unit-test classes that could potentially form a layer of cement. Lately I've been using the console for development in rails and javascript more than anything and it is a really good way to iterate on a solution quickly.

Bingo.

Especially in a functional language, if you architect your code well, e.g. avoiding large (lengthy) functions. You write a function, test it in the REPL, and forget about it. Until, of course, someone hands it data you weren't expecting. But here Clojure helps you a bit with it's effort to provide consistent interfaces to its collection types, e.g. lists, vectors and maps. And the most expressive and fast to write code in, the more time you can devote to testing.

I'll bet in practice this sort of TDD works very well, as long as your coders are diligent. For the projects I've done this way, including a couple in C using a very good but now defunct interpretive environment for it (CenterLine's CodeCenter/ObjectCenter), it's been superb. In an extreme case, I spent around a week programming in C the engine of a high speed document imaging scanning system, at which point I got the driver that let me speak directly to the scanner. The first time I tried it end-to-end it worked ... until I ran out of file descriptors (had forgotten to close() each file after writing out its contents).

There was of course a whole lot of experience that made that feat possible, but I found it very impressive how the environment allowed me to write code with so few flaws (that was, in fact, the only major one I can remember once I declared a function finished and ready to try out for real).

Re: Clojure at a Bank – Moving from Java (2012)

#64
post #2

I 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 wi…

Above a certain level I don't think your thesis is currently valid.

For a "bank bank", "playing with people's life savings", the lower level transnational stuff, yeah. Although I don't get the impression that the current stuff doing that is prone to disastrous failures, and I believe the system has some slack here and there to reverse errors, i.e. transfers of money vs. buying and selling financial instruments. The current infamous failure in this area, which was WRT to the latter, was at Knight Capital.

But above a certain level, at which point we're not so much "playing with people's life savings" (or, rather, if they have a clue, only a small portion of them), the situation can be a lot more fluid. E.g. changing trading strategies, which can be driven by the capriciousness of governments. The current state of the art doesn't make it practical to embed the US tax code into source code amenable to automated proof, especially before it changes again, right??

Re: Clojure at a Bank – Moving from Java (2012)

#65
post #61

Earlier quoted context omitted.

6a) .. because instead of using a language designed in part to address turnover and difficulty of keeping avant garde coders in banal and soul sucking jobs, the management passed the business decision of "what tools do we use?" to the said workers.

On the other hand, the language chosen might ensure high turnover of the sorts of coders you'd really like to keep, assuming you could ever attract them in the first place. Management has choices here, including simply making the best business will stay good enough, or even if it doesn't, prioritizing keeping an essential core of its technology people short of anything but completely closing down the unit. One thing…

> On the other hand, the language chosen might ensure high turnover of the sorts of coders you'd really like to keep, assuming you could ever attract them in the first place.

I'm sure Bell Labs never had that problem :) I was reading someone's PhD dissertation on Chill [1] and what was interesting to note was how many of the players ended up outsourcing their software development to 3rd parties.

Software is hard.

There other day I was talking with someone in tech management from a national chain (think malls). They are rolling their own commerce platform since "nothing" out there can satisfy their ecommerce requirements. I didn't say this upfront -- a potential client -- but the idea that this chain will actually get into serious software development, develop an A team, and keep them, is complete and utter wishful thinking.

My advice to anyone running a non-tech company is own the data and the apis and off load the rest to a[n] actual tech company.

[1]: http://web.bi.no/forskning/papers.nsf/0/42215f66b6282965c125...

Re: Clojure at a Bank – Moving from Java (2012)

#66
post #24

One 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 would argue that Clojure-Java interop is better than Scala-Java. E.g. Clojure's collections are Iterable, can be used in Java without conversion. 'reify' and protocols are other good things in this area.

Keeping old programming style sure allows to lessen frustration compared to diving right into working with immutable collections but the difference won't be that big if you are learning anyway.

Re: Clojure at a Bank – Moving from Java (2012)

#67

Earlier quoted context omitted.

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 sy…

If you're interested in learning about them, those two links are going to do a better job of explaining what both Typed Clojure and Schema are that I am across a few comments.

Wrt the typing of Maps and Arrays, what Clojure supports goes way beyond what Java's type system supports: you can specify that the first element of an array has to be of type X, the second is of type Y, the third can be either NULL or Z. For maps, you can specify that a key must have a particular type and must be in the map, with a specific value while other keys may be present (required or not) and you can compose any of the constraints mentioned on the values the keys may take.

This is different from Generics in that Generics constrain to homogeneity for an entire collection.

You could create formal objects in your Java code to express similar constraints, but you're not achieving the same result: a Java object actually has the property (even if it's null) while a map (or an array) with an optional member will only have it if it's present. With Java you'd need many classes to model all the specific combinations. Java's current type system is significantly less expressive and doesn't have the same power. I realize those are subjective. By expressive and power I am referring to whether you can declare an idea in your code or whether you have to write the imperative logic to implement an idea (the former meeting my definition of expression or power).

Thanks for the question.

Re: Clojure at a Bank – Moving from Java (2012)

#68

Earlier quoted context omitted.

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 sy…

The Null annotations approach runs into problems quite fast, though. How about a list of values? How do you annotate that the values are not null? How about a list of lists?

Quickly you discover you need a type system. (I'm not familiar with Kotlin but I'm sure it's fine.)

The answer is that core.typed's type system is proper space-age tech, but it's also not exactly ready for production use.

Post reply on HN