Re: A couple of questions about goops method parameters

[Marko Rauhamaa]

Taylan Ulrich Bayirli/Kammer <address@hidden>:

> Marko Rauhamaa <address@hidden> writes:
>
>> [...] However, since Scheme can do everything C can without static
>> type information, the principal justification for its existence is
>> performance. [...]
>
> I think that's a wrong way to look at it. Scheme has a type system
> too; a dynamic/run-time one.

You are changing the topic a bit.

> The "default" situation would be to have no type system at all, where
> you can add 5 to "foo" and use the result in a floating-point
> operation where it counts as 1.8142093e-316.

It's perfectly fine to avoid errors by generalizing semantics so I
wouldn't mind if you did what you propose. However, the dynamic type
system is necessary for the simple fact that you will need to define
runtime semantics.

As a less convoluted example you could take classic λ calculus or the
abstract set theory, whose entities could really be considered typeless
(no integers, no strings, no files etc).

> That's confusing if you do it by accident, so we use type systems to
> prevent us from it, which is the principal justification for their
> existence.

No, the primary objective is not to prevent errors but to have
well-defined semantics. Scheme, Python, C or Java would function
perfectly well without any type error checking, static or dynamic. The
results could be undefined or a burning computer, that doesn't matter.
What matters is that you know what a well-defined program is supposed to
do.

> The choice between a static and a dynamic one is then influenced by
> their performance characteristics, the time at which they can tell you
> your mistake (compile time vs. run time), how readable they make the
> code (some say manifest types make code clearer), etc.

Yes, early static error checking is a happy side effect of a static type
system.

However, in my extensive practical experience, a static type system,

 * makes writing a program a huge chore,

 * invites lazy shortcuts and accidental mistakes,

 * often makes the logic of the program very hard to follow.

Moreover, coming up with the correct type annotation can become a
frustrating metaphysical exercise. For example, C++ calls for template
acrobatics and C's const keyword is impossible to get right (and nobody
even tries anymore).

I'm seriously saying Python or Scheme programs make it much easier to
write and maintain very complex software systems than C, C++ or Java
even though they don't catch early type or call signature violations.
IOW, you sacrifice a little bit of quality and gain a lot.

The only remaining consideration is performance. There still remains an
ever dwindling niche where dynamic programming languages just aren't
performant enough.

> Sorry for being pedantic. :)

No harm done.


Marko