[E-Lang] required type annotations lead to more integration bugs (was: expression-style syntax is insecure? (was: multi ple-domain language, plus Super Newbie is lost without "The Dot" (was: do wn with `define' (was: newbie syntax: picayune points from a prejudiced p rogrammer))))

[zooko@zooko.com]

 Alan wrote:
> zooko wrote:
> > 
> > I certainly agree.  If it were my development team, I would instruct
> > people to start with whatever they felt was easiest while doing
> > rapid-prototyping and then start adding type annotations as they
> > "firmed up" the code or as they did security audits.  This would, IMO,
> > strike the right balance between rapid coding and bug detection.
> > 
> 
> Actually, my experience was the opposite for the first Java version of
> e-speak.  Those developers who cast everything to Object got their stuff to
> compile quite quickly, and even got some small bits of code to run.
> However, the first time they had to interact with someone else's code, they
> spent days tracking down bugs related to type mismatches.


This is the important difference in practice between type *inferencing*
with optional type annotations versus dumb type checking and required
annotations a la Java.  The type mismatches that were so hard to track
down were hidden by the "Object" casts that the programmers had added
(which is, ominously, exactly the same as the ":any" annotation that E
coders will normally use).


If they had type inference (especially with tool support), then each
type mismatch would have been soon identified either by an actual type
checker showing that the code was badly typed or by the inference
annotations showing that the principal type is not what you think it
should be.  (Those annotations could be generated by the
auditor/integrator herself, by other coders, or by a tool like the
Ebrowser.)


No type mismatches would be hidden, but would instead be brought to
your attention.


Leaked-access security flaws will often (but not always) show up as
"principal return type too general", i.e. I'm looking at a function
that is supposed to give me access to a button and it is giving me
access to a frame -- hey waitasec -- why is this function giving me a
frame...?


If you require type annotations then developers will normally choose
the most general for most of their functions, leading to the problem
you experienced with Java e-speak.


Regards,

Zooko

P.S.  I've done the same thing myself in Java -- everything starts
getting cast to Object everywhere... Ugh.  Most of the problems were
with containers, of course, but also with "parallel subtyping", and
also with general uncertainty about interface typing...