Interesting question

The scientific community has frequently gone against legacy dogmatic positions, even if not every member of it have done so. If a disruptive discovery is verifiable, those hanging on to old dogma, assuming they are scientists, should feel a sense of discomfort or even shame. The problem tends to be self-correcting.

Using examples from centuries ago may not be all that valid, as the scientific method was not common knowledge, back then. But certainly today, debates like the "creationism vs evolution" debate are a good example of what you are describing. The debate should not even exist in the scientific community, and the majority know this. Whatever is offered as the best current understanding of "truth" needs to be explained and verified, needs to be flexible enough and open enough to accommodate future revisions, and cannot be based on just fairy tales. To be blunt.

Dear Dr. Manfredi,

I have to respectfully disagree with you. Similar problem of blindly defending dogmatic beliefs exists even today. In the 16th century the beliefs were about the reality of the planetary orbits.

In the 21st century, the beliefs about things such as the reality about the components in the context of CBE/CBD (Component Based Engineering or Design and Development) of countless products (we use every day) such as cars, computers, cell-phones, TVs, ACs, airplanes, office or medical equipment such as printers, MRIs, X-Ray, scanners, machines or machinery for factory to name a few.

In such context, no part can be a component, if the part is conducive to be assembled and disassembled. Saying this obvious fact attracts wrath of software research community. If you don’t believe me, just look at the threads for my questions and my papers. I was banned from sending e-mails to a research institute IIIT-Hyderabad for insisting parts that can’t be assembled are not components in the context of CBD/CBE of products, because this fact contradicted their revered belief system “component composition models”.

This is the response from Dr. Kesav Nori (He is a moron, but pretending to be a researcher - a poseur or imposter): I suggest that no one respond to Raju Chiluvuri, as it is a waste of time and he does not value foundations. If he claims to have patents and a struggle for 16 years of research, why isn't he the richest man on earth? He does not care to define components and their "compositionality", yet he claims a place in the sun for Component Based Seoftware Development!

Does components must have compositionality? What a moron? These corrupt guys at IIIT-Hyderabad taking salary from tax payer money and running private training institute as a side business. This is the first email I got for my proposal for parts that can be assembled and disassembled. I did have patents for parts that can be assembled such as 7827527, 7840937, 8527943, 8392877, 8578329 and 9058177. I just filed a patent for a new invention just last month.

I have been doing research on this for past 16 years. I have accumulated huge evidence, such as: Our Company Pioneer-soft.com has team of 15 engineers creating complex GUI applications every day by assembling large 2D/3D real-time data driven GUI components.

No one else ever even tried to invent software parts that can be assembled and disassembled for building software products by assembling the components. For example, no other GUI-technology (e.g. from Microsoft, Oracle/Java or Apple) in the world is capable of creating component that can be plugged-in and un-plugged. This kind of statement can be falsified by finding even a single large GUI component that can be assembled and disassembled.

Sir, almost every software researcher insists that, that kind of thing (i.e. geocentric paradox rooted in a lie) can’t repeat in 21st century. But repeating right under their nose, and yet unable to recognize it. They can’t comprehend the objective reality by fooling themselves any kind of part is a component for the CBD/CBE.

This is second and final response from Dr. Kesav Nori of IIIT-Hyderabad (Claimed to be a research Universality)

>> Are parts components? Not in your world it seems.

>> Please don't write to me anymore

Please read attached PDF. These are few examples from my experience spanning many years. The threads in my RG account is living proof that such things can repeat even in 21st century.

Sir, how do you know you don't have any revered beliefs? Until year 2001, I shared all those revered beliefs with software community. But later I accidentally stumbled onto components that can be assembled. It took me many years to realize my beliefs were wrong (only after creating thousands of large components that can be assembled).

Best Regards,

Raju

Dear Mr. Manfredi,

