A proposal... (python)

[AnonymousHero]

But you should be prepared to write such unit tests no matter what the programming language.

No. In Scala/Haskell/O'Caml/Java you *don't* need to write unit test checking for types -- the compiler eliminates that class of bugs. In Haskell (and probably O'Caml too) you can actually make your types strong enough to make static guarantees about list lengths, e.g. guaranteeing that "concat <list-of-length-N> <list-of-length-M>" results in a <list-of-length-N+M>". That is an extreme (but real) example, but the principle applies generally.

I know it may sound like it, but I'm not actually partisan towards any particular language. It's always a trade-off, but you *really* have to know your programming language theory to know what you're trading off and for what.

The litmus test for any new language I learn is this: If the implication "It compiles => It works" generally holds, then it's a good language.

[Derakon]

The litmus test for any new language I learn is this: If the implication "It compiles => It works" generally holds, then it's a good language.

I have years of experience with compiled languages, and I can count the number of times I compiled a program and had it pass all of my tests right off without running out of fingers. Now, you may be a better programmer than I am, but I find it hard to believe you would think that compilation and functionality have anything to do with each other. Sure, you eliminate type mismatch errors from the equation, but those are only a small minority of the errors a typical program will encounter.

[zaimoni]

No. In Scala/Haskell/O'Caml/Java you *don't* need to write unit test checking for types -- the compiler eliminates that class of bugs. In Haskell (and probably O'Caml too) you can actually make your types strong enough to make static guarantees about list lengths, e.g. guaranteeing that "concat <list-of-length-N> <list-of-length-M>" results in a <list-of-length-N+M>". That is an extreme (but real) example, but the principle applies generally.

First, I think you're misreading the scope of unit testing. If it's not types, it's something else.

Second: Java and Haskell are not targets of my absence of strong static typing digression. Strong static typing is mandatory in Java, and optional in Haskell. [I haven't used Scala or O'Caml so no comment there.]

The litmus test for any new language I learn is this: If the implication "It compiles => It works" generally holds, then it's a good language.

By that criterion, there are zero good programming languages in existence.

[Sirridan]

The litmus test for any new language I learn is this: If the implication "It compiles => It works" generally holds, then it's a good language.

Usually true with most good languages/compilers, however the real test is "Did I tell the computer to do the right thing?"

[AnonymousHero]

Usually true with most good languages/compilers, however the real test is "Did I tell the computer to do the right thing?"

Heh, point taken. You can't avoid regressing to that. However, with practise you can get pretty close to telling the computer to do the right thing. That it can then check whether I'm being consistent in my wishes is a good thing .

[AnonymousHero]

First, I think you're misreading the scope of unit testing. If it's not types, it's something else.

I'd rather not have to write tests for classes of errors that a compiler could trivially catch, aka. type errors.

Second: Java and Haskell are not targets of my absence of strong static typing digression. Strong static typing is mandatory in Java, and optional in Haskell. [I haven't used Scala or O'Caml so no comment there.]

Eh, sorry? Optional static typing in Haskell? Are you serious?

I think you may be confusing type inference for weak typing. It's nothing of the sort.

(The forum removed my own part of the quote below. This board sucks at nested quoting )

By that criterion, there are zero good programming languages in existence.

Note that I said "generally", not "always". In O'Caml or Haskell the implication actually does generally hold. Once you get used to that it's very hard to go back.

[zaimoni]

I'd rather not have to write tests for classes of errors that a compiler could trivially catch, aka. type errors.

I think we're in violent agreement.

Second: Java and Haskell are not targets of my absence of strong static typing digression. Strong static typing is mandatory in Java, and optional in Haskell. [I haven't used Scala or O'Caml so no comment there.]

Eh, sorry? Optional static typing in Haskell? Are you serious?

Yes, when I'm programming in Haskell I do use this feature. Bolt in the type signature late in the debugging process, to turn off those parts of type inference that threaten to break the source.