2018-06-08 17:05 GMT+02:00 Thierry Goubier <thierry.goub...@gmail.com>:
> 2018-06-08 16:35 GMT+02:00 Nicolas Cellier <nicolas.cellier.aka.nice@
> gmail.com>:
> >
> >
> > 2018-06-08 14:50 GMT+02:00 Thierry Goubier <thierry.goub...@gmail.com>:
> >>
> >> Hi Ben,
> >>
> >> Interesting find.
> >>
> >> ... snip ...
> >>
> >> > Table 7 makes and interesting assertion that static types are more
> >> > important
> >> > for readability than preventing bugs.
> >>
> >> This one is in line with Dan Luu meta-study that static typing catches
> >> at best a small proportion of bugs.
> >>
> >> Note that this is used in Smalltalk, when you write anInteger, aString
> >> : you're using a form of typing for documentation.
> >>
> >>
> > Exactly!
> >
> > And if you transpose this style to static typing you get things like
> > Cat *theCat = new Cat;
> > Being tainted, I always thought that is was noise...
> > You'd better rename your variable felix;)
>
> This is a good example of noise :)
>
> What my concern would be is that advances in AI, like the Bayou
> completion system, clearly shows that this is noise and that it can be
> inferred.
>
> > Static typing may help the IDE (refactoring and navigating).
> > My POV is thus that you enter this information for the tools, not for the
> > humans (compiler, navigator, refactoring engine, ...).
>
> I used to believe that, and then I switched to a slightly different
> view, thanks to some use of the OCaml type inference. In some cases,
> when you design systems for reuse (for example libraries), you
> understand that you're building code generic enough to accept a lot
> more than the types you intent to allow (and even static type
> inference manages to infer that fact for you). So, to ease reuse and
> maintenance of your code, typing the API (either by naming convention
> or by restricting types in OCaml) can be a good solution.
>
> Now, the real need for types is when you want to do high performance
> compilation, because compilers are pretty bad at type inference (and
> need very precise and limited types to produce efficient code).
>
> Yes, I don't know these languages enough, but it's indeed an extensible
specification of types (as expectations).
And this have values both for tools (compiling/browsing/static checks) and
humans.
Oh, and if it helps browser, then it helps humans, because browser is for
humans.
Our Smalltalk way would be to use many small Traits specifying the API and
have optional type hints using those Traits
(wasn't it a Strongtalk experiment?)
But note that such static analysis imposes more limits on code than
necessary:
If I have some method like this:
myMethod
myInstVar doSomething
Then a naive static inferencer will deduce that myInstVar can't be an
instance of MyPartlyPolymorphicClass
because it does not responds to doSomething .
However, it's a lot more involved to analyze whether myMethod is ever
reached...
For example, if myMethod send was protected with a guard clause or
exception handling...
mainMethod
myInstVar likesToDoSomething ifFalse: [^self].
myInstVar doSomething
anotherMethodSendingDoSomething
[myInstVar doSomething] onError: [IncorrectInput raise]
IOW, since myMethod is not private, I can't guaranty that the library is
correct.
But a more clever analyzer could guaranty that a certain usage of that
library is.
Even in OCaml or Haskell, I'm not sure whether the type inference would be
powerful enough...
OK, maybe such liberality is not a good feature in the long term
i.e. necessitates implicit knowledge of crooked implicit pre-conditions
that message arguments must meet,
or render the understanding of code difficult, thus the testing, the review
and the modification worse, etc...
But it might be very useful for short term experiments.
Allowing partially correct programs/libraries is an important feature for
the exploring phase.
> I have differently tainted colleagues still thinking that the type help
> them
> > reading code...
> > So, IMO, this assertion reflects the dominant culture rather than
> intrinsic
> > merits.
>
> I still think that whatever name you use for your variables, you often
> convey an idea of a type with your naming choices (i.e. felix is
> probably a cat, probably not a dialog box....)
>
> Agree, type and semantics have some coverage, but as I wrote in answer to
Thomas, such inference requires prior knowledge.
I once had a colleague choosing completely arbitrary names for temporaries
(like the first name of his children).
Whatever the presence of type declaration (C++), this was really disturbing!
Bad names are bad names, and the type declaration does not help that much
in such case.
Nicolas
> Thierry
>
> > Nicolas
> >
>
