Hi, all,

Michael Feathers tossed off, in a recent thread:

> hoping to see testability as a use case for
> language design in my lifetime

And I'd like to encourage the group here to begin the discussion - if
it's not already underway elsewhere - of what that could mean. I'd
very much like to see the language that emerges from that use case -
and I'm pretty sure I'd like to use it.

For my part, I find it easiest to think about language and (other)
development tools together; that is, the implications of a testable
language I envision through their manifestations in (for notable
example) the IDE. We have some of that with JUnit integration in
Eclipse and other Java IDEs and nUnit integration into Visual Studio,
and it's great to have that, but in what ways could it be better? I
like the notion of some kind of special status for test code that
gives it access to things that might not be accessible to production
code, and an execution context that refuses to execute untested or
failing code - of course the tests need a different execution context
or code could never be tested. I am also fond of the notion of inline
tests - not in a nearby or parallel package, not in a separate class,
but right there in the code: THIS is what this function is required to
do. But I can also see that getting messy.

Michael, what do you imagine a highly testable language would look
like? How would it differ from today's languages, and what impact
would testability have on development and deployment tools? Anyone
else?

Peace,
--Carl

--
http://undisclosed-recipients.blogspot.com
http://www.flickr.com/photos/carlmanaster/sets/228603/