I feel you have enough exposer to software by looking at your background. Maybe you can explain why obvious fact attracts wrath (e.g. vicious personal attacks) of software researchers such as: No part can be a component, if the part is not conducive to be assembled and disassembled in the context of CBE/CBD of countless products (we know and use every day) such as cars, computers, cell-phones, TVs, ACs, airplanes, office or medical equipment such as printers, MRIs, X-Ray, scanners, machines or machinery for factory (to name a few)?

The software engineering paradigm have been evolving for past 50 years by relying on received beliefs such as ingredient parts (e.g. equivalent to material such as steel, cement, plastic, alloys, metals, or specialized material such as silicon to make computer chips, nickel-cadmium, led-acid or lithium-ion to make batteries) that are reusable are components.

Such ingredient parts are composed, so not conducive to be plugged-in and unplugged. Dr. Nori (of IIIT-Hyderabad) enraged when I said, components I invented don’t have compositionality model (because they are conducive to be plugged-in and unplugged – The essential requirement for components to achieve real CBD/CBE).

I hope you read PDF file attached to my previous reply: Keep in mind that the single greatest contributor for increasing manual productivity in designing, engineering and building large or complex physical products is using particular kind of parts that can be assembled and disassembled (that are known or referred to as components).

We want roses (a particular kind of flowers that smell sweet are referred to as roses), because they smell sweet. What is the use of Roses, if they smell like pigs? We need components because they can be assembled and disassembled. What is the use of components, if they can’t be assembled.

The 2300 years old received belief (the Earth is at centre) alter mankind’s perception of reality for 1800 years until 16th century. Likewise, the 50 years old received beliefs about so called components for software alter our perception of reality of CBD/CBE of products.

Saying the fact “the Sun is at the centre” attracted the wrath of 16th century researchers. Saying the fact that CBD/CBE of products require using parts that must be conducive to be assembled and disassembled attracting the wrath of 21st century software researchers. For example, Prof. Nori resort to vicious attack for saying that my components have no compositionality model.

I could not have believed that this kind of thing could happen in the 21st century, If I have not been enduring repeatedly from countless software researchers and experts for many years.

How can you invent fibre optic networks by being clueless about nature and characteristics of light (e.g. how it behaves in fibre strands)? How can you invent semi-conductor chips by being clueless about nature and characteristics of electrons (e.g. how they behave in semi-conductor material)? How can you invent cures for infections by being clueless about nature and characteristics of bacteria or viruses?

There is no better method than “scientific method” for discovering nature and characters of things such as light, electrons, viruses, bacteria or components. How can we invent parts that can achieve real CBD/CBE by being clueless about nature and characteristics of parts that are essential for achieving real CBD/CBE?

In fact, asking computer scientists to use “scientific method” to know reality about the nature and characteristics of components for achieving real CBD/CBE enraged many researchers of computer science. They openly argued in many of my threads here in RG that computer science is not science, but a branch of mathematics. You can find the threads and articles.

Best Regards,

Raju

Dear Dr. Farid,

P.S: Dr. Farid removed his response, but I kept this, because it is relevant to this thread

Thing that most amazing to me is, how well-educated people repeat one of the well documented set of mistakes. Please read this outstanding synopsis for the famous book “The Structure of Scientific Revolutions” by Thomas S. Kuhn, who is one of the greatest philosophers of science of 20th century: https://www.uky.edu/~eushe2/Pajares/kuhnsyn.html.

The first paragraph of this synopsis says:

A scientific community cannot practice its trade without some set of received beliefs. These beliefs form the foundation of the "educational initiation that prepares and licenses the student for professional practice". The nature of the "rigorous and rigid" preparation helps ensure that the received beliefs are firmly fixed in the student's mind.

[Mistake-1] Scientists take great pains to defend the assumption that scientists know what the world is like...

[Mistake-2] To this end, "normal science" will often suppress novelties which undermine its foundations.

[Mistake-3] Research is therefore not about discovering the unknown, but rather "a strenuous and devoted attempt to force nature into the conceptual boxes supplied by professional education".

================

For example, each and every book on software and research paper in the world teach that “parts that are designed and/or conducive to be reusable are components” and “CBD/CBE (Component Based Design, Development or Engineering) of a product is using such parts (that can be reusable) for building the product”.

