Dear Anonymous Friends,

            Instead of sending clandestine messages and anonymous down votes, I greatly appreciate, if you post your messages at this question. Only incompetent people or crooks try to hide behind secrete accounts.

            Many people don’t even know what I have been facing every day. Many people just want to silence me by resorting to personal attacks or insults. Keep in mind certain facts in view of the figures in the attached PDF file (1) Today almost every large physical product is built by assembling replaceable components (e.g. to achieve CBD-structure: http://real-software-components.com/CBD/CBD-structure.html), where each component is designed and built individually (e.g. by using CBD-process: http://real-software-components.com/CBD/CBD-process.html). The FIG-1 in the attached PDF illustrates how each of the components is plugged-in to build a product having 6 components.

            Today no software product in the world is created by assembling such replaceable self-contained components. Hence code base for any application ends up as a big ball of mud as illustrated in FIGs 2, 3, 4 & 5. But there is no valid reason, why software can’t be built by assembling replaceable self-contained components (i.e. real-software-components).  

           Unfortunately, respected researchers trying hard to silence me and hide such facts by resorting to insults and personal attacks. Each of the facts is backed by clear evidence and anyone is free to falsify the evidence. It is impossible to engage in civilized discussion, when facts and evidence is countered by clandestine personal attacks or insults.

         Please refer to attached PDF for summary of facts and evidence. Instead of assembling or plugging-in each component (by a replaceable module in a Class-definition and associated exclusive files), the code base for each component is broken into many sections and merged into non-exclusive files for expand the big ball of spaghetti code as in FIG-2, FIG-3 & FIG-4. 

Best Regards,

Raju Chiluvuri

Dear Raju,

I would like to answer to you and support you. Those from not from field have problems to understand you. For this you need a clearer explanation.

What are you mean under:

a)    heliocentric model of software engineering?

b)    geocentric paradox of software engineering?

If you are correct you can formulate in simple way your problem. Try again look us like a small children and try to explain again

