computer science is a BoK, which can be and must be expanded by adding ... means to address certain kinds or classes of problems (or gain knowledge.
Pragmatic Perspective of “Body of Knowledge” for Computer Science (or Software)
Please pensive each of the scientific disciplines in different pragmatic perspective: Physics is a BoK (Body of Knowledge) accumulated for a given subject area (i.e. a particular domain) by using tools such as science and mathematics. Likewise, chemistry is body of knowledge accumulated for another particular domain by using tools such as basic methods of science and mathematics. Botany and zoology are body of knowledge accumulated by using tools such as science (i.e. scientific methods and processes).
For example, basic scientific disciplines such as physics or chemistry alone can’t provide comprehensive knowledge foundation necessary for addressing many kinds of problems in respective domains (i.e. in the areas of particular subject) by scientific processes alone. So each of the scientific disciplines extensively relies on other tools such as mathematics to fill large gaps to gain deeper insights and fully comprehend each of such problems.
The purpose of research in the subject areas of computer science or domain of software is to accumulate necessary BoK (Body of Knowledge) to understand and/or address each and every kind of problems in subject area (or domain) of software. In pragmatic perspective, software or computer science is a BoK, which can be and must be expanded by adding more and more new knowledge using any and every tool having proven track record for acquiring new knowledge such as science, maths, logic or
philosophy (e.g. epistemological methods such as empiricism or rationalism).
I want to differentiate normal engineering from engineering research for advancing technological progress. Let me define, engineering research for advancing technology is inventing useful things or processes for addressing unsolved real-world problems or issues (by relying on the existing BoK). Relying on the existing BoK for substantially improving existing useful things or processes is also engineering research. If the existing body of knowledge is not sufficient to address certain kinds of problems, it is essential to create additional knowledge by doing basic (e.g. theoretical or scientific) research using any and every appropriate and available tool (e.g. science, maths, logic or philosophy) having proven track record for acquiring such knowledge.
Today computer science and software engineering are treated as a sub-set or sub-domain of mathematics. But computer science and software engineering need to address many kinds of diverse problems and issues that are outside the competencies of mathematics. Hence computer science and software engineering must emerge as independent fields to address any kind of problems/issues, which must be addressed for technological progress in software. The body of knowledge in computer science must have all the necessary kinds of the knowledge essential for software engineering research to make useful inventions for addressing each of the problems and hurdles.
The researchers of computer science have been using mathematics as a tool to accumulate body of knowledge. This knowledge is enough to address many kinds of problems and issues by the researchers of software technology. However, researchers of computer science are not using other powerful tools for gaining knowledge such as science (i.e. not using proven scientific methods and processes) to add to the body of knowledge. Hence failed to address many kinds of problems such as software crisis due to spaghetti code or real Computer or Artificial Intelligence.
Mathematics alone can’t provide necessary knowledge foundation or means to address certain kinds or classes of problems (or gain knowledge in certain domains), which must be addressed by researchers of computer science and software. For example, researchers must use appropriate tools having proven track record for gaining knowledge in certain domains or addressing certain kinds/classes of problems. There are many proven methods and tools (e.g. mathematics, science, philosophy, logic or rationalism, empiricism and common sense) for acquiring necessary knowledge. To help technological progress in the field of software, researchers of computer science must use all necessary or appropriate tools to provide necessary knowledge foundation essential to address each kind of problems.
Is there any evidence to show that it is impossible to use other tools such as scientific methods for acquiring useful knowledge for addressing
unsolved software problems such as software crisis by eliminating spaghetti code or real Artificial Intelligence? Software researchers must select appropriate set of proven tools to address each of the problems in the software. It is a mistake to impose unnecessary artificial limitations to just one tool to solve each and every kind of software problems.
Existing BoK (Body of Knowledge) in computer science is not sufficient to address certain huge unsolved problems such as infamous software crisis (e.g. due to the spaghetti code) or real AI (Artificial Intelligence) equivalent to even the simplest neural networks in the brains of living things (e.g. equivalent to the neural networks in the brains of even the smallest flies or insects). Today software engineering is in crisis due to the spaghetti code. Except software products, design and development of no other product in the world is infected with such spaghetti design (or code), which includes design and development of even very large and complex one-of-a-kind physical products such as experimental spacecraft or pre-production working prototype for next-generation jet-fighter.
In such products, each large component is custom designed to satisfy unique needs of the product. That is, most of the large components are reusable or standardised. In other words, it is not necessary that even a single large component need to have any useful properties (e.g. reusable or standardised) attributes to so called software components nor conforming to so called component models. The components in the pre-production
working prototype are useful references to mass-produce interchangeable components to set-up assembly line for mass production.
Each of the components is designed and developed individually outside of the product free from spaghetti code. Each of the components can be tested individually. Once all the necessary components are built and tested individually they are assembled to make sure each of them fit perfectly and perform as expected. At first attempt (i.e. when assembled first time) most components don’t fit perfectly or perform as expected (i.e. might not collaborate with other components as expected).
The components are unplugged to refine (i.e. redesign) and test individually outside of the product to make each component as best as it can be. Once all the components are refined and tested individually (free from spaghetti code) they are assembled to make sure the product performs as expected. The above two steps are repeated until the prototype product performs as expected (i.e. each of the components fit perfectly and perform as expected). It is an iterative process, where each of the components is redesigned many times until each of the components fit perfectly and both the components and the product perform as expected.
The designers of all the other products successfully eliminated spaghetti design (or code) by implementing about 95% of the features and functionality in such components. Where each of the components can be designed (or redesigned many times) and tested individually free from
spaghetti design (or code). Hence each of the components is free from spaghetti design (or code). Since 95% of the features and functionality implementing in such components, about 95% product design is free from spaghetti design (or code). It is impossible to find a valid reason, why large and complex software products by implementing over 90% of its features and functionality in such components. Where each of the components could be designed (or redesigned many times) and tested individually free from spaghetti design (or code).
Amazingly, it is simple to gain necessary BoK using proven scientific processes and methods (i.e. science as a tool) for addressing infamous software crisis. Each scientific discipline (e.g. physics or chemistry) accumulates BoK for a given domain using any and every proven tool (e.g. science, maths, logic or philosophy) for acquiring such useful knowledge. Likewise, researchers of computer science can and must use every proven tool (e.g. science, maths, logic or philosophy) for acquiring such useful knowledge for expanding the BoK (Body of Knowledge).
All we need to discover is the nature and essential properties of large physical functional components, where the functional components imply components that perform certain internal operations or functions. Where the essential properties are a set of properties uniquely and universally shared by every known physical functional component. Science is uniquely suited and proven tool for discovering the nature and essential properties of physical beings. For example, scientists or researchers discovered
essential properties of 10 to 50 times more complex beings such as viruses, elementary particles, light or bacteria. Many of them requires complex experiments and methodical investigation, because none of them are visible.
The researchers of natural sciences discovered essential properties of far more diverse species such as plants, animals, chemical elements or mammals. Neither diversity nor invisibility are hurdles for discovering nature and essential properties of physical things or phenomena. How hard it would be to discover the essential properties of large physical functional components? Of course, it may not be a trivial task, but It is not very hard task. This knowledge and hands on expertise is valuable in positively identifying many sets of features and functionality in any large application or software product under design, where each set of features and functionality can be implemented as a self-contained loosely coupled software component.
