3 ms·

The part about END, JSON, EQL, GraphQL is a bit of a strawman. EDN and EQL are specific to Clojure, JSON and GraphQL can be used with pretty much anything. Of c

by Zababa 5y ago

The part about END, JSON, EQL, GraphQL is a bit of a strawman. EDN and EQL are specific to Clojure, JSON and GraphQL can be used with pretty much anything. Of course if you're writing a data notation and a query language specifically for a language it will be better for that language, at least I hope so. For the part about "having a few data structure", doesn't that means that you lose all type safety? If you have an Order type and a PaidOrder type, the compiler can enforce that you won't use an Order that hasn't been paid in places you shouldn't. This part is not about this article specifically but about the way people talk about Clojure in general. Most of the time Clojure users compare Clojure to Java, which in a way is fair since Clojure leverages the JVM, but on the other hand Java isn't known for simplicity (part of it may be due to design, part of it is due to being older). Some tradeoffs are presented as strict wins (see above the part about type safety vs a few collections). Most people mention being skeptic at first with Clojure, and now being in love with it. Shouldn't that mean that they should keep looking for new things since they were trapped in some kind of local maximum before?

nlitened 5y ago
> If you have an Order type and a PaidOrder type, the compiler can enforce that you won't use an Order that hasn't been paid in places you shouldn't. First programmers make Order and PaidOrder classes to enforce static type checks, then they tell you that the system absolutely cannot support credit card chargebacks because PaidOrder becoming unpaid would ruin everything in the architecture, and you should teach the clients to never charge back.
- Zababa 5y ago
  I could also make a strawman about Clojure not working at all because you can never differentiate between paid orders and orders but I didn't because it would add nothing to the discussion. Adding features and refactoring statically typed code is feasible and has been done by lots of people, your point is invalid.
  - cutler 5y ago
    (def order {:amount 5.45 :currency "dollar" :paid true})
    - Zababa 5y ago
      Which is why I called this a strawman. The tradeoff is that you have to check yourself for the ":paid true" instead of having the compiler checking that you're taking a PaidOrder type.

by Zababa 5y ago

nlitened 5y ago

> If you have an Order type and a PaidOrder type, the compiler can enforce that you won't use an Order that hasn't been paid in places you shouldn't. First programmers make Order and PaidOrder classes to enforce static type checks, then they tell you that the system absolutely cannot support credit card chargebacks because PaidOrder becoming unpaid would ruin everything in the architecture, and you should teach the clients to never charge back.

Zababa 5y ago
I could also make a strawman about Clojure not working at all because you can never differentiate between paid orders and orders but I didn't because it would add nothing to the discussion. Adding features and refactoring statically typed code is feasible and has been done by lots of people, your point is invalid.
- cutler 5y ago
  (def order {:amount 5.45 :currency "dollar" :paid true})
  - Zababa 5y ago
    Which is why I called this a strawman. The tradeoff is that you have to check yourself for the ":paid true" instead of having the compiler checking that you're taking a PaidOrder type.