How a scientific Truth can be proved, if everyone try to ignore, cover-up or evade necessary validation by giving every possible excuse?

What is the reality of CBD of physical products? What is the true essence and nature of Component Based Design? For example, what are the properties or aspects that are uniquely and universally shared by every known design of physical products, including the design and development of one of a kind physical products such as an experimental spacecraft or prototype of a next generation Jet-fighter? Why almost every software expert insists that it is impossible to invent real CBSD (CBD for software), without even knowing what is real CBSD? Mankind designing and building hundreds of newly invented products using CBD. For example, let’s see an example that illustrates the reality of CBD: https://www.youtube.com/watch?v=hc5e5cYdshI

Please pay attention to 15 seconds bit starting at 1 minute 55 seconds. Let me paraphrase the 15 seconds bit, as I understood it: Essential purpose of the real CBD or engineering is ability to look, feel and test each component independently to tweak and optimize individually for making each component as best as it can be. Periodically bring the components together to build product for making sure that (a) each of them properly collaborating with other parts, and (b) all the components are fulfilling their respective roles as intended for proper operation of the container product.

Let me define my understanding of reality of true essence and essential aspect of ideal CBD: Implementing over 95% features & functionality in physical replaceable components. The term replaceable component imply any component that can be un-plugged (or disassembled), for example to redesign and test individually outside of the product and re-plugged-in (or reassembled) into the container component/product.

Each replaceable component is 100% free from spaghetti code (or design), because each replaceable component can be redesigned (e.g. even little-by-little) or refactored and tested individually (e.g. to make it as best as it can be and/or to fit exactly and function as expected when assembled into product) without any need for seeing even a single line of internal code (or design) implemented for any other component or container application/product. Over 95% of the code (or design) of the product is free from spaghetti code, since over 95% of the features and functionality of the application or product is implemented in such replaceable components.

Hence true essence of the CBD is eliminating spaghetti code (or design). Over 90% of the features and functionality of almost every known large physical product is implemented in physical functional components, where each component is designed and refined individually (free from spaghetti code/design). It is not necessary that even a single large functional component in the physical product is reusable, standardized or conformed to any component model attributed to so called software components.

Most experts insist software is unique and/or different, without giving any valid reason or explain why and what manner. Designers of every new product need to tweak most of the parts (i.e. functionality and features) continuously and/or frequently until prototype is functioning and performing as expected. So it is not unique to software products. The difference is designers of physical products are doing the tweaks to over 90% of the functionality and features free from spaghetti code/design. Only designers of software unnecessarily burdened with the spaghetti code/design.

No software expert can answer what is the true essence of CBD, but almost every one insist that real CBD for software is impossible. Why is it not possible to achieve real CBD for software, if real CBD for software is to implementing 90% of the functionality and features in such replaceable components? No replaceable component (including the necessary communication code for allowing collaboration between this component and other parts of the application) requires more than 3 to 5 lines to plug-in and removing the 3 to 5 lines must effectively remove the component.

It is impossible to find a valid reason why it is not possible to achieve real CBSD. On the other hand, I can demonstrate hundreds of replaceable components and hierarchies of replaceable components to prove that real CBSD is possible. Almost every researcher and scientist I contacted refuse to see proof to know the reality/Truth. Any scientific Truth/reality or engineering invention (if it is real) can withstand rigorous validation and prevail, but how a scientific Truth can prevail, if everyone try to ignore, try to cover-up or evade necessary validation by giving every possible excuse?

We created the first and the only GUI-API that is capable of creating replaceable GUI components for building complex hierarchies of replaceable components to achieve real CBD for software. So even junior Java programmers can achieve real CBSD for RIA (Rich Internet Applications) with little or no help from us. Achieving real CBSD for RIA help designers gain experience and knowledge about the innate nature and essential properties uniquely and universally shared by each and every known physical functional component, for example, to positively identify features and functionality that can be implemented as equivalent replaceable software components for achieving real CBSD for non-GUI applications as well.

