🚀 go-pugleaf

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.

> 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?

> 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.

> >  quickpick
> >  fast(define builtin_bitcount 0)
> >    count = bitcounts[j & 65535] + bitcounts[(j >> 16) % 65535];
> >  fast(define builtin_bitcount 1)
> >    unsigned long i;
> >    for(i = j;i;i >>= 1) count += (i & 1);
> >  endquickpick
> I'm just claiming that there are so many alternative algorithms
> that you'd end up with say a hundred alternatives, and that
> this would happen all over the place.

I don't think so! 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.

---Dan