Re: [Caml-list] The boon of static type checking

[Thomas Fischbacher <Thomas.Fischbacher@Physik.Uni-Muenchen.DE>]

On Sat, 12 Feb 2005, Brian Hurt wrote:

> And I disbeleive the "makes it easier with large programs" statement.  
> It's contrary to all evidence I've seen, and all my experience.  The 
> complexity of a program is, I've postulated, a function of the number of 
> interactions between different parts of the code.  And that therefor the 
> innate complexity approximately scales with the square of the number of 
> lines of code- so a 10,000 line program is 100 times as complicated as a 
> 1,000 line program.  Brooks has evidence of this as well.

I don't think this is true. It certainly is for spaghetti code, but isn't 
it just the essence of structured programming to avoid having complexity 
scale like (lines)^2?

There are both quite general and strong reasons why one 
should expect the complexity of programs of roughly the same "style" 
(whatever one has to invent to make a proper, meaningful notion out of 
this) to obey a scaling law of the form

 [nontrivial interactions] ~ [lines]^N

but not necessarily with an integer exponent. I furthermore strongly 
suppose that this exponent should depend a lot on the programmer.

> Very small functions, yes.  But it's less of an optimization than people 
> think, and (especially in C++) it gets way overused.
> 
> Allowing the programmer to force some functions to be inlined is right up 
> there with allowing the programmer to force some variables to be stored in 
> registers in usefullness.

Sure. Never forget that inlining increases the amount of memory and cache 
bandwidth needed for getting the code into the CPU.

-- 
regards,               tf@cip.physik.uni-muenchen.de              (o_
 Thomas Fischbacher -  http://www.cip.physik.uni-muenchen.de/~tf  //\
(lambda (n) ((lambda (p q r) (p p q r)) (lambda (g x y)           V_/_
(if (= x 0) y (g g (- x 1) (* x y)))) n 1))                  (Debian GNU)