I know we've been "at it" in a previous post about this, but once again I am going to remind you.  Software and Computer Science are technically independent.  When we demonstrate results in CS, good solid research has theorems proved, or programs written to see if our ideas work well.  So if anything, if you wanted to engage in physical evidence that debunks the methods of computer scientists, you'd need to radically change the field by showing one of its fundamental principles is false.  One notable theses in our field is the Church-Turing Thesis (it's an important empirical assumption we do make as computer scientists).  It's widely accepted by computer scientists, and allows us to make statements about computers quite effectively.  Honestly, if you wanted to show anything radical, I'd go after showing that is wrong, not this other stuff as computation can "live on" without software technically since computation is a mathematical construct, independent of physical computers.  CS doesn't really jump hoops passed what other scientific fields ask for (when I say this, I of course am talking about what is traditionally considered CS, not applied CS); it does fine as a scientific discipline.

Hi,

Long text you have there. Not sure it's the best way to approach debate in media such as research gate (because it's hard to reply to all information you've wrote). Anyway I'll try to give my opinion.

Although the absolute objectivity of science is a widespread conception, at it's roots this is not exactly true. Science is more like "educated guessing" and less like "absolute truth". It's less subjective than most disciplines but that does not mean it's not subjective.

A good example is the use of the expression "laws" in science. It was an expression more common in the beginning of the last century than today. The reason is simple. There were so many exceptions to the accepted "laws" at a given time that a possible analogy could be "approximation" or "reasonably accurate".

Even our more basic sciences have their axioms or assumptions. Why is it that any number with an exponent of zero equals one? Why is it that the factorial of zero equals one? Why is it that two negative numbers multiplied give a positive one? And the list continues on and on. These are premises (not irrefutable facts!), or starting points, that we use to enable us to continue to study further (but still human conceptions just like any other product of human linguistics).

That said the problem you put here is a complex one but it should seen with some perspective. The current computer science paradigms are not any more flawed than any other science out there. They're just the "working model" of our days. And it will continue to be until a new (or old) better model is proposed or implemented. From what I understood you would like to propose (or develop) a new stance for either software, hardware or both.

Seems great but most companies are looking for something that brings an effective advantage (performance, simplicity, etc.). My advice is for you to look into companies working with electronics in very isolated environments such as digital clocks. Nothing goes in, and nothing goes out. It's just code and hardware for "simple" (simple here is controversial but you get the point) mechanics. The perfect lab for some hardware-software experimentation. There should be a lot more examples (I just can't remember any at this time) you can consider but remember that there must be an initial purpose (again: performance, development simplicity, flexibility, etc.) otherwise almost no one will see the point in the effort.

Hope it helps.

