If computer science is not real science, can researchers of computer science/engineering pretended to be scientists/engineers?

  

Software researchers are blinded by their prejudice and confirmation bias. They refuse to consider the possibility that definitions based on their flawed assumptions about the essential property and nature of the physical components might be wrong (e.g. nature of components is not reuse). One can even convince a devote priest, a possibility that there is no God. But one can’t make software researchers to see the obvious reality and investigate Truth: http://www.researchgate.net/publication/284167768_What_is_true_essence_of_Component_Based_Design

I contacted hundreds of researchers and they used every possible excuse in the world to avoid their obligations and sacred duty, which is to investigate the Truth and Reality. Pursuit of absolute truth is not only an obligation of real scientists but also a sacred duty. They made up their mind and not open to rational reason or investigating Reality. Simply they are refusing to know reality to investigate Truth. This is how members of any cult behave.

It would send shockwaves across research community of any mature scientific disciplines, if one of the basic discoveries or axioms (considered to be self-evident fact) at the root of a major sub-discipline of any mature scientific disciplines has never been tested and might be flawed. The software researchers justify their relying on untested axiom by saying that the computer science is not real science and/or software engineering is not real engineering. If that is true, why do they pretend that they are scientists, researchers and/or engineers? Instead of blocking the progress of knowledge, they must have integrity to allow real scientists to investigate the reality. If computer science is a religion they must be priests. If computer science is a cult they must be cult leaders.

Even the basic sciences were not real science until a flawed axiom (considered to be self-evident fact) at the root was exposed. Saying that the Sun is at the center (500 years ago) offended common sense and deeply entrenched conventional wisdom. The philosophers (scientists referred to as philosophers) blinded by their prejudice and confirmation bias, choose to impression Galileo for life rather than investigate reality by looking through his telescope.

If the philosophers were wrong (i.e. a cult) for relying on untested axiom (i.e. the Earth is static) until 500 years ago, software researchers and scientists were also a cult for relying on axiom that were never tested. No one can name, who discovered and who proved the definitions for so called software components and CBSE. If I am wrong, where can I find the documentation for the proof? Defending and relying on untested axioms (by insisting the axiom is self-evident Truth requires no validation) is not science but a cult.

History proved that no real science can ever be created by relying of an untested flawed myth (by concluding that the myth is self-evident truth requires no validation). How any one can pretend to be scientists/researchers, if they insist that there is nothing wrong in relying on untested fundamentally flawed axiom for advancing the our knowledge (e.g. when there is no evidence exists to show any one ever validated the axiom)? Furthermore almost every one admits that existing concepts and definitions for CBSE contradict reality we know about the physical components and CBD of physical products.

Mankind already wasted 30 years by relying untested axiom (i.e. myth) and willing to waste rest of their life by relying on the myth rather than investigate the Truth and Reality. If this kind of flaw is discovered in basic sciences such as physics or botany, wouldn’t it send a shockwaves? Unfortunately software researchers justify this by saying computer science is not a real science and yet they consider them selves scientists and researchers.

How can they consider themselves scientists and engineers, if they insist computer science is not real science and software engineering is not real engineering? If computer science is real science, can they rely on untested myth (by insisting that it is self-evident fact that needs no validation)?  Don’t they need to have an irrefutable proof for the basic facts on which they have been relying for advancement of knowledge? If the basic fact on which they have been relying is flawed, isn’t every concept derived most likely be flawed?

They made up their mind and not open to rational reason or investigating Reality. This is how members of any cult behave.  Not only they are wasting their time by relying on untested myth, they are teaching the myth (as if it is self-evident Truth) to brainwash impressionable students to expand the cult. If one ready to accept software is not real science/engineering rather than investigate Truth, how can he consider himself a scientist/researcher?

Can any real scientist ignore reality and continue to rely on unproven myths (by refusing to investigate reality), even after acknowledging that the myths were never validated, and has no basis in reality but in fact contradict reality? http://real-software-components.blogspot.in/2015/11/each-researcher-has-obligation-to-know.html

