Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Clojure at a Bank – Moving from Java (2012)

pitheringabout.com

Post reply on HN
Print view View original

31–40 of 68 posts

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

#31

Post by liviu- »

mercurial wrote: post #23
BjoernKW wrote: post #4

Earlier 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.

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

>I also dispute the claim that a strong type system is a "tiny factor" in code quality.

There actually are some studies that show that using a static typing system is only a tiny factor when it comes to code quality:

http://wadler.blogspot.co.uk/2011/09/experiment-about-static...

However, I've also read studies that show the opposite, but the lack of rigurosity and the possible confounds that show up for both sides seems to render this as an open question.

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

#32

Post by htor »

lmm wrote: 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 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 to make a transition into Scala, but I don't think using Scala will solve the actual problem, even if it does have FP capabilities and encourage immutability.

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

#33

Post by calibraxis »

liviu- wrote: post #31
mercurial wrote: post #23

Earlier quoted context omitted.

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

>I also dispute the claim that a strong type system is a "tiny factor" in code quality. There actually are some studies that show that using a static typing system is only a tiny factor when it comes to code quality: http://wadler.blogspot.co.uk/2011/09/experiment-about-static... However, I've also read studies that show the opposite, but the lack of rigurosity and the possible confounds that show up for both sides s…

With Clojure, you can begin to compare static vs. dynamic typing — keeping the language the same.

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

#34

Post by HillOBeans »

weavejester wrote: post #12
tormeh wrote: post #2

I always thought critical applications like banking needed compile time type checking. Clojure is neat and all, but it's dynamic.

Java doesn't have particularly good compile-time type checking. It's mostly there for performance rather than safety guarantees. While Clojure is a dynamic language, it actually does have optional type checking, courtesy of the core.typed library. This isn't perfect, but it is considerably more sophisticated than Java's inbuilt type system. Even without static type checking, I'd argue that Clojure is the safer langua…

This. The immutable nature of Clojure is what, IMHO, makes it such a better choice than Java for me. I frequently see discussions/debates around type safety on HN, but in my experience, it has been the mutable nature of Java systems that has created more bugs than anything else. Clojure being immutable by default has drastically reduced the pain caused by these bugs. Clojure's collections, FP style, and meta-programming (via macros) all make it a great choice for me, but I think being immutable by default is the biggest thing.

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

#35

Post by dragonwriter »

tormeh wrote: 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 critical applications like banking needed compile time type checking.

They need quality, trustworthy software. Compile time type checking is a tool that can be used to help get there (but how useful it is in getting there depends on how robust the type system is, and Java's is not particularly robust).

Clear and concise code that is readily understood, avoids visual noise so that the programmer can focus on function, also is a tool that can help with that.

Clojure focuses more on the latter than the former, but that doesn't necessarily make it worse, and may make it better.

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

#36

Post by mercurial »

liviu- wrote: post #31
mercurial wrote: post #23

Earlier quoted context omitted.

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

>I also dispute the claim that a strong type system is a "tiny factor" in code quality. There actually are some studies that show that using a static typing system is only a tiny factor when it comes to code quality: http://wadler.blogspot.co.uk/2011/09/experiment-about-static... However, I've also read studies that show the opposite, but the lack of rigurosity and the possible confounds that show up for both sides s…

> However, I've also read studies that show the opposite, but the lack of rigurosity and the possible confounds that show up for both sides seems to render this as an open question.

This doesn't look particularly convincing, indeed (though studies about programming languages rarely are).

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

#37

Post by mercurial »

d4n3 wrote: 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.

It's great for quick feedback. It's less good when your coworker breaks the build on a less-used codepath because there are no unit tests to run.

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

#38

Post by jim_greco »

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 developers leave en masse before everything is completely rewritten.

6) New developers come in and spends the entire time fighting fires and patching the system instead of building new stuff.

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

#39

Post by Glide »

calibraxis wrote: post #33
liviu- wrote: post #31

Earlier quoted context omitted.

>I also dispute the claim that a strong type system is a "tiny factor" in code quality. There actually are some studies that show that using a static typing system is only a tiny factor when it comes to code quality: http://wadler.blogspot.co.uk/2011/09/experiment-about-static... However, I've also read studies that show the opposite, but the lack of rigurosity and the possible confounds that show up for both sides s…

With Clojure, you can begin to compare static vs. dynamic typing — keeping the language the same.

A language having static or dynamic typing is only a part of the puzzle. Having tools that let you understand a codebase better through static typing is more important. With a statically typed language you have the compiler as a baseline, but it enables IDEs to do far more powerful things.

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

#40

Post by lmm »

sz4kerto wrote: post #29
lmm wrote: 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…

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…

> And what did you gain?

All the functional goodness of easier to reason about code. A much more concise way to express common patterns, and a type system powerful enough to abstract away things that you have to repeat in Java. More dynamism than is possible to use safely in a dynamically-typed language, because I can write code that simply "does the right thing" in a principled, safe way that the reader can confirm by checking the types, whereas in something like Python it would be impossible for a reader to see whether that code was buggy.

> It is just a different syntax, that is nicer than Java on one hand, but also big and not straightforward on the other

Actually the syntax is often more straightforward than Java's. E.g. {} just means a block in a sense that's handled consistently everywhere in Scala, whereas in Java {} are required on a try/catch or a method but optional on an if/else.

> making core 'half-functional' does not bring any benefits in terms of composability, concurrency, reasonability (about the code).

Of course it does, or at least if it doesn't then the whole functional programming effort is a mistake. Any "pure" core is a) relative to some notion of equivalence that might or might not correspond to the things that are important to your particular problem and b) doesn't do anything without an impure interpreter. See e.g. http://conal.net/blog/posts/the-c-language-is-purely-functio...

Post reply on HN