I know we've been "at it" in a previous post about this, but once again I am going to remind you.  Software and Computer Science are technically independent.  When we demonstrate results in CS, good solid research has theorems proved, or programs written to see if our ideas work well.  So if anything, if you wanted to engage in physical evidence that debunks the methods of computer scientists, you'd need to radically change the field by showing one of its fundamental principles is false.  One notable theses in our field is the Church-Turing Thesis (it's an important empirical assumption we do make as computer scientists).  It's widely accepted by computer scientists, and allows us to make statements about computers quite effectively.  Honestly, if you wanted to show anything radical, I'd go after showing that is wrong, not this other stuff as computation can "live on" without software technically since computation is a mathematical construct, independent of physical computers.  CS doesn't really jump hoops passed what other scientific fields ask for (when I say this, I of course am talking about what is traditionally considered CS, not applied CS); it does fine as a scientific discipline.

Greetings,

Perhaps a visionary could step out of this complex box, try to think in abstract terms, you have identified a problem, separate the real issues and the others that are fluff and rather than attempt to discredit or disprove another's work or theory develop your own that is based upon objectionable theory or fact, you are obviously very smart.

A new concept could be the use of metallic bonding in a multi dimensional field  or even polar covalent bonds where you are able to rewire the nucleus and.... perhaps a misguided attempt in the nanotechnology arena.

In my country we have a saying, it is my ball and I make the rules (referring to baseball), well Raju I respectfully leave the ball in your hands

Dear Dr. Correia,

          I believe computer science no longer needs different and new definitions (e.g. properties and descriptions) for software components and CBSD (CBD for software products). I believe that, I can provide physical evidence, that it is possible to discover the accurate descriptions for the large physical functional components and CBD (Component Based Design) of one-of-a-kind physical products (having at least a dozen physical functional components) such as experimental spacecraft or prototype jet-fighters, and invent real software components (that satisfy the accurate description for the physical functional components) for achieving real CBSD, where real CBSD must satisfy the accurate description for the CBD of physical products.

I heard many unsubstantiated assumptions, such as software is unique/different and/or it is impossible to invent real-software-components that are equivalent to the physical functional components (by satisfying the accurate description for the physical functional components). In real science, anything not having proof is an assumption and such assumptions must be documented before relying on them to create definitions/concepts. No text book for introducing software component listed such assumptions.

When any scientific discipline was in infancy, researchers are forced to make assumptions. For example, assumption "the Earth is flat" was a reasonable assumption 3 to 5 thousand years ago. Likewise, the assumption "the Earth is static" was a reasonable assumption 2000 years ago. But documenting such assumptions would avoid huge pain and suffering such as: http://real-software-components.com/forum_blogs/BriefSummaryOfTruths.html#Chronology. If that error was not yet exposed, no meaningful scientific progress would have possible.

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

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

          This is highly falsifiable first principle (i.e. assumption), so it can be proved false, if it is flawed.

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

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

All I am saying is, it is wrong to NOT document such assumptions before relying on such assumptions for making up definitions for so called software components (out of thin air without any basic in reality, but based on wishful thinking).

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

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

Best Regards,

Raju

Dr. Page,

I am asking, what kind of physical evidence is required for you to expose the error? Today I can demonstrate hundreds of components and component hierarchies (i.e. physical evidence) such as: http://real-software-components.com/CBD/City_GIS.html. I asked you many times, can you show me even a single RCC (Replaceable Component Class) – a class definition that can encapsulate a ‘self-contained feature’ such as City_ATC or City_LandMarks in a replaceable class anywhere in the world?

It requires just 3 to 5 lines to assemble each of such self-contained components into any application (by using its RCC), and the component can be disassembled by removing the 3 to 5 lines. Without such RCC, developers are forced to add code chunks of this component into many non-exclusive files comprising code-sections for many other such components – resulting in spaghetti code. It is impossible to redesign and test such components individually.

When I explain this, many people in Industry suggested me that, it gives them more confidence and gives me more credibility, if I can build their complex GUI applications as CBD-structure: http://real-software-components.com/CBD/CBD-structure.html.

Considering the complexity, I felt, I need to build a team of 10 to 12 engineers for training them in our processes and build necessary API/Tools, so that, our team can work closely with their engineers (to solve their problems) for few weeks or even couple of months, so that their enginers can experience the physical evidence firsthand.

I believe, they can’t deny the truth after having firsthand experience for few months (and maintaining each of the RCCs free from spaghetti code for years after deploying the application to the customers), so I am in the process of starting a company http://www.pioneer-soft.net to provide physical evidence to whoever is willing to give us an opportunity.

Dr. Page, I am asking you to come after me to prove me wrong by give me an opportunity to provide physical evidence. Show me a single application toady, where 97% of the features and functionality implemented in RCCs (e.g. http://real-software-components.com/CBD/City_GIS.html)? Alternatively, give us an opportunity, and we can help you build your application (free of cost) by assembling such RCCs. I am sure each of the large applications you designed contains multiple ‘self-contained features and functionality’, which can be implemented as RCC (free from spaghetti code), but none of them are implemented as RCCs (so ended up as spaghetti code).

Dr. Page, even if computer science is not a real science (but a kind of mathematics as you had been insisting), isn’t wrong to rely on such unsubstantiated assumptions to derive definitions/concepts for software components? What is wrong with documenting them, so that future generations can expose the flaws, if they are flawed (when technology advances sufficiently for validating them, even if no one can validate them at that time)?

Dr. Page, you tone feels like (please correct me if I am wrong), you wanted to silence me forever from expressing my views, which I considered to be facts. I spend, more than a decade to make sure that I am absolutely right. For your kind information, I accidentally stumbled on to a new kind of components during 1999 and created hundreds of component hierarchies during 2000 to 2003, which induced irresistible curiosity to leave my work to focus fulltime on this research and pursuit of Truth (I am not saying, my answers are absolute truth, but I am only perusing the truth and I am sure that my concepts are correct steps in the right direction, so closer to the Truth).

Dr. Page, last year I only objected to personal attacks and insults, but you can always welcome to come after my views and concepts. They are published openly in my blogs and website http://www.real-software-components.com. In near future (our team and tools are ready), our team can provide physical evidence (free of cost), if any one willing to give us an opportunity.

Dr. Page, if you wanted to know the truth and engage in productive discussion, please kindly suggest me, what kind of physical evidence can convince you (and others experts like you) and compelling enough for you to give me enough time to verify the physical evidence.

Intention of this questions is get such suggestions, I will try to create such physical evidence, if it is practical and within the reach of my affordability. My friends suggested, I can convince them, if we can help them build their applications by assembling RCCs. It was a reasonable and constructive suggestion, so I am in the process of creating necessary tools and a small team. I am happy to oblige, if you have any such constructive suggestions.

Best Regards,

Raju

Dear Dr. Fitzgerald,

Thank you. I need the ball in my hands to get opportunity to show physical evidence. Being from a mature scientific field of physics, I am you sure you could understand my above argument that: In real science, any thing that can’t be proved is an assumption. It is an error to rely on any unproven assumption without documenting the assumptions.

I believe, endless debate 500 to 400 years ago didn’t settle the argument, if the Earth is moving and which planet is at the center. The argument eventually settled due to the advancement of technology (e.g. telescope) to see the physical evidence and the willingness of young researchers to see the physical evidence with open mind.

A real Kuhnian paradigm shift is a complex process, because each of the core concepts of a new paradigm contradicts a dozen concepts of old paradigm, so nearly impossible to explain any of the core concepts of new paradigm to highly skeptical audience, who are experts and well versed in the concepts of old paradigm.

Only way is: creating necessary tools for advancing the technology for accumulating and demonstrating physical evidence to whoever is willing to see physical evidence with open mind. Some experts are lost cause, because it is impossible get an opportunity to show the physical evidence and convince them to examine the physical evidence with open mind (free from preconceived notions and without conformational bias).

Even though I said many times that I meant no disrespect, few experts feel that I am arrogant and disrespectful to even ask such questions. There is no polite way to ask such inconvenient questions. For example, saying the fact that ‘the Sun is at the center’ offended then deeply entrenched conventional wisdom and common sense.

When any scientific discipline was in infancy, researchers are forced to make few assumptions. For example, assumption "the Earth is flat" was a reasonable assumption 3 to 5 thousand years ago. Likewise, the assumption "the Earth is static" was a reasonable assumption 2000 years ago. But documenting such assumptions would avoid huge pain and suffering such as: http://real-software-components.com/forum_blogs/BriefSummaryOfTruths.html#Chronology. I believe, if the error at the root of geocentric model was not yet exposed, no meaningful scientific progress would have possible.

As science and our knowledge expands, future generations can create tools to validate such assumptions, if such assumptions are documented. Unfortunately computers science defined each kind of useful parts (e.g. having useful properties) is a kind for software component for a kind of CBSD. No one documented the assumptions that resulted in such definitions, which are far from reality we know about the physical functional components. Using such fake components is not CBD.

Best Regards,

Raju

Raju,

"When any scientific discipline was in infancy, researchers are forced to make assumptions."

We are always making assumptions. Infancy or not. You've mentioned the geocentric model of the universe. It is as truth as an assumption as it is the non-geocentric model of the universe. Although I won't try it (I'm guessing it would take a while) it's probably possible to make our whole physics based on the geocentric model with no significant loss of accuracy. It's numbers and you can "engineer" your way to whatever assumption you want to believe. The reason why non-geocentric model is accepted is just because it makes more intuitive sense. So common sense is the great decider.

Science is not the art of truth, it's the art of accurate. Better science does not mean you are closer to the truth (you would have to know the truth to be able to claim that!), it just means you are able to model more accurately a phenomena. Nowadays modern societies seem to view science almost to religious status (we keep assuming dogmas, only this time with university degrees). Personally I see it as a fork. I know it, I use it and than I wash it for the next meal.

Besides the philosophical ideas I would suggest you to define some few points open to debate. It's very complicated to debate such a broad subject. It's too vague. I've read your comments and I still can't put my finger in what exactly are your trying to reform (in good part maybe because I don't have enough skill in some of the areas you're touching).

Dear Dr. Correia,

            I have to respectfully disagree with you. I believe, relying on the first principle (e.g. assumption) that “the Earth is static” lead us in to a wrong path and derailed our scientific progress. How could you explain, a big planet Sun that is 300,000 times bigger than the Earth circling the Earth. Newton discoveries such as Gravity and laws of motion (and calculus to prove the laws) could not have possible without Kepler’s laws.

            Of course, one going on train might pensive that he is static and landscape is traveling backwards. It could make good logical argument. But I believe, when discussing relative truths, we need to rely on guidance provided by great philosophers of science, For example, let me quote a paragraph from Wiki-page for Dr. Karl Popper:

Popper is known for his rejection of the classical inductivist views on the scientific method, in favor of empirical falsification: A theory in the empirical sciences can never be proven, but it can be falsified, meaning that it can and should be scrutinised by decisive experiments. If the outcome of an experiment contradicts the theory, one should refrain from ad hoc manoeuvres that evade the contradiction merely by making it less falsifiable. Popper is also known for his opposition to the classical justificationist account of knowledge which he replaced with critical rationalism, "the first non-justificational philosophy of criticism in the history of philosophy."

Also, my goal is to achieve CBD-structure for any software application: http://real-software-components.com/CBD/CBD-structure.html for any complex software products. For example, see a sample application: http://real-software-components.com/CBD/City_GIS.html. I believe this would have profound effect of software engineering, especially creating complex applications.

My goal is: if an application has 6 “self-contained features”(SCC), each engineer must be able to design and test each SCC individually. Then application must require no more than 30 (i.e. 6*5) lines of code to assemble the 6 components. This is not that much different from, how we build a physical product created by assembling 6 components, as illustrated in step-1 & step-2 of CBD-process: http://real-software-components.com/CBD/CBD-process.html

This must be true, even the software/physical product has 2000 SCCs. If I am responsible for a component, I should be able disassemble the component, to refine it and test it individually outside of the product (without being forced to see code for any other part of the product). I think that it is possible and would like to provide physical proof, by inventing CASE-tools like the one shown in FIG-3 in: http://real-software-components.com/CBD/Sample_SoA_CASE_tool.html

I hope the above gives you the context. Also, on a lighter note please let me give you a funny analogy:  I live in Hyderabad (a city in southern India) and if I want to visit New Delhi (a northern City and capital of India). It sounds odd, if I say New Delhi is traveling towards me, while I am sitting in static Train (because when I saw outside, if looks like I am sitting in static train and the landscape traveling backwards and New Delhi coming towards me).

Just having fun with your logic. No disrespect intended, just trying to be funny. Billion+ population of India disagrees with me and insist that I am moving and they are not moving :-)

You said:

> We are always making assumptions. Infancy or not.

All I am saying is, it is mistake to not document such assumptions. If they are documented and if they are wrong, future generations can invalidate the assumptions as our knowledge expands. Such mistake would have huge costs, because, the whole paradigm would collapse, if first principle (i.e. assumption) at the root of any paradigm is wrong (even if the paradigm evolved for 1000 years and result of passionate effort of million researchers).

When the assumptions can be proven wrong, we must scrap all the concepts and definition of our perception of reality (i.e. paradigm) derived by relying on flawed assumptions and start over again to reconstruct new perception of reality based on more accurate first principles (if it is possible to discover more accurate first principles, this time by not repeating the same mistakes and based on far more advanced latest scientific knowledge available today).

Hopefully the new perception of reality end up bit more closer to absolute True reality and/or puts on right track to get closer and closer to the absolutely True reality. That was what discovery of Copernicus did 400 to 500 years ago at a huge suffering: http://real-software-components.com/forum_blogs/BriefSummaryOfTruths.html#Chronology

P.S: I am not saying, existing mankind’s perception of reality is absolute Truth, but I am sure every philosopher of science agrees that existing perception of reality is far more closer to the absolute Truth compared to the perception of reality painted by geocentric model 500 years ago. A whole discipline of epistemology (a major sub- discipline of philosophy) is created for analyzing the accuracy of the knowledge.

Best Regards,

Raju

Hi Raju,

You misunderstood me. I've not argued in favor of geo-centrism, I've just put into perspective what knowledge as we know it may be (which is the main reason for the philosophical science epistemology). For that very reason I've finished that particular paragraph of my answer with an opinion of "common sense is the great decider".

As for believing other models from the currently accepted I would have to be naive to not consider it. For most of mankind documented history we've believed in things that today make no sense at all. Go even further from geo-centrism: in ancient Greece it was believed that Delphi was the center of the world. Were they dumb? Of course not, they just had different assumptions (or common sense told them differently).

Besides I can argue (with excellent points) that "believing" the earth not to be flat earlier would be highly beneficial for mankind. But I could also argue (again with valid points) that finding it out earlier would have made us dig holes instead of building boats to get to the other side of the planet. It's an hypothesis. I'm not agreeing or disagreeing, I'm just sharing it for consideration. Alas for you to get to the conclusion that the sun is 300.000 times bigger than the earth you needed countless centuries of developments in astronomy, mathematics (trigonometry), logic and so on. From my point of view my thumb is enough to hide it and the earth is immense. If I didn't knew better (or lived in another age) I could see myself believing the sun to be much smaller that the earth. What reasons would I have not to?

As I said before I see science as a tool not dogma. If I agree with a scientific theory, I'm agreeing with it's scientific merits not it's closeness to truth. That would just prevent me from ever considering other (equally or more valid) hypothesis.

As for the the links you've sent to explain the the CBD structure it seems to me you're referring to software architecture. There are many software that are designed that way to facilitate development (i.e. a well conceived library from a programming language). Others would be more difficult since doing that takes time which is something that in the programming world is usually not abundant. Nevertheless I'm not seeing how does that indicate (or points to) the current computer science assumptions to be flawed or in need of rectification or further documentation (even if they do...).

Dear Dr. Correia,

            Thank you for clarification. I want to clarify that, I believe, it is not very hard to identify multiple large “self-contained features/functionality” in any software product for building each large “self-contained features/functionality” as a RCC (Replaceable Component Class) for achieving CBD-structure, once the essential properties of physical functional components are discovered.

However it would take several days to even weeks to discover the essential properties that are uniquely and universally shared by each and every physical functional components and gain sufficient hands on expertise to positively identify each “self-contained features/functionality” that can be implemented as a RCC.

We would like to provide this kind physical evidence to whoever willing to gives us an opportunity, when our Tools/GUI-API are ready. I am hoping, this would give our team to closely work with engineers of willing evaluators for weeks not only to inject hands on expertise but also resulting in their application comprising multiple RCCs, where each RCC can rapidly adoptable to changing needs free from spaghetti code for years. I believe it could work, so I am taking a calculated risk to build Tools/GUI-API/Team. Objective of this question is, learn what kind of physical evidence could be more effective.

Best Regards,

Raju

"Objective of this question is, learn what kind of physical evidence could be more effective."

For a start typical benchmarking should do fine. Usually benchmarking is done for performance but I'm sure you can make some kind of measurement for development speed, code ergonomics, etc.

If you are in need of a possible experiment to test your hypothesis than you can create something like:

NOTE: the following test could be an experiment designed to perceive if some set of rules for programming can be beneficial in the medium to long term development.

########################################

a) In one of your links you have an example of a possible GIS software. Write a program that returns the areas given by:

- Theaters less than 1000 meters from an hotel.

- Those hotels must be less than 2000 meters from a tourist spot.

- Only return theaters within the previous conditions plus having no air traffic flying over it for at least the previous 5 hours.

The input of the software would be: time, city map, landmarks (hotels, theaters and tourist spots), and air traffic (which I assume to be time dependent).

b) Divide the number of your team members by half. Randomize which members belong to first half and last half.