Best Regards,

Raju Chiluvuri

How to explain simple facts to the smartest researchers or scientists, who are brainwashed or deeply influenced by conformational bias?

It reminds me Will Smith’s dialogue in iRobot (smartest dumb person), when an expert refuses to verify simple fact that contradicts his paradoxical paradigm, where the fact is otherwise simple and obvious to even a layman.

How can any one say some thing is impossible without ever even trying or even knowing what it is? No software researcher knows the answer to a simple question (i.e. what is CBD) and yet blindly insists that it is impossible, without ever even trying to know what it is (that he is insisting is impossible). How could any one conclude that it is impossible without ever even trying?

The question is: What is meant by the CBD (Component Based Design) for the large physical products? That is, what is the true essence of the CBD? For example, what are the striking aspects or characteristics uniquely and universally shared by each and every known CBD (Component Based Design) of large physical products?

In other words, what are the striking aspects 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. cell-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.

In software, we deal with 100s of product families ranging from compilers, OSs, Word, Spreadsheets, Games, Browsers, RDBMS, Hadoop, search engines, PDF and ERP etc. The design of most software products is more like designing of one of a kind product such as an prototype of an experimental jet-fighter rather than the design of a model in a crowded product family such as cell-phone, where software (e.g. OS and apps) are used for competitive differentiation but not the core components (e.g. DRAM, Screens or Flash memory).

Even in mature and crowded product families such as automobiles, the core components (e.g. engine or gear-box) are custom designed for each model for competitive differentiation. A mature product family means, first model of the product invented decades ago, while crowded product family means, hundreds of new models belong to the product family is under design by dozens of product makers each year.

Let me define “what is real CBD” (e.g. true essence and striking aspects): Implementing about 90% of the features and functionality in replaceable components (i.e. real functional components), where each component can be disassembled to redesign it individually and test it outside of the product. Once the component is made as best as it can be, it can be re-assembled to make sure it fits perfectly and performs as expected.

Every year mankind is trying to invent and design 100s of new kinds of physical products. Kindly allow me to give a simple example for real CBD. Please watch this short 3 minute video either at: http://www.real-software-components.com/CBD/CBD_of_new_product.html or at you tube https://www.youtube.com/watch?v=hc5e5cYdshI – This shows the reality of CBD of physical products, where no core component is reusable or standardized.

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 engineering is ability to look, feel and 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 fit perfectly and properly collaborating with other parts, and (b) all the components are fulfilling their respective roles as intended for proper operation of the container product.

Designer of no physical functional component needs to deal with spaghetti code/design, because it can be disassembled for redesigning to make it “as best as it can be” (e.g. refining little-by-little by finding and fixing its shortcomings) and testing it individually. Designer of no physical component needs to deal with spaghetti code, because he is never forced to see even a single line of code implemented within any other part. Each and every large physical product is free from spaghetti code, because 95% of the features & functionality is implemented in such replaceable components, which are free from spaghetti code.

Therefore, the striking aspect of the CBD of physical products is – no spaghetti code/design – about 90% of the features and functionality is implemented in replaceable components, where a replaceable component means a component that can be disassembled for redesigning it individually and re-assembled after testing in outside of the product.

Therefore, a real CBD for software can be defined as: implementing over 90% of the features and functionality in replaceable components (or real software components that are equivalent to the physical functional components). How can we invent real software components that are capable of achieving real CBD for software? One way is to discover the sticking characteristics uniquely and universally shared by each and every known physical functional component. Unfortunately every software researcher insisting that it is impossible to achieve real CBSD by refusing to learn the simple truth, which is otherwise obvious.

