3 ms·

Clojure's take on types is not so much that types are bad at micro scale, it's that focusing on proving referential transparency above all else leads to cultura

Clojure's take on types is not so much that types are bad at micro scale, it's that focusing on proving referential transparency above all else leads to cultural problems at the macro scale. For example, the Datomic Peer API is the most elegant and ergonomic database API I've ever seen. Queries compose as functions under the illusion that the database is a local data structure and this results in a beautiful information model. But if you tried to put IO types on Datomic you find that it spews IO everywhere. And yet it works incredibly well with good enough performance for a wide band of applications! I think you don't find stuff like that in Pure FP ecosystems because those communities coordinate under principles of RT and algebra, and are thus unable to consider a solution space rooted in a different set of principles.

jedimind 6y ago
> focusing on proving referential transparency above all else leads to cultural problems at the macro scale Can you elaborate on what you mean by that?
omginternets 6y ago
Do you have examples to illustrate the Datomic Peer API ergonomics you described? This is really interesting to me, and I’m still struggling to grok it.
- dustingetz 6y ago
  http://www.dustingetz.com/:datomic-in-four-snippets/ http://www.dustingetz.com/:datomic-in-four-snippets/
  - omginternets 6y ago
    Brilliant, thanks.
smabie 6y ago
I've personally never thought the cost of tracking mutation and IO in a type system is particularly worth the complexity and hassle. But for everything else, an advanced Hindley Milner derived type system is absolutely, 100% worth it. I do think there might be some middle ground where you can annotate non pure functions in order to help the compiler with aggressive optimization.
lmm 6y ago
> But if you tried to put IO types on Datomic you find that it spews IO everywhere. So you put it in a monad and get on with your life? It's like one or two extra characters on your operators just to mark out where you're doing effect composition, and the benefit is that you can immediately see where all the effects are happening. Code is read more than it's written, so it's a really good tradeoff. > And yet it works incredibly well with good enough performance for a wide band of applications! How big is it, and how many people work on it? IME not tracking effects works great as long as everyone working on the codebase can keep the whole thing in their head. But you hit a wall (for me it's about 20kloc - I'm sure smarter people can push it a bit further, but everyone will have a limit eventually) once you can no longer reason about how one part affects every other part, and at that point a little helping hand from the compiler helps a lot.
- deleted 6y ago
  [deleted]
- dustingetz 6y ago
  The closest thing I can think of from the pure FP community that makes queries compose in a monad is Scala Slick, which adds an extraordinary amount of complexity to compose queries in exactly the wrong way. The whole FP community's thesis seems to be "take adderall and follow the math" and that thesis leads to Slick, not Datomic. (Both are early 2010s era so i think this is a fair comparison)
  - lmm 6y ago
    Slick is for querying traditional SQL RDBMSes, so it has to deal with a massive impedance mismatch compared to a greenfield project. I'd look at something like Facebook's Haxl (for querying GraphQL) for a fairer comparison IMO.

jedimind 6y ago

> focusing on proving referential transparency above all else leads to cultural problems at the macro scale Can you elaborate on what you mean by that?

omginternets 6y ago

Do you have examples to illustrate the Datomic Peer API ergonomics you described? This is really interesting to me, and I’m still struggling to grok it.

dustingetz 6y ago
http://www.dustingetz.com/:datomic-in-four-snippets/ http://www.dustingetz.com/:datomic-in-four-snippets/
- omginternets 6y ago
  Brilliant, thanks.

smabie 6y ago

I've personally never thought the cost of tracking mutation and IO in a type system is particularly worth the complexity and hassle. But for everything else, an advanced Hindley Milner derived type system is absolutely, 100% worth it. I do think there might be some middle ground where you can annotate non pure functions in order to help the compiler with aggressive optimization.

lmm 6y ago

> But if you tried to put IO types on Datomic you find that it spews IO everywhere. So you put it in a monad and get on with your life? It's like one or two extra characters on your operators just to mark out where you're doing effect composition, and the benefit is that you can immediately see where all the effects are happening. Code is read more than it's written, so it's a really good tradeoff. > And yet it works incredibly well with good enough performance for a wide band of applications! How big is it, and how many people work on it? IME not tracking effects works great as long as everyone working on the codebase can keep the whole thing in their head. But you hit a wall (for me it's about 20kloc - I'm sure smarter people can push it a bit further, but everyone will have a limit eventually) once you can no longer reason about how one part affects every other part, and at that point a little helping hand from the compiler helps a lot.

deleted 6y ago
[deleted]
dustingetz 6y ago
The closest thing I can think of from the pure FP community that makes queries compose in a monad is Scala Slick, which adds an extraordinary amount of complexity to compose queries in exactly the wrong way. The whole FP community's thesis seems to be "take adderall and follow the math" and that thesis leads to Slick, not Datomic. (Both are early 2010s era so i think this is a fair comparison)
- lmm 6y ago
  Slick is for querying traditional SQL RDBMSes, so it has to deal with a massive impedance mismatch compared to a greenfield project. I'd look at something like Facebook's Haxl (for querying GraphQL) for a fairer comparison IMO.