[orolle]

It is nature of the problem space which requires you to produce high quality code. If you have a small error in your program, the financial market participants will use it against you to profit. What you loose, others win! Google "fat finger" for examples. In banking you have to keep track of every transactions, see "double accounting". You never delete a transaction, you only retract! Mutablity can cause you a lot of trouble there. SQL DELETE and UPDATE are extremly dangerous! Clojure and datomic solves this through immutibilty. Lastly time is relativistic, meaning that every IT system has a slightly different time. Normaly you never notice this. But they are the cause of tricky race conditions and cost you real money. Think about bank transactions, where you have a transaction date (date you send money) and valuta date (date your friend receives money). One transaction 2 different dates, depending which perspective you take (perspective is relativistic, Einstein is right even in IT!). Datomic linerialies transactions thus this problem does not occure on database level.

[socksy]

I love immutability and Datomic as much as the next Clojure programmer. But this sounds quite a lot like post-hoc reasoning.

For example, there's quite a few situations where you require mutability in bank data (e.g. with government requirements, or when you want to rollback fraudulent trading). Sure, both are solvable with Datomic, but they don't scream "huge advantage with an immutable datastore".

And there are plenty of highly competitive industries where code quality matters, but they're not flocking to functional programming.

Don't get me wrong, I think functional programming is an absolutely great way to structure and think about programming (and have coded professionally in Clojure for the last 5 years or so). But I suspect the prevalence of FP in some industries is as much chance/social reasons than it is for some inherit superiority in the approach.

[polityagent]

small note: Banks do not want to forget fraud, the rollback would be akin to a git revert. Even if the history presented to the customer makes the fraud vanish it won't be forgotten by the bank.

With government requirements I'm assuming you mean something like gdpr. Datomic supports actually removing data via excision. it's just not the default behaviour. I personally prefer a system that doesn't forget by default whilst preserving the option to do so.

you can also support destruction of personal data via other means such as key shredding.

[galkk]

Aren’t “rollbacks” done as separate transactions, that return account amount to Previous value?

[socksy]

Depends on the legal requirements of that rollback

[moon2]