The software researchers have been pursuing fantasy and goals that are impossible to achieve such as software-ICs, reusable or standardized components for 50 years. Designers of no physical product achieved the goal such as software-ICs, except computers and cell-phones because they are using not the core components (e.g. CPU or DRAM) but the software (e.g. OS and apps) for competitive differentiation. How do they imagine that it is possible to build software by assembling COTS (Commercially off the Shelf) components, when designers of no other physical product (where software can’t be used for competitive differentiation) ever achieved such fantasy?

On the other hand, no large physical product failed to achieve real CBD, where real CBD can be defined as, implementing over 90% of the features and functionality in replaceable components. Either complexity or uniqueness (e.g. such as one-of-a-kind prototype of a spaceship or a new kind of experimental jet-fighter) can’t prevent the designers from achieving the real CBD. Each replaceable component is free from spaghetti code, because it can be disassembled to redesign individually and test it independently outside of the product. Since 90% of the design/code is implemented in such components, over 90% of the code/design is free from spaghetti code/design.

Many experts insist that it is impossible to achieve real CBD for software, without ever even trying. In fact, no one even knows or ever heard what real CBD is, but blindly insists that it is impossible. No one ever tried to define what real CBD is or try to achieve real CBD for software. If they tried, they would have achieved within a short time. If anyone disagrees, I respectfully request him to show me proof, if any one ever even tried to define what is meant by CBD for the physical products, for example, what is the true essence and essential aspects uniquely and universally shared by design of any known large physical product.

The DEMO pages in our website (e.g. www.pioneer-soft.com) demonstrates many real-software-components and sample applications, if they want to see the proof that it is possible to achieve real CBD for software. In fact, any one can create real-software-components and hierarchies of replaceable components using our GUI library. And yet many researchers refusing to verify the proof, by insisting that it is impossible to achieve real CBD for software.

The software researchers erroneously concluded decades ago that CBD is using reusable or standardized components and pursued wrong goals such as software-ICs for many decades, but not seceded and will never succeed. So they concluded that it is impossible to invent real CBD for software. Now they are not only insisting that it is impossible to achieve real CBD but also refusing to know the truth about the real CBD (i.e. accurate definition for real CBD).

The well known and irrefutable fact is, for real CBD (e.g. of the artificial kidney or an experimental spaceship), it is not necessary that even a single functional component is reusable, standardized or conforming to any so called component models attributed to so called software components. Their own conformational bias is preventing them from seeing even such simple facts, which are otherwise obvious to even the laymen.

