Here's the video from his talk at EuroClojure 2012
Clojure at a Bank – Moving from Java (2012)
21–30 of 68 posts
Re: Clojure at a Bank – Moving from Java (2012)
#22Note this was from 2012, and the author no longer works there - I wonder how this system developed in the intervening years?
> I wonder how this system developed in the intervening years?
It probably developed into a great opportunity for consultants.
Re: Clojure at a Bank – Moving from Java (2012)
#23I always thought critical applications like banking needed compile time type checking. Clojure is neat and all, but it's dynamic.
Most of the times, they don't. Static typing helps with catching certain types of errors long before the compiled code arrives in production but it's just one tiny factor that contributes to overall software quality. Lack of expressiveness or lack of developer happiness can be much more detrimental to software quality than lack of static typing.
> Lack of expressiveness or lack of developer happiness can be much more detrimental to software quality than lack of static typing.
Except 5 years later, when the happy developers have gone on to express themselves elsewhere, and left behind them a mess. Now, you can make a mess in any language, but a mess in a dynamic language is considerably harder to refactor.
I also dispute the claim that a strong type system is a "tiny factor" in code quality. Being able to express invariants with types makes code much robust, and self-documenting.
Re: Clojure at a Bank – Moving from Java (2012)
#24One 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 business logic into the type system. But it doesn't have to be a big-bang switchover; you can be productive from day 1, hour 1 even.
Re: Clojure at a Bank – Moving from Java (2012)
#25Earlier quoted context omitted.
Most of the times, they don't. Static typing helps with catching certain types of errors long before the compiled code arrives in production but it's just one tiny factor that contributes to overall software quality. Lack of expressiveness or lack of developer happiness can be much more detrimental to software quality than lack of static typing.
I second this. I'm currently creating a new dynamic website, which will see around 10k users a day. We could have done it in a week with rails scaffolding capabilities and the vast gem environment, but we are doing everything manually in Scala, because type safety and performance. It's so frustrating that I'm looking forward to quit very soon.
This is a weird complaint.
The fact that Rails has scaffolding and whatever Scala framework your team uses doesn't has little to do with type safety (there are plenty of web frameworks in dynamic languages without scaffolding as well).
There are several languages which require a comparable amount of typing to a dynamic program, while adding considerable type safety.
Re: Clojure at a Bank – Moving from Java (2012)
#26I 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...
Re: Clojure at a Bank – Moving from Java (2012)
#27I always thought critical applications like banking needed compile time type checking. Clojure is neat and all, but it's dynamic.
I'd feel better building complex financial system in Clojure rather than C# (the 2 languages I'm most familiar with at this point).
With contractual based programming, pre/post assertions, schema validation, etc... you can add all the type checking you want. That along with the other well known benefits of functional programming I think would make it highly desirable to build large complex systems in.
Re: Clojure at a Bank – Moving from Java (2012)
#28Earlier quoted context omitted.
Most of the times, they don't. Static typing helps with catching certain types of errors long before the compiled code arrives in production but it's just one tiny factor that contributes to overall software quality. Lack of expressiveness or lack of developer happiness can be much more detrimental to software quality than lack of static typing.
Exactly. Not to mention that in any large scale system your functional and integration tests are the most useful for producing high quality software than simply having static types.
No-one is arguing that you should just have static types and nothing else. The argument is that static types and testing are better than just testing. After all, static types are a kind of test that the compiler verifies for you, leaving you free to focus on the rest of the tests. I'd say in any large scale system, dynamic typing is a risk (though there are ways of mitigating this risk, of course).
Re: Clojure at a Bank – Moving from Java (2012)
#29One 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…
And what did you gain?
What I found is writing Scala that is not striving for ~100% immutability and functional style does not bring much benefit. It is just a different syntax, that is nicer than Java on one hand, but also big and not straightforward on the other (in the C++ sense, so 'Scala' does not have a conventional coding style, it ranges from Java to Scalaz). Also, making core 'half-functional' does not bring any benefits in terms of composability, concurrency, reasonability (about the code).
That's why I am pro Clojure.
Re: Clojure at a Bank – Moving from Java (2012)
#30Earlier quoted context omitted.
The verbosity of Java isn't necessary in all statically-typed languages. For instance Haskell is no more verbose than, say, Python, and has an even more expressive static type system than Java.
I didn't mean to imply that the verbosity/complexity of their original code base was caused by the type system. The article is light on details, so we can only speculate: maybe they'd be better off with Haskell but just failed to consider it, or maybe they considered all options and decided it would be easier to retrain their team and integrate with the existing code based if they used a JVM Lisp. What is clear is th…
I agree with you that a smaller, cleaner codebase with less boilerplate probably leads to better software, regardless of type system.