4 ms·

nothing like having dynamic types manage your money

ilikehurdles 3y ago
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.
- ilkhan4 3y ago
  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.
  - mvc 3y ago
    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.
    - ilkhan4 3y ago
      Sure, I get that they have to justify themselves, but when the answer to that question is (almost) always "Because Nubank!" for the past 10 years it doesn't feel like much of a justification.
bnert 3y ago
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 languages consider data correctness as access patterns which preserve previous version of data which a caller may still need to reference, or another part of the system references. Functional languages (in most cases) disallow direct mutation without some sort of immutability or persistence. Types have little (or nothing) to do with program correctness, or data correctness as it relates to external storage engines and their concurrency guarantees (i.e. FoundationDB, PostgreSQL, MySQL, etc...). Therefore, in this scenario, what matter's most is the correctness of underlying storage (including the rigor of validating expected behavior) and the event sourcing/messaging systems, not on the internal data structures and their idioms conveyed by the language.
- lmm 3y ago
  > 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 program correctness On the contrary, they're still the most effective technique we've found for improving program correctness at low cost.
  - bnert 3y ago
    > 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. > On the contrary, they're still the most effective technique we've found for improving program correctness In which domain are you working in where this has been the case? It may be my experience, but types as I have seen them used in industry have been more as "data containers with some behaviors". I'd appreciate some examples of where you think I may be getting types wrong or missing the point.
    - lmm 3y ago
      > 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). I wouldn't say it's "extreme", it's very normal and natural. You just stick everything in the types and it works. > C++ and other similar OO's, the type system isn't as compelling as a correctness measure. Agreed that C++-style types are awful. You can generally encode whatever you need if you work hard enough at it - e.g. https://spin.atomicobject.com/2014/12/09/typed-language-tdd-part1/ https://spin.atomicobject.com/2014/12/09/typed-language-tdd-... - but it's painful. > In which domain are you working in where this has been the case? It may be my experience, but types as I have seen them used in industry have been more as "data containers with some behaviors". > I'd appreciate some examples of where you think I may be getting types wrong or missing the point. I've worked in "regular industry" and found types to be very effective. Let me turn it around: what kind of logic errors are you seeing that you think wouldn't be eliminated by using types? Types can't help you avoid errors in the specification itself, and there are a few domains where they may not yet be practical (mainly math-heavy things like linear algebra, where there's centuries' worth of mathematics that's applicable except where it isn't, and we just don't capture all of that in practical type systems yet), but the vast majority of the time you can construct your types in ways that force your logic to be correct because you just don't offer the ability to do the wrong thing.
waffletower 3y ago
I would worry more about developers understanding JVM's numerics, personally. And there are also dragons in Clojure's numeric tower built atop it.
dgb23 3y ago
Clojure you can express arbitrary data constraints and pre/post conditions (design by contract), with spec or malli. Clojure is also strongly typed, has (optional) type hints, which are understood by linting during dev time and helps the compiler to avoid reflection and boxing. It’s a very robust language that people use for critical stuff.

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.

ilkhan4 3y ago
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.
- mvc 3y ago
  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.
  - ilkhan4 3y ago
    Sure, I get that they have to justify themselves, but when the answer to that question is (almost) always "Because Nubank!" for the past 10 years it doesn't feel like much of a justification.

bnert 3y ago

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 languages consider data correctness as access patterns which preserve previous version of data which a caller may still need to reference, or another part of the system references. Functional languages (in most cases) disallow direct mutation without some sort of immutability or persistence. Types have little (or nothing) to do with program correctness, or data correctness as it relates to external storage engines and their concurrency guarantees (i.e. FoundationDB, PostgreSQL, MySQL, etc...). Therefore, in this scenario, what matter's most is the correctness of underlying storage (including the rigor of validating expected behavior) and the event sourcing/messaging systems, not on the internal data structures and their idioms conveyed by the language.

lmm 3y ago
> 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 program correctness On the contrary, they're still the most effective technique we've found for improving program correctness at low cost.
- bnert 3y ago
  > 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. > On the contrary, they're still the most effective technique we've found for improving program correctness In which domain are you working in where this has been the case? It may be my experience, but types as I have seen them used in industry have been more as "data containers with some behaviors". I'd appreciate some examples of where you think I may be getting types wrong or missing the point.
  - lmm 3y ago
    > 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). I wouldn't say it's "extreme", it's very normal and natural. You just stick everything in the types and it works. > C++ and other similar OO's, the type system isn't as compelling as a correctness measure. Agreed that C++-style types are awful. You can generally encode whatever you need if you work hard enough at it - e.g. https://spin.atomicobject.com/2014/12/09/typed-language-tdd-part1/ https://spin.atomicobject.com/2014/12/09/typed-language-tdd-... - but it's painful. > In which domain are you working in where this has been the case? It may be my experience, but types as I have seen them used in industry have been more as "data containers with some behaviors". > I'd appreciate some examples of where you think I may be getting types wrong or missing the point. I've worked in "regular industry" and found types to be very effective. Let me turn it around: what kind of logic errors are you seeing that you think wouldn't be eliminated by using types? Types can't help you avoid errors in the specification itself, and there are a few domains where they may not yet be practical (mainly math-heavy things like linear algebra, where there's centuries' worth of mathematics that's applicable except where it isn't, and we just don't capture all of that in practical type systems yet), but the vast majority of the time you can construct your types in ways that force your logic to be correct because you just don't offer the ability to do the wrong thing.

waffletower 3y ago

I would worry more about developers understanding JVM's numerics, personally. And there are also dragons in Clojure's numeric tower built atop it.

dgb23 3y ago

Clojure you can express arbitrary data constraints and pre/post conditions (design by contract), with spec or malli. Clojure is also strongly typed, has (optional) type hints, which are understood by linting during dev time and helps the compiler to avoid reflection and boxing. It’s a very robust language that people use for critical stuff.