Best Regards,

Raju

Why software scientists refusing to investigate simple and obvious facts (that are found everywhere all around us) to discover reality?

Reality is immutable and never changes. Duty of scientists is pursuit of absolute Truths for discovering the reality (a set of Truths and laws of nature that are proven). Mankind’s perception of reality changed many times. For example, several thousand years ago mankind believed that the Earth is flat. Later 2000 years ago mankind believed that the Earth is static. Until 500 years ago this flawed axiom (i.e. “The Earth is static” considered self-evident truth) shaped our perception of reality (a paradoxical paradigm), which was altered reality filled with retrograde motions and epicycles.

            Philosophers had no problem accepting untested axiom (a Lie: the Earth is static) as self-evident Truth (even though they have no evidence any one ever validated it). But it had taken over 100 years to accept the Truth “the Sun is at the centre”. This Truth faced huge resistance and undergone most rigorous validation.

            Let me introduce reality of CBD (Component Based Development) using a small example. Mankind each year inventing and building 100s of new kind of products around the world. For example, one example is trying to create artificial kidney in this video: http://real-software-components.com/CBD/CBD_of_new_product.html.

Please kindly pay attention to 15 seconds bit starting at 1 minute 55 seconds. Let me paraphrase the 15 seconds bit, as I understood it: Essential purpose of the real component-based design is ability to look, feel & test each component independently to optimize individually for making each component as best as it can be. Periodically bring the components together to build product for making sure that (a) each of them properly collaborating with other parts, and (b) all the components are fulfilling their respective roles as intended for proper operation of the container product.

Please notice the reality of CBD: There is no spaghetti code. Each component can be refined individually and tested outside. Over 90% of the features and functionality is implemented in such components. Any component can be refined and tested individually free from spaghetti code. That is, without any need to see internal design or single line of code of any other component. Hence over 90% of the design is free from spaghetti code. Each component is custom designed to fit perfectly in just one product model, so no component is reusable, standardized or conform to any of the so called component models erroneously attributed to the software components.

Any true scientific fact, concept or discovery must satisfy two conditions (1) it must not contradict the reality we all know in the real world and (2) it can’t be falsified, while being highly falsifiable. In light of these observations, let me define the reality of ideal CBD (Component Based Design) for large physical products: The reality of an ideal CBD for physical products is implementing over 90% of the functionality and features in replaceable components, where each component can be refined and tested individually (free from spaghetti code). The physical product is evolved (or redesigned) by evolving (or redesigning) a set of replaceable components.

Nether complexity nor uniqueness (e.g. of a one of a kind product such as an experimental spacecraft or prototype of a next generation jet-fighter) can prevent designers from achieving 90% modularity. That is, the reality of CBS is implementing 90% features and functionality in replaceable components, where each component is free from spaghetti code (i.e. designer of any component never forced to see even a single line of code implemented inside another component). It is not necessary that even a single component in the product is replaceable, standardized or conform to any so called component models (erroneously attributed for software components).

Unfortunately the perception of reality for software components and CBD for software has been shaped by fundamentally flawed definitions and interpretation of the reality: When Douglas McIlroy proposed building products by assembling COTS (Commercially off the Shelf) parts as we build computers, it was just a proposal – a desire or wishful thinking. It is not a scientific discovery (like the Sun at the centre). There is no evidence any one ever tested its validity. But researchers in late 1960s considered that it is a self-evident truth, and today software researchers have been relying on this as if it is proven fact. Dr. Brad Cox proposed software-ICs in 1980s.

Because of this altered perception researchers completely lost their ability to even see obvious facts and apply reason to discover the reality. It is nice to have software-ICs, but is software-ICs possible or reality? Inventing cold fusion is nice, but can we discover laws of nature that can make it reality? I don’t know about the cold fusion, but I am sure that software-ICs as intended can never be a reality.

