Comment "Perceived"... and the Red Light District (Score 1) 291
> A major precondition for the success of a software framework is [its] acceptance...
Not necessarily. The financial success of less desirable, less innovative, less secure, and/or less refined technologies is typically propelled by market sway, however ill founded; and of course, the prevailing sway is not necessarily motivated by fairness, or pure rules of better development. As we look back on the last 25 years for instance, it is obvious that principal market sway has ascribed to a circuitous route which is neither financially or programmatically advantageous to the market masses.
COM/ActiveX is a good example. Is the interface based inter-object communication technique of COM/ActiveX inherently superior to the pointer-based (but COM compliant) techniques of Delphi? On the contrary, ActiveX/COM is inherently an open door to insecurity; requires many times the processing cycles; imposes many times the resource footprint; consumes far more resources at run time... and is designed only to do things we may better do without. You can "improve" upon or elaborate the techniques of COM all you want, but there is no real security (even though the very purpose of COM is inter-object communication in circumstances which *require* security), and COM can *never* be as efficient as pointers, because pointers *are* the most simple, optimal technique.
Yet, on into the many "futures" of COM, the greater masses have been drawn.
An endless serial of further technologies/frameworks are based on COM and its succeeding generations. But what do they provide us? They likewise can only be open doors to security breaches, and yet beyond this impermissible fault, they provide us an inherently inferior way to do something we may not want to do at all (if a consistent purpose is *best* technique). The infrastructure makes that way redundantly complicated, because many steps and skills are required to accomplish the very same purpose which can be accomplished, straight-forward, with pointers. *Then*, a "framework" implements the requisite skills (so that those without the requisite skills can implement the technology -- with this "framework" *therefore* inherently *involving* methods of administrating the many redundant layers of complexity)... and the result therefore is still something which can be no more simple (or better) than using pointers.
Adherents will argue that we need COM methods of interaction for DLLs and other infrastructures. But do SQL servers deploy COM? Hardly so. Why? Because optimal approaches are vital.
Undaunted by insecurity, or by inherently inferior resource consumption, reliability, and processing speed... COM adherents (of many "frameworks") build COM/ActiveX objects into web pages and applications, as if here too we require (or benefit from) COM functionality. But COM is neither more efficient in a DLL than optimized techniques of addressing objects and passing arguments; and what good software design always requires is method-specific optimization -- stripped, direct ways of accomplishing objectives.
The formula for enduring software design therefore is enduring underlying principles; and this does not mean one yet further abstraction of those principles -- it means strict adherence to *the* optimal principles.
Thus, superior frameworks/technologies/tools therefore *can* quietly succeed (even perpetually), because they are based on superior, enduring principles; and work based on these enduring principles too succeeds (not necessarily in the usual market "sense" of selling more tools or infrastructures to a mass of "developers"), because of the very stability of the underlying principles.
While the majority of the market is readily swayed from the best principles, this stability is a real, perpetual principle of better software design (it is even an ostensible objective of the vacillating "ever better" technologies/"frameworks" which purport to better software development); and therefore it is a vital directive for truly successful enterprises (as opposed to enterprises bumbling through one "better" IT after another).
> perceived... perceived... perceived... perceived...
I appreciate then how you prefaced each characteristic with the word, "perceived," because indeed, redundant layers of complexity for instance may not provide better (or enduring) "ease of use," even if the complexity simplifies more complicated issues: those issues may not even exist in a better "framework"/technology. Nor does the claim of security prove closing every door to security breaches, particularly if the very technology is based on an open technique of inter-object communication with no means of real security at all.
I agree with your criteria, with the caveat (implied by your usage of "perceived") that *perceiving* is what establishes the best determination -- which is not the usual stampeded direction of the masses. After all, if we have done our work right, we can ask first 1) how our enterprise application system will benefit from the elimination of real pointers; 2) what then justifies us re-writing millions of dollars worth of code for this ostensible advantage (and calling this "easier" or more expedient); and 3) how all these integral applications will benefit from compiling them JIT...
By the third question at least, we should wonder if we should be swayed by this "new," "better," "innovative" technology.
> Red Light MAKERS, and "STABILITY"
There are of course other aspects of stability, and a common market "perception" is that the most financially successful maker is the product line to go for. If we examine the greatest of these, we find instead that work in one product after another has been subjected to changes which compel re-purchase, but in fact obstruct the stability of our code bases.
Decisions to use *any* such family of wares are the substance for which boards of knowledgeable directors should perform hangings. If these many new "frameworks" were truly stable and advantageous, and if we based our decisions on substance, what question would there be?
