🚀 go-pugleaf

In article <18281:Sep2702:57:1090@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
>In article <1990Sep26.191602.6195@newcastle.ac.uk> Chris.Holt@newcastle.ac.uk (Chris Holt) writes:
>> It seems as though you want the basic ideas of object-oriented
>> programming,
>
>It seems as though I'm missing the definition of ``object-oriented,''
>which is used as a catchphrase for the much better-defined ideas of
>modularity, portability, reusability, and extensibility.

Sorry, I was using my own private definition ( :-) of an object
as a structure perhaps containing code and data, with a well-defined
formal interface.  However, I think you do want all the buzzwords
above, so it doesn't matter very much.

>> In this case, count-the-bits could be specified as something like
>>         output = sum(bit-to-int over int-to-array-of-bits(input))
>
>But how do you propose to give the compiler a fighting chance to
>optimize this? Rather, to let the programmer give the compiler that
>chance?

What I think I'm trying to say is that the compiler will in general
have a better chance of recognizing specifications than algorithms,
when we start getting into the use of large libraries of alternative
code fragments.

>> If the compiler is to be portable, it's going to have to remember
>> an awful lot.
>
>The compiler won't be portable, because it has to be custom-tailored to
>recognize (e.g.) how to use a count-the-bits instruction.

I'd rather have a portable compiler that has information about a
variety of machines; then it is given as one of its inputs the
parameters that describe the given machine.  Custom-tailoring
is expensive (not that the alternative is cheap).

>        ...  It really is true that 50/80/90% of a program's time
>is spent in 50/20/10% of its code, and that the same holds recursively
>inside each bottleneck. Programs won't balloon just because you're
>simultaneously optimizing for a Sun and a Convex. Also, I doubt there
>are a hundred sensible alternatives for any short section of code.

I think the variety in machine architectures is not going to be
reduced for a while.  It's not just a Sun and a Convex, it's also
a hypercube, a shared memory multiprocessor, a vector machine,
a DAP, a transputer network, etc.  [I don't remember what a
Convex looks like, sorry.]  After all, the attempts at
defining abstract assemblers like JANUS, to solve the nxm problem
for compilers, tended to get into trouble just because there were
so many different machine models around.


-----------------------------------------------------------------------------
 Chris.Holt@newcastle.ac.uk      Computing Lab, U of Newcastle upon Tyne, UK
-----------------------------------------------------------------------------
 "What two ideas are more inseparable than Beer and Virtual Reality?"