Re: Is this expected behavior or not

["Nasser M. Abbasi" <nma@12000.org>]

On 3/22/2013 2:51 PM, Dmitry A. Kazakov wrote:

> Anyway all boils down to run-time
> checks (faults) vs. compile-time checks (errors/bugs). A failed run-time
> check is a program state to anticipate. More such checks you do, more
> states you have, more difficult it becomes to design tests covering these
> states, or just to keep in mind that such states exist and are reachable.
>
> I don't buy run-time checks unless *proven* that compile-time check would
> be impossible to have. And this is not an optimization issue.
>

In languages like Matlab and others like it, which do not
have static type checking and everything is done at run-time,
you'll typically see more than 50% of the code just doing
manual checks on function parameters to make sure it is the
'correct input' needed by the function.

Since there is no compiler to check statically, what ends
happening is that now the programmer is doing what the
compiler could have done and much better.

The programmer spends more time adding code to check that types
match (is this a structure? is this a string? is this a 1D vector
etc...) I am not even talking about checking that the
range of the values makes sense, just to check that the
input is even of the correct 'kind' that is all.

All of this is such a waste of time and energy, as a strongly
typed static language will not need all this, and one will
simply  declare variables of needed types and be done with
it and then spend the time thinking on the problem domain
itself and on the algorithm.

The sad thing, is that more and more languages are going to this
'write anything you want and leave the checking for when the code runs'
way of doing things.

--Nasser