Now every researcher in the world strenuously and devotedly working hard to force the nature into the conceptual boxes (i.e. knowledge boundaries of a dominant paradigm) supplied by their flawed education and many years (or decades) of work and experience confined to the conceptual boxes (i.e. dominant paradigm).

Dr. Kuhn and Dr. Popper are considered two of the greatest 20th century philosophers of science. Dr. Popper works describe ideal scientific process in the perfect world, while Dr. Kuhn describes imperfect states of scientific knowledge. No one in the world can prove that this statement is wrong: Software researchers have been committing all three mistakes described by Dr. Kuhn’s famous book.

Researchers violently oppose any thing that oppose their sacred received beliefs such as a discovery of a novel fact that is outside of the conceptual boxes (i.e. dominant paradigm), for example, by resorting to hostile attacks to suppress novelties that are often obvious facts such as parts that are not conducive to be assembled can’t be components.

That is, parts that are designed and/or conducive to be assembled are known (i.e. referred to or named) as components. So, no part can be called as a component, if it is not designed or conducive to be assembled (even if the part is reusable). Today, no known kind of software components are designed and/or intended to be assembled by any stretch of imagination.

The dominant geocentric paradigm of 16th century was rooted in 2300-year-old received belief “the Earth is static at the centre”. In other words, the researcher 2300 years ago believed that the Earth is static at the centre. The research community accumulated huge BoK (Body of Knowledge) for next 1800 years until 16th century by relying on this flawed received belief, where the BoK fundamentally altered their perception of reality. Their research was therefore not about discovering the unknown, but rather "a strenuous and devoted attempt to force nature into the conceptual boxes supplied by the huge BoK (i.e. conceptual boxes for dominant paradigm)".

The researchers treated the received beliefs as revered laws of nature and violently oppose any thing that is perceived to be contradicting the sacred beliefs by instigating religious institutions to prosecute anyone questioning the untested or unproven sacred beliefs that resulted in killing or imprisoning him for heresy.

Likewise, the dominant software engineering paradigm exists today is rooted in 50 to 60 years old flawed untested or unproven received beliefs (that are revered as laws of nature). The research community accumulated huge BoK (Body of Knowledge) for past 50 years by relying on the 50 to 60 year old untested or unproven flawed received belief, where the BoK fundamentally altered their perception of reality.

Unfortunately, even in the 21st century that research is therefore not about discovering the unknown, but rather "a strenuous and devoted attempt to force nature into the conceptual boxes supplied by the huge BoK (i.e. dominant paradigm)". The researchers vehemently opposing any thing that contradicts their sacred received beliefs, for example, resorting to hostile personal attacks to suppress novelties that are often obvious facts given below:

The reality of CBD/CBE (Component Based Design, Development or Engineering) of a product can be briefly summarized as follows: Implementing large portion of features and functionality of the product in a set of special kind parts, where the parts are designed and/or conducive to be assembled (or plugged-in). The special kind of parts are known (i.e. referred to or named) as components and the product is built by assembling (or plugging-in) the components. A part that is not conducive to be assembled is not a component.

For example, computers or cell-phones are built by assembling many components such as CPU, RAM, Hard Drive, Screen, Key Board or Power Supply, where each component implements a specific features or functionality, which are a subset of the superset of all the features or functionality necessary for overall functioning of the product. These components collaborate and/or communicate with each other for providing the overall features and functionality of the product. Likewise, automobiles are built by assembling components such as engine, battery, gear-box, steering system, alternator and wheels etc.

I humbly request software researchers to introspect, for example, before resorting insults or personal attacks for defending the fiction and lies in the existing software engineering paradigm, which in effect suppressing novel facts that are obvious to laymen, such as: The obvious reality (in the context of countless products such as cars, computers, cell-phones, airplanes, machines or factory machinery) is: A very special kind of parts that are designed and/or conducive to be assembled (or plugged-in) is named (i.e. referred to or known as) components. No other kind of part that is not designed and/or conducive to be assembled is called component.