What was before 50-60 years ago in computer softer science? What is the paradox The heliocentrism, geocentrism terms is connected to the Earth and Sun… Why they are used in software engineering? (Really I  know where you are going, but I do not know anything about your particular problem.

You have the Galileo letter to Kepler?

Best Regards,

Laszlo

Dear Dr. Laszlo,

               Thank you very much for your kind support. The simple facts are: In case of physical components, each and every self-contained physical component is designed and developed individually (outside of its product) and assembled after testing it individually. Each component can be redesigned at any time in the future individually free from spaghetti code by disassembling the components, for example, to keep up with changing needs of the product or for building future upgrades. The attached PDF contains figures referred below.

             Today, almost no large self-contained software component is assembled. Instead its code sections are implemented in multiple non-exclusive files as illustrated in the FIG-2, FIG-3 and FIG-4. Hence the big ball of spaghetti code expands as the code sections for each of the new self-contained components is added to the application as illustrated by FIG-3 and FIG-4. It was inconceivable to invent real-software-components 50 to 60 years ago, when wise men reached “consensus” about the nature and properties of so called software components.

            Isn’t the above comparison between the physical components and equivalent software components is as clear as black and white? But unfortunately software researcher defending the “consensus” as if they are sacred Truth for eternity and questioning their validity is sacrilege and uncivilized (as disputing the lie “the Earth is static” perceived to be sacrilege 500 years ago). Unfortunately mass prejudice is silencing the reasoning and facts.

            Let me add couple of points: Unfortunately, researchers and scientist readily accept lies that confirm their prejudice and biases (e.g. epicycles and retrograde motions) while feel offended or repugnant by the facts or truths that contradict their prejudice and biases. A scientific Truth or fact can be repugnant or uncivilized by no starch of imagination, if the truth or fact is about objective reality (even if it is perceived to be sacrilegious or uncivilized).

              Of course, it is hard to understand a Truth or fact that contradicts deeply entrenched paradox, even if the fact is simple and otherwise obvious or self-explanatory to an unbiased layman expert (e.g. scientist or researcher). Proving truth (that contradicts deeply entrenched prejudice) is an uphill battle filled with landmines (e.g. countless unproven preconceived notions, prejudice, egos and sacred “consensus”). When presenting to an expert or scientist, all the effort would blow up in the face, if even a single concept of heliocentric model contradicts his sacred epicycle or retrograde motion (he has been experiencing for many years). He just walks out of the presentation or resorts to insults.

            The problem is that software researchers & scientists have been brainwashed for over 50 years into believing the geocentric paradox of software engineering, which was rooted in fundamentally flawed “consensus” arrived 50 to 60 years ago and has been evolving for many decades by relying on the “consensus” (i.e. definitions for the properties and nature of so called software components and CBSD/CBSE).

Useful Quotes About Truth

"All great truths begin as blasphemies."

George Bernard Shaw, Irish playwright and critic (1856-1950)

Quotes by Arthur Schopenhauer (Great 19th Century German Philosopher)

“The discovery of truth is prevented more effectively, not by the false appearance things present and which mislead into error, not directly by weakness of the reasoning powers, but by preconceived opinion, by prejudice.”

“All truth passes through three stages. First, it is ridiculed. Second, it is violently opposed. Third, it is accepted as being self-evident.”

“Thus, the task is not so much to see what no one yet has seen, but to think what nobody yet has thought about that which everybody sees.”

1. Research is to see what everybody else has seen, and think what nobody has thought.

         Almost no one can dispute the Truth and objective reality about the CBD of physical products or physical components, which is in open for any one to see: https://www.researchgate.net/publication/284167768_What_is_true_essence_of_Component_Based_Design. Also more detailed description for objective reality for CBD (e.g. http://real-software-components.com/CBD/CBD-structure.html and http://real-software-components.com/CBD/CBD-process.html) is provided in the links given in the web page: http://real-software-components.com/moredocs.html.

Best Regards,

Raju Chiluvuri

Article What is true essence of Component Based Design?

Dear Dr. Laszlo,

            You said: You have the Galileo letter to Kepler? What do you mean by this? You can find this by Google for “Galileo letter to Kepler in 1610”. I quoted this because I have been facing exactly similar kind of reaction:

           I requested thousands of researchers for an opportunity to demonstrate real-CBD applications created by assembling real-software-components during past many years. Almost no one wants to see the evidence. Also I requested any one to show me even a single large self-contained GUI-component that is encapsulated in class-definitions (and associated exclusive files), so that it can be assembled and disassembled as the components for the physical products.

           Today no large self-contained GUI component is assembled, but its code base is broken into many sections and merged into the code base of the application to expand the big spaghetti ball of code. Most people resort to personal attacks rather than supporting their prejudice or trying to find flaw in my counter evidence.

         I can’t find any civilized way to engage in productive debate except bribing or dragging to court to justify the geocentric paradox of software engineering rooted in flawed sacred “consensus”, which already cost trillion dollars to the world economy.

          If the research community gives me an opportunity, I can prove that almost every large software application can be created by assembling many replaceable self-contained components, which eliminate infamous spaghetti code - The root cause for the software crisis. The designers of physical products face crisis no different from software designers, if they were prevented from assembling physical components (i.e. forced to merge as the software components are merged).

Best Regards,

Raju S Chiluvuri

Dear Raju,

Thank you for responses!

I will give you an idea how you can do something to be more supported..

 Example you can make a particular school (analogous with Chinese Kung Fu schools) and escape them from the modern teaching brainwash.

I do not have enough time to deep me well in the computer scince, for this is hard to me to understand well where you are going. One thing I have clear geological and physical evidences about tricky of these fields. Example condition of discoveries of gravitational waves by LIGO shows where when we observing a collective globalist falsification of science.

Best Regards,

Laszlo

Hi Raju,

I think that bnaches of science will force humanity to realise some problems are in focus and some are irelevant to us. One of questions is that you stated "Is there a civilized way for exposing a geocentric paradox of a 21st century scientific discipline?". many other answers will have to be aswered soon.

Dear Friends,

         Let me provide clear and unambiguous contrast between the self-contained components for software and physical products (no contradicting can be as black and white as this contradiction): In the context of the physical products (every large physical product can be partitioned into many large disjoint sets of self-contained features and functionality): Almost each and every disjoint set of self-contained feature and functionality can be implemented as replaceable component, which can be disassembled and reassembled at any time in the future (e.g. redesign and test individually free from spaghetti design). That is, each component is assembled or plugged-in as illustrated in FIG-1.

          In the context of the software products (every large software product comprises many large disjoint sets of self-contained features and functionality): Almost no large disjoint set of self-contained features and functionality is implemented as replaceable component (e.g. as a module that can be assembled or plugged-in). But each and every large disjoint set of self-contained features and functionality can be implemented as RCC (Replaceable Component Class).

That is, the code base of each large self-contained component is broken into many code chickens and added to (or spread across) many non-exclusive files (i.e. mixed with code chunks for other self-contained components), where each non-exclusive file contains spaghetti code for multiple large self-contained components (as illustrated by FIG-2, FIG-3 & FIG-4 in the attached PDF).

         The root cause for this problem is: No one in the world even today knows what is the purpose and true essence of the CBD for physical products. The flawed “consensuses” reached 50 to 60 years ago diverted research efforts into a wrong path, as the 2300 years old flawed consensus “the Earth is static” diverted research efforts into wrong path that resulted in geocentric paradox (an altered perception of reality filled with epicycles and retrograde motions).

           My struggle to compel research community to investigate evidence, reality and facts to discover the nature and essence of the real-CBD (Component Based Design) for physical products, which can be summarized as: CBD is Implementing about 90% of the features and functionality in replaceable components, where replaceable component imply components that can be easily dis-assembled (or un-plugged to redesign or refine individually outside of the product free from spaghetti design/code) at any time for periodical feature or functionality maintenance or up-gradation releases and re-assembled (or re-assembled after testing it individually free from spaghetti code). Since over 90% of the design and code for features and functionality is implemented in such components (where each is free from spaghetti code), over 90% of the design and code of the product is free from the spaghetti code.

         Such real-CBSD addresses the infamous software crisis, because the root cause for the software crisis is the infamous spaghetti code. Design and development of no other product is infected with such spaghetti code, for example, particularly design and development of complex one-of-a-kind-products such as experimental spacecraft or fully-tested pre-product golden prototypes of next generation Jet-fighters. It is not hard to achieve such real-CBD: https://www.researchgate.net/publication/292378253_Brief_Introduction_to_COP_Component_Oriented_Programming

      Today no one even knows what the true essence of the CBD is, but every researcher insist that it is impossible to invent real-software-components for real-CBD. I have been struggling to provide counter evidence for many years such as hundreds of software applications built by assembling replaceable components (e.g. See real-software-components.com and pioneer-soft.com).

       Any research efforts for any discipline would be diverted into a wrong path, as soon as research efforts start relying of flawed “consensus” (by assuming then to be self-evident facts). The research efforts persist in the wrong path for long enough time (without realizing the error), the research efforts accumulates huge BoK (Body of Knowledge) filled with epicycles over the time and the discipline ends up is a paradox. Today, exiting CBSD paradox is supported many times bigger BoK than the BoK that existed 450 years ago in support of geocentric paradox.

Best Regards,

Raju Chiluvuri

Article Brief Introduction to COP (Component Oriented Programming)

I think you can answer your own question, by trying to find journal articles that oppose the prevailing orthodoxy on any topic. Most research is conducted to publish journal articles which in turn will contribute to tenure, promotion, or grants. So the practice is to slice the salami thin and say the same thing that everyone else says.

You make a very elaborate and length argument, but it is people that have gone through the system and agree with it. So you are swimming up stream. Good Luck. 

Dear Raju,

 I have read through your paper titled ‘Brief Introduction to COP Component Oriented Programming.' Let me tell you my observations.

 You have met “a standard” problem of reverse engineering.  In case of software engineering, an engineer makes a design of a software component (or a class in modern terminology). Obviously, class (or object in some programming languages) uses an isolated program code that can be used in any other class that appears at a higher level of class hierarchy. That is basis of modern understanding of implementation of software classes.

 In your case, you like to make a “sub level class.” But you fail because modern software paradigm denies appearance of any “sub level classes.” That is correct because you should make engineering process (class creation process) from down to up (not vice versa). In other words, you should make lower level classes first of all. After that, you can use them in a complex hierarchy of other classes. 

 For example, no one can build a house from the roof because a roof falls on the ground without any support.

 In your case, you’d like to make some functional by software code based on the same code already included in program code of a given class. That causes your problem. If you like to do that, you should make a lower level class with some functionality that you need and plug that low-level class in every other class that requires its functions by “the 3 lines of code” as you mentioned.

 That is the only one right way of solution of the problem. If your company do no use that way, you have a lot of “spaghetti code” as you call it. That means only critical misunderstanding of creation of classes and their hierarchy (or maybe absence of a good software engineer in your company, I’m sorry for that observation).            

 You mentioned your “patented COP.” Can you tell me the number of your patent (or patent application)? As you remember, obvious solutions cannot be patented. Therefore, if you have patent on an obvious solution, that is a failure of a patient because someone can raise objection for the patent.

P.S. I can put this answer on comment of your paper mentioned above if you like, just let me know.        

Sorry, I'm a bit old fashioned. Having developed commercial software in all 4 prevailing paradigms, I become vary nervous when someone suggests that there is only one solution to avoid "spaghetti code". Having built my fair share of "spaghetti code" (In the 1960's we called it following standards), I have a bit of insight.