Isn’t it a classic example for extremely smart expert behaving like a dumb person? How can I get through him and make him validate the truth – physical evidence. We can provide any help he needs to build hierarchies of replaceable components (e.g. http://www.real-software-components.com/CBD/City_GIS.html) on his own to experience the truth firsthand. I made this offer countless times to hundreds of researchers.

Let me conclude this long post by quoting Galileo’s famous letter to Kepler:  "My dear Kepler, I wish that we might laugh at the remarkable stupidity of the common herd. What do you have to say about the principal philosophers of this academy who are filled with the stubbornness of an asp and do not want to look at either the planets, the moon or the telescope, even though I have freely and deliberately offered them the opportunity a thousand times? Truly, just as the asp stops its ears, so do these philosophers shut their eyes to the light of truth."

            I can’t understand, why smartest and accomplished scientists and researchers even in 20^th century, behaving not much differently from the principle philosophers (i.e. scientists were referred to as philosophers) in the dark ages.

Best Regards,

Raju

Why Software Engineering & Computer Science ended up in Crisis

            Software researchers and Scientists forgot a simple scientific fact/rule: In real science, anything not proven is an assumption. When any scientific field is in infancy, researchers have no choice but to make few educated assumptions (e.g. first principles). The researchers and scientists rely on such assumptions for advancing makings knowledge. Unfortunately the scientific progress side-tracks and derails (i.e. end up in crisis sooner or later), if there are fundamental errors in the first principles (or assumptions) at the root of the scientific field.

It is essential to document the assumptions to avoid or minimize the harm caused by such first principles that are fundamentally flawed. Unfortunately computer science and software engineering has such fundamentally flawed assumptions at the root. It is not wrong to make assumptions 50 years ago (when software engineering was in infancy) and rely on such assumptions to advance our knowledge. But it is wrong and violation of scientific process/principles to rely on such undocumented or unknown assumptions.

I am sure thousands of researchers would have exposed such fundamentally flawed assumptions, if the assumptions at the root of software engineering were documented. For example, there are many baseless assumptions at the root of software engineering such as software components are different or unique. and it is impossible to invent software components that are equivalent to the physical functional components (by having essential properties uniquely and universally shared by each and every known physical functional component) for achieving real CBSD (CBD for software), where real CBSD is equivalent to the CBD (Component Based Design) of one-of-a-kind physical products (e.g. an experimental jet-fighter or prototype of a new kind of spacecraft).

For example, 500 years ago it was considered blasphemy to question validity of then undocumented assumption ‘the Earth is static’. Mankind relied on this undocumented assumption for centuries and created a complex paradoxical paradigm (i.e. altered perception of reality), and over the period this assumption at the root and the paradoxical paradigm deeply entrenched into the collective wisdom of mankind.

Today it is considered arrogant and disrespectful to question the validity of the definitions for so called software components and so called CBSD/CBSE. Mankind relied on such undocumented fundamentally flawed assumption for half-a-century and created a complex paradoxical paradigm (i.e. altered perception of reality), and over the period this assumption at the root and the paradoxical paradigm deeply entrenched into the collective wisdom of software researchers. Not documenting such untested assumptions is tantamount to considering them to be inalienable laws of nature, which would become impossible to question over time as they deeply entrenched into collective conventional wisdom. It might be impossible to even imagine invalidating such assumptions 50 years ago, but not documenting them is kind of like assuming that no one can ever find flaw in such untested assumption in million years.

Such untested assumptions must be documented in the first chapter books on software components and CBSD/CBSE, so that they will be always on the collective consciousness of students. Documenting such assumptions allow researchers to either validate or invalidate each assumption as and when mankind’s scientific advanced sufficiently. Since such assumptions are not documented, persons like me have to endure insults and disdain to even mention possible error. Is it really impossible to find real software components (e.g. for achieving real CBSD) even in a million years. If it is not impossible to invent such real software components, such assumptions must be documented, so that, future generations have a fighting chance (without facing insults and disdain) to invalidate such flawed assumption for putting the scientific and technological progress on right tracks.

If mankind were to acknowledge the possibility that, the Erath might be moving just like any other planets, I am sure, many researchers would have discovered that the Sun must be at the centre. After all, there are just 9 known planets including Moon (e.g. to test the hypothesis by putting each planet at the centre). But it was inconceivable 500 years ago the possibility that the Erath is moving around any other planet. I am sure anyone can discover real software components within weeks, if they acknowledge possible error and try to investigate truth. How complicated it is to discover the essential properties uniquely and universally shared by each and every known physical functional components? Based on my experience, it just takes couple of weeks. Unfortunately discovering the truth is not real problem, but the problem is questioning the validity of the flawed first principles (i.e. assumptions) at the root, which is real cause for any software field to end up in crisis. This struggle gave me unique perspective of why and how any scientific field end up in crisis (and how exposing the errors lead to scientific revolution by putting progress on right tracks).

Best Regards,

Raju

An irrefutable proof to show that the existing CBSD is a paradoxical paradigm resulted from relying on undocumented flawed assumptions.

In real science, anything not having proof (or not proven) is an assumption and such assumptions must be documented before relying on them to create definitions/concepts. Progress of any scientific discipline would be sidetracked into a wrong path and end up in a crisis, if there are errors in basic assumptions and if researchers relied on such erroneous assumptions for creating definitions or concepts and for advancing any scientific filed by relying on such definitions or concepts. No meaningful scientific progress is possible until the scientific progress is put on right path by exposing errors in such basic assumptions.

Why CBSD (Component Based Design) for software needs different and new description (i.e. definitions and/or essential properties) for software components and CBSD? These new and different description, properties, and concepts for so called software components and CBD for software products are in clear contradiction to the reality (i.e. facts, concepts and observations) we know about the physical functional components and CBD of large physical products (having at least a dozen physical functional components).

There exists no proof to show that any effort was ever made to discover reality about the physical functional component and CBD of physical products before creating the definitions and concepts for so called software components and concepts. The definitions and concepts at the root of existing CBSD (Component Based Design for Software) were made up out of thin air, without documenting the reasons or first principles (i.e. assumptions) that compelled to create such definitions and concepts that are in contradiction to the reality.

When I inquired for reasons, I heard many unsubstantiated assumptions, such as software is unique/different and/or it is impossible to invent real-software-components that are equivalent to the physical functional components (by discovering accurate description for the physical functional components and inventing real software components that satisfy the accurate description). In real science, anything not proven is an assumption and such assumptions must be documented before relying on them to create definitions/concepts. No text book for introducing software component or CBSE/CBSD listed such assumptions. No research paper or publication listed such assumption at the root of existing CBSD paradigm, which has been evolving for nearly 45 years by relying on such unsubstantiated definitions and concepts made out of thin air..

When any scientific discipline was in infancy, researchers are forced to make assumptions. For example, assumption "the Earth is flat" was a reasonable assumption 4 to 5 thousand years ago. Likewise, the assumption "the Earth is static" was a reasonable assumption 2000 years ago. But documenting such assumptions would avoid huge pain and suffering such as: http://real-software-components.com/forum_blogs/BriefSummaryOfTruths.html#Chronology. It is not hard to prove that, if the error at the root of geocentric model was not yet exposed, no meaningful scientific progress would have possible during past 500 years. As science and our knowledge expends, we can create tools to validate such assumptions, if they are documented and well-known.

All I am saying is, it is not wrong to make assumptions but it is wrong to not-knowing and forgetting (e.g. by not documenting) the assumptions at the root of our scientific knowledge, such as concepts and definitions for software components/CBSD. In real science, any thing that can’t be proved is an assumption. It is an error to rely on any such unproven assumption (without clearly documenting the assumptions) to derive concepts or definitions.

For discussion sake, let’s assume that the basic assumption was: “it is impossible to discover a set of essential properties uniquely and universally shared by each and every large physical functional component for inventing equivalent software components (having the essential properties)”.

This is highly falsifiable first principle (i.e. basic assumption at the root of software components and existing paradigm for CBSD), so it can be (and must be) proved false, if this basic assumption is flawed.

Likewise, if the assumption was: “it is impossible to invent a set of essential aspects uniquely and universally shared by each and every CBD of large physical product for achieving equivalent CBD for software products (having the essential aspects)”.

This is highly falsifiable first principle (i.e. assumption), so it can be proved false, if it is flawed. May be such assumptions could not be proved wrong (when such assumption was made and relied up on) 50 years ago, but they could be proved wrong when technology advances sufficiently for validating each such assumptions in the future (if such undocumented assumptions are flawed).

All I am saying is, it is wrong to NOT document such assumptions before relying on such assumptions for making up definitions for so called software components (out of thin air without any basic in reality, but based on wishful thinking). If there are errors in such undocumented first principles (i.e. basic assumptions), they sidetrack the scientific progress into a wrong path and scientific discipline end up in paradox.

If such assumptions were documented, I am sure 1000 researchers would have proved each of them wrong in past 50 years. But toady no one even know the assumptions to prove them wrong, if they are wrong. Such unsubstantiated assumptions were completely disappeared from our collective consciousness to even question their validity in light of technological and scientific advancements.

For example, this kind of assumption (i.e. it is impossible to discover such essential properties for the physical functional components) contradicts almost every thing mankind knows today. Let me define a universal rule: There exists an accurate description (e.g. a set of essential properties) for every known kind of a physical being or specie and the accurate description (e.g. a set of essential properties) can be used to positively identify each specimen belong to the being or specie. That is, the essential properties for any kind of physical being or specie can be used to positively determine weather a given specimen belongs to the physical being or specie.

Physical functional components can’t be an exception to this universal rule, since it is impossible to find any exception to this universal rule: It is possible to find an accurate description (e.g. essential properties) for each and every kind of a physical being or specie. Mankind’s scientific knowledge comprises accurate descriptions (e.g. essential properties) for millions of physical beings or species. There are millions examples to prove this universal rule, but impossible to find an exception to this universal rule (e.g. to falsify this rule). Every scientific discipline comprises accurate descriptions (e.g. often defined by a set of essential properties) for physical beings or species (to positively identify each specimen belong to respective kind of being or specie).

For example, isn’t essential for the field of zoology to acquire and accumulate the knowledge of accurate description for animals? Isn’t essential for the field of botany to acquire and accumulate the knowledge of accurate description for plants? The same is true for various sub-fields of microbiology such as virology, mycology, parasitology, and bacteriology. Likewise, accumulating knowledge of accurate description of atoms, molecules, compounds or elements is an essential for each sub-field of chemistry such as organic, inorganic or bio chemistry. No proof exists to show that the physical functional components are exception to this universal rule. It is impossible to find any one ever even tried to prove that the physical functional components are exception to this universal rule.

Once the set of essential properties uniquely and universally shared by each and every physical functional component is discovered, why is it not possible to invent equivalent software components having the essential properties? Although we can’t articulate the essential properties of the physical functional components, when any physical functional component is shown, it is not hard for any expert to positively identifying that it is a physical functional component. Likewise, it is not hard for any expert to positively identifying that it is not a physical functional component, if he is shown any other kind of physical part (that is not physical functional component).

This expertise of positively determine any given physical part whether it is a physical functional component or not a physical functional component, can be leveraged to discover essential properties uniquely and universally shared by each and every large physical functional component. Once the essential properties are discovered, it is a trivial task to invent real software components having the essential properties for achieving real CBSD, where the real CBSD must share the essential aspects uniquely and universally shared by each and every known CBD of large physical product (having at least a dozen physical functional components).

In fact, I can help any engineering expert or researcher to discover the essential properties uniquely and universally shared by each and every known large physical functional component. Likewise, I can help any engineering expert or researcher to discover the essential aspects uniquely and universally shared by CBD of any physical product (having at least a dozen physical functional components). It must not take more than couple of weeks to train any expert to gain this kind of expertise for positively identifying multiple real software components (equivalent to the physical functional components by having the essential properties) in any software application for achieving real CBSD (equivalent to the CBD of physical products by sharing the essential aspects).

Both teachers and books teaching concepts and definitions of so called software components and CBSE to impressionable students by forcing the students to learn definitions either to pass the exams or solve problems using the definitions and concepts. Without having proof, if it is right path or wrong path, we are pushing the impressionable students to well traveled (but wrong) path. Instead of teaching them (i.e. brain washing them),

We must ask impressionable students to investigate truth, instead of brainwashing then and pushing them into wrong path by teaching flawed definitions and concepts (derived by relying on undocumented assumptions). Please kindly read this interesting article, how reality can be distorted: https://www.psychologytoday.com/blog/pieces-mind/201208/few-the-many-ways-we-distort-reality. One can find so many examples that show, how reality can be distorted and end up in a paradox.

After graduation and gaining 10 years hands on experience on so called software components and CBSE (living in paradox of such distorted reality), obviously any CBSE expert thinks I am crazy (arrogant or disrespectful) for saying reality/facts such as, ideal CBD requires over 97% code must be implemented as CBD-structure (free from spaghetti code), but it is not necessary that even a single large component in the hierarchy need to have any properties we erroneously attributed to so called software components.