Re: operation can be dispatching in only one type

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Mon, 30 Nov 2015 16:22:12 -0600, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:11das66l3vhic$.1stkau3dqp6ld.dlg@40tude.net...
> ...
>> 2. What makes you think that the compiler always knows better how to
>> control raw memory?
> 
> Because it's true?? :-)
> 
> In an ideal world (with an ideal programming language), the compiler always 
> knows far more than the programmer about the target,

In most cases yes. But note you focused on the hardware here. Even with
hardware, the compiler knows nothing about the layout of a packet from some
I/O protocol. Countless requests here in c.l.a. concerning instructing the
compiler to do it right is a proof.

But when it becomes the problem space the compiler knows absolutely nothing
about handling proxy objects located in the memory. A row of a DB record
result set is a record for which the compiler has no slightest idea how to
map it (onto the DB environment, connection, cursor).

> To the extent that there is information that the compiler doesn't 
> have, the focus should be on giving it that information, not on telling it 
> what to do. (For instance, it is better to tell a compiler which subprograms 
> are "hot" than to tell it that it must inline certain subprograms --  
> inlining is just one possibly way of improving the performance and the 
> compiler is in a better position to juggle the trade-offs than any 
> programmer could be. That's one of the reasons that just-in-time compilation 
> produces better performance than one would imagine just based on 
> traditionally compiling individual subprograms.)

Not exactly. It is true when we talk about non-functional requirements and
wrong for the functional ones. The example with inlining works because it
is non-functional.

> In the real world, of course, there are limitations on compilation time, 
> execution information, and so on, but it still is the case that it is rare 
> that a programmer can really do better at these things (especially at the 
> "raw memory" level) than a decent compiler. That's why it's unfortunate that 
> most programming languages (and Ada is no exception) focus too much on 
> features that can be implemented easily and less on improving abstraction. 

There is no contradiction in providing simple building blocks for higher
level abstractions. There is no reason why indexing or record member access
should be less efficient when a user-defined implementation allowed, but
not actually used.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de