The primary cause of "spaghetti code" was the standards in translating flow charts to code. Typically, flow charts were developed by "Systems Analysts"  who for the most part did not write code. Also the notion of a predefined function did not become a logic concept (symbol) until the mid-1970's. To make the design for the software clear, on the 11X17 flow chart forms (no cad software), the Analyst would draw the main-line using off-page connectors to the desired logic, and then in the shared logic they would code a series to condition to take the logic back to the appropriate point in the mainline. To make coding this consistent in multiple languages an off-page connector was implemented with a hard branch or "GOTO". Since computers can not make a comparison between two operands, they use a non-destructive subtraction with a CPU posting the results of less than zero, zero, greater than zero in its status word (string comparisons are algorithmic).

Since I also hold a patent, I can provide a bit of insight there also. A patent describes a unique solution to a problem or process. For example, the use of an inclined plan to raise an object to an object to a level is not patentable, but using a incline plan to reduce the foot print of an object is. Processes are a little different, and much easier to change, but essentially the same. There is another issue about the term "Patented". Depending on where you leaned to write English, the word patented is an archaic substitution for unique, and it was used to cover any from of Intellectual Property (IP) such as trade secret.

When discussing software architecture the is little room for "snarky-ness". There are many times, that to accomplish the mission developers must violate many of the accept standards and guidelines. Successfully violating the rules is how we make progress.

Dear Dr. Zade,

            So far I secured the 6 patents (USPTO numbers: 7827527, 7840937, 8527943, 8392877, 8578329 and 9058177). I did my MS in CS with 4.0/4.0 GPA in 1988 in the USA and worked in the Silicon Valley for nearly 12 years in leading companies including Oracle. I am engaged in this self-funded research for over 15 years ever since I accidentally stumbled on to a fascinating kind of components, which turned out to be very close to the real-software-components.

            My start up company based in India created first GUI-technologies in the world that is capable of creating real-software-components. No other GUI-technology (e.g. from Microsoft or Apple) is capable of creating real-software-components discussed in the COP. It is impossible to practice COP, if it is impossible to create real-components. Likewise, using fake-components is not CBD. If you like to know more, we can have Skype meeting to see our GUI-technologies.

           You can prove me wrong by showing even a single real-software-component anywhere in the world such as a replaceable component class for a small application such as City_ATC or City_ER (Emergency Response), where it contains few dozen data driven GUI-components. No GUI-technology allow software engineers to encapsulate such self-contained components in a Class definition. If it can’t be implemented in a class, it can’t plugged-in or unplugged. The developers are forced to merge the code base in to the code base of the application resulting in spaghetti code.

            Kindly keep in mind that I am not trying create theories and find evidence. We stumbled on the real-software-components 16 years ago. Our engineers created several hundreds of complex component hierarchies 16 years ago. This induced irresistible curiosity to close a profitable software consulting business to focus on the research. I had to struggle many years to find rational explanation. Ever after finding rational explanation my understanding is evolving continuously. You can see that in my patents. I have keen interest in patent litigation and have been closely following every software related patent case reached the Supreme Court of the USA.

Dr. Zade, you said:

 In your case, you like to make a “sub level class.” But you fail because modern software paradigm denies appearance of any “sub level classes.” That is correct because you should make engineering process (class creation process) from down to up (not vice versa). In other words, you should make lower level classes first of all. After that, you can use them in a complex hierarchy of other classes. 

            You are trying to understand heliocentric concepts in the perspective of geocentric paradox. Today almost every software product can be designed and built by assembling real-software-components. But not even single product is created by assembling real-software-components. My patents cover inventions for enabling the real-CBSD. Every software product is infected with spaghetti code, while no large physical product is infected with spaghetti design. Please see above answers.

You said: (or maybe absence of a good software engineer in your company, I’m sorry for that observation)

            We are the only company in the world, who can create application without spaghetti code. You can prove me wrong by showing even a single application anywhere in the world, where 90% of the code in implemented in RCCs (Replaceable Component Classes). Keep in mind, no other GUI platform is capable of creating such RCCs.

              I had heated debates with leading software researchers in my earlier Research Gate questions since 2012, but no one ever showed me an example. You can try. So far no one even knows “what is the reality and purpose of the CBD?” How can any one achieve it, without even trying to even know what it is?

           Our patents are strongest in the world, because they are rooted in my scientific discoveries such as nature and essential properties of the components. We invented software-components having the essential properties. Scientific discoveries can’t be patented, but each and every useful invention rooted in scientific knowledge (so useful inventions can be patented).

         Since our patents are rooted in scientific knowledge (not know to any one else), our inventions can with stand even the toughest scrutiny in the world. I challenge any one to raise objections by showing priory art. I enjoy and craving for toughest scrutiny of my discoveries and inventions. 

Best Regards,

Raju Chiluvuri

Dear Dr. Muller,

            Can you summarize objective reality such as true essence of the CBD (Component Based Design) for the physical products? I asked this question over few thousand software researchers during past 10 years. No one gave correct answer to this question.  How any one can say, it is impossible without even making any attempt to know what it is?

           I have been begging software researchers for past decade to discover the immutable objective reality about the nature and purpose of the CBD (Component Based Design) of one of kind new products and the essential properties uniquely and universally shared by each and every known large physical component. Discovering this reality and facts put research efforts in the right path (as the discovery “the Sun is at the centre” put the basic science on the right path in 17th century).

             If the essential properties of the components are {R, S}, then it is a trivial task to invent real-software-components (having the essential properties {R, S}), which can achieve real-CBSD for effectively addresses the infamous software crisis by eliminating its root cause “spaghetti code”.

           Is it possible to invent things like fiber optic networks, by being clueless about nature and properties of light? Is it possible to invent things like semiconductor-chips/ICs, by being clueless about the nature and properties of electrons? How is it possible to find treatments for infections, by being clueless about nature and properties of viruses or bacteria. No useful engineering invention can be made, if necessary knowledge is flawed.

           How is it possible to invent real software components for achieving real CBD for software by being clueless about nature and properties of physical functional components? Many experts insist real CBSD is impossible without even knowing what it is (and refusing to even know what it is). Anyone can discover these facts (or objective reality) within a week or two at most.

             If the essential properties of the components are {R, S}, then it is a trivial task to invent real-software-components (having the essential properties {R, S}), which can achieve real-CBSD for effectively addresses the infamous software crisis by eliminating its root cause “spaghetti code”. All the evidence is already openly available on the web: real-software-components.com. I can illustrate this using 100s of examples, if anyone has any doubts.

          If no physical part can be a component without having the essential properties {R, S}, isn’t it wrong to define software parts without having the properties {R, S} are software components. No known kind of software components has the essential properties {R, S}.   

             Software researchers already wasted more than 25 years on the, since technological advancements allowed it possible to invent real-software-components for achieving real CBSD in 1990. Isn’t it painful, when researchers refuse to spend few hours to discover the truth, while has been wasting their hard work for nearly 27 years in pursuit of 21st century alchemy by relying on a lie (as researchers wasted hundreds of years evolving geocentric by relying on a lie)?

            I am not asking any one to believe me. I am begging to discover the objective physical reality such as nature and essential aspects of the CBD for physical products and essential properties of physical components.

              Answer to this question “which planet is at the center” is objective reality. Wrong answer 2300 years ago diverted research efforts into a wrong path for next 1800 years, until the fact (the Sun is at the center) is discovered.  

          Answer to these question “what is the nature and essential aspects of the CBD” and “what are the essential properties of the components” are objective reality. Relying on wrong answers 50 to 60 years ago diverged research efforts into a wrong path (that accumulated BoK 25 to 40 times more than the BoK for geocentric paradox). That is the reason, so far I can’t find any civilized way for compelling software researchers to investigate the evidence (except bribing them or suing the tax payer funded research organizations – When I can save enough money). I hope they sue me first, because burden of proof is on them (so it costs me a fraction, which I can afford).

