6 ms·

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

by orolle 6y ago

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.

hk__2 6y ago
> 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?
- in9 6y ago
  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.
- orolle 6y ago
  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 6y ago
    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 6y ago
      maybe they do have a problem if their net worth is so low in comparison :D
- maximente 6y ago
  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 6y ago
    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").
- Nihilartikel 6y ago
  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.
- beders 6y ago
  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.
socksy 6y ago
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.
- galkk 6y ago
  Aren’t “rollbacks” done as separate transactions, that return account amount to Previous value?
  - socksy 6y ago
    Depends on the legal requirements of that rollback
- polityagent 6y ago
  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.
alexbanks 6y ago
> 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".
- darthrupert 6y ago
  That’s unfortunately hard to find, since hardly any customers require that these days. Fast and cheap is where it’s at.
  - alexbanks 6y ago
    Or, as I'm asserting, it's just totally bogus.
- beders 6y ago
  https://cacm.acm.org/magazines/2017/10/221326-a-large-scale-study-of-programming-languages-and-code-quality-in-github/fulltext https://cacm.acm.org/magazines/2017/10/221326-a-large-scale-... Section 3, RQ1
  - alexbanks 6y ago
    I have quite a few gripes with this article, and overall question the validity of its assertions, but interesting nonetheless.
    - amw-zero 6y ago
      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.
moon2 6y ago
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-and-adapters-microservice https://github.com/nubank/basic-microservice-example#ports-a... [2] http://wiki.c2.com/?PortsAndAdaptersArchitecture http://wiki.c2.com/?PortsAndAdaptersArchitecture [3] https://practicalli.github.io/clojure/thinking-functionally/pure-functions.html https://practicalli.github.io/clojure/thinking-functionally/...

by orolle 6y ago

hk__2 6y ago

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

in9 6y ago
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.
orolle 6y ago
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 6y ago
  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 6y ago
    maybe they do have a problem if their net worth is so low in comparison :D
maximente 6y ago
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 6y ago
  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").
Nihilartikel 6y ago
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.
beders 6y ago
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.

socksy 6y ago

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.

galkk 6y ago
Aren’t “rollbacks” done as separate transactions, that return account amount to Previous value?
- socksy 6y ago
  Depends on the legal requirements of that rollback
polityagent 6y ago
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.

alexbanks 6y ago

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

darthrupert 6y ago
That’s unfortunately hard to find, since hardly any customers require that these days. Fast and cheap is where it’s at.
- alexbanks 6y ago
  Or, as I'm asserting, it's just totally bogus.
beders 6y ago
https://cacm.acm.org/magazines/2017/10/221326-a-large-scale-study-of-programming-languages-and-code-quality-in-github/fulltext https://cacm.acm.org/magazines/2017/10/221326-a-large-scale-... Section 3, RQ1
- alexbanks 6y ago
  I have quite a few gripes with this article, and overall question the validity of its assertions, but interesting nonetheless.
  - amw-zero 6y ago
    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.

moon2 6y ago

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-and-adapters-microservice https://github.com/nubank/basic-microservice-example#ports-a... [2] http://wiki.c2.com/?PortsAndAdaptersArchitecture http://wiki.c2.com/?PortsAndAdaptersArchitecture [3] https://practicalli.github.io/clojure/thinking-functionally/pure-functions.html https://practicalli.github.io/clojure/thinking-functionally/...