I requested many researchers to investigate the reality. Is Software-ICs reality? Is it possible to achieve Software-ICs for any other kind of physical product (e.g. automobiles or Airplanes), where it is not possible to use software and applications for competitive differentiation from competing products? The physical products such as cars must use core components (e.g. engine, gear-box or powertrain) for competitive differentiation from competing products.

For example, the makers or cars, jet-fighters or other products custom design core components for competitive differentiation. For example, even when they are relying on third party component vendor for a component, they work closely with the component vendor to custom design the part to perfectly fit juts one product model. For example, Boeing works closely with Rolls Royce or Pratt and Whitney to build custom engine. Likewise, Honda company works closely with makers of various non-core components such as break-pads to custom build the break-pads (to perfectly fit just one model). One can notice this kind of reality of CBD everywhere all around us.

Software researchers argue that software is unique, different and must undergo constantan changes. Why is it any different from the above example for Artificial Kidney? They must also constantly change each of the components until the whole product works. Only difference is, they don’t have spaghetti code. That is, designer of any component can refine and test his component individually, without being forced to see even a single line of code implemented internally for any other component.

Another reality is: The automobile engineers just deal with many product models within just one product family (automobile product family). Likewise, hardware engineers deals with many kinds of product models within just on product family (i.e. families such as computer or smart-phone). In software, we deal with hundreds of product families ranging from compilers, OS, Video games to MS-Office. It is impossible to reuse core components (e.g. engine or gear-box) for automobile product family can’t be reused in any other product from another product family (e.g. PC or AC). Likewise, core components for compiler product family can’t be used in any other product from another product family such as Video games.

This kind of reality about the CBD of physical products is everywhere all around us. All I am asking is to investigate such simple and obvious facts to discover the reality. Isn’t is obvious that it is impossible to achieve Software-ICs, where it is not possible to use OS and applications for competitive differentiation? Can we invent COTS that allow us to build new products (e.g. Artificial Kidney) that is not yet invented? Is such COTS (e.g. Software-ICs) for not yet invented physical products or that can be readily reusable across hundreds of families of physical products?

Often, designing each new software product is more like inventing a new physical product such as designing one of a kind spacecraft. It is desirable to eliminate the spaghetti code, because the features and functionality must be constantly changed until each of the components and the whole product satisfies the unique and exact requirements. Furthermore, this product must be changed many time in the future to make each successive release. Over 90% of the cost, time and complexity can be eliminated for making large changes by eliminating the spaghetti code.

What is the reason for spaghetti code, even one need to satisfy unique and exact needs by iteratively changing each of the parts little-by-little (e.g. see Artificial Kidney)? Nothing in the reality of CBD for physical products can prevent software designers from implementing 90% of the features and functionality is replaceable components for achieving real CBD for software. Unfortunately every software expert insists that it is impossible to achieve real CBD, without knowing what it is.

How can anyone insist something is impossible, without knowing absolutely nothing and clueless about it? It is impossible to find evidence that any one even ever tried to investigate, what is the true essence of CBD for physical products, such as what is the most useful and striking aspect that is uniquely and universally shared by every known design of large CBD product in the world.

In other words, what are the striking aspects that are unique to the CBD of physical products and universally shared not only by the designers of product models of mature product families (e.g. automobiles) and countless models of crowded product families (e.g. smart-phones), but also the designers of one-of-a-kind product models such as an experimental spacecraft, prototype of next generation jet-fighter or a new kind of fuel-cell or nuclear powered locomotive. It is impossible to find any evidence that any one ever even tried to investigate for answers to this question. But every one insists it is impossible to achieve real CBD for software, without even knowing what it is. Also most of them bluntly refusing to even know what it is.

I am sure, it is possible to achieve the goal of implementing 90% of the features and functionality in replaceable components for any software application. I am openly offering first GUI library that allow anyone to create real software components for achieving real CBD for software. The experience and insights gained while building GUI applications by assembling real software components help software designers discover the truth by experiencing reality. Also I believe, this reality will be more useful than software-ICs, especially for building large software applications.

