4 ms·

Maybe I'm just missing something, but the "domain expert" that is described here is just... a function? The big win in Clojure is apparently using code instead

Maybe I'm just missing something, but the "domain expert" that is described here is just... a function? The big win in Clojure is apparently using code instead of types? (defn apply-shipping-rules [order] (cond-> order (and (= :premium (:customer-type order)) (> (:order-total order) 100)) (assoc :shipping-cost 0)))

sirwhinesalot 1y ago
Yes, the point of the article is that people should do this (as is common in Clojure) rather than try and encode the rules in the type system (be it as a class hierarchy or a sum type).
- GiorgioG 1y ago
  So (I don't know Clojure) - is the author saying everything should be a map/dictionary? That sounds like complete chaos - I'm not an OOP proponent.
  - sirwhinesalot 1y ago
    Yes and no. The core point is that business rules should be encoded as functions, not in the type system. Everything ending up a map is a side-effect of that since the functions need somewhere to store the information. But a map is also just one solution. You could use a fat struct as well, or implement a ad-hoc relational database (like what entity component systems really are)
rjknight 1y ago
The "domain expert" is the business-person who is, it is suggested, more capable of reading and comprehending the Clojure code than the Haskell code. Since there is an equivalence between types and propositions, the Clojure program also models a "type", in the sense that the (valid) inputs to the program are obviously constrained by what the program can (successfully) process. One ought, in principle, to be able to transform between the two, and generate (parts of) one from the other. We do a limited form of this when we do type inference. There are also (more limited) cases where we can generate code from type signatures. I think op's point is that the Clojure code, which lays the system out as a process with a series of decision points, is closer to the mental model of the domain expert than the Haskell code which models it as a set of types. This seems plausible to me, although it's obviously subjective (not all domain experts are alike!). The secondary point is that the Clojure system may be more malleable - if you want to add a new state, you just directly add some code to handle that state at the appropriate points in the process. The friction here is indeed lower. But this does give up some safety in cases where you have failed to grasp how the system works; a type system is more likely to complain if your change introduces an inconsistency. The cost of that safety is that you have two representations of how the system works: the types and the logic, and you can't experiment with different logic in a REPL-like environment until you have fully satisfied the type-checker. Obviously a smarter system might allow the type-checker to be overridden in such cases (on a per-REPL-session basis, rather than by further editing the code) but I'm not aware of any systems that actually do this.
- vips7L 1y ago
  I honestly doubt a business person would be able to read Clojure. I’ve been programming for 15 years and it doesn’t make any sense to me.
  - senderista 1y ago
    I've been reading and writing English for half a century and Chinese doesn't make any sense to me, so I doubt any ordinary human could read it.
    - vips7L 1y ago
      That’s quite the false equivalence.
      - michaelsbradley 1y ago
        How so?
        igouy 1y ago
        Alphabet? Generality?
  - rjknight 1y ago
    I think it depends a lot on the org. In enterprise software development, there's definitely a type of "business analyst" or "domain expert" who is capable of reading code, at least to the extent that the code resembles a flow chart. Clojure's small syntax means that it's fairly easy to write code that is obviously just a flow-chart in text form.
    - vips7L 1y ago
      There is absolutely no chance I could show the enterprise spaghetti I work with to a domain expert and they would understand any of it.

sirwhinesalot 1y ago

Yes, the point of the article is that people should do this (as is common in Clojure) rather than try and encode the rules in the type system (be it as a class hierarchy or a sum type).

GiorgioG 1y ago
So (I don't know Clojure) - is the author saying everything should be a map/dictionary? That sounds like complete chaos - I'm not an OOP proponent.
- sirwhinesalot 1y ago
  Yes and no. The core point is that business rules should be encoded as functions, not in the type system. Everything ending up a map is a side-effect of that since the functions need somewhere to store the information. But a map is also just one solution. You could use a fat struct as well, or implement a ad-hoc relational database (like what entity component systems really are)

rjknight 1y ago

The "domain expert" is the business-person who is, it is suggested, more capable of reading and comprehending the Clojure code than the Haskell code. Since there is an equivalence between types and propositions, the Clojure program also models a "type", in the sense that the (valid) inputs to the program are obviously constrained by what the program can (successfully) process. One ought, in principle, to be able to transform between the two, and generate (parts of) one from the other. We do a limited form of this when we do type inference. There are also (more limited) cases where we can generate code from type signatures. I think op's point is that the Clojure code, which lays the system out as a process with a series of decision points, is closer to the mental model of the domain expert than the Haskell code which models it as a set of types. This seems plausible to me, although it's obviously subjective (not all domain experts are alike!). The secondary point is that the Clojure system may be more malleable - if you want to add a new state, you just directly add some code to handle that state at the appropriate points in the process. The friction here is indeed lower. But this does give up some safety in cases where you have failed to grasp how the system works; a type system is more likely to complain if your change introduces an inconsistency. The cost of that safety is that you have two representations of how the system works: the types and the logic, and you can't experiment with different logic in a REPL-like environment until you have fully satisfied the type-checker. Obviously a smarter system might allow the type-checker to be overridden in such cases (on a per-REPL-session basis, rather than by further editing the code) but I'm not aware of any systems that actually do this.

vips7L 1y ago
I honestly doubt a business person would be able to read Clojure. I’ve been programming for 15 years and it doesn’t make any sense to me.
- senderista 1y ago
  I've been reading and writing English for half a century and Chinese doesn't make any sense to me, so I doubt any ordinary human could read it.
  - vips7L 1y ago
    That’s quite the false equivalence.
    - michaelsbradley 1y ago
      How so?
      - igouy 1y ago
        Alphabet? Generality?
- rjknight 1y ago
  I think it depends a lot on the org. In enterprise software development, there's definitely a type of "business analyst" or "domain expert" who is capable of reading code, at least to the extent that the code resembles a flow chart. Clojure's small syntax means that it's fairly easy to write code that is obviously just a flow-chart in text form.
  - vips7L 1y ago
    There is absolutely no chance I could show the enterprise spaghetti I work with to a domain expert and they would understand any of it.