Best Regards,

Raju

Dear Friends,

                 My struggle is to compel the research community to discover the truth (on their own) by investigating all evidence, objective reality and facts. I stand by every thing I said in the each of the over 30 contributions at: https://www.researchgate.net/profile/Raju_Chiluvuri4/contributions and each of the web-pages listed in this web-page provides general BoK (Body of Knowledge) for real-CBSD: http://real-software-components.com/moredocs.html

               Let me provide clear and unambiguous contrast between the self-contained components for software and physical products (no comparison can be as black and white as this contradiction): (A1) In the context of the physical products (every large physical product can be partitioned into many large disjoint sets of self-contained features and functionality): (A2) Almost each and every disjoint set of self-contained feature and functionality can be implemented as a replaceable component, (A3) Almost each and every disjoint set of self-contained feature and functionality can is implemented as a replaceable component, which can be disassembled and reassembled at any time in the future (e.g. redesign and test individually free from spaghetti design throughout the evolutionary lifecycle of the product). That is, each component is assembled or plugged-in as illustrated in FIG-1 (of attached pdf). This is the known objective reality for the CBD of physical products.

                 (B1) In the context of the software products (every large product comprises many large disjoint sets of self-contained features and functionality): (B2) Each and every large disjoint set of self-contained features and functionality can be implemented as RCC (Replaceable Component Class), so that it can be easily plugged-in & unplugged – This is the Heliocentric model of software engineering.

              This is the geocentric paradox of software engineering: (B3) Almost no large disjoint set of self-contained features, functionality is implemented as replaceable component (e.g. a module such as a class-definition for an object-instance that can be assembled or plugged-in). In other words, no effort is made to identify each of the sets of optimal size self-contained features and functionality, where each can be implemented as a RCC (Replaceable Component Class).

P.S: Notice the black and white contrast between A3 & B3, while A1 and B1 is same; and A2 and B2 being the same.

               The root cause for the geocentric paradox of the software engineering: The wise men (i.e. researchers and scientists) 50 to 60 years ago came to “consensuses” that it was inconceivable to create such replaceable modules, in light of then leading programming technologies Fortran or assembly languages. Based on best information and evidence available then, the thought leaders (i.e wise men or great minds) concluded that it is impossible to invent real-software-components (that are equivalent to the physical components) for achieving real-CBD for software, which is equivalent to the CBD of physical components.

                No one made any efforts to discover the objective reality such as nature and essence of the CBD and essential properties uniquely and universally shared by each and every known component in the world. That is, if the essential properties of the components are {R, S}, then no part can be a component without having the essential properties {R, S}. Understandably, the wise men at that time had no reason for doing research for acquiring such knowledge about the objective reality of nature of the CBD and components. Furthermore, it was not-useful and very hard to acquire such knowledge without any context and well defined objectives/goals.

              One can see that the difference is like black. If no physical part can be a component without having the essential properties {R, S}, isn’t it wrong to define software parts without having the properties {R, S} are software components. Today, no known kind of software components has the essential properties {R, S}, hence each and every known kind of software components are fake components and can’t achieve real-CBSD.

             It is complex to oppose the deeply entrenched convectional wisdom and common sense. It is not like preaching to the converted. My life’s mission is to compel researchers to investigate the evidence and facts to discover the Truth. No one questioned the validity of the lie (the Earth is static), but the Truth (the Sun is the center) faced the greatest hostile resistance. I expected rigorous but professional scrutiny. But I am not expected uncivilized attacks in the 21st century, when requested for an opportunity for demonstrating the proof.

Best Regards,

Raju Chiluvuri

Dear Dr. Mueller,

            Just like to humbly clarify this. No disrespect is intended, but kindly allow me to clarify my position. You said: Having developed commercial software in all 4 prevailing paradigms, I become vary nervous when someone suggests that there is only one solution to avoid "spaghetti code".

            I don’t know where I said that. But I said some things, which can be misunderstood as you quoted. I said, there is only one objective realty for things such as (1) nature and essential aspects for the CBD of physical products and (2) nature and essential properties that are uniquely and universally shared by each and every known physical components.

            In general, there exists just one objective reality for things such as nature and properties (or aspects) of physical things (or phenomena). The physical components are not exception to this rule. The purpose of scientific research is to discovering the objective reality by using theories (e.g. string theory) to get closer and closer to the objective reality (until it is possible to discover the one and only objective reality).

            In that context, I stand by my statement: There is only one right path for scientific progress. Such path must go though facts such as “the Sun is at the center”, “discovery of gravity”, “Newton’s 3 laws” and countless proven facts discovered by the researchers during past 200 years. Even if we might not know the objective reality (e.g. string theory), we can be sure that scientific research can’t make any progress in any other way that is not close enough to the objective reality. The geocentric paradox and exiting CBSD paradox are clear proof for this: Any research efforts end up in a wrong path, if it relies on belief that is in clear contradiction to the objective reality.

            I never said that “there is only one solution to avoid spaghetti code", although I invested lot of effort to prove this – I could not find any proof. My patents become useless, if there is other way to avoid spaghetti code.  Except the components and CBD, mankind found no better way for eliminating spaghetti code for past 1000 years. So I have a reason to believe that is true.

             But I am sure I must not have said that because I invested lot of time (and still investing) to find logical explanation to support or disprove my belief, but so far failed. So I am sure, I must not have said that (but I would admit mistake, if you can show me where I said that).

Best Regards,

Raju Chiluvuri

Dear Raju,

You told us this, “My patents become useless if there is other way to avoid spaghetti code.”

 There is one more problem actual for everyone who hold a patent. You, as a patent holder, should explain a given solution of a problem by your patent for everyone else. Otherwise, your achievement cannot be understood the right way. That is the situation that you face now.

 I can show you the easiest example of the situation. A well-known paradigm tells us this. If you have a physical object with N properties that you can change (or interact with), then you should create a class that describes that object. That class should have N methods which describe interaction with that physical object from a computer.

 For example, any driver of an operation system “knows” all N methods of a given device. Therefore the driver uses those methods to make a proper interaction with that device. If you replace that device with another device, the operation system plugs a new device to the computer be another driver. What is wrong here?  

 You tell us this. That is a wrong way of software creation. Very well! Can you tell us, please advantage of your point of view in not more than six sentences?    

