Class Browsers vs Static Types (Re: Inefficiency of __getattr__)

Boris * (1+(is->cic)) borcis at geneva-link.ch
Wed Oct 4 13:03:50 EDT 2000


Marcin 'Qrczak' Kowalczyk wrote:
> 
> [crossposted]
> 
> Wed, 04 Oct 2000 05:41:01 GMT, Kragen Sitaker <kragen at dnaco.net> pisze:
> 
> > OK, so you agree that silent coercions cause problems in some cases
> > in C++, some of which cases are built into the language.
> >
> > So what's the advantage of static typing over dynamic typing?
> 
> More errors are fixed at compile time, before testing.

Mmmhhh...:) one might be tempted to argue that this way of
putting it is politically loaded in the direction of disallowing
undecidable compilability... arguably (as far as I heard recently
on the c.l.f.) undecidable static typing is concievable in the
context of parametric polymorphism and type inference... and before
a language with such a feature, it becomes a bit of an abuse to
distinguish compilation from testing, does it not ?

On the other foot, then, one may argue that "more errors are fixed
early" is a desirable property of any programming system, so that,
if we concile the above idea that forbids us to distinguish
compilation and testing nor to speak of that desirable property in
the terms you used (e.g. as that consequence of static typing),
then we should promote the property as an autonomous principle.

> Sometimes tools in the language are more expressible because of
> static typing, sometimes less. The "more expressive" part relies
> on the ability to determine the meaning by the context of usage.
> 
> My favorite languages, Haskell and OCaml, have static typing and no
> implicit coercions at all.

Logical ;-)

...tempting to suggest that dynamic OO languages have natural
and efficient class browsers and method editors where static
typing languages have natural and efficient checks and
error messages. Is that anywhere close to what you wanted to
say with "more expressive tools" ?

MMmmmhhh... could it not be argued that, even when there is
no check and enforcement, distribution of methods in classes
provide a guideline "network of borders" that helps locating
bugs (relative to other forms of structuring code) ?

> > Does it help you catch bugs, and if so, which ones?
> 
> It certainly does help. It's rare that a large piece of newly written
> code compiles the first time. OTOH it usually works the first time
> once compiles.

Magical !

[...]
> Explicit type signatures are optional in both Haskell and OCaml, but
> Haskell encourages to write them more than OCaml. The effect is that
> when there is a type error in an OCaml program, sometimes I have to
> spend some time finding it, often by adding explicit type signatures
> to see if a function is incorrectly defined or incorrectly used.

Interesting.

> 
> It clearly indicates that if the program was written in a language
> without static typing *in the OCaml's style*, it would be hard to find
> that bugs basing only on runtime behavior, even if tests covered the
> whole code.

This looks as if it could be universally assumed that typing bugs
would translate to bugs during program execution if they weren't
caught during compilation... I am not totally convinced, but would
welcome a bit of convincing theory.

> One thing applying especially to Haskell:

Why Haskell and not OCaml ?

> it's harder to add debugging
> output. It's the basic functional nature, returning expressions
> instead of performing computation steps. So finding bugs at runtime is
> harder, and finding bugs at compile time is easier than in imperative
> languages.

So what we want is an analogue to debugging hooks... again, could
the "programming language organ" that is an "inferred static typing
system" not evolve to "a facility to throw tracing (e.g. recoverable)
exceptions from a lexical distance" ?

What if we assumed the real benefit (or reason for popularity) of dynamic OO
languages to stem from a particular "implicit adequation" of "class &
method-ic" division of code with IDE integration (and related advantages) ?

- where I mean "particular implicit adequation" in an almost algebraic
sense, just as if I was saying (which I am not) that because dynamic OO
languages are "abelian groups" whence static fp language are "non-abelian
groups", the former interface trivially where the latter do not.

- another angle, way to put it : the real canonical OO programming situation,
that which won OO the market, is the one provided by GUI builders; and
it was the old timer's definite feeling upon 1st contact with GUI-builders
powered OO-language IDEs, that this integration killed the role of
a classical entity : the source code file - the things we used to have
listings of. Listings felt like the more manifest and explicit form of a
before then. The change may appear trivial, but in some sense it has
to do with generalizing the notion of syntax from the case of linear
text to something sensibly different.

> I think that the functional style encourages operating on a bit higher
> level of abstraction: combining partially applied functions themselves
> instead of stating what the result is when applied to an argument,
> using wrappers like foldr (Python's reduce) instead of explicit
> recursion, using monads, using custom higher order functions, passing
> lists instead of iteration. Also more values are passed explicitly
> instead of relying on an implicit state.
> 
> In this style there are more "levels" of objects present at the same
> time: plain values, functions of varying arity, monadic actions, lists,
> tuples. Programs are shorter but denser. To manage this complexity of
> flow control and passed state, a static type system is very helpful:
> it is easy to make mistakes by confusing those "levels", and they
> are almost always catched at compile time.

Thank you for this informative exposition.

BB



More information about the Python-list mailing list