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

41–50 of 68 posts

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

#41

Post by scalesolved »

xfalcox wrote: post #8
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.

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.

The Play! Framework http://www.playframework.com has been pretty sweet for us so far and we use Java with it and that plays second fiddle to Scala users who really enjoy the full benefit of the framework.

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

#42

Post by lmm »

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.

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

If you use them right, expressing the constraints of your system in the type system, you can improve huge areas of quality. It doesn't give you much for free, but it does give you a tool that lets you check your own correctness properties more efficiently and maintainably than any alternative.

> Lack of expressiveness or lack of developer happiness can be much more detrimental to software quality than lack of static typing.

Agreed - but good static typing makes a language more expressive, not less.

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

#43

Post by rdtsc »

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.

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 distributed platform, with a tiny number of engineers (about 10 or 20) by also leveraging a non-statically compiled and functional language.

In general static type checking is nice, I like it. But clearly not a deal breaker. O often hear "I won't touch anything unless it has static typing" or "large applications should have static types".

But maybe the question to ask, should applications be that large? Lately we have been all upvoting microservices. And if anything those encourage decoupling large monstrous application into smaller independent services. At that point there are just a soup of dynamically typed components.

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

#44

Post by [deleted] »

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…

[deleted]

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

#45

Post by Ironballs »

rdtsc wrote: post #43
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.

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…

From what I've seen, Clojure has a strong type system, but is dynamic. These terms aren't orthogonal. If I understand correctly (+ 'a' 1) is not allowed. Immutability only strengthens it.

I ask this because I've been eager to get my hands dirty with Clojure. I have experience with other functional languages (Haskell, OCaml, F# and some Emacs Lisp), so the paradigm isn't new.

I've looked at core.typed, but doesn't seem as neat as the syntax of Typed Racket. It's something, though. Is it checked at compile time?

What irks me is that static typing and type inference can make code feel really robust, and for the lack of a better word, safe. In Clojure I see a lot of nice things but the lack of typing, though common for Lisps, always bothers me a bit. I don't like runtime errors that happen because the compiler wasn't able to tell me that this object doesn't have that method. JavaScript's undefined is not a function or its kin in Python are examples of this behaviour, which I don't like.

Though, I see that Clojure's answer to this is rapid REPL development--which is great!--and unit testing, and what I've recently discovered, pre- and post-conditions. But it still feels somehow inferior.

I am torn between learning Scala or Clojure. Knowing OCaml and F#, Scala doesn't look that interesting, messy and multi-paradigm. Clojure appeals to me because its a Lisp and has one paradigm, but on the other hand I'm scared by runtime exceptions.

Should I just ignore my trepidations and proceed?

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

#46

Post by mtrimpe »

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?

Yup; but asserts that a) describe an entire 'object' (usually a map or list) b) can be composed together and c) be used to generate e.g. documentation or validated forms

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

#47

Post by rdtsc »

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…

Sounds like you've had a bad experience.

Hopefully they had tests. And unless they've mathematically proved the code always does what it expects (I've only seen that in avionics systems).

Also depends on application of course. Large concurrent and distributed applications benefit a bit less from static typing in traditional languages. Or rather, they are so hard, that type error are not as much of a significance. How concurrency, communication and failure is handled is more critical.

But say a game or a large desktop application with millions of lines of code, could get a larger benefit from static type checking, no doubt.

Now for a bit of personal experience. I have programmed in Java, C#, Python, Erlang, C++. I have found that when working with large or unknown code bases C# for example is great. Just having the IDE and generics support in C# during compile time is awesome. But if I program something from scratch, I can make a lot faster progress in Python. I often put more work into both unit tests and integration tests because I just have more time available.

Also failures during run-time, even in Python, in my systems a very rarely type errors (those are caught pretty early one). But they are often logic or concurrency errors.

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

#48

Post by rdtsc »

Ironballs wrote: post #45
rdtsc wrote: post #43

Earlier quoted context omitted.

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…

From what I've seen, Clojure has a strong type system, but is dynamic. These terms aren't orthogonal. If I understand correctly (+ 'a' 1) is not allowed. Immutability only strengthens it. I ask this because I've been eager to get my hands dirty with Clojure. I have experience with other functional languages (Haskell, OCaml, F# and some Emacs Lisp), so the paradigm isn't new. I've looked at core.typed, but doesn't see…

> Should I just ignore my trepidations and proceed?

Yap give it a try.

From what I understand Core.typed while not as rigorous as static type system in Haskell or OCaml can let you gradually add typing to your application. They more you add the greater the benefit.

But also personally haven't used it.

I used Dialyzer in Erlang, which is a similar concept. You annotate your code with types and the more you do the more type errors it will find for you:

http://learnyousomeerlang.com/dialyzer

It is surprisingly good. Here is example of production code in Erlang with some type annotations (it is a websocket handler from Cowboy a webserver):

https://github.com/ninenines/cowboy/blob/master/src/cowboy_w...

Notice the type and -callback declarations at the top then the -spec lines before some functions.

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

#49

Post by eternalban »

jim_greco wrote: post #38

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.

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

#50

Post by mod »

xfalcox wrote: post #8
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.

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.

I'd enjoy getting paid to go slow and learn Scala.

I really despise the "let's finish this in one week" that is typically going on for me. I'd rather learn best practices, even if they're in a language, and have some experience building long-lasting services.

Feels like the difference in working at a mobile home shop vs a custom log home company.

Post reply on HN