Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Griffin – A fully-regulated, API-driven bank, with Clojure

juxt.pro

Post reply on HN
Print view View original

161–170 of 223 posts

Re: Griffin – A fully-regulated, API-driven bank, with Clojure

#161

Post by mvc »

ilkhan4 wrote: post #59
ilikehurdles wrote: post #23

Earlier quoted context omitted.

While I also love to take part in cargo cults, you should probably fit some good blinders on before looking over at Nubank’s stack.

I wish people would stop bringing up Nubank when it comes to Clojure/FP as if it's some sort of mic drop that proves that it's the Right Way to develop financial software. When you have to keep bringing up the same example, it's not a very good argument.

There are always going to be niche langauges and mainstream languages, and as a result, users of niche languages will always have to "justify" their use of such. To investors, to potential new users, to potential colleauges.

They're not having a bash at $your_favorite_langauge. Or suggesting that nubank couldn't have been built on any other platform. They are simply responding to the oft-stated question "are there any examples of it working at scale".

What do you care whether it's "the right way" to develop any kind of software? "Clojure" was in the title. If you don't like Clojure, skip along to the next article.

Re: Griffin – A fully-regulated, API-driven bank, with Clojure

#162

Post by maxehmookau »

Interesting idea. This was the sales pitch that drew me to Mondo (now Monzo) but they ended up dropping their user-facing API almost entirely and replaced it with Open Banking APIs that aren't available to regular hobbyists.

That said, looks interesting! Good luck!

Re: Griffin – A fully-regulated, API-driven bank, with Clojure

#163

Post by anentropic »

n42 wrote: post #89
gremlinsinc wrote: post #41

Earlier quoted context omitted.

the whole article read to me like a guide: How to over engineer a project for kicks and giggles.

how would you under engineer your bank?

maybe by not building our own database

seems a bit like engineering for the sake of engineering

I'm all for it if it floats your boat, not sure that it's what I want from my bank though

Re: Griffin – A fully-regulated, API-driven bank, with Clojure

#164

Post by Jach »

lmm wrote: post #60
bnert wrote: post #31

Earlier quoted context omitted.

