🚀 go-pugleaf

there seems to be a collision of programming styles going on in this
group.  in particular, the edit/compile camp insists that run-time
flexibility is not really needed since most of the work of
instantiation and inheritance can be done at compile or edit time,
while the interactive/run-time binding camp insists that this is not
sufficient.

in particular, william thomas wolfe puts the compile/edit side of the
argument concisely when he writes


      Regarding 1), I have exactly the opposite perspective; in general,
      either a component is readily available (mostly the case), or it
      gets invented on the spot.  Furthermore, in the very unlikely event 
      that I need to slightly modify an existing ADT, a tool can be used to
      generate another level of abstraction and proceed from there. 

what he misses are the real reasons inheritance must be implemented in
a more fundamental way than just a fancy editor.  these reasons are
parsimony in the source text, and flexibility in the program
development phase.

while it is true that having an editor write interface and
implementation code effectively provides the necessary mechanisms of
inheritance, this ignores the fact that the programmer is left with a
LARGE mass of code to work with.  anyone who has tried to write a new
x-window widget that is only a trivial specialization of an old one
can tell you that there is a HUGE amount of code that you have to
learn to ignore.  this overhead should be hidden from the programmer
to simplify the reading of the code (even after you have learned to
ignore huge chunks of stuff), and also to prevent inadvertent
modification.

secondly, having an inheritance mechanism built into the language will
likely have the secondary consequence that the mechanism will be built
into the debugges for the language.  trying to debug an object
oriented program without support from the debugger is similar to
trying to use a debugger which does not support structure display.  a
debugger must avoid presenting the programmer with excessive detail as
a default.

      Regarding 2) and 3), I don't perceive any need for run-time binding.
      Even if we were to define classes of types (characterized by the
      operations which it has available) and allow procedure parameters
      to be described in terms of such classes, this still would simply 
      amount to a more readable version of "this procedure is generic in 
      the type of this parameter; auto-instantiate as necessary after 
      determining at compile time the type of the actual parameter".

you can't be seriously saying the the equivalent of c++ virtual
functions is not needed.  it is crucial that you be able to pass
around an object which is declared to be a relatively general object
but which is in fact some unknown (to the code at run-time)
specialization.  

if you aren't saying this, then you must be saying that the extent of
genericity of a class can be determined at compile time.

if so, consider a program that reads a textual description of objects
to be instantiated.  this is a simplification of what an interpreter
for an object oriented language must do.

how in a completely compile oriented environment can you provide
consistent instantiation mechanism in this case?  must you resort to
the fabrication of an entire run-time class inheritance scheme from
whole cloth?

why is a language that requires this a good one?

- of course, since no other language but ada is worthy, then the
- simulation of object oriented languages is also not worthy :-)