Did anyone else notice that the biggest non-academic supporters of functional programming seem to be financial institutions?
Is it due to the nature of the problem space? Is it because finance people tend to be more analytical? Something else?
Is it due to the nature of the problem space? Is it because finance people tend to be more analytical? Something else?
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.
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.
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/...
Wouldn’t a strongly-typed language be a better choice here?
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
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.
Would love to see any actual data or studies showing that functional programming implicitly produces "high quality code".
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.
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.
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.
Yes, but the whole purpose of my post is to point out the difficulty in _finding_ the good programmers.
> Also, use the right tool for the job.
Not sure how this applies. You can build banking software in literally any programming language.
> 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.
Again, this is just totally unsubstantiated. You're using "higher quality code" to mean "code I like more".
> 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.
Where have we demonstrated that clojure has implicit higher quality? Also, where have we demonstrated that all clojure devs keep their functions pure? Or test them? And how does clojure enforce that?
Your last bit kinda proves my whole point, I think. You like a language a lot, and you make good use of its tools. But again, when you're looking at large groups of programmers, they're going to drastically lower the bar on what you "should" do - talking about "strong desire" and "dead simple" is totally unrelated to whether people will _actually do_ something in the wild. And what's the best way to keep a codebase good? Well first, tooling, but second, not letting bad devs get ahold of it.
The software is always expected to be correct, never fail and fast. Otherwise, someone will lose the money, and usually, you (bank or institution) will have to recoup that, plus penalties, plus name damage.
Source: worked there.
Then again, Wirecard happened. But perhaps that wasn’t exactly banking.
I tried unsuccessfully to get a job with them about 4-5 years ago. They are a huge Haskell shop.
I simply didn't have enough background in Haskell. The interview was fun. The interviewer did his PhD in Haskell and compiler theory.
Around the same time, I applied to Facebook's Haskell group, and I got to interview with Simon Marlow, which was great. He also said that I didn't have enough Haskell experience and suggested that I do more Haskell consulting work, and re-apply in a year.
Anyway, I love coding in Haskell but my skills need improvement.
Considering that finance is decently geographically distributed, I'd say it's more SV has become javascript hell than finance is especially FP oriented.
Given you have a basic grasp of bookkeeping, accounting and financial statements: Would you rather program these things in a functional or imperative language? Would you rather store the transactions in a accreting, value oriented database or one that has no inherent notion of these concepts?
Or more generally, if your application has a temporal reporting feature, then you need to be able to ask questions like: "What were these values at date X and what are they going to be at Y?" etc.
Plenty of financial institutions use lots of c++ or java and plenty use cobol too.