c) Put the first half  (A) doing this individually using whatever means they find better. Put the second half (B) doing this individually using the rules stated by you. Benchmark against each other all solutions including for development time and performance.

d) Now using the solutions or re-doing a whole new program:

Write a program that gives you :

- the minimum accumulated distance between any combination of triplets - theater, hotel and tourist spot -

- only consider triplets that had no air traffic for the last 5 hours over the theater of the triplet.

The inputs are the same.

e) Benchmark again: performance, development time, code ergonomics.

From here you can keep doing tests. At some point (if the rules you've stated are in fact useful) the solutions that come out from the team B should start to have far less development time while maintaining the same performance. If you want your experiment to even better introduce at middle way new programmers to see how they react to both team B code and team A (control group) code.

#############################

But please consider that no matter the results of this experiment you won't really prove or disprove the assumptions of computation. But you may be able to propose a new way of conducting software development. Also the information you give your "players" should be all written down. So the rules you give to team B are going to be your method proposal.

Dr. Correia,

You misunderstood the point. The true purpose of real CBD is to eliminate the spaghetti code. The point is: Building and testing each component (i.e. self-contained feature/functionality) individually as an application. That is, implement all the code for each component in a set of files (i.e. exclusive files in a folder) and implement this application as class to assemble the application (i.e. component) as a subcomponent in another container component by writing about 3 lines.

That is, this component can be assembled by just instantiating an object instance, which requires no initialization and just one or two lines of configuration code, since class code for each component comprises all the application logic (e.g. accessing data and processing data), presentation logic and customization or configuration code to satisfy unique needs of a give/specific target application. Please kindly note, this kind of replaceable components is not reusable, because each is custom designed to satisfy unique needs of just one target application. For example, many core components such as 2014 Camry-engine is custom designed for just one product-model 2014 Camry model, so that it can be readily assembled in an assembly line and can be easily disassembled to replace by another new engine (in case of wear and tear).

This class can be refined and tested individually throughout the evolutionary life the product. That is, all the fun things you listed can be done to this class individually any time in the future. If in one attempt, if a new engineer made mistakes and doesn’t work as intended, you can always go back to previous stable code version to start over again. Alternatively, you can create 2 or 3 alternative models to show your customers to pick one, and so on.

The point is, today you can’t do all this kind of fun things (without touching and seeing even a single line implemented for other parts of container application), because no other GUI-API allows you to implement GUI-application (having a dozen large GUI-components) in a class and a set of exclusive files associated with the class. You can prove me wrong, by showing even a single replaceable class for any GUI application having a dozen large componets.

Each component is free from spaghetti code, throughout the evolutionary life of the product. Over 90% code implemented for the application can be free from spaghetti code, if over 90% of the application code is implemented as such replaceable component classes.

The real components offer many benefits such as increasing the degree of specialization, increasing the degree of division-of-labor and highly conducive for automation by using Tools such as the one illustrated in FIG-3: http://real-software-components.com/CBD/Sample_SoA_CASE_tool.html.

I already created countless such components and can demonstrate today, but many asked me, if I could implement their complex applications as hierarchy of replaceable components? They said, firsthand experience could increase their confidence, for example, if their engineers can do fun things like the once you listed (free from spaghetti code).

For example, today if they need to add a new component (e.g. City Ambulances), they are forced to add code sections in to the code base of the City_GIS application. That is, at least few code sections implemented for the City Ambulances are end up in some of the non-exclusive files of the City_GIS application.

But in our case, such components can be implemented as an individual application/class and can be tested individually. However, this component is custom designed to perfectly fit the target application such as its co-ordinate system and the coupling interfaces (just like the Camry engine is custom designed to perfectly fit and perform in a Camry). It requires just 3 lines to assemble (or disassemble) this object instance of this component-class and the above CASE-tool can take care of communication code.

This new component can be redesigned and tested individually (free from spaghetti code) any time in the future to satisfy evolving business needs (or to do fun things and experimentation such as the ones listed by you). If the experimentation doesn’t work, you can always restore original code and start over again. If this code spread over many non-exclusive files, it is hard to even finding the code to change and later restoring the original code.

            I hope, you understand the nature and purpose of True Component Based Design. The purpose of CBD is not reuse or standardization (as popular misconception) but evolve each component individually free from spaghetti code. The second step in the CBD-process is not applicable to the software products: http://real-software-components.com/CBD/CBD-process.html.

            My goal is just eliminate the spaghetti code to do fun things or to make the software engineering a fun task – one component at a time. I believe, eliminating spaghetti code allows us to build many times more complex applications than practical today. For example, any team could plug-in thousands of components in to the CAS-tool and the CASE-tool can assist in adjusting the coupling interfaces to allow collaboration between the replaceable components. See FIG-4 and FIG-5 in: http://real-software-components.com/CBD/Sample_SoA_CASE_tool.html

Best Regards,

Raju

Dear Dr. Page,

            You want a revolution? I believe, the same mistake is repeated in case of neural networks for artificial intelligence. There is no documentation for few assumptions (i.e. first principles) that lead to the definitions, nature and descriptions for neurons.

            It is impossible to invent true CBSD by relying on exiting descriptions for so called software component (i.e. building blocks for the CBSD), where the exiting descriptions have no basis in reality.

            Likewise, it is impossible to invent true artificial intelligence by relying on exiting incomplete or even flawed definitions for the building blocks (i.e. neuron). If the descriptions are flawed, future generations can’t expose flaws to put the artificial intelligence on right tracks (based on reality) to advance on right path.

Any error in the first priceless sidetracks scientific progress in to a wrong path and no meaningful progress is possible (if it ends up in a wrong path), even mankind invest a trillion dollars (or waste another 50 years in case of CBSD or wasted another 1000 years in case of geocentric paradigm).

I don’t think, I am capable of solving problems of artificial intelligence or the Church-Turing Thesis. I feel, it is unfair to say that I can’t pursue an area that fascinated me and talk about my findings, I believe to be true. You are free to expose errors in my findings, if there are any errors in my findings. I believe, I can provide physical evidence to back my findings, if you give me an opportunity.

Dr. Page, let me rant my thoughts on Church-Turing Thesis. Since it is not solved for 75 years, I believe, there could be two reasons (i) there is no solution this problem or (ii) along the way (during past 50 years), researchers might have relied on undocumented assumptions that led the research in wrong path, so you are looking in wrong place.

            If the 2nd is true, the assumptions are unknown, so best hope is some one like me who is clueless about the well traveled path and lost his way and accidentally end up in discovering the undocumented assumption. Experts like you are extremely familiar with well traveled path, so unlikely to lose path. Even if you lost path, you could quickly recognize and return to the familiar well traveled path. Only outsiders and clueless people could lose well traveled path and out of thousands losing path, one may end up in right spot by chance (it is not by design). Also he might need to apply sound reasoning, if he is close to the right spot, to find and to build confidence that he might be in right spot.

Even if hundreds end up in right spot, only one might be fascinated and have time to persist for decades and have thick skin to endure insults and humiliation to expose the error. I hope, you would be more patient and open minded to give him a chance, if any one says that he has been working for over a decade and posts all his finds openly in a website for any one to find a flaw. I feel, he deserves few hours of your valuable time, if he invests 15 years of life on solving Church-Turing Thesis (even if his concepts contradict deeply entrenched epicycles).

Today there are about 10 million software engineers, many of them are clueless (while learning on their own) and could potentially lose way and end up in uncharted territory. But chances are far less for artificial intelligence and Church-Turing Thesis because, at most few thousand researchers are working, and they are far more complex than physical components. So must be clueless to lose way and many times intelligent to solve such complex problems – otherwise, even if someone stumbles onto it, it is like a diamond in the hands of a monkey – he just can’t recognize the value and throws away.

Best Regards,

Raju

Raju,

Unless I'm missing the point what you propose is already common methodology today. I've built software using different specific libraries that do pretty much what you've said. For example:

1) I have a file utilities library

