> 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.
.NET is another example. While.NET supports the latest COM implementations and forfeits real pointers altogether, how will.NET truly prove to provide real security (or any kind of functionality which can otherwise be provided more simply, *with* real security); and how will.NET applications prove to accomplish anything which should be accomplished, better than good practice in the technologies.NET supposably supersedes? On the contrary, we can observe that an obligatory aspect of Windows security is disablement of ActiveX, and that a vast proliferation of.NET applications running over The net (without any truly *proven* prescription for true security) may (therefore!) prove to be a huge (next) security disaster, of proportions equal to the very proliferation of such applications.
"Success" of JAVA?
From what I hear and see, there would be more JAVA engineers out of work for many years now than engineers of any other major development language, and, at some risk of unintentionally offending some, I'll submit what many of us said long ago, which imho has certainly proven true: the reasons were plain from the inception of JAVA, because JAVA's limitations and overhead were plain from its very inception.
JAVA projects are notoriously more costly; notoriously more prone to flaws; and notoriously less efficient than alternative approaches. Talk to candid, truthful JAVA engineers, and you'll get the same story: Instead of realizing the promise of portability, they found they had to write down to the least common denominator -- the functionality of the least of involved systems. This itself "suggests" a very limited scope of functionality, achieved at great expense of learning those limitations "the hard way" -- and being "stuck" with them.
Is JAVA as fast, cost effective, or reliable as the best development alternatives? Absolutely not. Nor can it ever be, because even before JAVA existed, development tools reached far beyond the potentials of JAVA. IF JAVA applications ever reached even the functionality threshold of conventional applications, it would be because local JAVA engines evolve to be as much as a second, redundant operating system. Is its concept even as clean and as clear as the best object oriented alternatives? No; and this answer particularly, if we are to respect the concept of building our wares out of the "right" building blocks, is a most important one, as it separates the right tools from the wrong ones.
In engineering anything to be epitomized, nothing is done without a reason, and in fact, everything is done because ALL the questions were asked, and ALL the BEST answers WERE adhered to, without deviation.
There is no "secret" to good engineering: it's a formula for closed doors to software failure (and thus insecurity); it's a formula for unlimited functionality; it's a formula for a balance of speed and resource conservation with no forfeiture whatsoever of reliability. In each of these areas, the very concept of JAVA suffers serious obstructions to excellence, to real portability, and thus to the cost and quality of end product. No time (or possibly place) for [more of] an article here, but you can count me among the many who think JAVA is a crazy way to do ANYTHING. Similarly, I believe there are subversive reasons behind the conception of DOT NUTS; I don't believe DOT NUTS either will serve its purported purposes -- and certainly no better than the best compiled executables of the present (except perhaps for areas of refinement of the object oriented architecture underneath it all -- which only suffers because the preceding architecture was in considerable areas, badly conceived).
Interestingly however, the similarities between JAVA and DOT NUTS implementations are substantial. Even more interesting is the fact that our ahem, exalted, domineering, "fairly competing" company chose the architect of the best object oriented tools of this day -- and what many of us consider the first true object oriented development environment -- to try to engineer this concept into something maybe it cannot be.
But they picked the best for a reason: the best was built on the right formula; and our giant monopoly really CANNOT "compete" unless such perfection is an integral foundation of their venture into a JAVA-like implementation, which strikes me most to serve the interest of involving particularly web development, with a system which at this very moment we can do entirely without, and best do without, if we are to maintain the standard of security carried by Linux. To make a long story short, I say executable web applications -- applications to which client-side executable objects are integral (versus data transmission supported by server-side functionality such as forms, web server applications, etc.) are INHERENTLY insecure, because merely opening the door to execution on the client
In identifying the flaws in this story, a good post. Thank you for it.
One further thing: The weaknesses this purported Trojan/bug (which is mistakenly associated interchangeably to chips or software) purportedly targets, such as the "welds" in the pipelines DO NOT EXIST -- and certainly cannot be "known" to exist by software or hardware. In any pipeline, the welds should be expected to be stronger than the surrounding lines.
But to assert that pump pressures can be mis-managed by an application to exceed vessel pressures, is quite improbable, particularly to intentionally produce so huge an explosion as claimed.
Incidentally, I wonder why we never heard of that explosion otherwise?
I'm reminded of the constant fate of every pathological liar. Evidently, the current regime, which we certainly need to change, believes it enjoys free license to make up anything -- and "we" (the people) shall never know?
Too often the deceiver believes they are a step ahead, when in fact they are many, many, behind.
Slashdot Mirror
> 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 sof
"Success" of JAVA? From what I hear and see, there would be more JAVA engineers out of work for many years now than engineers of any other major development language, and, at some risk of unintentionally offending some, I'll submit what many of us said long ago, which imho has certainly proven true: the reasons were plain from the inception of JAVA, because JAVA's limitations and overhead were plain from its very inception. JAVA projects are notoriously more costly; notoriously more prone to flaws; and notoriously less efficient than alternative approaches. Talk to candid, truthful JAVA engineers, and you'll get the same story: Instead of realizing the promise of portability, they found they had to write down to the least common denominator -- the functionality of the least of involved systems. This itself "suggests" a very limited scope of functionality, achieved at great expense of learning those limitations "the hard way" -- and being "stuck" with them. Is JAVA as fast, cost effective, or reliable as the best development alternatives? Absolutely not. Nor can it ever be, because even before JAVA existed, development tools reached far beyond the potentials of JAVA. IF JAVA applications ever reached even the functionality threshold of conventional applications, it would be because local JAVA engines evolve to be as much as a second, redundant operating system. Is its concept even as clean and as clear as the best object oriented alternatives? No; and this answer particularly, if we are to respect the concept of building our wares out of the "right" building blocks, is a most important one, as it separates the right tools from the wrong ones. In engineering anything to be epitomized, nothing is done without a reason, and in fact, everything is done because ALL the questions were asked, and ALL the BEST answers WERE adhered to, without deviation. There is no "secret" to good engineering: it's a formula for closed doors to software failure (and thus insecurity); it's a formula for unlimited functionality; it's a formula for a balance of speed and resource conservation with no forfeiture whatsoever of reliability. In each of these areas, the very concept of JAVA suffers serious obstructions to excellence, to real portability, and thus to the cost and quality of end product. No time (or possibly place) for [more of] an article here, but you can count me among the many who think JAVA is a crazy way to do ANYTHING. Similarly, I believe there are subversive reasons behind the conception of DOT NUTS; I don't believe DOT NUTS either will serve its purported purposes -- and certainly no better than the best compiled executables of the present (except perhaps for areas of refinement of the object oriented architecture underneath it all -- which only suffers because the preceding architecture was in considerable areas, badly conceived). Interestingly however, the similarities between JAVA and DOT NUTS implementations are substantial. Even more interesting is the fact that our ahem, exalted, domineering, "fairly competing" company chose the architect of the best object oriented tools of this day -- and what many of us consider the first true object oriented development environment -- to try to engineer this concept into something maybe it cannot be. But they picked the best for a reason: the best was built on the right formula; and our giant monopoly really CANNOT "compete" unless such perfection is an integral foundation of their venture into a JAVA-like implementation, which strikes me most to serve the interest of involving particularly web development, with a system which at this very moment we can do entirely without, and best do without, if we are to maintain the standard of security carried by Linux. To make a long story short, I say executable web applications -- applications to which client-side executable objects are integral (versus data transmission supported by server-side functionality such as forms, web server applications, etc.) are INHERENTLY insecure, because merely opening the door to execution on the client
In identifying the flaws in this story, a good post. Thank you for it. One further thing: The weaknesses this purported Trojan/bug (which is mistakenly associated interchangeably to chips or software) purportedly targets, such as the "welds" in the pipelines DO NOT EXIST -- and certainly cannot be "known" to exist by software or hardware. In any pipeline, the welds should be expected to be stronger than the surrounding lines. But to assert that pump pressures can be mis-managed by an application to exceed vessel pressures, is quite improbable, particularly to intentionally produce so huge an explosion as claimed. Incidentally, I wonder why we never heard of that explosion otherwise? I'm reminded of the constant fate of every pathological liar. Evidently, the current regime, which we certainly need to change, believes it enjoys free license to make up anything -- and "we" (the people) shall never know? Too often the deceiver believes they are a step ahead, when in fact they are many, many, behind.