Theory Of Language Environment Suckage

Some programming language environments help you more than others. What is one way of quantifying what makes one environment suck less than another? At least in terms of measuring feedback, we have:

: For each of the development stages (edit time, compile/test time, and run time), an error is progressively more difficult to find. A programming environment should do everything possible to expose the errors earlier.

RonJeffries's Corollary:

: And a developer should do everything possible to compensate for the holes in his environment (and those in his head).

Another kind of language environment suckage:

The environment has a very clear and well-defined model for how you should do your work... and it doesn't match your problem domain.

Using this theory to compare languages with StaticTypeSafety to others:

There is a certain class of errors that can be identified before the program is run.
With DynamicallyTyped languages (such as SmalltalkLanguage/PerlLanguage) and simple editing environments, you catch these errors at run time.
With StaticallyTyped languages (such as CeePlusPlus/JavaLanguage) and simple editing environments, you catch this class of errors at compile time, which is better.
However, with a more intelligent editing environment (such as the ones that you typically use for Smalltalk), you can actually catch these errors at edit time, which is even better still.
- Nit. You're catching them at run time because Smalltalk is always running.

Bringing it to the next level, RonJeffries's corollary to the TheoryOfLanguageEnvironmentSuckage states that "a developer should do everything possible to compensate for the holes in his environment (and those in his head)."

There are many, many errors outside the class of errors that can be caught at compile time. These are the ones that cannot be caught without the programmer explicitly stating the expected output for a given input (though DependentTyping or StaticAssert will cover many of these).
In comes the UnitTest, which can catch both kinds of errors. These may not catch the errors at the physical compile time, but to the programmer there is little difference. You hit the big red "compile & test" button, and wait until the environment tells you if you've done anything wrong; does it matter if the compiler or the unit test suite tells you this? UnitTests effectively give you custom control of the "compile-time" rules, so the next question would be, "DoesUnitTestingMakeStaticTypingLessUseful"?

Continuing with the theory, corollary in tow:

There is yet another "time" when you can catch errors: at "think time".
Behold, the discipline of PairProgramming. The very moment you begin to make an error your partner can help you flag it, and vice versa.

However, even if the above is accepted as true, we haven't seen any advantages of dynamically typed languages -- only that they have potential. For that, you must see BenefitsOfDynamicTyping.

Great -- sounds like a terrific argument in favour of using static type safety wherever you learn of a way to apply it.

But what if the types are redundant? What benefit does that then give?

I do hope we are not thinking "redundant == useless" !!

RedundancyIsInertia. In code, inertia isn't good. Therefore, redundancy is useless".

(Much discussion moved to "DoesUnitTestingMakeStaticTypingLessUseful?".)

See OneButtonTesting (but pretend it has relevant contents ;-)

I don't agree with the list of stages (in the beginning of this page). Many BasicLanguage environments written by MicrosoftCorporation catch parse errors in edit time, and continually interrupt you from writing your code.

Nit again. This is run time because BASIC is always running.

In the QuestForThePerfectLanguage, it should be obvious but the environment should not suck. Personally I like being able to just type in a text editor and interpret/compile from CommandLine but if there is an GUI IDE, it should be written in the language itself and serve as an example program

NoSilverBullet