2) I have a geometric operations library

3) I have an interpolation and estimation library

To attach all of the above together I have:

4) Objects library

, which has the classes that all other libraries can read and manipulate either transforming or outputting objects within the "Objects library".

If I were to build your hypothetical GIS software I wouldn't need to change the base code to put "City Ambulances" in the final product, I would just need to build the specific code of "City Ambulances" in accordance with the objects my software understands (let's say shapes, grids, lines, points, etc.). I would only need to do strong re-development if I were to build a whole new class of objects, but these are the kind of considerations you need to make in the design/architecture step of software development.

In terms of "physical evidence" for your proposal I must remain with my prior suggestion. If you want something considered by your peers the best way to do it is designing an experiment, analyzing the results, and than share them. Evidently that designing an experiment implies a lot more that I think it would be particularly helpful in this debate. One such example is that it would force you to state your proposal into workable (and thus debatable) guide points such as (this is an example):

a) No function can have more than one output argument.

b) Every function should be workable without the need of a GUI (thus an API).

c) etc.

Nevertheless I wish you the best of luck in your endeavors.

@Raju: You said:

"Dr. Page, let me rant my thoughts on Church-Turing Thesis. Since it is not solved for 75 years, I believe, there could be two reasons (i) there is no solution this problem or (ii) along the way (during past 50 years), researchers might have relied on undocumented assumptions that led the research in wrong path, so you are looking in wrong place."