In OO languages (Java, C#, C++, etc...), and functional ones (F#, Haskell, OCaml, etc...) types do not validate the correctness of logic, they evaluate the correctness of data structures and their access/mutation as they are manifested in the language. OO languages consider data correctness as access patterns of encapsulated primitives (or other data structures) through defined behaviors on a "class". Functional lang…

> In OO languages (Java, C#, C++, etc...), and functional ones (F#, Haskell, OCaml, etc...) types do not validate the correctness of logic, they evaluate the correctness of data structures and their access/mutation as they are manifested in the language. Nonsense. Types validate whatever you use them to validate, which can certainly include what we usually call "logic". > Types have little (or nothing) to do with pro…

Agree that you can use types to express and prove logical properties via compiler; it can be a fun way to solve a problem though too much of it tends to frustrate coworkers in JavaLand. It's also not exactly "low cost"; here's an old quip I have in my quotes file:

"With Scala you feel smart having just got something to work in a beautiful way but when you look around the room to tell your clojure colleague how clever you are, you notice he left 3 hours ago and there is a post-it saying use a Map." --Daniel Worthington-Bodart

> On the contrary, they're still the most effective technique we've found for improving program correctness at low cost.

This is not borne out by research, such as there is any of any quality: https://danluu.com/empirical-pl/ The best intervention to improve correctness, if not already being done, is code review: https://twitter.com/hillelogram/status/1120495752969641986 This doesn't necessarily mean dynamic types are better, just that if static types are better, they aren't tremendously so to obviously show in studies, unlike code review benefit studies.

My own bias is in favor of dynamic types, though I think the way Common Lisp does it is a lot better than Python (plus Lisp is flexible enough in other ways to let static type enthusiasts have their cake and eat it too https://github.com/coalton-lang/coalton), and Python better than PHP, and PHP better than JS. And I prefer Java to PHP and JS. Just like not all static type systems are C, not all dynamic type systems are JS. Untyped langs like assembly or Forth are interesting but I don't have enough experience.

I don't find the argument that valuable though, since I think just focusing on dynamic vs static is one of the least interesting division points when comparing languages or practices, and may be a matter of preferred style, like baseball pitching, more than anything. If we're trading experience takes I think Clojure's immutable-by-default prevents more bugs than any statically typed language that is mutable by default; that is, default mutable or default immutable (and this goes for collections too) is a much more important property than static types or dynamic types. It's not exactly a low cost intervention though, and when you really need to optimize you'll be encouraged by the profiler to replace some things with Java native arrays and so on. I don't think changing to static types would make a quality difference (especially when things like spec exist to get many of the same or more benefits) and would also not be a low cost intervention.

Some domains also demand tools beyond type proofs. i.e. things like TLA+. I think adding static types on top of that isn't very valuable, similar to adding static types on top of immutable-by-default isn't very valuable.

Last quip to reflect on. "What's true of every bug found in the field? ... It passed the type checker. ... It passed all the tests. Okay. So now what do you do? Right? I think we're in this world I'd like to call guardrail programming. Right? It's really sad. We're like: I can make change because I have tests. Who does that? Who drives their car around banging against the guardrail saying, "Whoa! I'm glad I've got these guardrails because I'd never make it to the show on time."" --Rich Hickey (https://www.infoq.com/presentations/Simple-Made-Easy/)

Re: Griffin – A fully-regulated, API-driven bank, with Clojure

#165

Post by _dain_ »

bnert wrote: post #79
lmm wrote: post #60

Earlier quoted context omitted.

> In OO languages (Java, C#, C++, etc...), and functional ones (F#, Haskell, OCaml, etc...) types do not validate the correctness of logic, they evaluate the correctness of data structures and their access/mutation as they are manifested in the language. Nonsense. Types validate whatever you use them to validate, which can certainly include what we usually call "logic". > Types have little (or nothing) to do with pro…

> Types validate whatever you use them to validate, which can certainly include what we usually call "logic". I'd love an example of this! I concede that I could be wrong on the point's of ML/Haskell families, however, it relies on the practitioner correctly using the type system to the extreme (at least, that is my impression). C++ and other similar OO's, the type system isn't as compelling as a correctness measure.…

Are you familiar with the idea of "making illegal states unrepresentable", and "parse, don't validate"?

https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va...

You brought up the examples of doing the wrong thing with booleans. With a good type system you can cut down on needing to use booleans in the first place for a lot of things. Your isSomething(x) example is a good one: presumably some code after this is implicitly relying on this predicate being true about x. If you forget to do the check, or you invert the check, then that's a bug.

But another way to do this is to encode the predicate into the type system, so the compiler makes you get it right. Concretely, supposing x is a string, and you need to check if x is a valid username before invoking username-related code on x. Then you can have a function like:

    fn as_username(x: String) -> Optional[Username]
A Username is just a type alias for a String, i.e. the runtime representation is the exact same, with no overhead. You put the parsing/validation logic inside that function. Then code expecting a username will take a value of type Username rather than String. If as_username is the only function with Username in the return type, then having a value of type Username is proof that the as_username function was already called at some point previously, and gave its blessing to the underlying string so that the Optional could be unpacked.

    match as_username(raw_string) {
    // compiler forces us to handle both cases, ie we can't forget
    // to check validity
        case Some(username: Username) {
            // code in here can assume we have a proper username
        }
        case None {
            // handle what to do otherwise
        }
    }
Sure, you have to write the as_username function correctly, there's no getting around that. But you only have to get it right once.

Re: Griffin – A fully-regulated, API-driven bank, with Clojure

#166

Post by richardw »

teamspirit wrote: post #3

Why are these API banks always in the UK? I've been waiting to do my banking using curl for years and no one has made it available in the US.

67m people in UK in a far more homogenous market. US is a lot more complicated, has a lot more legacy and more parties to get anything done.

See e.g. the sluggish move to chip and pin, sluggish death of checks, slow move to real-time payments. Hard to turn a supertanker with many states and thousands of banks.

Re: Griffin – A fully-regulated, API-driven bank, with Clojure

#167

Post by ehhthing »

varispeed wrote: post #160
ehhthing wrote: post #86

Earlier quoted context omitted.

I'm confused by this statement. fintechs aren't just proxies for banks, they're financial products that people want to use. There are plenty of cool and innovative things you can do with just a banking API beyond just creating another bank Sure the costs for any fintech using these products are the same, but they can offer a million different types of products which make them unique.

Then company underpinning those fintech businesses decides to pull the plug and suddenly everyone finds themselves up in a creek without a paddle.

This is true for basically everything powered by an API.

I mean if you want to start your own bank and deal with compliance then sure do that! I don't see your point here, there is no sensible alternative to this problem.

Re: Griffin – A fully-regulated, API-driven bank, with Clojure

#168

Post by donatj »

tmpX7dMeXU wrote: post #158
weird-eye-issue wrote: post #115

"We kind of joke that we’re a tech company that happens to have a banking license." This is one of those quotes that can look really bad in hindsight if something goes wrong

I wouldn’t use a bank with this attitude. With a “tech company” label comes a lot of unjustified hubris based on an assumption that one is good at everything just because they write code. My employer called themselves an education research company that happened to use software to commercialise their findings. It sat a lot better with me and made for better culture in my eyes.

I have been using Wells Fargo for almost thirty years and while I don’t know if it’s still the case, as recent as four years ago their passwords were case insensitive. I’ll take a little sane fintech in my banking please.

Re: Griffin – A fully-regulated, API-driven bank, with Clojure

#169

Post by philipwhiuk »

donatj wrote: post #168
tmpX7dMeXU wrote: post #158

Earlier quoted context omitted.

I wouldn’t use a bank with this attitude. With a “tech company” label comes a lot of unjustified hubris based on an assumption that one is good at everything just because they write code. My employer called themselves an education research company that happened to use software to commercialise their findings. It sat a lot better with me and made for better culture in my eyes.

I have been using Wells Fargo for almost thirty years and while I don’t know if it’s still the case, as recent as four years ago their passwords were case insensitive. I’ll take a little sane fintech in my banking please.

Why is case sensitivity in passwords important?

If your answer is: because 62^8 (^12, ^16) is much bigger than 36^8 (^12, ^16) then I assume you don't actually know how people crack passwords, which isn't brute-force.

If your system is capable of being brute-forced, you already failed, because there's no reason to give someone enough guesses that a brute-force approach succeeds.

Re: Griffin – A fully-regulated, API-driven bank, with Clojure

#170

Post by yladiz »

Serious question, and I apologize for the strong language: why should I give a shit about the language a service I consume is written in? Why does it matter it’s in Clojure? I am professionally a Clojure dev so it’s cool to see something written in Clojure like this, but why should I care about that?

This is one of the things I really dislike about the community. Yes, Clojure is a powerful language, and I really enjoy working with it, but I often feel that the community has some kind of imposter syndrome that drives the need to tell others and justify the use of the language in some project, and it’s weird.

Post reply on HN