5 ms·

I mainly program in clojure. The experience is just too good to be swayed by the bad points. That said, I wrote a moderately complex program recently where ha

I mainly program in clojure. The experience is just too good to be swayed by the bad points. That said, I wrote a moderately complex program recently where having dynamic types was a hindrance. I had to do mental book keeping in order to make sure I was constructing correct structures. I frequently didn't and the bugs were hard to track down. However, Clojure Spec came along, and I applied it to the problem. The difficulties became surmountable. It's a case where if I had been fluent in haskell, I probably would have used it. But I'm not, and this project was for work, so I didn't have the luxury of time to figure it out. Spec alleviates mental book keeping of structures by adding checkers and clarifying/codifying intent.

hellofunk 9y ago
How much Spec do you sprinkle in your code? I'm often using a keyword to query a map. Should I always spec/assert the return of this simple and common task? Because if you type the wrong keyword, a typo or just because you confuse different keywords in your mind, then it doesn't matter how much spec you have applied to the top-level data structure, the function arguments or other things, you still end up with a very easy nil or just incorrect value floating through your data transformations. The only way I see to have a lot of confidence is to add Spec to every new binding that is created, confirming that all named values are exactly what you think they are. Perhaps that is how most Spec users are working? That would mean asserting every item in a "let" for example.
- GlennS 9y ago
  I would suggest that, rather using spec everywhere, you can use it as a barrier to contagion. That is, only checking that data conforms to your spec when it goes through the major interfaces between parts of your program. In this approach, you're not relying on spec to verifying the correctness of everything. Rather you use to reduce surprise bugs where a little change here makes something weird and unexpected happen all the way over there.
  - DigitalJack 9y ago
    Agree, this is my approach. Also, I do checks on the data structure, less on how they are used. So if a function expects a certain structure I’ll spec that. But I don’t do checks on getter setter type operations.
    - GlennS 9y ago
      I'd add that I think the correctness problems with (good) dynamic language really only start appear as the program gets larger. Dividing your program up into large chunks with rigorously defined and checked interfaces (e.g. using spec) does a lot to mitigate this. Meanwhile, you still get the benefits of dynamism (concise code tightly focused on the problem domain) within each module.

hellofunk 9y ago

How much Spec do you sprinkle in your code? I'm often using a keyword to query a map. Should I always spec/assert the return of this simple and common task? Because if you type the wrong keyword, a typo or just because you confuse different keywords in your mind, then it doesn't matter how much spec you have applied to the top-level data structure, the function arguments or other things, you still end up with a very easy nil or just incorrect value floating through your data transformations. The only way I see to have a lot of confidence is to add Spec to every new binding that is created, confirming that all named values are exactly what you think they are. Perhaps that is how most Spec users are working? That would mean asserting every item in a "let" for example.

GlennS 9y ago
I would suggest that, rather using spec everywhere, you can use it as a barrier to contagion. That is, only checking that data conforms to your spec when it goes through the major interfaces between parts of your program. In this approach, you're not relying on spec to verifying the correctness of everything. Rather you use to reduce surprise bugs where a little change here makes something weird and unexpected happen all the way over there.
- DigitalJack 9y ago
  Agree, this is my approach. Also, I do checks on the data structure, less on how they are used. So if a function expects a certain structure I’ll spec that. But I don’t do checks on getter setter type operations.
  - GlennS 9y ago
    I'd add that I think the correctness problems with (good) dynamic language really only start appear as the program gets larger. Dividing your program up into large chunks with rigorously defined and checked interfaces (e.g. using spec) does a lot to mitigate this. Meanwhile, you still get the benefits of dynamism (concise code tightly focused on the problem domain) within each module.