{{htmlmetatags>metatag-robots=() 
metatag-title=(Abstractions or distractions? The MIDRES Library) 
metatag-keywords=(Optimization,MIDRES,design,isomorphis) 
metatag-description=(Abstractions are as efficient as their use is consistent with what they were designed for.)
metatag-media-og:image=(::midres-logo-fb.png)
metatag-og:title=(Abstractions or distractions? The MIDRES Library) 
metatag-og:description=(Abstractions are as efficient as their use is consistent with what they were designed for.)
}}

====== ABSTRACTIONS OR ... DISTRACTIONS? ======

Abstractions usually deal with the fact that a program written for a computer would be recompilable, simultaneously, for others. Abstraction simply takes for granted the existence of an imaginary computer, an abstract computer. The abstraction describes its operations. Then this abstract computer is "translated" into the real one.

This approach certainly has the advantage of making the programmer indifferent to hardware changes and, often, such abstractions rely on libraries written in highly optimized assembly.

However, since they are generic libraries, **they are as efficient as their use is consistent with what they were designed for**. If the program that uses the libraries does not work with the same "direction" with which the libraries have been optimized, **the result is certainly worse than the isomorphic approach**.

{{ :midres_library:tutorial:mctile:mctile64.png?nolink&400 |}}

This is almost inevitable if the authors of the libraries and programs are different. Giving an example, try to think about the writing of a single "tile" on the screen. In this case **the optimizations are wasted because the operation is elementary and cannot be further simplified**.

Isomorphisms cannot (co)exist with an abstraction and have no limit of applicability based on the hardware underneath.

Move to page [[midres_library:isomorphism:otherlibs|NOT ISOMORPHISM OF EXISTING LIBRARIES]].

[[:midres_library:isomorphism|{{ :midres-logo.png?nolink&600 |}}]]