First, the Church-Turing Thesis isn't a problem, it's a statement that is testable.  If Science found a conflict with it, the evidence would come, but it hasn't (at least yet) in all our attempts!  It's a widely accepted empirical statement (since it isn't one that can be mathematically proven (as far as we know as it isn't really a mathematical statement)).  Every turn in new paradigms whether it be parallel computing, even DNA computing or quantum computing thus far, we have yet to see any kind of conflict appear yet with it!  Based on what you said, I'm unsure if you understand what the Church-Turing thesis is.  Understandably so, based on our previous chats about this on here, it at least seems (I could be wrong) like you aren't attacking concepts in Computer Science itself (which would be more valuable).  

Dear Dr. Correia,

I believe, you misunderstood my definition for true CBD. Alternatively, I could be wrong, if you are saying that, you can implement any small GUI application as a Class, where the small application comprises (i) application logic to get raw data from data sources and iterate over the raw data for extracting data summaries and (ii) presentation logic to use the data summaries and reusable GUI components to present at least a dozen large GUI components.

In case of City Ambulances, each Ambulance contains code to get latest location to update its location on the map every few seconds. Also when clicked on the Ambulance, it should get several pieces of status information such as speed, condition of patient, Blood pressure and Hart beat etc.

If an application has 6 (or even 100) such components, it must not require more than 3 to 5 lines to assemble each of the components. This last condition is an absolutely essential condition for a true Component Based Design. I believe, no other GUI-library (e.g. Windows/VB or Java/Swing) is capable of implementing such GUI class (that can encapsulate a large data driven application).

