Three weeks ago I have written about my interest in validation libraries. There were some benchmark results in that post that I was not too happy with. I am working on a new, more comprehensive benchmark.
Type systems should be considered design tools rather than safety wheels of a programming language or laser guided missiles for software defects. Compile time type checking can find type related defects, but not value related ones. Values are not known yet.
Lazy evaluation is delaying known operations until they are forced. What I mean by laziness in this post is a bit more general than that, for some constructs what operations are delayed is not known and some are evaluated before a value is forced. When used correctly these differences should not matter. A significant detail, however, is that they all evaluate at most once.
First part was about certain biases managers of software developer have towards taking shortcuts and against taking bitter pills in general. To recap:
- The cost of doing the right thing™ can be calculated but the cost of dealing with foreseeable problems can only be estimated.
- Things might just work out fine in the end.
- It is easier to manage down.
- Blame can always be shifted below.