3 ms·
Why not fix the problem with 2 languages? Let me explain. You would have: 1. a language for your actual code - the real code of your application (imagine an a
by nnq 15y ago
Why not fix the problem with 2 languages?
Let me explain. You would have:
1. a language for your actual code - the real code of your application (imagine an application programmed in Python or C++)
2. a language to concisely describe what the code does - the code for your "tests" (imagine the tests written in a simplified Haskell or some dialect of mathematical language)
There would be different constrains for the two languages, as language (2) would not have to be efficient or portable or any other requirements you can imagine, it should just be very concise, to allow to describe in a couples of lines what 100 or 1000 lines of language (1) code do.
And it would be very different from just writing very granular tests: the program could be run in "debug" mode, with the language (2) tests or executable-descriptions of a function running after every function call (very slow but still working), and in a "real" mode in the client computer or when profiling and optimizing for speed. You could still have regular test and language (2) could be much simpler than something like Haskell because it would not need have fast execution and it will only be written in short snippets that could be proven correct by "pen & paper" or "mind running".
[minor edit for spelling and paragraphs]
- wladimir 15y agoI really like this idea. You'd essentially have to describe the same system twice, from two angles, and the compiler cross-validates them. This is more work, but I think this will help humans understand what it does, and what it is supposed to do better as well. And it would aid maintenance/refactoring. Behavior that is now implicit in the code would have to be written down explicitly (separating desirable behavior and side effects/bugs), and unlike "design documents" it is actually validated... (ie, a refactoring would be changing representation 1 without changing representation 2) Separating intent and implementation, so to say. You might be on to something.
- apl 15y agoHow does that differ from, say, Haskell's QuickCheck [1] and its ten thousand counterparts in other languages? [1] http://en.wikipedia.org/wiki/Quickcheck http://en.wikipedia.org/wiki/Quickcheck
- nnq 15y agoThanks, I took a better look at that and realized there are 2 implementations of QuickCheck for Python... I'm not really a Haskell developer so I didn't knew much about QuickCheck. Though I still think none of our current programming languages are good "test" languages... I just gave Haskell as an example, but there are probably tons of things that would make it annoying for writing descriptive versions of an algorithm that could be used as tests... And at least the Python version of QuickCheck I just looked at are far from a descriptive "implementation" of a function... they seem more like some test-automation that could only prevent most of the bugs that might not crop up in typed language...