In the case of real CBD, each component can be refined and tested individually as one can test an individual application. Each component/application can be assembled by implementing just 3 lines and disassembled by removing the 3 lines. No additional communication code is needed, because they contain code to use the CASE-tool for registering their action/service functions and to get needed services.

If you are already doing all this, I have to admit that I am wrong. That is, if an application has 25 such components, the application must not require more than 25*4 (100) lines of code to assemble all the components, once each of the component class is built and tested individually. I was under the impression that, no other GUI library (e.g. Windows/VC++ or Java/Swing) is designed to implement large applications (e.g. MS-word, MS-Excel) as a replaceable class, so that it can be assembled as subcomponent in another application to build large component hierarchy in a single executable.

Objective of true CBSD, is to build each large custom GUI application as an assembly of custom classes, where each custom class (i.e. RCC) is designed and tested individually as an application. In other words, 97% of the custom application code must be implemented in such custom RCCs. None of the RCCs are reusable, but custom designed to a given target application, so that No RCC must require more than 3 to 5 lines to assemble into the target application.

Best Regards,

Raju

Dear Dr. Page,

            You are right about my knowledge on Church-Turing Thesis. My interest on neurons is also more of a curiosity. Being a software engineer, my personal belief decades ago was, there are two of the greatest challenges eluding the researchers for decades (i) True artificial intelligence (e.g. even super computers can’t navigate or maneuver a flight as skillfully as a small fly of size 1-quibic millimeter. Imagine its brine size, if the fly is smaller than 1-quibic millimeter).and (ii) true component based design for software products, which was defined in various ways such as: http://www.atp.nist.gov/focus/cbs.htm

            I am sure most of the computer scientists, software engineers or professionals were fascinated with true artificial intelligence. When I was working in Silicon Valley, this was the frequent hall-way and lunch time discussion topic during late 1980s and early 1990s. Also I had couple of great teachers at Ohio University, who encouraged me to explore further by giving books from their private collections. It was more fascinating to me, may be because I was born and raised in a remote village in India and never seen amazing things like computers. This fascination helped me secure 4.0/4.0 GPA.

            The second most discussed topic was “software components” and “component based software engineering” as Object Oriented Programming is proliferating into Silicon Valley companies during early 1990s. I started learning and using C++ in 1993. I was a ‘C’ programmer. I could not master OOP because my mental model and blurry intuition or imagination was in conflict with what is being thought in the class for Object Oriented Analysis. I had to struggle a lot to align my blurred intuitive model with what is being taught. So I was not a good OOP developer, except using objects with my superficial understanding. I got ‘A’ grade in my UC-Santa Cruse night classes, by memorizing object oriented concepts (but not by comprehending in-depth to form a solid mental model to apply concepts a skillful expert could do to solve engineering problems).

            However, in 1998 I wanted to create a java GUI-API for building data driven rich internet applications. I had full time job and I was doing this part time. By late 1999 and 2000 we were able to create replaceable component classes and assemble them to build large component hierarchies, where no component needed more than 3 lines to assemble. This was purely a coincidence, not by design. I was not familiar with web-programming and I lost my way due to my intension to catch-up in hurry (not by taking classes but by following my intuition and searching on web for answers).