Dear Dr. Zade,

            You said: I can show you the easiest example of the situation. A well-known paradigm tells us this. If you have a physical object with N properties that you can change (or interact with), then you should create a class that describes that object. That class should have N methods which describe interaction with that physical object from a computer.

            I agree and felt the same way, it is very insightful suggestion. But unfortunately it didn’t work. In the past 10 years, I tried almost every thing and learned countless things that didn’t work. I am still searching for a thing that works. One of my friends works for a defense company in the Silicon Valley.  They simulate the physical components in software (as you outlined).

             I requested for an opportunity to explain, why their components are very close the real-software-components, but they are obsessed with reuse, so my explanation is incommensurable in light of the existing paradox. I could have explained, if they had given me few hours of time (but I got just 20 minutes time).

You said:

You tell us this. That is a wrong way of software creation. Very well! Can you tell us, please advantage of your point of view in not more than six sentences?  

Let me try in 3 long sentences:  

(1)   Discover the nature such as objective reality about true essence or essential aspects of CBD of physical products (particularly design and development of one of a kind large physical products such as experimental spacecraft or fully-tested pre-production next generation Jet-fighter), where the essential aspects are the aspects uniquely and universally shared by design and development of every known physical CBD product.

(2)   Discover the nature such as objective reality about essential properties of physical components, where the  essential properties imply the set of properties (e.g. {R, S}) uniquely and universally shared by every known large physical component.

(3)   The 2nd is the most complex thing. It would take one to two weeks. Once the 2nd task is accomplished, it is a trivial task to invent real-software-components, which is capable of achieving the real-CBSD.

             The two of the greatest inventions for increasing the manual productivity are (1) Introduction of interchangeable components 200 years ago by Eli Whitney (which increased manual productivity by 200 folds), and (2) Ford’s moving assembly line 100 years ago (which increased manual productivity by 7 folds). Our experience in the industrial engineering shows that productivity can be increased by increasing the degree of each of these (i) increasing the degree of division of labor, (ii) increasing the degree of division of specialization and (iii) increasing the degree of division of automation. Every engineering activity employees all these activities. Hence, we are not inventing them, but trying to increase the degree of each of them.

            Eliminating the spaghetti code substantially increases the 1st and the 2nd, while the components are highly conducive to increase to automation by inventing sophisticated CASE-tools (one of the best tools I patented). Please keep in mind, over 80% of the software engineering is changing existing or already created software. Each large replaceable component can be redesigned at a fraction of the cost and time, because it can be redesigned and tested individually out side of the product free from the spaghetti code.

You said: You, as a patent holder, should explain a given solution of a problem by your patent for everyone else.

            Our patent disclosures explained extremely well considering the complexity and incommensurability. As per USPTO, my patents are the largest containing several hundred pages (not including source code attachments). The duty of patent filer only limited to disclosing comprehensively how one can achieve real-CBD by creating real software components, if and when he wants to achieve real-CBSD. On the other hand, it is the responsibility of the inventor or entrepreneur to promote invention, so that others want to achieve real-CBSD. The later has no bearing on the former.

Best Regards,

Raju Chiluvuri

Dear Raju,

You told this, “Discover the nature such as objective reality about essential properties of physical components, where the essential properties imply the set of properties (e.g. {R, S}) uniquely and universally shared by every known large physical component.”

 There is a problem here.  A computer has not any knowledge about “objective reality about essential properties of physical components.” A computer uses only electric signals coming from (to) a physical device. Therefore, physical properties of a device are unknown for a computer.

 Suppose you write a program code that a computer uses to communicate with a given device. That means only electrical communication between two devices, not “understanding of nature by a computer.”

I can show you my case if you have any interest in it. During 20-th century everyone made a measurement of the speed of light by a round-trip experiments sending a signal to a mirror and receiving a mirrored signal. The speed of light was ever determined by the distance separating the signal source and the duration of a round-trip experiment. The famous Michelson-Morley experiment used the same method. It gave the so-called null result.

 My research shows this. That is a common situation with any signal in every medium. To detect observer-to medium motion we need to split the experiment for two one-way experiments and make measurements of the duration of signal propagation to and from the mirror separately. That is the essence of my invention covered by the patent application WO/2015/040505. 

 Don’t you see how easily I can explain the core problem solved my invention? Obviously, that leads to a huge problem in theoretical physics because it means complete self-inconsistence of the theory of Relativity and physicists “refuse to build that device (SMA)” as well as “physicists from the past” refused to use Galilean telescope.

I guess that is a common situation that depends on human ego and has not any relationship with science.         

Dear Dr. Zade,

            I never talked about the computer. I only asked to gain knowledge about the objective reality such as essential properties. I only said this knowledge is absolutely essential If you want to pain an elephant, you need to know how it looks like. Paper does not have any knowledge about the elephant and the painting is just ink-dots.

            You can’t paint an elephant, if you have no clue what it is (e.g. animal, tree or landmark). Software researchers struggling to invent real software components for over 50 years by assuming reusable software parts are components- The mistake diverted software research into a wrong path, which after 50 years of research ended up in a paradox. I am trying to expose the root cause.

            It looks like, you have no clue about software components. Today there are many kinds of software components, where each kind of component is having certain useful properties of conforming a so-called component model. Instead of inventing fake components (having wrong properties), I am requesting to invent right components by discovering right properties.

            One must have knowledge of the essential properties to invent equivalent software components by sharing the essential properties. We know for fact that the design and development of physical produced is not effected by spaghetti code, because each of them are built by assembling the components (where each component can be refined and tested individually free from spaghetti code). The whole product is free from spaghetti code because about 95% of the features and functionality is implemented in such components.

Let me copy part of an earlier reply:

               Let me provide clear and unambiguous contrast between the self-contained components for software and physical products (no comparison can be as black and white as this contradiction): (A1) In the context of the physical products (every large physical product can be partitioned into many large disjoint sets of self-contained features and functionality): (A2) Almost each and every disjoint set of self-contained feature and functionality can be implemented as a replaceable component, (A3) Almost each and every disjoint set of self-contained feature and functionality can is implemented as a replaceable component, which can be disassembled and reassembled at any time in the future (e.g. redesign and test individually free from spaghetti design throughout the evolutionary lifecycle of the product). That is, each component is assembled or plugged-in as illustrated in FIG-1 (of attached pdf). This is the known objective reality for the CBD of physical products.

                 (B1) In the context of the software products (every large product comprises many large disjoint sets of self-contained features and functionality): (B2) Each and every large disjoint set of self-contained features and functionality can be implemented as RCC (Replaceable Component Class), so that it can be easily plugged-in & unplugged – This is the Heliocentric model of software engineering.

              This is the geocentric paradox of software engineering: (B3) Almost no large disjoint set of self-contained features, functionality is implemented as replaceable component (e.g. a module such as a class-definition for an object-instance that can be assembled or plugged-in). In other words, no effort is made to identify each of the sets of optimal size self-contained features and functionality, where each can be implemented as a RCC (Replaceable Component Class).

