[SDL] Off-Topic: Quake II Ported to HTML5

[Mason Wheeler]

>----- Original Message ----

>From: Rainer Deyke <rainerd at eldwood.com>
>Subject: Re: [SDL] Off-Topic: Quake II Ported to HTML5
>>> From: Rainer Deyke <rainerd at eldwood.com>
>>> Subject: Re: [SDL] Off-Topic: Quake II Ported to HTML5
>>>  def max(x, y):
>>>    return x > y ? x : y;
>>>  // What's the type of 'x' and 'y'?  Trick question; the function
>>>  // works for a wide range of types.  What's the return type?  I don't
>>>  // know, maybe the common type of 'x' and 'y'?  Not so hard, is it?
>> 
>> This means that you can't tell what the return type of a function is just
>> by looking at its interface.  It's a serious problem in Python. So much
>> for abstraction and encapsulation, or design by contract...
>
>If you understand what the function does, you know its return type.  If
>you don't understand what the function does, maybe you shouldn't be
>using it at all.

You're still thinking like a code writer and not a code reader.  Of course
you understand what the function does when you create it!  But what if I
created it a year ago, then I went and took another job somewhere else,
and you get a CR to fix a bug that eventually takes you into the routine,
and you've never seen it before.  Don't you want as much *explicit*
information presented to you as possible, to aid you in figuring out what
this function is doing?  With real code these days now spending more
than 60% of its life cycle in maintenance, not development, you're
approaching this from a very counterproductive paradigm.

I think that's the biggest sin of modern ultra-high-level languages:
promoting the dangerous fantasy that the ability to create code quickly
is good, important and desirable.  That sounds nice in theory, but in
the real world the ability to read code, to easily figure out its meaning,
and to catch errors as early as possible are all much more important,
and writing code quickly usually comes at the expense of one or more
of these three.