3 ms·

In most cases I agree with you. In this case though, the speed penalty could have been an argument not to use contracts.ruby...and I wanted to avoid that :)

catnaroek 13y ago
Runtime tests always cause a performance penalty. (And they do not prevent you from writing buggy programs! They just make the runtime environment yell at you if a bug is found.) If you want to guarantee that a property holds for all the elements of a set (every possible running instance of a program), forget about the elements and work with the set's definition (the program itself).
- egonschiele 13y ago
  Do you mean something like laser?: https://github.com/michaeledgar/laser https://github.com/michaeledgar/laser
  - catnaroek 13y ago
    LASER's homepage ( http://carboni.ca/projects/p/laser http://carboni.ca/projects/p/laser ) for some reason does not load in my browser. http://downforeveryoneorjustme.com/http://carboni.ca/projects/p/laser http://downforeveryoneorjustme.com/http://carboni.ca/project... Judging the project from its feature list in the README.md, it does not seem like LASER is capable of handling arbitrary invariants.
- ufo 13y ago
  Static analysis is really hard in general though, and in complex and highly dynamic languages like Ruby its even harder. Some things you really are better off using runtime checks for... And in the end, smaller overhead on the contract checker means that the programmer has more room to add extra tests and less reason to turn off the checks in production.
  - catnaroek 13y ago
    If you are developing a system meant to be stable and run for an indefinite period of time, static analysis imposes less computational overhead. You pay the price of static analysis only once. You pay the price of runtime checks every time you use the checked functionality. Even worse, if a check in the middle of an ongoing transaction fails, you must accept the cost of rolling back the whole transaction. From a purely computational point of view, static analysis is less expensive. (Of course, this analysis of the situation changes drastically if you take into consideration the overhead on the poor programmers' brains. Static analysis is intellectually more demanding.)
    - vidarh 13y ago
      Static analysis of any sizeable Ruby program is at best an unsolved problem, at worst impossible, as a lot of Ruby libraries depend on eval() and tracing down the sources of data for the eval string to verify that it isn't potentially user supplied (and often it can be)is hard enough, and the moment the data may be user supplied, you've "lost": Pretty much anything you thought you knew up to the eval() call can be wrong after the eval() call. If you need/want static analysis, the option for the foreseeable future is to use another language (and I say this as a huge Ruby fan that also would love to see an evolution of Ruby that'd make some/more static analysis feasible, but for that to happen I believe you need an effort to provide a module encapsulating common eval() behaviour and a huge effort to replace eval in common Ruby libraries - it's not likely to happen anytime soon).
vidarh 13y ago
A thought for you: Testing with respond_to etc. is great. But there's a special place in hell for you if you get people to start testing against specific classes. It's almost always a horrible anti-pattern in Ruby to do "kind_of?" tests or similar, unless you depend on a huge portion of the interface of said class. But almost always code that does tests like that really only depends on a method or two, and doing class based tests makes the code vastly less reusable. I don't want to dissuade you from this project. There are useful things you can do with contract specifications in Ruby that'd be interesting to explore. But I do hope to dissuade you from having all those class based tests in your tutorial for example...

catnaroek 13y ago

Runtime tests always cause a performance penalty. (And they do not prevent you from writing buggy programs! They just make the runtime environment yell at you if a bug is found.) If you want to guarantee that a property holds for all the elements of a set (every possible running instance of a program), forget about the elements and work with the set's definition (the program itself).

egonschiele 13y ago
Do you mean something like laser?: https://github.com/michaeledgar/laser https://github.com/michaeledgar/laser
- catnaroek 13y ago
  LASER's homepage ( http://carboni.ca/projects/p/laser http://carboni.ca/projects/p/laser ) for some reason does not load in my browser. http://downforeveryoneorjustme.com/http://carboni.ca/projects/p/laser http://downforeveryoneorjustme.com/http://carboni.ca/project... Judging the project from its feature list in the README.md, it does not seem like LASER is capable of handling arbitrary invariants.
ufo 13y ago
Static analysis is really hard in general though, and in complex and highly dynamic languages like Ruby its even harder. Some things you really are better off using runtime checks for... And in the end, smaller overhead on the contract checker means that the programmer has more room to add extra tests and less reason to turn off the checks in production.
- catnaroek 13y ago
  If you are developing a system meant to be stable and run for an indefinite period of time, static analysis imposes less computational overhead. You pay the price of static analysis only once. You pay the price of runtime checks every time you use the checked functionality. Even worse, if a check in the middle of an ongoing transaction fails, you must accept the cost of rolling back the whole transaction. From a purely computational point of view, static analysis is less expensive. (Of course, this analysis of the situation changes drastically if you take into consideration the overhead on the poor programmers' brains. Static analysis is intellectually more demanding.)
  - vidarh 13y ago
    Static analysis of any sizeable Ruby program is at best an unsolved problem, at worst impossible, as a lot of Ruby libraries depend on eval() and tracing down the sources of data for the eval string to verify that it isn't potentially user supplied (and often it can be)is hard enough, and the moment the data may be user supplied, you've "lost": Pretty much anything you thought you knew up to the eval() call can be wrong after the eval() call. If you need/want static analysis, the option for the foreseeable future is to use another language (and I say this as a huge Ruby fan that also would love to see an evolution of Ruby that'd make some/more static analysis feasible, but for that to happen I believe you need an effort to provide a module encapsulating common eval() behaviour and a huge effort to replace eval in common Ruby libraries - it's not likely to happen anytime soon).

vidarh 13y ago

A thought for you: Testing with respond_to etc. is great. But there's a special place in hell for you if you get people to start testing against specific classes. It's almost always a horrible anti-pattern in Ruby to do "kind_of?" tests or similar, unless you depend on a huge portion of the interface of said class. But almost always code that does tests like that really only depends on a method or two, and doing class based tests makes the code vastly less reusable. I don't want to dissuade you from this project. There are useful things you can do with contract specifications in Ruby that'd be interesting to explore. But I do hope to dissuade you from having all those class based tests in your tutorial for example...