P.S: Notice the black and white contrast between A3 & B3, while A1 and B1 is same; and A2 and B2 being the same.

            I am sure ignorance could cause huge irreparable damage. On the other hand, real scientific knowledge could not do any harm (even if its uses are immediately apparent). I am only asking software researchers to discover the essential properties. When they discover the Truth, I don’t need to tell them anything. They would know what to do with this kind of knowledge. If the Sun is at the centre, even fools would realize that “the Earth can’t be at the centre”. Likewise, if the essential properties are {R,S}, then it is foolish to define any part not having properties {R, S} as components.

            Dr. Zade, this kind of discussion would be more productive, if you give me benefit of doubt (by not patronizing) that I have basic knowledge in my field of research. My point is simple: There is no reason for software engineering to be infected by spaghetti code – The root cause for the infamous software crisis. This already cost world economy more than trillion dollars.

P.S: I am not qualified to make any intelligent comment on your work or such subtle matters of physics.

Best Regards,

Raju

Dear Raju,

There is not any “patronizing” from my side. I show you only light situation. You tell us obvious things that all program code should use physical properties of a physical unit. In other words, a class of a program code should use methods that a physical device supports. Everyone understands that.

However, in practice, some software project do not use that easy way. That is a problem of software developers, not a present paradigm. 

You mentioned an interesting thing, “This already cost world economy more than trillion dollars.” Very well. That causes another question to you. Suppose, you can make a solution of that problem.

Why do not you take all those “trillion dollars” by your invention? 

Dear Dr. Zade,

Keep in mind, initially the signals are sent by machine instructions (i.e. number codes). It was so complex, so assembly language was invented, so that one can write in English rather than number-codes. Then Fortran was invented to write code in English-line programming language. The OOP is invented to organize code around objects.

Researchers have been struggling to invent COP (Component Oriented Programming) and CBSD (Component Based Software Design) for decades. The approach they took is by using reusable parts, without having any knowledge about the objective reality such as essential properties of components or true essence of CBD. My argument is simple, just acquire the knowledge and solution to the problem would be no brainer (i.e. straightforward and appetent to any software expert).

Best Regards,

Raju  

Dear Raju,

You think this, “The approach they took is by using reusable parts, without having any knowledge about the objective reality such as essential properties of components or true essence of CBD.”

 That is a good observation. But everyone can ask you a question. How can you separate "an essential property" of a component from other properties?

Strictly speaking, there is not any possible way to make such separation. Different persons and different applications use different properties of the same component. Therefore, the list of “essential properties” of a component depends on the purpose of the application that uses the component.

How can you avoid that duality? 

For example, a GPS receiver can be used to make determination of the location of the object (the receiver itself) or by receiving the signal of the current Time. What is the right list of properties of that component from your point of view?

Dear Mr. Zade,

            The estimated cost of software crisis is no my words, but by many respected institutions including many government organizations. Please see the attached summary. I am giving 1995 estimates. For example, before year 2000 alone cost of bugs is nearly US$60 billion per year to the US economy alone.

            The latest Boeing Air Craft has 2 million components, which creases once in 2 million take-offs, while MS-Word having 2000 equivalent size components crash every other week. The case for Word, only cause for crash is internal design, while Air Craft cause for crash is external such as Terrorist, Wear-tear, Human-mistakes or weather.

            There is no reason, we can’t build software 100 times more complex than practical today (having 100 times more quality). Also read this interesting article:  http://www.sandia.gov/LabNews/LN09-10-99/super_story.html

You said:

Why do not you take all those “trillion dollars” by your invention? 

            It is uncalled for. Anyone can make sarcastic comments, but competent people counter facts by facts and reasoning.

Please see attached PDF. This situating existed for past 27 years, because software advanced sufficiently to achieve real-CBSD since 1990. Worldwide costs are hundreds of billions of dollars each year.

Best Regards,

Raju

Dear Raju,

I have read through all documents you mentioned in your previous post. You like to see an obvious counter-arguments. OK let’s discuss a counter-arguments. 

 All things mentioned in the documents that you referenced shows a common misunderstanding of the process of software development by a general population.

 All work in software development starts from a specification. That is a cone stone of every project. A creator or (writer) of that specification should explain all things that he requires from the software. Unfortunately, that is not ever reachable. As a result, many decisions appear at the process of software development. Moreover, many customers, frequently request self-inconsistent or self-controversial requirements for the software product because they have not a clear imagination about the result they need. Sometimes, it takes a lot of time to make things clear. 

 Usually, the extra budget appears as soon as a customer “make a tremendous decision to make a product better” after agreed specification. Such decisions make 90% of “Spaghetti code” because software engineers should rebuild code from the scratch to meet the “new purpose” that was not mentioned at the start of the engineering process.  

Now, you’d like to make a solution of that problem by CBD. That is impossible because any model of software development is irrelevant to that problem.

From the other hand, we have the same situation. Suppose, you write a perfect code using your CBD-software model. Very well! Your class uses N methods which exactly match N functions of the physical device. It looks fine at first glance.

 However, a next edition of the same physical device uses N+M functions and destroys your “perfectly written and organized class” because you have no idea of those M new functions at the moment of creation of your perfect class based on your CBD-software model.

Worse than that, the outer code that calls your class has no idea about those M extra functions too. Therefore, you need to rewrite that code too and all other code that have any interaction with those M extra functions. In other words, your idea of the simple plug-in of a new CBD-class loses its attraction because you need to rewrite all code outside of you CBD-based class.

That is the critical point that all developers who know problems mentioned above never use anything like CBD-based classed.

In case of physical objects, they do their action because of physics that allows them only restricted actions. There is nothing like that in the area of software development because a computer has no idea of possible usage (or physical restrictions) of a device. 

Have you any more question now?

