What's the best way to minimize the need of run time checks?

[BartC]

On 12/08/2016 12:07, Steven D'Aprano wrote:
> On Fri, 12 Aug 2016 07:38 pm, BartC wrote:
>
>> 'year' has been spelled wrongly
>
> How do you know?

I know because my intention was to create a RECORD, with a specific set 
of members or fields. With records, you usually don't just create 
arbitrary named members as you go along.

But in Python, the mechanism and syntax used to create such members is 
the same as used for ad-hoc attributes. This was the point I was making 
about sometimes it can be a little too dynamic.

> There are broadly two tactics that a language can take when it comes to
> attribute (or more widely, variable) names:
>
>
> (1) Editing is cheap, but compiling and testing code is expensive

No, compiling is cheap too.

> The first time I ever compiled a full-sized application (not a particular
> large one either, it was a text editor a little more featureful than
> Notepad) it took something like nine hours to compile on a Mac SE (this was
> circa 1990).

That is completely crazy even for 1990. I was using my own tools then 
and the time to re-compile a 50,000-line application would have been 
measured in seconds. Certainly not minutes anyway (I wouldn't have had 
the patience!).

> How mad would I have been if, eight hours and thirty minutes
> into the compilation, the compiler suddenly stopped with an error caused by
> a mistyped variable name?
>
> Today, I could probably compile the equivalent program in a minute.

I'm actually working on a compiler now that could compile a 50Kloc 
application in about 1/16th of a second (to byte-code; perhaps 1/8th of 
a second to in-memory native code).

A pass that merely checks that names have been declared has effectively 
zero cost.

> It *absolutely makes sense* to require variable declarations (possibly
> including type information, where it cannot be inferred)

My example was specifically about attribute names where pre-declaring 
the set of allowed attributes would not be onerous, would be usefully 
self-documenting, and would allow more errors to be picked up.

(Of course the design of Python makes that impractical because it would 
require the byte-code compiler to see inside imported modules before 
execution is commenced.)

> Turn it around though: one of the reasons why languages like Ruby,
> Javascript, Lua, Python, Perl etc are so ridiculously productive is that
> you don't have to keep stopping to declare variables just to satisfy the
> compiler. Need a new variable? Just assign to it and keep going -- there's
> no, or very little, mental task switching.
>
> Another reason why such languages are so productive is the availability of
> an interactive REPL where you can try out code interactively. How clumsy
> and awkward the REPL would be if you had to keep declaring variables ahead
> of time.

I agree when it comes to variables. But it /does/ allow these extra 
errors to creep in that are not detected until that particular fragment 
of code is executed.

-- 
Bartc