This ability to assemble components for creating complex hierarchies aliened more with my blurred intuitive model. It induced an irresistible curiosity to reduce my work to part time job until 2003. After making some progress, I felt it requires intense focus, so decided to focus nearly full time on this problem that fascinated me since mid 1980s.

Dr. Page, last year discussions helped me to improve my understanding and I hope, I would get better in providing sound proof one day. So let me thank you. I greatly appreciate any constructive suggestions and guidance. Past few months gave me fascinating insights into philosophy of science. I hope, my intuitive model of philosophy of science is right, because for me it seems to align with the views of Sir Karl Popper. I don’t have a Ph.D and my English is poor, so I can’t articulate my ideas as effectively as some one having a Ph.D.

Best Regards,

Raju

Dear Friends,

Best way to create right environment for intelligent people is not teach any thing but give some set of clues and problems, and hope they could end up finding right path.

If I were in such position, I would pick smart students and ask each of them, individually go and figure out how components (or neurons) work for achieving real CBD (or intuition). This requires them to investigate what is real CBD and how physical components can achieve such real CBD? For example, they could learn a lot by observing design of a new product such as artificial kidney at: http://real-software-components.com/CBD/CBD_of_new_product.html. Every year many such products are invented or/and in various stages of development - Over 97% of features is implemented as custom designed replaceable components (each is built and tested individually), so making 97% of the design and development free from spaghetti code.

Both teachers and books teaching definitions of so called software components/CBSE to impressionable students and insisting the students to learn definitions either to pass the exams or solve problems using the definitions. We are pushing the impressionable students to well traveled path, without having proof, if it is right path or wrong path.

Instead of teaching them, we need to force impressionable students to investigate truth. Please kindly read this interesting article, how reality can be distorted: https://www.psychologytoday.com/blog/pieces-mind/201208/few-the-many-ways-we-distort-reality. One can find so many examples that show, how reality can be distorted.

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

Best Regards,

Raju

Hi,We are dealing with a conflict between discursive reason, in opposition to intuitive reason. Intuition, a phenomenon of the mind, describes the ability to acquire knowledge without inference or the use of reason whereas reason is the capacity for consciously making sense of things, applying logic, establishing and verifying facts. Reason is dynamic as facts changes remember the ultimate truth is a lie.

