clojure 2020-07-05 | Slack Archive

vemv17:07:05

Like any tool, in good hands :pre/:post is neat. Of course one needs some thinking and agreement about what/where/when can be asserted, and then follow that design consistently. There's no right answer as for whether *assert* should be turned off in production. I do, because I use it mostly for type-like checks, which aren't free.

noisesmith18:07:04

also, the normal way to do design by contract is to use pre/post checks in development and turn them off in runtime code - the arguments against this practice are also arguments against design by contract

p-himik18:07:40

That doesn't sound correct. I.e. if I do not disable asserts in production, it doesn't mean that I violate design by contract, no? Because the contract is still there.

vemv18:07:45

Design by contract is a pretty specific thing (:pre/:post which apparently is influenced by Eiffel) so 'violating' it is not something wrong, it's simply a tool you are not using

➕ 3

p-himik18:07:38

I made my statement in the context of design by contract being a practice in general, without any attachments to any languages. But it's all just semantics, hardly useful to anybody in this case.

millettjon19:07:08

Yeah. Maybe there are some narrow contexts where that is what you want, but doesn't seem prudent for the general case.

noisesmith20:07:26

what I'm describing is the development process, of course one can borrow pieces of one process or another, but "design by contract" as its normally understood uses dev time assertions, and I think the other thing being argued for is a different though related practice, with different priorities and aims

noisesmith20:07:11

and it's OK with me to reject design by contract, I don't use it myself, but I do like to be clear about definitions

👍 3

2020-07-05

Channels