How do we know and mankind proved, the axiom “the Earth is static” is wrong and the axiom “the Sun is at centre” is correct? Because the second axiom helped us to make subsequent discoveries that include Universal gravity and Newton’s three laws of motion. The three laws of Kepler and Universal gravity with the help of Calculus allowed mankind to create a consistent mathematical model.

These and many other unexpected discoveries (e.g. discovery of the Pluto due to inexplicable perturbations in the orbit of Uranus) conclusively proved that our understanding of reality is progressing on the right path. Of course, many other discoveries such as Theory of relativity shaping our understanding of reality, which hopefully taking our understanding closer and closer to the absolute Truth.

In software, we need to discover reality to define the realistic goals. Achieving Software-ICs is not realistic. On the other hand, it is impossible to find a valid reason why it is not possible to achieve 90% modularity. Today not even 10% of the features and functionality of any large software application is modularized as the way real physical functional components modularize the design of that large physical products.

P.S: Sample description for CBD application at: http://real-software-components.com/CBD/City_GIS.html. An example CBD application for 5 cities can be found here at: http://www.pioneer-soft.com/#/realairtraffic. Please notice Airplanes and Ambulances moving and clicking on Airplane gives real-time data. The shapes and colours indicate various states. Few other such features are not shown.

Best Regards,

Raju Chiluvuri

What are the root causes that are seeds for the Scientific Crises?

In real science, anything not having conclusive proof must be considered as no more than an assumption. A real proof requires irrefutable rational reasoning backed by predictable and repeatable empirical evidence.

            The root cause of one of the most famous scientific crisis resulted from evolving mankind’s knowledge by relying on flawed untested assumption ‘the Earth is static at the centre’. This axiom or postulation was considered self-evident fact needs no proof. No one considered that it is an assumption and no one consciously aware (and could have named it ) that this axiom was at the root of mankind’s perception of reality (i.e. About 500 years ago, this reality was a complex paradoxical paradigm comprising countless concepts backed by meticulously documented retrograde motions and epicycles constructed for over 1000 years).

            Of course, root cause was untested and unproven axiom “The Earth Was Static at the Centre”, which was widely accepted as self-evident Truth 2000 years ago. Can this kind of thing happen in 21^st century? Of course, I am sure there could be other such scientific crises in existence even in 21^st century? Many experts feel that this kind of thing can’t happen today, because mankind’s scientific knowledge, processes and expertise advanced substantially during past 500 years. I disagree.

            I discovered such root cause for scientific crisis in the field of computer science. An important sub-field of computer science is CBSE (Component Based Software Engineering). At the root of CBSE there exists such axioms or postulations, which were considered self-evident Truths 50 years ago (so required no proof or even documenting for future generations to know for validation). That is, 50 years back software researchers assumed that it is impossible to invent real-software-components equivalent to the physical functional components for achieving real CBSD (Component Based Software Design for Software Products), where real CBSD must be equivalent to the CBD of physical products (e.g. one–of-a-kind experimental jet fighter or prototype of a spacecraft).

            It was a reasonable assumption when leading edge programming languages were assembly languages and FORTRAN. Structured programming languages were a distant dream. Things like Object-Oriented Programming languages and GUI components (that are more conducive for real-CBSD) were beyond imagination. So they started using the term ‘software components’ as an alias to useful software parts. In other words, they defined each kind of software components is a kind software parts either having certain useful properties (e.g. reusable or standardised) or conform to a so called software model.

            Today no one even aware of the root cause (e.g. axioms) for such definitions for software components. Today if you ask any one, why do we need many different and strange descriptions for software components and CBD for software products, they give excuses such as software is unique and/or different, without giving any proof or justification for why and what manner software design is deferent from the design of one–of-a-kind products such as experimental jet fighter or prototype of a spacecraft.

            Why can’t we invent software components that are equivalent to the physical functional components for achieving real CBSD, where real CBSD is equivalent to the physical products?

            To invent real software components (that are equivalent to the physical functional components) requires discovering (i) accurate description for the physical functional components and (ii) accurate description CBD of physical products (e.g. for achieving the real CBSD that is equivalent to the CBD of physical products). Best way for defining an accurate description for any physical being (e.g. a specie) is by finding a set of essential properties uniquely and universally shared by each and every specimen belong to the specie (e.g. to positively identify each of the specimen, weather the specimen belongs the specie or not). Likewise, accurate description for CBD of physical products requires finding essential aspects uniquely and universally shared the CBD of each and every known physical product.

            Many experts come up with strange excuses, when I ask why we can’t invent that software components that are equivalent to the physical functional components by discovering the essential properties of the physical functional components. Mankind’s scientific knowledge comprises accurate descriptions for countless complex and physical beings or species that are 20 time more complex than physical functional components, such as in fields ranging from biology, zoology or scientific discipline of microbiology such as virology, mycology, parasitology, and bacteriology. They insist that it is impossible to find such essential properties for physical functional components, without ever trying or showing any evidence that any one ever tried.

           