Dear Dr. Zade,

            If you could go back 400 years, I am sure similar rationalization was used for justifying geocentric paradox. I am software engineer having 28 years experience, of witch 12 years working for leading technology companies in the Silicon Valley (dealing with millions of lines of code).

            Why do you think such problems only effect software. Almost design and development of any and every new product have all these kinds of problems. No designer knows what the end product would look like. For example, let me show you a small video of designing a new product (please jump to third paragraph and see small video in the link provided artificial kidney): http://real-software-components.com/technologies/componentization_purpose.html

            If you observe design priorities of automobile or Air-plane, you would notice that many designers are obsessed with “service access” to most of the parts, so that they can be easily replaced. You don’t want to disassemble your whole engine to change spark-plugs or change oil. Likewise, 30 years ago, many of us upgraded our PCs by upgrading CPU or memory etc. The “service access” even today allow us to add more DRAM etc.

            Any application designed as CBD provides outstanding “service access”, so each component can be redesigned at one-tenth cost or time. Please go back and read my compression between A3 and B3. Today no set of self-contained features and functionality is implemented as RCC (Replaceable Component Class), but each and every set of self-contained features and functionality can be implemented as RCC. We invented intelligent CASE-tools (copied from Boeing, which are used to assure compatibility) for automatically creating and managing the communication interfaces to allow collaboration between the components.

            All these things would be apparent (and how it works), once researchers spend a week or two to gain knowledge about the nature and the essential properties of the components. Today no one even knows, what real-CBD is. The CBD for software provides outstanding “service-access” to each and every RCC, so that it can be redesigned at a faction of the cost and time. Our innovative CASE-tools are valuable to maintain compatibility. A simple or trivial version of the CASE-tool is at: http://real-software-components.com/CBD/Sample_SoA_CASE_tool.html

    We built many unique applications, where each major feature or functionality needs to be changed 20 times even before first release (in the same way as the artificial kidney). Having “service access” to each component (by making it free from spaghetti code) and CASE-tools eliminate over 90% of the error prone activities.

   Let me illustrate this using example: http://real-software-components.com/CBD/City_GIS.html.  Today no GUI-technology allows you to implement City-ATC or City_LandMarks as RCC (even if the components need to talk to any other component in the application). If you need to implement 5000 lines for CiTY_ATC, in case of real-CBD it is implemented as RCC, which requires just 3 lines to plug-in the component. But today, you need to merge most of the code into the code for the software application. So you need to remove several thousands of lines of code to replace it.

           Kindly give me some benefit of doubt that I know what I am talking about. I spent 15 years for accumulating overwhelming empirical evidence and debated with over thousand leading software researchers by attending many leading software engineering conferences.

Best Regards,

Raju Chiluvuri

Dear Friends,

            Many researchers argued that “incommensurability” is not real. Scientific revolution is not noticeable in section-6: https://plato.stanford.edu/entries/thomas-kuhn/#6. Let me prove that they are wrong.

            The geocentric paradox evolved for 1600 years rooted in a lie “the Earth is static”. This altered their perception of reality. Likewise, software engineering evolved for 50 years by relying on lies (e.g. reusable parts of components). The reality is, almost all the large replaceable components are custom designed to satisfy current unique needs of the application (and to quickly adopt to often unpredictable changes).  Eliminating spaghetti code eliminated over 90% of the cost and time to keep up with changing needs.

            Any lie can be easily corrected if there is no BoK (Body of Knowledge) is acquired by relying on the lie. But research efforts are invested by relying on the lie for accumulating huge BoK, this process alters perception of reality. Since the geocentric model acquired huge BoK for 1600 years, there was incommensurability between geocentric model and heliocentric model.

            Today, existing CBSD paradox has accumulated 20 to 30 times more BoK then the geocentric paradox. I have been experiencing incommensurability every day. For me it is not a myth. It is a significant problem. Keep in mind, I was a huge supporter of “No silvered bullet”, “Mythical man month” or “Big Ball of Mud” until 16 years ago. My own discoveries contradicted my convictions, which induced irresistible curiosity to focus on this research.

            Keep in mind, a lie on its own don’t leads to a scientific crisis. But the BoK created for long enough time for accumulating big enough “conceptual matrix” of interdependent concepts and observations by relying on the lie leads to scientific crisis.  For example, the huge BoK for geocentric model was rooted in a lie (i.e. the Earth is static). Likewise, the 20 times huge BoK for existing CBSD paradox was rooted in lies.

         The concepts and observations painted a reality (see FIG-1), which was radically different from objective realty (See FIG-4) at: http://real-software-components.com/more_docs/epicyles_facts.html.

            Each of the concepts or observations in the BoK (or conceptual matrix) for geocentric model is consistent with each other and with the reality painted by FIG-1. Likewise,  Every concept and observation in the BoK (or conceptual matrix) for Heliocentric model is consistent with each other and with the reality painted by FIG-4. But each concept or observation in Heliocentric model is nearly impossible to understand in light of geocentric model.

           Dr. Zade and others inability to understand my facts is an example for the incommensurability. Hence incommensurability is real and it is a huge problem.

Best Regards,

Raju

Dear Mr. Zade,

1. Some of us find inappropriate to accept the title of Dr. when it is not earned, and I can't find any indication that you have a Doctorate. You are only referred to as a Russian Research, but you appear to live in the UK.

2. Also, I can not find any indications that you have a degree or experience in software development or computer science. As you demanded to know Raju patents, I would like to know the educational and experience bases for participating in this discussion.  

3. I'm curious as why you fell the need to belittle Raju work when It is clear that you have nothing to add, and no actual experience in the work.

Sincerely

Carl J. Mueller, Ph.D., CISSP