Saying the truth “the Sun is at the centre” offended the common sense and enraged many researchers in 16th century. Unfortunately, many software researchers in the 21st century are reacting no differently than the researchers in the 16th century. Many software researchers feel offended or even enraged by simple facts (that are considered obvious by non-software experts or engineers) such as: “It is error to define parts that are not designed and/or conducive to be assembled (or plugged-in) are components”; and “It is error to define CBD/CBE (Component Based Design, Development or Engineering) is using any other kind of parts that are not designed and/or conducive to be assembled (or plugged-in)”.

Best Regards,

Raju Chiluvuri

Raju, sometimes, when people react with frustration, it might be perceived as incoherent wrath? Just a thought. I do remember that long thread, now that you mention it. It didn't make a lot of sense to me last time around, though.

So for example, when you insist that "No part can be a component, if the part is not conducive to be assembled and disassembled in the context of component based engineering," I'm not even sure what that philosophy means. I reuse parts of programs, maybe entire subroutines, many times, and have no philosophical adverse reaction to doing so. I cut and past code from one program to another without a second thought. Saves me a lot of time, a lot of debugging, a lot of testing.

Just like an auto manufacturer might use precisely the same wheel assembly in two different car models, and in fact, the entire drivetrain is frequently reused in different models, and the customer might not even have a clue.

None of this is a matter of religious dogma or unfounded beliefs. It's the way systems are almost always built. Few systems are build from scratch, from the ground up. That would be hopelessly inefficient.

I honestly don't know why you need to stipulate "if the part is not conducive to be assembled and disassembled." What does that have to do with anything? Is a standard screw, let's say, not a component part? The fact that the screw cannot be "disassembled" does not negate that a screw, or nut, or washer, are parts. Similarly, I can treat a subroutine as a "black box," not touch anything inside, and insert that subroutine in a different program. Surely, you aren't insisting that this cannot be done, right?

Dear Mr. Manfredi,

Thank you for elaborating your perspective. Kindly keep in mind, any new paradigm is incommensurable. The context is engineering, designing and building each new product by assembling custom components. Kindly elaborate this using a sample City-GIS application: http://real-software-components.com/CBD/City_GIS.html

This application is partitioned into 3 self-contained components and each component is designed as a pluggable component. Each component is designed, developed and tested individually. Then the application is built by plugging-in the components.

If one of the components is too big, it can be partitioned into self-contained sub-components and each sub-component is designed as a pluggable component. Then the component is built by plugging-in the sub-components, and so on.

Today, no other GUI-technology in the world is capable of implementing self-contained GUI-components such as City_ATC, CityLandMarks in a class definition, so they can’t be assembled.

That is, if each component requires implementing on average 3000 lines of application code, today it requires creating 9000 lines of application code by merging the code for all the code for 3 components. In other words, many source code files for the application contain source code for more than one component.

In case of our patented real CBD/CBE, it requires only 9 lines of code to assemble the three components as illustrated in listing-1. Each component requires implementing 3000 lines of code, but requires only 2 to 3 lines of code for plugging-in and to unplug each component.

That is, real RBD/CBE requires implementing 97% of application code in such components that can be plugged-in and unplugged, where each component can be redesigned and tested individually outside of the product.

We invented enabling mechanism (i.e. virtual sockets or software motherboard) for creating and managing communication code to allow collaboration between the components (so there is no need for manually implementing any communication code).

Kindly review this in the context of engineering, designing and development of a new product such as artificial kidney at: https://www.youtube.com/watch?v=hc5e5cYdshI and http://real-software-components.com/technologies/componentization_purpose.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 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 properly collaborating with other parts, and (b) all the components are fulfilling their respective roles as intended for proper operation of the container product.

When you build a product by assembling pluggable components, each component can be redesigned and tested individually free from spaghetti code or design. If 97% of the features and functionality is implemented in such pluggable components, then 97% of the code is free spaghetti code.

For example, if you add 5000 lines of code for CityLandMarks into you application, you can’t test the component individually. You have to test the whole application. If you implement CityLandMarks as a class definition, you can redesign it and test individually.

