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

11–20 of 68 posts

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

#11

Post by noelwelsh »

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.

Technology adoption is almost always driven by the people, not the technology. The OP is a big fan of Clojure, having used it elsewhere, so its no surprise they brought Clojure to their new job.

To be clear, I'm not suggesting that Clojure is a bad language. I really enjoy using Lisp-like languages! I also enjoy modern statically typed languages (and on balance prefer them). My experience is that having good people and avoiding bad technology choices (e.g. choosing Ruby for high throughput and low latency environments) is the secret to success. Stories like these are invariably sold as technology successes (and, equally, technology is blamed when things go bad.) I believe the reality is more that better technology attracts better people. It's the better people and chance to avoid legacy that gives success.

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

#12

Post by weavejester »

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 language by default, since it mostly avoids mutability.

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

#13

Post by shellac »

kyleburton wrote: post #10
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.

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…

I'm ignorant here. From what you say it sounds like Typed Clojure is traditionally what we think of as 'types', whereas schema is more along the line of asserts.

Is that fair?

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

#15

Post by d4n3 »

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.

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

#17

Post by iak8god »

thu wrote: post #9
iak8god wrote: post #5

Earlier quoted context omitted.

The arguments I've heard supporting this are usually weaker than their proponents think because they simply don't understand the alternative. Even if this is true though, "banking" is much too broad a category to make such general statements. Consider: > Here are some specifics – our new code is going to be an order of magnitude less in volume than the old and this is being conservative. Java's static typing would he…

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 that they have a much smaller and more maintainable code base now than they had before, and so they're better off than they were.

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

#19

Post by jeletonskelly »

BjoernKW wrote: post #4
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.

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.

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

#20

Post by taylorlapeyre »

shellac wrote: post #13
kyleburton wrote: post #10

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…

I'm ignorant here. From what you say it sounds like Typed Clojure is traditionally what we think of as 'types', whereas schema is more along the line of asserts. Is that fair?

That's correct.
Post reply on HN