[qu4z-2]

Type systems are a little more than just syntax. Static analysis can identify unreachable sections of code, for instance, which will often indicate a bug.

Unit tests cannot prove correctness, only provide a finite set of ways in which the program /isn't/ wrong. (having said that, they're definitely useful)

And above all, he's talking about his ideal programming language. Test coverage is the domain of the programmer. There's very little you can put in a language spec to improve test quality.

For the record, I'm a static typing proponent, and I do most of my coding in vim; I only use an IDE when I /have/ to (I use C# at work). I think a lot of people assume static typing necessarily means very verbose languages like Java, which isn't at all true. My ideal solution is some combination of type inference and optional typing that I haven't quite arrived at yet. I like being able to whip up a quick program without worrying about manual type annotations, but it's nice to be explicit about expected types in an API for instance.

[Someone]

"There's very little you can put in a language spec to improve test quality"

You could require presence of unit tests with 100% code coverage (compile both in memory, run unit tests, write object file if 100% coverage)

I'm pretty sure it would drive people crazy, though, and would have them write almost meaningless tests. 100% coverage isn't enough, either.

[qu4z-2]

As I said, very little that can improve test quality. :)

Good to brainstorm though. But in my experience, anything that breaks flow (like those languages that refuse to compile if there's unused code, even if you've just commented something out for debugging) is a bad idea. Often it's nicest just to write the code, then write the unit tests once you've got the core idea down, rather than having to alternate between them at high frequencies.

[Someone]

OK, try #2:

Loosen the unit test restrictions to just require that edge cases for function preconditions are tested. For example, a precondition 'x>3' would require a test calling a function the function with x=4 and one with x=MAXINT (if x is an int) or with x=nextFloat(3) and one with x=MAXFLOAT (if x is a float)

Ideally, the language would require gets for all edge conditions, but doing that is impossible. Instead, specify something similar to what Java does for 'variables must be provably initialized before use' to find easily detectable (in some sense) edge cases.

Also, allow the IDE to run and debug unit test code before it complies with the rules.

Keep the rule 'never write an object file that can be used outside of the IDE until the code passes tests'.

I think I could find such restrictions useful, if I were writing pacemaker software or something similarly critical.

If you find that too restricting, also allow debugging non-unit tet code from the debugger.

[qu4z-2]

I like the idea of automatically generating a set of test cases, but requiring you to fill out the tests. Even better if I can run

    my-lang --gen-test-cases input.lang

and it outputs stub tests for the edge cases.