Hacker News new | past | comments | ask | show | jobs | submit login

How about writing tests that enforce invariants?

I have been doing clojure dev for a little bit, and here's what I do -

- Run tests in the background continuously (lein expectations will give you that. or you can write your own shell script)

- Do small checkins, frequently to git

- Write tests that enforce invariants. Haven't gotten to test check yet - but I guess that would be even better.

The trouble with types is they push you into a corner early, and after a while people will be coding to zombie constraints - the constraints that were there before, but not true anymore. They are also verbose, and need tooling to get you out of the corner. If the requirements change a little bit, it could be that, your old solution goes against the grain of the new problem, which is very hard to get rid of without rewriting the code.

With dynamic languages, I find that I think more about the problem, than trying to do constraint satisfaction with other entities in the code, not to mention the language itself.




I've honestly never felt like types have gotten in the way. I also write plenty of tests with plenty of mocking, it's just that the type system means we don't have to write tests for the things the type checker checks for.

I'm having trouble thinking of a time when I felt something akin to what you describe with zombie constraints. If anything, having a good type system makes it easier to rip out code that isn't used anymore. And Generics can help with keeping your solution from getting too specific.


The only dynamic language I used in production code is Clojure, hence my perspective is probably skewed by it.

> I'm having trouble thinking of a time when I felt something akin to what you describe with zombie constraints

Think of deprecated methods in a class, unneeded methods in an interface that are stubbed etc.

> I also write plenty of tests with plenty of mocking

This is good. But what happens to mock objects when the underlying class changes its implementation - It needs a large number of changes in tests.

If you are writing micro-services, the guarantees that typed system gives you are more trouble than they are worth. If your average microservice is less than 10k lines of code, it probably reduces to 1000 lines of code in Clojure, and for the codebase of that size, typed systems provide little value for the cost(atleast for me).


I've run into a case where we model an ID as a number, then added a partner that uses alphanumeric IDs.

But I'm still pro-types, and think they solve way more problems than they cause.


The funny thing is with tooling you get the power of being able to instantly refactor your way out of a "zombie constraint" and seeing if you like it.

There is no textual or design pattern alternative to that - ides simply get you there faster and safer.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: