On 11/10/2010, at 12:24 PM, BGB wrote: > <-- > Does anyone know about a language (possibly something in smalltalk) that > involves spec-driven development? > > A language that stipulates a spec (in code - ie a test) must be written > before any code can be written, and that can also do self-checks (sort of > like a checksum) before the code is executed? > > Julian. > --> > > possibly relevant questions: > what would be the merit of imposing such a restriction? > how would one enforce such a restriction? > how could this be done without compromising the ability to use the language > to get much useful done? > ... > > IMO, any such restrictions are better left under the control of "the > development process" rather than trying to enforce them at the language level. >
The merit of imposing that users write specs first assumes that programmers have a plan before they start writing code, and then encourages them to become aware of their plan and requirements, explicitly laying them out in a series of test of behaviour. (See http://behaviour-driven.org/ possibly for a good explanation of where I'm coming from here). I'm not advocating enforcement, rather encouragement. As most of us know, you cannot happily enforce things on people, let alone programmers - for example Java's nightmarish type system hinders more than helps (in my humble personal opinion, only). One *can* encourage certain things through the FORM of the language/IDE/workspace/etc., though (for example, smalltalk's class browser encourages a programmer to think in terms of classes)... unfortunately composition might be a better practice most of the time and it *may* be that having a class browser as a default tool encouraged the "over-use" of inheritance that we have seen as quite a dominant practice/idea in the OOP world. What I *am* advocating, though, is a checksum that is written by testing suites at various levels that would mean that code wouldn't run unless it had at least the most basic testing suite run against it. I'm advocating that behaviour-tests should be a mandatory part of development (any development process - be it writing a song, programming a program or building a house). The best of us as developers in any realm do these kinds of requirement-conformance "tests" when building whatever it is we're building ANYWAY, so I see it as simply a formalisation of a hitherto unexpressed best-practice. Code should simply be able to test itself, to perform minimal self-diagnostics in the same way that advanced photocopiers or computers can do this. If we bake this in at a micro-granular level, then the reliability and stability of systems will skyrocket. Not only this, but code essentially self-documents then. If we are as programmers, encouraged to document before *and* after we write code, we will end up with a neat description of what we were trying to do and not just the output. As a community, I'm trying to get us to shift from being the kid in maths class who says "12" when the teacher says "What is 3 times 4"? The working out is at least as important as the answer... as we all know in later mathematics, more weight is attributed to the process than to the outcome... if there are 12 steps in a process to build an answer, and only the 12th is incorrect, then that is 11 out of 12 as a score, as averse to if there is only an incorrect answer and no working out, that is 0 out of 12 as a score... or 12 out of 12 if it is correct. Do you see my point here? Of course, just as it's possible to write structured code inside Smalltalk, or any Object-Oriented language, it would be possible to "get around" this encouragement of behavioural-driven-testing built into a language. But that's beside the point. I'm not trying to get to a state where things are IMPOSSIBLE to break. I'm trying to get to a state where they're encouraged to work. If I didn't want to write tests, I could simply write tests that evaluated in true. Hands dusted and done. Mind you, the stakeholders (maybe me) would probably get frustrated as the project gets larger and more regression errors creep in with each suite of changes imposed on the system. Respect, Julian. _______________________________________________ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