Today, no other GUI technology (e.g. from Microsoft or Apple) allow you to implement such component as a Class-definition, so you are forced add the 5000 lines code as spaghetti code to 100K lines of application code comprising dozens of other such components (e.g. by using your favorite cut-and-paste:-).

No disrespect is intended. Just making fun of cut-and-paste method. In fact, I extensively employ cut-and-paste to create each class-definition for each pluggable component such as CityAmbulances or CityATC etc. We can still use our favorite cut-and-paste method.

Today, if you implement 3000 lines for CityATC as an independent application, you are forced to cut-and-paste code section into many files of the application. I would rather implement this as a Class and add just 3 lines as illustrated in listing-1.

Keep in mind over 80% of software engineering is changing existing code. Each component is evolved little-by-little for getting closer and closer to perfection (eventually for many years or even decades). Which one you would rather change little-by-little? The class-definition containing 3000 lines or finding 3000 lines spread in 100K lines of application code? I hope, you can see my perspective.

Sir, I am not suggesting you to build from ground-up. We pioneer-soft has most comprehensive library of reusable GUI-classes and utilities for over 1000 GUI-components (e.g. charts, dials, trees, maps or meters etc.), more than any one else in the world.

Sir, in fact we have been creating most extensive library for 3D GUI components for web based applications for real-time IoT, SCADA, Digital Twin or Cyber Physical Systems. May be Boeing is interested :-). All of them are based on our patented inventions.

Let me assure you that we only have the second risk (in the question), so you can verify upfront today. For example, this kind of applications that is created by assembling 2D components were created in 2005 (12 years ago): http://www.pioneer-soft.com/#/realairtraffic, where the components such as CityATC is created by reusable GUI classes for presenting components such as Airplane and Ambulance etc. Now we are working on 3D capabilities for Digital Twins or Cyber physical systems for smart cities or geospatial systems.

Best Regards,

Raju

Dear Manfredi,

Here I am trying to be very brief: Let me summarise in different perspective: Assume even after maximizing reuse in every possible way, in case of many application it still requires implementing hundreds of thousands of lines of custom application code.

In case of real CBD/CBE, this custom code is implemented in components of optimal size (e.g. 1500 to 3000 lines), where the components can be plugged-in as illustrated in listing-1 or listing-2. The class for each pluggable component is created by using reusable code or cut-and-paste or any such method we use for building applications. http://real-software-components.com/CBD/City_GIS.html

Only difference is: today the 3000 lines for City_ATC or CityAmbulances is added to the application code. That is, code sections for such components are added to many files implemented for the application, where most files comprise code for other such components.

Today no other GUI technology create a class for components such as City_ATC or CityAmbulances, so you are forced to create spaghetti code by merging the code base, even if you created each component as an independent application.

If you don’t agree, you can prove me wrong by showing even a single GUI-application that is created by plugging in such pluggable components. You can’t even implement such applications in a class-definition, so you can’t even find such class definitions.

Today you are forced to merge code for each such component, in the code for the application. Merging code for many such components in each of the files is the root cause for spaghetti code. To remove such component, requires removing code sections from multiple files (where each file comprises code chunks for other components). To redesign a component, one must spend lot of time finding code chunks spared across many files (where each file comprises code chunks for other components).

In the past, many experts insisted that GUI applications of size such as CityATC or CityAmbulences can be implemented in a class-definition (so that it can be included by implementing 3 lines for including an object instance as in listing-1 or listing-2). Don't they need to justify such assumptions?

I requested them to show even a single such class definition anywhere in the world. Few experts resorted to personal attacks for requesting them to justify such assumptions. But no one showed me such a pluggable GUI component so far. I have been doing research on such pluggable components for past 16 years.

In conclusion, each large software application comprises code for many such self contained components, but code for not even single large self-contained component is implemented as pluggable component. So the code for each such large component is spread across many application files, where most files comprise of code for other such self-contained components.

Best Regards,

Raju