Dear Friends,
I believe, it is extremely valuable to create a list of mistakes (researchers did in the past) that must be avoided (or must not be repeated) at any cost by the researchers of any scientific or engineering discipline. I feel young researchers and scientist must be educated about such mistakes by using the past mistakes as example to illustrate subtle symptoms and causes that lead to the mistakes.
Biggest mistakes cause huge wastage. This kind of knowledge & insights help spot early and/or avoid each such mistake (much sooner rather than much later or even after it is too late). Also, it would become much easier to spot such hidden or undetected mistake and easier to expose the mistake, if such mistake is already committed and/or exists in any scientific or engineering discipline.
Let me start with the biggest mistake that the 17th century founding fathers of modern scientific discipline wanted to avoid this kind of mistake at any cost: The researchers of basic sciences committed a mistake more than 2000 years ago by believing that: “the Earth is static” is a self-evident fact (i.e. they insisted that the belief needs neither proof nor documenting it as an assumption). The biggest mistake any scientific or engineering discipline must never commit (or must be avoided at any cost) is: Relying on undocumented and unproven beliefs (or assumptions) by insisting that the beliefs are self-evident facts (so needs neither proof nor mentioning that the belief is an assumption).
Research community of no scientific or engineering discipline want to waste decades of their hard work on perfecting epicycles of geocentric paradigm of their discipline. I have been trying to find, if any other scientific or engineering discipline committed this kind of mistake since the 17th century scientific revolution. I could not find any such example. I am sure it would be widely debated (subtle reasons for such error to go undetected for decades), if and when such error was exposed. It must not be hard to find crisis resulting due to such error and especially scientific or engineering revolution that follows soon after exposing such error.
The researchers of software committed this kind of mistake more than 45 years ago. Today software engineering is in crisis, because exiting software engineering paradigm has been evolving by relying on the flawed beliefs (and even today researchers insisting that the beliefs are self-evident facts). Many experts feel that it is a heresy (e.g. offending the common sense or deeply entrenched conventional wisdom) to request proof for so called self-evident facts. Questioning the validity of the beliefs is perceived as arrogant and disrespectful.
I feel it is extremely valuable to educate young researchers and scientist about such potential mistakes in pragmatic perspective and right context (i.e. what are the circumstances and conditions even a widely used process could end up a mistake). For example, relying of beliefs (or assumptions) is essential part of exploration of scientific or engineering frontiers to expand the Body of Knowledge. It is not wrong to rely on beliefs (or assumptions), but it is wrong to (i) not documenting by clearly disclosing that the beliefs are only assumptions (i.e. not yet facts) or (ii) insisting that the beliefs are self-evident facts, without providing falsifiable proof backed by demonstrable evidence.
The 17th century founding fathers of modern scientific discipline had to endure huge pain and suffering to expose the mistake. If the subtle causes, symptoms and consequences are well documented and understood, this kind of pain and suffering could be minimized or even avoided. Even today it is nearly impossible to expose such mistake, if such mistakes are exist at the root (or core) of a modern scientific or engineering discipline and already detected.
I wanted to collect a list of other such mistakes, which are illustrated by examples to help gain insights into subtle causes and symptom (e.g. to avoid and to help detect and expose such mistake, if such mistakes is already committed). Attached PDF illustrates one mistake and symptoms by using examples. In light of such clear understanding and insights, no one could argue that it is OK to rely on such belief. There are no exceptions. Many experts blindly insist that their field is an exception to the rule, without giving any valid proof. They justify each belief by using more unproven beliefs (by insisting each is a self-evident fact). In hard sciences, there are no self-evident facts. Nothing can be a fact, until it is proven by a falsifiable proof and only if the proof can’t be falsified.
P.S: Attached file DescriptionOfBiggestMistake.pdf describes a biggest mistake and PDF file ExampleForBiggestMistake.pdf illustrates symptoms and causes for this kind of mistake by using an example.
Best Regards,
Raju
Thesis Description & summary of one of the biggest mistakes researc...
Dr. Peter,
You are back with your trademark sarcasm. Thank you for the information. I will book my ticket to visit the USA (no later than 10 days) and try to sneak into Mt Rushmore to see the list.
Mankind observed retrograde motions and epicycles for thousand years. Are they facts? What you observe is your perception based on and shaped by your underlying assumption.
Let’s assume you are right. Where did software researchers observed that: Any kind of physical parts either having certain given properties (e.g. reusable or standardized) or conforming to a so called component model is a kind of components? Where did software researchers observed that: Using such fake components is CBD (Component Based Design)? Is it the true essence of CBD of physical products?
Dr. Peter, if you have patience to read the attached paper, you would know what is a fact in the abstract: Anything can be a fact, if and only if, it is proven by using demonstrable, repeatable and falsifiable proof backed by sound evidence and it is impossible to falsify the proof and evidence. Nothing else must be treated or considered as fact, for example to rely on it to expand the BoK (Body of Knowledge). Everything else must be treated and clearly documented as an assumption, that must be validated (if and when it is possible to validate).
Dr. Peter, thousands of ‘observations’ can be falsified. Your eyes and senses can be deceived or influenced by your altered perception. That is the reason, each fact must be supported by a documented proof, so that the published proof can be validated at any time by any one and falsified any time in the future. The facts are the pillars of our mansion of knowledge. You don’t want the pillars to be week (and retain their strength as long as you live in the house), if you want to add the weight of each new floor (i.e. new knowledge – it is essential for progress).
The biggest mistake is: Relying on any belief by concluding that it is a self-evident fact. That belief likely not mentioned or documented either as a fact or assumption. If it is a fact, it must be backed by a proof. If it is an assumption, the documenting informs other researchers that it is an assumption, so their effort could be wasted, if it is flawed.
Best Regards,
Raju Chiluvuri
Ok, then "The biggest kind of mistake is: Relying on any belief by concluding that it is a self-evident fact. "
The belief that “the earth is static” is one example, because this belief is not documented nor proven, but concluded that it is a self-evident fact.
The belief that “reusable software parts are software components” is another example for this kind of mistake.
Dr. Peter, my vocabulary is limited. I can’t understand three terms in this sentence “dungbeetles are parsiform ungulates.” Also I can’t understand what you mean by last paragraph. I am not trying to be difficult. I usually try my best to understand.
My goal is not writing paper and publish them (to expand resume). My goal is exposing this kind of error in software. I am exploring every possible way including writing articles and putting them publicly (e.g. in my ResearchGate account and web site real-software-components.com).
Objective of this question is to build awareness (i) to prevent this kind of mistake in other disciplines or (ii) make it simpler to expose this kind of mistake, if it is already committed. Since software has this kind of mistakes, we can’t rule out possibility of this kind of mistakes in other disciplines.
Regards,
Raju
Dr. Peter,
I searched for parsiform, but could not find its meaning. Now I searched for parsiform.com and no website is there. Likewise, dungbeetle also not a word in goole search. It is two words.
Please don’t use complex logic. I am not that smart. I am dealing with primitive computer science (software) that is stuck in the pre-Newtonian era. Things were much more clear, simple and straight forward. Most of it is black or white. Things got wired and complex later with things like quantum mechanics or theory relativity etc.
Bye,
Raju
Dr. Peter,
It is wrong to define “reusable software parts are components”. Many kinds of software parts are defined as software components, without any basic in reality. For example, if the essential properties of physical components are “replaceable” and “self-contained”, then replaceable self-contained parts are components (even if it is not reusable). That is, no part can be a component, if it is not “replaceable” and “self-contained” (even if it is reusable).
We need to accumulate BoK (Body of Knowledge) for computer science using science as a tool about the reality and facts of components and CBD (Component Based Design). Computer Science is a BoK for software. Many other scientific disciplines have been using multiple tools for acquiring BoK (please see attachment). Mathematics is just one tool for gaining knowledge, but not the only tool.
Mathematics can provide certain kind of knowledge or perspective, but can’t provide certain other kinds of knowledge or perspective. For addressing certain problems, we need more than one kind of knowledge and perspectives. That is the reason other scientific or even engineering disciplines are using multiple tools.
P.S: If you have time Google for "What is Science". One describes science as a tool to gain knowledge. Another two describes science as a body of knowledge for a particular discipline. Both are right depending on the context. Computer science is a body of knowledge for software. Computer science can and must use scientific processes as a tool for gaining necessary knowledge.
Regards,
Raju
Dr. Peter,
You are going completely wrong. The purpose of research is pursuit of absolute truth. It doesn’t necessarily mean discovering absolute Truth, but also includes getting closer and closer to absolute Truth. As a scientist or researcher, it is your sacred duty. If Science is a religion, the absolute Truths are the manifestations of the God.
It is a forum to present and discuss our perceptions of facts (that are closer to the absolute Truths). If you think, my perception is less close to Truth, you propose your closer perception of facts. No one owns the God or the absolute Truths.
Other people proposed gravity even before Newton, but Newton find better proof or reasoning using Mathematics in general and calculus in particular.
You know the general gist of my perceptions. If you think, they are absolutely wrong, don’t waste your time here. If you think, they are in the right direction, but off by certain degree, it is your duty (as a scientist) to find and propose better facts. Many people (e.g. Copernicus, Kepler, Galileo and Newton to name a few) got credit for Heliocentric model.
If I am right that Science can be used as a tool for software, I am sure many people would make significant lasting contributions. Why don’t you pursue your own path, if you thing I might be right (else don’t waste your time)? It is your sacred duty to pursue the absolute Truth (i.e. whatever you honestly feel is absolute Truth).
Dr. Peter, I can only present my perception of facts, which is sapped by experiences and influenced by failures on the way and adversities I need to overcome. For example, Kepler and Galileo generally agreed that “the Sun is at the centre”, but then they have pursued their own paths. Kepler and Galileo didn’t agree with each other on certain things. For example, Galileo believed that the orbits are circular and not elliptical, but Galileo also made other lasting contributions such as Galileo moons.
Regards,
Raju
Dr. Peter,
Just read few paragraphs in the attached Gist for two errors in software. If you think, they might be right – just pursue the Truth. If you think they are wrong, no point in vesting time on simple things.
Regards,
Bye
Dr. Peter,
I defined many times what is real software component: To invent real software components, one must discover essential properties uniquely and universally shared by each and every known physical functional component (by employing scientific process).
In other words, if the essential properties are {X, Y}, any physical part can be a physical component if and only if the part has the essential properties {X, Y}.
Any software part having the essential properties {X, Y} is a real-software-component. Any software part not having essential properties {X, Y} can’t be a real-software-component.
P.S: You can’t understand Heliocentric model in the context of epicycles and retrograde motions of geocentric model.
This must be the scientific definition for computer science (to gain knowledge, insights or wisdom). But I use slightly broader definition, for software engineering – Any kind of parts that can achieve real CBD for software, because my engineering research goal is achieving real CBD, where real CBD is Implementing about 90% of the code of any application in replaceable components.
P.S: Please see the attached Gist
Regards,
Raju
Dr. Peter,
Please try to discover the essential properties of the physical functional components. This is the knowledge foundations.
If the essential properties of the physical functional components are {X, Y}, any physical part, not having the essential properties {X, Y}, cannot be a component.
Likewise, my contention is that any software part, not having the essential properties {X, Y}, cannot be a component.
Then the following is the engineering research.
You need to look this discussion in the context and perspective of what I want to accomplish. I want to eliminate spaghetti code, since design and development of no other product is effected by spaghetti design/code.
I wanted to invent new kind of software components to achieve real CBSD, which is to implement 90% of the code for any application in replaceable components.
Dr. Peter, the above describes my subjective thoughts and processes. I don’t want to impose them on any one. My intention is, expose the errors and encourage others to discover answers on their own. They may come up with much better knowledge foundation, which can support much better inventions.
Dr. Peter, it is not impossible to discover essential properties of physical functional components. But it would take several weeks of hard work. It is not as hard as discovering essential properties of many things like light, virus, bacteria or many kinds of cells in bodies of living things – Each required years of hard work. Discover essential properties of physical functional components are not that hard, but it can’t be discovered in couple of days.
You said: So you need to define "reusable software part".
Why should I? I am not trying to increase reusability. I am not disagreeing with existing paradigm for other kinds of parts. Only thing I am saying is, it is wrong to define “reusable parts” are components, since most components are not reusable. Defining many kinds of parts as components gives false impression that components are already invented.
Let me quote from paper: Science, Mathematics, Computer Science, Software Engineering By Dick Hamlet
Does it matter whether CS is called science or mathematics? Shakespeare is often quoted to support the irrelevance of names: ‘. . . that which we call a rose// By any other name would smell as sweet . . .’. Juliet did not want Romeo’s name to matter, but in the end their surnames killed them. Names matter because they color everything around them. So long as CS is seen as a science, its theories and methods will be evaluated using inappropriate standards. Important research directions will appear to be closed, while others without substance appear to be promising. Acknowledging what CS and SE really do is a first step in doing it better.
Likewise, knowing what is a component and what is not a component do matter. Otherwise the terms color everything around them with wrong brush.
Regards,
Raju
Dr. Peter,
There could be many kinds of useful software parts. But none of them can be software components, if they are not “replaceable” and “self-contained”. Since there are no terminology is available to describe the essential properties, I picked terms that are close to my understanding of the property.
If you want to understand the properties, you need to see examples and analyze them in the light of nature of physical functional components. For examples, such as: http://real-software-components.com/CBD/City_GIS.html
The purpose of each replaceable component is to implement few thousand lines of custom code in a RCC (Replaceable Component Class), so that it can be refined and tested individually (free from spaghetti code).
If the B-tree is custom designed for a specific application and it can be effectively replaced (or removed) by replacing (or deleting) about three lines, then it is a real software component (in one context or perspective). No reusable part that requires more than 10 lines to initialize and integrate is can be a replaceable component, because it needs changing the 10 lines to remove the component.
Dr. Peter, you putting me in a awkward position of giving statements (saying Yes or No) that are not entirely accurate, in the light of the CBD of physical products. When you discover real CBSD, you see my statements are kind of general with many exception based on context. For example, those statements might not be accurate in the context of product line engineering.
For example, if I am using City_Map from Google or Bing, by writing 100 lines, I implement a RCC wrapper that encapsulated the 100 lines to make City_Map replaceable. I only implemented 100 lines and I can or need to maintain or redesign the 100 lines. Of course, I could change underlying map (from another vender) but can’t redesign it (except configure it as allowed by the interfaces provided by the vendor). This is how I partition my application. But it is up to the designers, if he thinks some thing else is better.
Regards,
Raju
Dr. Peter,
If you observe the designers of physical products, you would notice that some of them are abscessed with “service access” to certain components, which requires frequent maintenance or replacement (e.g. oil filter, battery or break pads).
In software almost every component needs to be changed frequently so needs best practicable “service access”. As a company pioneer-soft we have to be pragmatic, so I don’t want to make any assumptions.
So we decided to provide missing tools and capabilities for making it simpler to achieve real CBSD. For example, today no GUI technology is capable of creating replaceable components. Also we found reusable tools such as this kind of SRO (Service Registration Object) are valuable: http://www.real-software-components.com/CBD/Sample_SoA_CASE_tool.html
It is possible to create many variations to this can be implemented. For example, in a form each form element registers its validation function with the predefined global FMO, which calls the validation function when user selects submit. Also each form element sends name & value pair to the FMO (Form Management Object). This code is implemented with-in the code of Replaceable Component Class, so no additional code need to be implemented out-side the replaceable component object. This is an example for this context. It is a generic Object that can be used for any kind of form, which can be useful to make the components replaceable.
It is a skill and art to partition any product into components, which requires experience and deep domain knowledge. They have to make so many small decisions and compromises or trade-offs. All I want is remove the road blocks such as not able to build replaceable components for GUI applications.
I have to where two hats (1) as a researcher of computer science to gain theoretical knowledge and (2) as a researcher of software engineering to pragmatically leverage the knowledge to create useful things. I am not doing either of them very well. There are so many things that are beyond what average person can do.
For example, you find many things that can be done better as soon as users start using any product. Many things are changing. Technologies are changing. Business needs are evolving and often unpredictable. So I feel my first duty is removing the existing road blocks for real CBD rather than building new roads.
Regards,
Raju
Dr. Peter,
You said:
You do need to state what the intended abstraction is, providing examples of what does and does not satisfy, and why and why not. That's your job, not the rest of the world's!
I agree. That is the reason I started this company and built GUI library and other tools. I am looking for customers, to work with their engineers in building their web applications (e.g. Big data or IoT control Panels). When we are working together, they can start experiencing to gain hands on experience. The GUI applications are much simpler than non-GUI-applications. So I wanted to start with GUI applications.
But I feel software researchers are obligated to fix the huge structural mistakes in the Body of Knowledge of computer science and software. Isn’t wrong to teach the geocentric paradox of software to young researchers, when credible evidence is provided (by ignoring the evidence)? Doing nothing to prevent young researchers from wasting their hard work and efforts on the geocentric paradox of software, by ignoring clear evidence, is also wrong.
Regards,
Raju
Dr. Peter,
Reuse is three kinds (1) black box reuse – reusing 3rd party libraries or 'reusable components' (2) white box reuse – changing existing component by 2% to 15% (e.g. code reuse) and (3) knowledge reuse – Reusing code as well as expertise gained in solving a particular class of problems.
The replaceable components are custom designed for a given target application, so they are unlikely to be readily reusable (black box reusable). But they substantially increase 2nd and 3rd kind of reuse.
For example, look at the sample application: http://www.real-software-components.com/CBD/City_GIS.html. Today code base for each of the replaceable component class (or RCC) spread across many non exclusive files. So it is nearly impossible (or impractical) to reuse, if another application needs identical component with 15% feature redesign.
If you design engine for Camry, you can use the knowledge and the blue prints for designing smaller engine for Corolla (where blue prints are analogues to code). The RCC is another dimension of flexibility.
For example, to build each of the RCC for City_ATC, I would use every possible reusable ‘component’ to minimize the custom code. Only thing I am doing is, implementing the code base in a RCC (to eliminate spaghetti code).
Ever after using every possible technology and reusable libraries, still many applications have no choice but to implement 100s of thousands of lines of custom code. The purpose of CBD is to implement this minimized and unavoidable custom code in RCCs. So CBD is not in conflict with anything else, but a complementary addition. CBD doesn’t even reduce reuse even by 0.5%.
If you discover the intended meaning for “self-contained” you can positively identify what are the features and functionality in any application that can be implemented in each of the RCCs. One the features and functionality is identified that can be implemented in a RCC, you may use every available technology to minimize the code (by maximizing the reuse).
Regards,
Raju
Dear Dr. Peter,
I heard cohesive so many times about, but that is not reflecting my understanding of the components. I feel, if you discovered the nature of physical functional components, you would agree “self-contained” is the better choice. I spent many months for right term. I asked many smart people including my kids, what are the best terms to describe the physical components. They are smart and now working in the USA.
But I have struggled between “replaceable components” and “separable components” to indicate functional modules that can be un-plugged and re-plugged. Another term could be loosely coupled self-contained components. Loosely coupled is also good, but it used in other contexts and start paining different picture. Finally I settled with RC (“replaceable components”) because my initials are RC (Raju Chiluvuri). :-)
The spaghetti code (and software crisis) would be a thing of past, if few experts discover the nature and essential properties of physical functional components (particularly the intended meaning of “self-contained”). So I have been struggling to find concise description, but I could not. That is the reason I often use this quote of Galileo: “You cannot teach a man anything; you can only help him discover it in himself.”
Regards,
Raju
Dr. Peter,
Why don’t you try to describe distinct recognizable properties of large ideal physical functional components? The objective is to use this knowledge to positively identify features and functionality that can be designed as a replaceable component.
There will be no spaghetti code and software crisis, if few experts can discover such description. It is not impossible, but not a trivial task.
Let me define, ideal CBD for physical products: Implementing over 95% of the features and functionality (e.g. code) in optimal size replaceable components.
Regards,
Raju
Dr. Peter,
That is the reason I said, if the essential properties are {X, Y}, then no part can be a component without having the essential properties {X, Y}.
I am curious, how you would describe “physical functional components”. Please try your best.
Dr. Peter, it is called a paradigm shift for particular reason. Many terms in one paradigm have different meanings in another paradigm. The meanings are incommensurable. The meaning of many terms evolves over time, for example meaning or mental picture the term “Social Networking” paints is different now from pre-FaceBook time. Many terms we use now has no meaning 22 years before the release of Netscape browser.
Dr. Peter, we have been arguing for nearly 3 years. Any thing I could write would be perceived as crazy. Any few pieces in isolation appear crazy. Over time, you learned various pieces and if you are paining attention, it may be slowly painting blurred image. Attention span of people is small, especially if they are highly skeptical. One must try to learn this kind of things with open mind. I know, you read my ideas with so many pre-conceived notions (and my ideas didn’t fit your mental model).
Dr. Peter, The problem is, so called experts want proof in 3 short paragraphs. It is easy to take pot shots but no one ever done this in 400 years. Even the researchers in the dark ages has much better justifications such as (i) if the Earth is moving, how could the Moon is following (i.e. not left behind) or (2) why stellar parallax can’t be observed.
Regards,
Raju
Dear Dr. Peter,
I need to find a better way to explain this. Today computer science and software engineering ended up in crisis, because software researchers are not using any other proven methods except mathematics to acquire necessary Body of Knowledge (BoK) for solving unaddressed problems.
I want to make a very simple point: Certain unsolved software engineering problems such as real CBSD or real AI (artificial intelligence) can't be solved without using scientific methods for acquiring necessary body of knowledge. Only reason many such problems are not yet solved because software researchers not using scientific methods to gain necessary BoK (Body of Knowledge). Kindly think of this BoK as a consistent axiomatic system. Heliocentric model might have started from root axiom, the Sun is at the center, but it resulted in a consistent axiomatic system. Likewise the essential properties are just the root axioms to evolve axiomatic system.
My reasoning or argument is very simple: How can we invent (and continuously improve) fiber optic networks without having basic BoK about the nature and properties of light and how light behaves in optical fibers? How can we invent ICs (computer chips) without having necessary BoK about the nature and properties of electrons and how they behaves in semi-conductor material?
Is it possible to invent cures for infections, if researchers refuse to use right tools or proven methods to discover even basic facts (e.g. for BoK) about the nature and properties of bacteria/viruses?
Likewise, it is impossible to invent real CBD for software products by being clueless about basic facts and reality such as (i) what is the obvious nature and true essence of the CBD; or (ii) properties absolutely essential for the components to achieve and optimize/improve the true CBD. We need to construct a consistent axiomatic system, without ignoring the reality in the from of empirical results and observations about the physical components/CBD.
No scientific or engineering discipline can avoid crisis, if it is rooted in fundamentally flawed beliefs (by considering the beliefs are self-evident facts) and have been evolving for long time by relying on the flawed beliefs. The basics sciences ended us in crisis, when it was rooted in flawed belief (i.e. the Earth is static). If the essential properties for components are {R, S}, no part can be a component without having the properties {R, S}. In other words, if a part can be a component, only if the part has the properties {R, S}. Software engineering cannot avoid such crisis, if it is rooted in flawed beliefs (i.e. flawed properties for so called software components/CBSD).
Unfortunately, most software researchers think it is a heresy, if I insist on using proven scientific methods (e.g. classic science as you said) for grasping the reality and discovering necessary facts, as if I am demanding to expand the religion, for example, Christianity (i.e. religion of Mathematics) by adopting other religions such as Buddhism & Common sense (i.e. religion of Science & sound Logical reasoning). Mathematics or Computer Science is not a religion.
Many software researchers believe (by clearly implying in many published scientific papers and open discussions with me) that Computer Science is a sub-section of mathematics, hence there is no room for knowledge and facts (acquired by using proven scientific methods) in the BoK for Computer Science and Software Engineering. It is impossible to even start addressing huge unsolved and outstanding software problems (e.g. software crisis or real-AI) until this attitude of the researchers of computer science is changed.
Screwdriver (mathematics) is a great tool but one can't use screwdriver to unscrew lug-nuts and bolts. One needs wrench (scientific methods) to unscrew lug-nuts and bolts. One must use right methods or tools to gain necessary BoK for addressing each problem. The problems such as real CBSD or AI are not yet solved, only because researchers are not using right tools or methods for acquiring essential BoK. Mathematical methods are useless for discovering the nature and essential properties of physical things, while scientific methods have proven track record discovering the essential properties of physical things.
Dr. Peter, any kind of physical beings or things share a set of essential properties. Physical components are not exception. These properties can be discovered by employing scientific methods. Scientific methods have proven track record for discovering essential properties of not only far more complex physical things (e.g. viruses, bacteria, light, particles such as electrons) but also uniquely and universally shared properties by far more diverse species/beings (e.g. animals, plants or chemicals). Most of this kind of BoK comprises of objective facts and demonstrable evidence. All I am asking is to acquire this kind of BoK and use it to solve problems that are not yet solved by mathematics alone.
My recommendation is only to gain necessary BoK using scientific methods and use the BoK to address unsolved problems. One can follow my method of discovering essential properties and evolve the BoK by relying on the essential properties. Or he can find another better method to acquire the BoK and use the BoK.
Best Regards,
Raju Chiluvuri
- Badges
- Science topic
- Similar topics
- Computer Science