Not really a Clojure user, but I made a small API with it once and it blew my mind, especially the design patterns involved. An interesting one is the ports-and-adapters (a.k.a. hexagonal architecture) [1][2] . Basically, all the business logic will be kept at a layer, and all of the functions there should be pure (i.e. they will always return the same information according to your input, and these functions won't cause side effects [3]). Then you would have layers where you can plug databases and REST handling.

And Nubank take testing really seriously. REPL and pure functions makes it very easy to use TDD.

[1] https://github.com/nubank/basic-microservice-example#ports-a...

[2] http://wiki.c2.com/?PortsAndAdaptersArchitecture

[3] https://practicalli.github.io/clojure/thinking-functionally/...

[hk__2]

> It is nature of the problem space which requires you to produce high quality code.

Wouldn’t a strongly-typed language be a better choice here?

[Nihilartikel]

It takes the will and discipline to use it, but what Clojure Spec (and other schemata libs) offer is, in a lot of ways, more powerful and flexible than traditional type systems. A spec can be thought of more as a contract with the data, one with enough detail that it can be used to auto-generate conformant example data even. If, for instance, you have a function, that needs to work on either, integers, or numeric strings, and textual fractions like '1/5'. Enforcing this constraint on input, and getting informative exceptions on bad data is easy with a spec, and the function code does not need to contain all of the noise to validate or coerce data. Sure, you don't see the problem at compile time, but if you can auto-generate test data, the tests that you should already have become easier to write.

[maximente]

this is perhaps controversial but i actually think datomic is so powerful, it's worth using clojure for. in other words, the database is driving the choice of programming language.

the idea of viewing a database as an immutable state of the world at a given instant t0, and time becoming a parameter on that state of the world (in order to show changes as time goes forwards [or backwards!]), is extremely, extremely attractive for things like finance, whose first class citizens are among others:

- capability for audits e.g. show me the history of transactions from any particular account. since datomic is basically a collection of immutable facts over time, this is "free"

- distributed computing - datomic runs nicely across your own internal compute (often needed for financial stuff)

- transactions are no longer strings, but are actual data structures - this makes the gnarly steps of things like transferring assets across instruments a lot easier (i'd imagine). think about how you'd implement a shopping cart with transactions in postgres vs. how you'd do it with access to raw data structures

[fnordsensei]

Moreover, transactions are reified and can have arbitrary metadata, so you can query the transaction log itself (for example, "show me all transactions issued by person X").

[orolle]

I do not think so. The regulation is constantly changing and the meaning of names change frequently. Thus a "Verified Account" can mean different things over the years. The problem with types and object orientation is, that the names used in the domain diverge from the name used in source code (class name, types). Think about a class diagram with class names relating to each other. To represent the domain language better, you need to change a lot in a class diagram. Dynamic languages reduce the problem, as a lot less names are needed. Clojure spec is used for specification of data instead of types, but there is also clojure typed (which uses javas type system).

[elbear]

Standard Chartered, Mercury, Tsuru Capital (Haskell), Jane Street (OCaml) don't seem to have a problem with using a statically typed language in the financial space.

[moocowtruck]

maybe they do have a problem if their net worth is so low in comparison :D

[beders]

Unlikely. At least not for domain modeling.

Especially in that industry where your domain is changing all the time, where regulations are changing all the time, where the ability to reason about your domain at different points in time is essential.

Having more flexible types like maps is one of the building blocks to avoid complexity (there are more, more important ones) It sounds counter-intuitive, but it certainly is working out for companies embracing clojure.

[in9]

I wouldn't think that strong types are an advantage. They may be in classic software with long compile times and complex builds. However, the current landscape for financial institution doesn't require that. Immutability and functional paradigms seem to be much more in line with the needs of the business.

[alexbanks]

> It is nature of the problem space which requires you to produce high quality code.

Would love to see any actual data or studies showing that functional programming implicitly produces "high quality code".

[beders]

https://cacm.acm.org/magazines/2017/10/221326-a-large-scale-...

Section 3, RQ1

[alexbanks]

I have quite a few gripes with this article, and overall question the validity of its assertions, but interesting nonetheless.

[amw-zero]

There's a ton of problems with empirical studies about software in general. Very hard to conduct reliable experiments. In particular, I think analyzing public GitHub projects is pretty much the worst corpus possible.

For example, almost all of the projects in this study are infrastructure projects (I'm not familiar with all of them so I can't say that it's definitely all). I'm much more interested in application projects, and even if you (general you) aren't, you have to admit that an infrastructure project has a totally different set of characteristics than your average business application.

I think anything we can do to get more empirical data related to software the better, as we have devolved into strong personalities and conviction making pretty much all of the major decisions in our industry, which is really deeply sad. But we have to do better than just mining open source Github projects.

[alexbanks]

Yeah, I wasn't necessarily trying to get into an argument with the person who responded, but there's so many factors not being accounted for in that study that it might as well be measuring nothing at all.

Choosing Github projects and measuring defects on them has almost nothing to do with the quality of closed-source code (as we were discussing, functional programming languages in the wild). I also briefly started down the path of mapping that study's measurements to overall language popularity (as I think they're related - more C++ code available = more bugs), but gave up as I remembered that A.) Nobody's opinion changes as a result of a reasonable argument on the internet, and B.) Convincing this person nets me nothing at all.

You get higher quality code by hiring people capable of producing higher quality code. A great way to find people that are capable of producing higher quality code is by hiring for languages with extremely small talent pools - nobody got there because it was easy or the odds of getting hired were good. Functional programming might seem popular on HN, but in the wild is really not popular at all. Clojure developers probably care a great deal more about the quality of their work than, say, some random J2EE developer, as the Java dev might not care at all about anything other than staying employed.

I guess my argument summarizes down to "Functional programmers care more about their work", which, to my original point, has nothing at all to do with the languages they're using (as the person I responded to was saying). To assert that "Functional programming languages produce higher quality code" is like saying "This brand of hammer hammers better." It's just nonsense.

[beders]

That's oversimplification. Good programmers care about their work, doesn't matter which language.

Also, use the right tool for the job.

A language that forces you to think about values rather than mutable objects, will produce higher quality code as the number of ways you can shoot yourself in the foot are drastically reduced.

Clojure will make you run your code constantly in the REPL. Paired with a dead-simple testing library, the desire to keep your majority of functions pure, it is not hard to see why Clojure code has higher quality.

[darthrupert]

That’s unfortunately hard to find, since hardly any customers require that these days. Fast and cheap is where it’s at.

[alexbanks]

Or, as I'm asserting, it's just totally bogus.