If one deeply investigates the root cause of each of the scientific crises, he end up finding a hidden flawed axiom at its root, which in past considered self-evident truth and no one ever tried to validate. Seeds for a scientific crisis would be sowed when researchers pick an axiom based on their senses or instincts, without either documenting or finding valid scientific proof. Mankind followed their collective senses, when they assumed that the Earth is static. Researchers followed their then collective instinct, when they defined each kind of useful software parts are a kind of software components. It was beyond their wildest imagination 50 years ago that it might be possible to invent software components that are equivalent to the physical functional components for achieving real-CBSD, where real-CBSD is equivalent the CBD of physical products. Even structured programming was distant possibility 50 years ago and Object oriented programming and GUI library was not even contemplated.

This paper provides the root causes for any scientific crisis. This also provided a proof that kind of error could possible even in the 21^st century. It is the responsibility of the research community to investigate the Truth, if any lone researchers discovers a root axiom and no one can find any evidence that the root axiom was validated. Insulting or snubbing the lone researcher for questioning the validity of such axioms is not called for and unbecoming of a scientist or researcher. In real science, no axiom is self-evident Truth until the axiom is tested and validated.

Who discovered that ‘’the Earth is static’?  Ans: No one. There is no proof and no one tried to proof it. Who discovered that the Sun is at the centre? Ans: Copernicus. Who discovered any kind of useful parts is a kind of component? And: No One. They why researchers have been blindly defending the so called software components?

P.S: More about it at: https://www.researchgate.net/publication/280803360_What_is_this_thing_called_Science_What_is_real_science_any_way

Best Regards,

Raju

Who is better: the 21st century software researchers or 16th century scientists who felt that it was a blasphemy to say ‘the Earth is moving’?

Is it a blasphemy to ask respected researchers to discover objective facts about the quintessential nature of the large physical functional components (e.g. essential properties uniquely and universally shared by each and every known physical functional component) and essential aspects uniquely and universally shared by any CBD (Component Based Design) for one of a kind physical products such as building a working prototype of a next generation Jet-fighter, nuclear powered locomotive engine or spacecraft?

It is shameful and scandalous that even in 21^st century modern scientific and engineering disciplines (originated just about 50 years ago from mid 20^th century) are rooted in myths, wishful thinking and fantasies (e.g. that forced researchers to practice 21^st century alchemy).

Mankind believed until 500 year ago that “the Earth is static (at the center)”. Mankind evolved a complex paradox (altered reality) for thousands of years by relying on this unproven myth (e.g. by considering that it is an inalienable Truth).

Which planet is at the center? Who made the great discovery “the Earth is static”? Who verified this discovery, before accepting and relying on it as an inalienable Truth for advancing the mankind’s knowledge for 1000 years? No one asked this simple question: Is there any proof to show that “the Earth is static”?

Who discovered software parts having useful properties (e.g. reusable or standardized) are real components for software for achieving real CBD (Component Based Design) for software products? Obviously this is in clear contradiction to our knowledge facts and the reality we know about the physical functional components and CBD of new and one of a kind physical products (e.g. experimental spacecraft and prototype of a next generation jet fighter).