Dear Dr. Mueller,

            Thank you for your support to keep this debate civilized. Very few people have any courage to openly support me (i.e. my right to expresses my views (I have good reason to believe to be facts), but other's perceive to be politically-incorrect, disrespectful or heresy to question conventional wisdom).

            My view are formed by keenly observing the many realities of physical products such as documents works “the Evolution of Useful things”: http://real-software-components.com/misc_docs/EvolutionOfUsefulThings.html and undocumented things spread across the web such as introduction of interchangeable components, where I had to search and find hundreds of piece of information available on the web to paint a picture of what really might had happened. Of course, we all have prejudice (even if we admit or not), so my understanding might not be perfect but I feel close enough (because I used so many hundreds of pieces of information to paint nearly consistent picture for my self). More and more good pieces allow painting increasingly better picture, because this overall growing knowledge allow to make educated guess about the quality of each piece of the information.

            Many software researchers feel software is unique, but they are making apples to oranges comparison. But I am requesting that we need to make apples to apples comparison: http://real-software-components.com/CBD/main-differences.html - Comparing design and development of one-of-a-kind new physical product with the design and development of new software product. I have to paint a new perception of reality, which is complex task because of the incommensurability.

Best Regards,

Raju

Dear Carl J. Mueller,

I started the discussion with Raju in another thread where he asked a question about a paradigm shift. He had a detailed answer from me, and he was greatly satisfied. Later I had a decision to see his research deeper and came to this discussion. Personally, I have some experience and background in many areas including embedded micro-controllers, software development, ISO 9000, patents, and others.

Therefore, Raju’s activity looks interesting for me. I gave him some answers on his initial question of this discussion. My business answer was this. A businessman uses his idea to build a highly profitable business and not to spread an idea among other businesspeople. Business community thinks in its basic categories of profit and income. Any other businessman asks Raju the same question. As a result, Raju has not any progress (by his words) in the last decade.   

My patent answer was this. Any patent researcher asks Raju a question about the novelty of his invention and inventive step (I guess you know it). Raju should answer those questions before he got a patent. To my surprise, Raju gave not any suitable answer. All his references show only dynamically build classes which are known as prior art. Therefore, that idea cannot be treated as a patentable invention. I can tell you between us; I saw some “patents” which describe “a Perpetuum mobile.” Those patents were granted because the description (or the idea) of “a Perpetuum mobile” can be seen only after a detailed analysis of specification.           

My answer as a software analyst was this. Any method of any class should be called from another program unit in general case. Raju’s explanations and links he provided show this. All his speculations are based on a standard user interface that uses a mouse and a computer screen. That is a particular case. Therefore, user interaction with “a method of a registered class” appears as a mouse click on a user interface object.

In general case, he faces a different situation. For example, suppose he uses his components in avionics. The on-board computer of an aircraft has not anything like screen user interface. Therefore any program unit should “know” the right list of methods applicable to a given CBD-class. Calls of those methods appear in the program code of other modules. Therefore, the on-board computer program crashes (or fails to proper work) as soon as Raju removes a single CBD-class of a critical on-board device (Pitot tube, for example). They tell him that counter-argument for a long time, but he didn't listen to them (for ten years as he mentioned).

Moreover, Raju gave not any answer on my question about a physical unit that can be used in more than one way (GPS- unit, for example). In other words, Raju does not like to discuss the problem from a different perspective. From my point of view, he likes only to make a presentation of his idea without discussion of counter arguments.

Do you agree that point of view?      

Dear Mr. Zade,

            I must disagree with many of the things you said about me. I am here in the ReserachGate as a researcher but not as a business man. This is not a forum for business ideas but for exchanging or debating novel concepts.

            Mr. Zade, I gave you patent numbers and abstract or each main claim summarizes novelty or inventive step. Also you can see each office action and process of approval of my patents at USPTO. I filed patents for missing pieces for achieving real-CBD such as CASE-tools or GUI-technologies.  Please go back and read your messages.

You said:

You mentioned your “patented COP.” Can you tell me the number of your patent (or patent application)? As you remember, obvious solutions cannot be patented. Therefore, if you have patent on an obvious solution, that is a failure of a patient because someone can raise objection for the patent.

            I clearly told, we invented world first GUI-technology that is capable of creating large RCC (Replaceable Component Class). Today no other GUI-platform (from Microsoft or Apple) can create such RCCs, for example, for applications such as: http://www.real-software-components.com/CBD/City_GIS.html and https://www.researchgate.net/publication/292378253_Brief_Introduction_to_COP_Component_Oriented_Programming

            Every reply contains such falsifiable facts, which can be falsified by just finding even single counter example. I have a dozen software engineers and we are creating solutions for every conceivable problems and encapsulating into RCCs. I answered every question you asked. But I can’t give answers you expect or you want.

          Entrepreneurship is taking risks and try to make money by providing value. Also to change the world for better. Almost every business is fraught with risks. Many greatest inventors never made money on their great inventions (e.g. Tesla or Eli Whitney). These are my personal views. I am not asking you to follow them. Likewise, you cannot expect me to understand your views about business.

           I invested 15 years of my productive time by closing profitable business. I am used to insults and personal attacks, because I feel it is my destiny to solve software crisis, even if it meant to be belittled or humiliated by irrational skeptics: http://www.real-software-components.com/misc_docs/irrational-skeptics.html 

            Dr. Zade, please don’t deflect blame on to me for your impatience and  sarcastic remarks. I stand by the facts that “the software crisis can be addressed” by gaining knowledge about the nature and objective reality about the essential properties of the components and true essence of the CBD. I gave example of viruses, fiber-optic networks or semi-conductors. 

          I clearly stated these goals in my profile. I am not going to give up until I am successful. I filed patents, because I can leverage them, if I need to invest raise VC money to achieve these goal.

            Of course, I am not yet successful so far in this effort but also I said this is because software researchers refusing to give me an opportunity to demonstrate proof. A paradigm shift is not a simple thing. Let me quote Bertrand Russell: “The whole problem with the world is that fools and fanatics are always so certain of themselves, and wiser people so full of doubts.”

            Very few people have courage to defend my rights to express my views as Dr. Mueller did here. He may or may not agree, but he defended my right to present my ideas in civilized manner. I never evaded any questions. I am sure, most agree that your comments are belittling. I clearly pointed out and you keep doing it.

Best Regards,

Raju

Article Brief Introduction to COP (Component Oriented Programming)

Mr. Zade,

Actually no, I do not agree with you. You complain about Raju, not answering you questions, but you did not answer mine.

Since I have developed and tested avionics software, I can say that you have no idea about what you are talking about. You present yourself as an expert, but you do have an academic credential, nor have you indicated a understanding of the problem. You actually are providing substantial for the premise of this thread.

Please troll elsewhere.

Raju,

James O Coplien might be able to help you with the work that your doing.  He is one of the pre-eminent scholars on OOP. He also is not like by some of the traditionalist.

Dear Dr. Mueller,

            Thank you. I just started following Dr. James O Coplien in ReserachGate and try to contact him.

            The problem I am facing is incommensurability: https://www.researchgate.net/post/Why_many_philosophers_argued_Kuhns_notion_of_incommensurability_does_not_exist_or_it_is_not_a_significant_problem

            Until researchers discover the objective reality about the CBD and components, and use this knowledge as a foundation to construct a CBD model, most of the things I say might appear strange or incommensurable.

            Also certain ideas need inventing “enabling tools and technologies”. For example, interchangeable components need invention of enabling tools such as jigs, dies, casting or molds etc.

            Likewise, real CBSD needs “enabling tools and technologies” such as CASE-tools for dynamically creating and maintaining coupling interfaces, and of course knowledge of the essential properties of components to positively identify each set of self-contained features and functionality that can be implemented as “real-software-component” (or replaceable components) and the ability to implement RCC-Replaceable Component Class (today no other GUI-platform is capable of inventing RCC).

            I am facing a strange problem: In the context of CBD for physical products, if a product has six components, then the CBD is designing and developing each of the components individually and plugging-in as illustrated in FIG-1 (in attached PDF). Isn’t it obvious? But such obvious thing appears to be strange and incomprehensible in the context of software products:

            If a software product has six components, no one able to understand this obvious thing: See this example with six software replaceable self-contained components, where each is plugged-in by writing just 2 lines of code: http://real-software-components.com/CBD/City_GIS.html and I used simple CASE-tools to allow necessary collaboration between components: http://real-software-components.com/CBD/Sample_SoA_CASE_tool.html

            Kindly notice that there is no additional communication code (other than the 2-lines to plug-in the component).Today such CASE-tool doesn’t exist (to allow communication between components with in a single executable). Also today no GUI-technology is capable of creating such RCCs, even if an engineer has knowledge to positively identify each disjoint set of self-contained functionality in an application.

Best Regards,

Raju Chiluvuri