Dear Dr. Hale,

            I believe, intuition is one of the ways scientist make up theories or choose paths to explore. Assumptions are also our intuitions. Also intuitions are the way we (e.g. our minds) fill the gaps in an incomplete picture.

            Of course, all these must be validated and proved beyond any doubt to be accepted as a scientific fact. Sir Karl Popper suggested empirical falsification. Popper is known for his rejection of the classical inductivist views on the scientific method, in favour of empirical falsification: A theory in the empirical sciences can never be proven, but it can be falsified, meaning that it can and should be scrutinised by decisive experiments

            What I meant in my previous email is, it would be easy to grasp any new subject, if it is close to our intuitive mental model. It would be very hard to grasp and apply the knowledge to solve problems, if it is in conflict with our intuitive mental model. When we are reading fist chapter of a book for introducing any scientific discipline, it introduces first principles.

            The first principles are used to support each of the concepts in the subsequent chapters and explain observations. While using internet, computers and airplanes, we can’t deny mankind’s scientific progress, although our knowledge may have large holes (e.g. definitions for so called software components). It is uneven progress. We made lot of progress in hardware and fibre optic networks, while software engineering is bogged down in software crisis (i.e. big ball of mud: http://www.laputan.org/mud/).

Best Regards,

Raju

Dear Friends,

            We at pioneer-soft.com created first GUI Library in the world that is capable of creating real software components that are capable of achieving real CBD for software.

            For example, please select “Real CBSD” under “DEMO” in the top menu bar. Then select “Assembling Replaceable Components for Multiple Cities” on the left side vertical list of URLs.

            Any large GUI application can be implemented as a Java class. For example, the TAB-component displaying ATC and Ambulances for multiple cities can be implemented as Java class. This GUI application can be assembled as a sub-component by writing just 2 to 3 lines using the Java class.  This GUI-Application/subcomponent can be effectively removed by removing these 2 to 3 lines.

Today no other GUI library is capable of encapsulating even City_ATC in a Java class. So it requires including many lines of spaghetti code into the code of the GUI application to include the City_ATC.

I believe, if software developers start creating real software components (also referred to as replaceable components) for achieving real CBD for software, it gives them hands on experience and insights on the innate nature and essential properties of physical functional components that are capable of achieving real CBD for physical products.

This knowledge and expertise gained in GUI applications help software designers to positively identify features and functionality in non-GUI applications (e.g. compilers or RDBMS) that can be implemented as replaceable components for achieving real CBD for software.

I believe, this is the physical evidence for real CBD for software. Let me define the CBD for the physical products: Implementing about 90% of the features and functionality in replaceable components. Each component can be refined individually and tested outside of the physical product free from spaghetti code. That is, designer of no component need to see internal code of any other component, when redesigning or re-factoring. Over 90% of the code is free from spaghetti code, because 90% of the code is implemented in such replaceable components (where each component is free from spaghetti code).

Neither complexity nor uniqueness of a physical product (e.g. an experimental spacecraft or prototype of Jet-fighter) prevents designers from implementing about 90% of features and functionality in replaceable components for achieving real CBD (i.e. hierarchy of replaceable components). But it is not necessary that even a single replaceable component in the hierarchy need to be reusable, standardized or conforming to so called component model (erroneously attributed to the software components).

Design of no physical product suffers with spaghetti code/design, but why software products must endure spaghetti code. If developer-A creates City_ATC and developer creates City_Ambulances for a City_GIS application, why the developers are forced to merge the code to create spaghetti code. After this point, to test City_ATC one must compile whole application and test whole application.

The code of the application having just two components and each of the components City_ATC and City_ Ambulances begins their lives as spaghetti code. Imagine the complexity and spaghetti code, if this application has 100 such large components (that can be designed as replaceable components).

This version of our GUI library is free, so any one can download and build applications to experience the real software components.

Best Regards,

Raju Chiluvuri

Hi,

“What kind of physical evidence is necessary & how can I provide the physical evidence to expose flawed 1st principles at the root of computer science?” In my opinion it’s, it’s objective. As a Douglas McIlroy's development before the age of windows and OSX it was based of centralism which companies with the “cloud” concept try to return too for commercial interest.

Dear Dr. Hale,

            Thank you. Nature and reality never changes. Reality and facts or truths about nature are objective. But our perception of reality changed many times. Mankind believed that the Earth is flat. Later mankind believed the Earth is static at center. Later we learned that the Sun is at the center of our planetary system.

Any true scientific concept or discovery must satisfy two conditions (1) it must not contradict the reality we know in the real world and (2) it can’t be falsified, while being highly falsifiable.

            It is not hard to observe the reality of CBD of physical products: The reality is implementing 90% of the features and functionality in replaceable components, especially true for one-of-a-kind physical products such as experimental spacecraft or prototype of next generation Jet-fighters.

The automobile engineer just deal with many product models within just one product family. Likewise, hardware engineer deals with many kinds of product models in just on product family. In software, we deal with hundreds of product families ranging from compilers, OS, Video games to MS-Office.

So often software designing is like creating a new product. Mankind designing hundreds newly invented products, both physical products and software products. For example, see the reality of designing a newly invented product: http://real-software-components.com/CBD/CBD_of_new_product.html

The reality is, almost no physical product is created by assembling off-the-shelf reusable components. Only exception to this rule is computers and cell-phones. It is possible because, the product makers can use software (and not the core components such as CPU, Screen or DRAM) for competitive differentiation.

For example, the makers or cars, jet-fighters or other products custom design core components for competitive differentiation. For example, when they are relying of third party component vendor for a component, they work closely with the component vendor to custom design the part. For example, Boeing works closely with Rolls Royce or Pratt and Whitney to build custom engine. Likewise, Honda company works closely with makers of break-pads to custom build the break-pads. One can observe this kind of reality about CBD everywhere.

When Douglas McIlroy proposed building products by assembling COTS (Commercially off the Shelf) parts, it is just a proposal – a desire or wishful thinking. Then Dr. Brad Cox proposed software-ICs. It is nice to have, but is it possible or reality? So does inventing cold fusion is nice, but can we discover laws of nature that can make it reality? I don’t know about the cold fusion, but I am sure that software-ICs as intended can never be a reality.

I am sure, it is possible to achieve the goal of implementing 90% of the features and functionality in replaceable components for any software application. Also I believe, this reality will be more useful than software-ICs.

Best Regards,

Raju