But no one asked this simple question such as: Is there any proof to show that it is a Truth before relying on this myth and wasting several decades? What are physical functional components (e.g. what are the essential properties uniquely and universally shared by each and every known physical functional component)? What is CBD for physical products (e.g. what are the essential aspects uniquely and universally shared by each and every known CBD of physical products)?

Any one ever proved that it is impossible to find such properties/aspects? If the answer is no, any one ever proved that it is impossible to invent true software components (having the essential properties) equivalent to the physical functional components? To prove that such newly invented components are real, they must be able to achieve real CBSD (CBD for software products), where the real CBSD must share the essential aspects of real CBD for physical products?

Today it is even impossible to find any one even ever tried to discover such properties/aspects. When computer science was in infancy 50 years ago, a committee decided that reusable software parts are software components (without any basis and reality). The committee set the goal for the CBSE is to build software products by assembling reusable components from 3^rd party component vendors as mankind has been building the computers by assembling COTS (Commercially Off The Shelf) components by ignoring the countless realities. For example, computer engineers deal with just one product family (i.e. computers) and use software for competitive differentiation, while software engineers need to deal with numerous and ever expanding product families such as OSs, compilers, Games, MS-Office, ERP or browsers etc.

Mankind wasted many centuries by relying on untested myth that “the Earth is static”. We all know that, no one proved that it is ‘the Earth is static’. It was just a myth originated thousands of years ago and passed on to each of the successive generations.

Mankind already wasted few decades by relying on hidden untested and undocumented myths by using baseless excuses such as software is unique and/or different. How many more decades mankind can afford to waste by relying on such baseless myths created in the formative years of computer science and passed on to each of the successive generation of researchers, who are forced to practice 21^st century alchemy?

Is it possible to invent reusable (i.e. COTS) physical functional components for build not yet invented or new one of a kind physical product by assembling such COTS? Then how is it possible to invent such software components to build software products for ever expanding software product families? Isn’t it equivalent to the 21^st century alchemy?

The discovery that “the Sun is at the center” resulted in a radically different reality, which comprising countless concepts that are in clear contradiction (e.g. diagonally opposite) to previously undisputed geocentric paradox. Now we know that it was foolish to use widely accepted concepts of geocentric paradox to discredit the Truths that were basis for then fledgling new heliocentric paradigm.

Likewise discovery of Truth (e.g. the essential properties/aspects) would result in a new radically different reality, which would comprise of countless concepts that will be in clear contradiction (e.g. diagonally opposite) to existing undisputed CBSE paradox. It is foolish to use widely accepted concepts of existing CBSE paradox to discredit the Truths that are at the root of fledgling paradigm that can be evolved by relying on the Truths.

Since the existing CBSE paradox evolved from myths (e.g. such as it is impossible to invent real software components equivalent to the physical functional components), no concept of the existing CBSE paradigm can be used to contradict the Truths (if the truths are in contradiction to the myths at the root of the existing CBSE paradox). It is an invalid circular logic to use the concepts of the existing CBSE paradox to defend the myths at the root of the existing CBSE paradox (e.g. to discredit the Truths of new proposed fledgling paradigm).

Galileo Galilee … I do not feel obliged to believe that the same God who has endowed us with sense, reason, and intellect has intended us to forgo their use.

Computer science needs scientists not yet forgo sense, reason, and intellect. How and where can I find such experts? I can understand why the 16^th century scientists believed that the “Earth is static”. Because they lived all their life on the Earth and not only themselves but many generations found no reason to suspect that “the Earth is moving (around any planet)”. But what reasons software researchers have to blindly defend the myths conceived 50 years ago about the software components and CBSE. Many experts not only blindly following the myths but also ferociously defending the myths conceived 50 years ago, even though countless concepts related to the software components and CBSE are in clear contradiction to the reality we know about the physical functional components and CBD of physical products.

Best Regards,

Raju