Dear Friends,
There is lot of hostility and fierce resistance to critical or decedent views or ideas that contradict prevailing dominant paradigm. Every researcher must watch the first 10 minutes of this interesting video about how climate of opinions, unanimities of biases or dominant paradigm suppresses counter evidence for diversity of views: https://www.youtube.com/watch?v=8a2lisF4XGg
Debating of diverse view and ideas are essential for advancing the frontiers of our scientific knowledge and/or expanding the boundaries of human knowledge and wisdom. Unfortunately, often research community is highly hostile and fiercely suppresses critical or decedent views and any attempt to initiate debate for critical or decedent views face fierce resistance (e.g. by resorting to personal attacks, insults or snubbing).
No one asked proof for the 2300 old lie “the Earth is at the centre” for 1800 years until 16th century. Nothing in the history of science faced more resistance than the truth “the Sun is at the centre”. This decedent discovery or idea undergone more rigorous scrutiny than any other discovery or idea in the history of science. Testing and challenging such ideas are expected, but resorting to personal attacks, snubbing or persecution for silencing such decedent ideas/views is deplorable and pathetic.
Even in the 21st century such deplorable problems exist. I have been struggling to expose a huge lie for many years and facing hostile resistance. The lie is the root cause for the infamous software crisis, which already cost more than a trillion dollars to the world economy. For example, even if I politely request for an opportunity for demonstrating counter evidence to expose the lie, certain research institution in India instructed their researcher staff to not talk with me (i.e. without any provocation from my side, or without even a response from their side, politely requesting for an opportunity by emails after they asked me to send the emails when I met them in a conference). Only crime I committed is requesting an opportunity to present counter evidence to basic or background assumptions at the root of the dominate paradigm.
The CBD/CBE (Component Based Design, Development or Engineering) for software and software engineering in general is rooted in 50 to 60 years old lies such as “reusable software parts are software components” and CBD/CBE for software is using such fake software components. Software researchers made such definitions 50 to 60 years by ignoring reality about the components/CBD and have been blindly struggling to fit the software components/CBSD to fit these fictitious definitions.
My argument is extremely simple, but people have hard time understand this simple argument and reasoning: What are the striking and main difference between the parts that are certainly components and other kind of parts that are certainly not components? How one can find out the striking and main difference, if there is such a striking and main difference?
Please list out a few dozen or even few hundred parts that are certainly good examples for components for the physical products that are built by using components (e.g. products such as cars, computers, airplanes or machinery etc.). Also pleases list out good examples for parts that are certainly not components for the physical products. Even simple analysis proves that: The striking difference is that the parts designed or conducive to be assembling (or plugging-in) are components. The parts that are not assembled (or plugged-in) are not components.
Hence, isn’t a lie to insist reusable or standardized parts such as TMT-steel, 53-grade cement, standardized plastic sheets, bare semiconductor wafers or plates of alloys that are used for making cars, airplanes or machinery? All these parts are highly standardized for using across many product families and manufactured in advanced factories (so they are complex parts).
Don’t we need to use apples to make apple juice? Can you make apple juice by using other kinds of fruits that are not apples? How can you call a method CBD/CBE that only uses other kinds of parts that are certainly not components by any stretch of imagination (since parts that can never be assembled under any conditions are not components)?
Today no known kind of so called software component is required to be assembled. Today, no one is even putting any conscious effort for making such so called software components conducive to be assembled. Isn't it a lie to define that: CBD/CBE is using parts that can't be components by any stretch of imagination?
We can’t ignore the great wisdom passed onto to us by great scientists such as Galileo or Newton. Let me quote Newton: “The best and safest way of philosophizing seems to be, first to enquire diligently into the properties of things and to establish those properties by experiments and then to proceed slowly to hypotheses for the explanation of them. For hypotheses should be employed only in explaining the properties of things, but not assumed in determining them; unless so far as they may furnish experiments.”
All I am requesting to do is to diligently inquire and document properties of the components and CBD/CBE before making flawed hypothesis such as “reusable parts are components” and “using such fake components is CBD/CBE for software”.
There exist certain kinds of parts such as hard drive, CPU, Engine, Alternator, 12VDC Battery in the car, DRAM or CD-players, where each of the parts can be disassembled form the product, for example, to repair or replace by a new/better part. Such parts (that are assembled and may be disassembled) are known as components.
On the other hand, other kinds of parts such as ingredient parts (e.g. steel, plastic, alloys or glass) are not assembled. Such parts are not referred to as components. The main thing that differentiates components from other kinds of parts is that, components are conducive to be assembled. Hence a part that can’t be assembled is very unlikely to be a component.
Isn’t commons sense: The CBD/CDE (Component Based Design, Development or Engineering) of any product must use components? Don’t you need to use apples to make apple juice? Can you make apple juice by using other fruits such as lemon or oranges? How can it be a CBD/CBE, if it is not using the components (i.e. but using other kinds or parts)?
Can we imagine the modern industrial world without the parts that can’t be assembled? Such parts are known as components in the context of the physical products such as cars, airplanes, computers or any machines or machinery for factories. The components are the backbone of our modern industrial society. It is not hard to invent such components for building complex software applications or products by literally plugging-in such components.
But unfortunately, we are facing fierce resistance and hostility towards our critical or decedent views or ideas in the community of software researchers. Many software researchers trying to do everything they can to silence us. How to alleviate such hostility for critical or decedent views or ideas.
Best Regards,
Raju Chiluvuri
Honestly, when I firstly read your question, I found it too dense and even unclear regarding its exact goals. I visited the sites in your profile and everything started making a bit more sense, but being still too confusing. Then, I read the attachment to this question and everything became slightly clearer.
This is a summary of what I think that you mean:
By assuming that I got all your ideas right, I do agree with what you are saying; although I also think that fully addressing this problem is very difficult, even impossible. In any case, I have written my preliminary impressions about how to proceed below these lines.
PRELIMINARY IDEAS FOR MODULAR-COMPONENT STANDARDISATION
First thing which I would do is to come up with a systematic enough classification where all the common-feature components will be incardinated. Examples: string analysis, numeric calculations (sub-categories: integer, floating-point decimal, non-floating-point decimal, etc.), ordering, encryption, etc.
Then, I would come up with a set of basic and specific-for-each-category rules. For example: clear definition of entry/exit points, expected errors (caught/not-caught exceptions), upper/lower values for inputs/outputs, etc.
I would also expect to have some kind of standardised tests which all the components should pass through in order to be considered valid.
I would also expect centralised/international/official authorities (perhaps existing ones like the ones issuing ISO rules) in charge of ensuring that the whole system works as expected. There should also be easily accessible by everyone repositories including all the valid components in all the categories and for all the main programming environments.
By bearing in mind our current stage of development, I would also assume all these efforts to be focused on actually-relevant parts. For example, plainly ignoring all the basic string/numeric operations already present in virtually any programming language would make much more sense than spending time on accounting for each single possibility which, in practice, nobody will ever use.
I think we discussed this briefly some time ago. On the surface, the idea sounds like something that is already being practiced, at least to a relatively large extent. Many people reuse their own code, or incorporate standard code, when writing something new. Things as basic as floating point routines wouldn't be reinvented with every new application?
http://ww1.microchip.com/downloads/en/AppNotes/00575.pdf
Alvaro mentions encryption. That not only commonly uses existing and approved code, but it's difficult to deploy anything crypto-credible that wouldn't use approved standard methods. (Although it's fun to invent these things.)
I guess my main question would be, what are the objections? Can't be anything with the general concept. Must have to do with specifics? Or maybe some people think you're making a big leap of faith, with some particular goal or claim?
Dear Mr. Garcia,
Thank you for patiently reading such a long question. I greatly appreciate your patience. My point is not complex. Any part that is not conducive to be assembled is not a component. This simple truth is not known today. Not knowing this truth diverted research efforts of software engineering in the context of CBD/CBE into a wrong path.
Not knowing the truth “the Sun at the center” diverted research efforts of mankind diverted into a wrong path for 1800 years until 16th century. More than 450 years ago large portion of our scientific knowledge is nothing more than illusion (e.g. retrograde motions and epicycles) rooted in 2300 years old flaw belief “the Earth is at the center”. This belief was proved to be a lie and exposing the lie transformed the basic sciences in to real hard sciences from pseudo sciences that resulted in the greatest scientific revolution.
Today most of the knowledge documented in software books and research papers related to so called software components in the context of CBD/CBE (Component Based Design, Development or Engineering) is mostly fiction rooted in 50 to 60 years old flawed beliefs such as (1) software parts that are reusable or conducive to be reusable are software components, and (2) CBD/CBE is using such so called software components. Basic common sense tells that it is a lie.
My point is simple: Today no known kind of so called software components is conducive to be assembled or plugged-in. It is not hard to invent software components that can be plugged-in and mechanisms such as software motherboard necessary for plugged-in the components.
Let me describe CBD/CBE: Component based engineering of a large product must implement large portion of features and functionality of the product in parts that are designed and conducive to be assembled. For example, please see a sample application built by assembling plug gable components: http://real-software-components.com/CBD/City_GIS.html
I can train any software designer in few weeks to couple of months to partition large portion any software product into such pluggable components. Few weeks to couple of months may not be a short time, but isn’t worth to implement 90% of the code in such pluggable components?
I had no problem training even junior programmers in creating and assembling such GUI components. They have created thousands of such components and hundreds of component hierarchies. Many experts feel irritated, because I am presenting a heterodox view no one ever even heard. My views contradict the unanimity of flawed assumptions (i.e. lies such as reusable parts are components and CBE using such fake components) considered to be objective.
Kindly review attached PDF files for more information. Please kindly don’t assume that real COP (Component Oriented Programming) paradigm is complex. It is much simpler than OOP (Object Oriented Programming) paradigm. One can learn basic concepts of OOP such as analysis and design in few weeks and master OOP in a year or two by practicing it.
Likewise, by using proper tools (that we invented and created) and training COP paradigm can be mastered in about half the time compared to time required for mastering OOP paradigm. Most software engineers have no problem mastering OOP. Likewise, most software engineers would have no problem mastering COP.
Best Regards,
Raju
Note that, in Spain and many Spanish-speaking countries, we have two family names. Usually (what happens in my case), the distribution is: first family name from the father and second one from the mother. Ideally, you should use both (Carballo Garcia, for me), although using only the first one is also OK (Carballo), but just using the second one is plainly wrong. Please, take this as curious information helping you avoid making mistakes (very common in certain countries, BTW) in the future.
Now, regarding your answer:
- "My point is not complex" -> I wasn't implying that it was complex, but that your description of it was too unclear (I might even use words like "messy"). You were asking for some help allowing your ideas to be easily transmitted and this was what I tried to do (sorry if my intention wasn't evident): highlighting that you might need to work more on the way in which you are communicating your ideas (you should also perhaps make an additional effort to adequately understand others' positions). Note that my preliminary ideas regarding how to proceed with this standardisation were also a way to tell you "what about trying to transmit what you want via actually-relevant examples, rather than through abstract and saying-nothing ideas"?
- "I can train any software designer in few weeks to couple of months to partition large portion any software product into such pluggable components" -> perhaps, I didn't get your exact intention right (again, your not-reader-friendly explanations are the ones to blame) or even perhaps I unconsciously evolved it further. I thought that you meant truly valid components to be used everywhere. For example, a function performing certain action which I can get right away in the language I want by being completely sure that I can fully trust it (e.g., ISO certified). But you were talking just about developing modular code? This is already done everywhere. I do it myself systematically. In fact, my only relevant open-source library so far (FlexibleParser) is precisely formed by fully autonomous parts. Any software development company (their quality department) should already make sure that the code they write don't depend on a specific person and can easily be extended/modified. Delivering high-quality code (what includes working fine now and tomorrow, being understood by anyone easily, etc.) is also part of the discipline, knowledge and even principles of every programmer, much more when dealing with (the very-common scenario of) clueless people (in general, about programming and/or about the specific development). I think that coming up with a set of generic ideas expecting to be the final solution to low-quality code (or even the more restricted version in your last comment: GUI?! I personally don't even care about GUI, this isn't my work nor my concern as far as my work is fully focused on algorithms, optimisation, etc.) and/or low-principles programmers is extremely naive and isn't even in a position to accomplish anything. On the other hand, the official standardisation which I proposed (by understanding that this was your intention as far as I don't see the use of any other application of these ideas) might be certainly helpful and reduce the main problems of software development (e.g., bugs created by using buggy third-party elements; a problem which I rarely have as far as I tend to develop all the code myself, precisely because of not trusting in the quality of third-party code).
- "Kindly review attached PDF files for more information". Sorry but I will not do that. I was trying to help you (a person who, IMHO, needs some help) and apparently I got wrong your exact expectations (you don't seem willing to be helped).
Dear Mr. Carballo Garcia,
Please carefully review the sample CBD application: http://www.real-software-components.com/CBD/City_GIS.html. Each RCC (e.g. CityATC and CityLandmarks) uses most powerful and flexible reusable library for GUI components.
This application maximizes the reuse. Yet it requires implementing few thousands of lines of custom application code for each of the GUI components (e.g. CityATC and CityAmbulences) to perfectly fit and function optimally within the application.
The essential condition for pluggable components: No component must require more than 3 to 4 lines of code to plug-in. The collaboration between the pluggable components is created and managed by an intelligent CASE-tool referred to as software motherboard for plugging in the components such as: http://www.real-software-components.com/CBD/Sample_SoA_CASE_tool.html
If application has 100 such components, total code for assembling the components must be less than 400 lines. Over 95% of the application code must be implemented in such pluggable components.
Real CBD requires two things (1) components that can be plugged-in and (2) software mother board that facilitates creation and manages communication code, so that components can be plugged-in. These are falsifiable statements by showing counter evidence: Today, no application is using such software motherboard. No GUI technology can build such RCC (replaceable component class).
You are talking about increasing reuse and increasing modularity. Please see the degree of modularization offered by pluggable components. Can you show me a single application that has few dozen pluggable components? No such pluggable component must require more than 3 to 4 lines to include an object fully self-contained instance. Such pluggable component must not require manually implementing any more communication code (i.e. all the communication must be implemented within the RCC by using the software motherboard).
P.S: Mr. Carballo Garcia, you are not helping me. You are trying to impose your biases due to existing dominant paradigm. The objective reality is that about 90% of large components for physical products are neither reusable nor standardized (e.g. http://www.real-software-components.com/CBD/main-differences.html). Each of them are custom designed to perfectly fit the product and perform optimally in the product. The main property all of the components share is that, each of them are conducive to be assembled as illustrated in the above CBD application example. In case of real CBD, about 90% of the functionality and featured are implemented in such components (that can be assembled or plugged-in).
Best Regards,
Raju Chiluvuri
I am afraid that the two first paragraphs of your reply are intrinsically incompatible: only "reusable library for GUI components" or "it requires implementing few thousands of lines of custom application code" can be true, but not both. Any piece of code which I develop and call "reusable" can certainly be reused with either minor or no modifications. As said, I am not too experienced in the GUI side of things, but certain ideas should hold everywhere. The fact that you call something modular/reusable/adaptable/etc. doesn't mean that it actually is such a thing, not for everyone and for any (quality) expectations. I see lots of libraries and methods which require a relevant amount of tuning-up, are faulty, are incompatible with many operating conditions without saying anything about that, etc. That's why I try to use as less external code as I can and think that a source of reliable enough code snippets (not just for GUI, for everything) would be beneficial.
Anyway, I am only interested in an aspect which doesn't seem too relevant to you and vice versa; so, I will better stop it here. In any case, note that I do consider your last comment much clearer, to-the-point and appealing-to-potential readers than all the previous ones.
Dear Mr. Carballo Garcia,
I said reusable library for GUI components (not of GUI components). An object instance of a reusable Java class for PIE-chart can be used to present a PIE chart GUI component by implementing application logic (e.g. to access data, process the data and input the data to the object instance).
Each RCC such as CityATC uses few dozens to few hundred reusable Java class instances for presenting GUI components such as Tables, Drawing Area, ToolTips and Airplanes etc. The RCC also implements all the necessary application logic for presenting the GUI components by initializing the GUI object instances of reusable GUI classes.
Kindly understand what is meant by plugging-in a component: Just include an object instance of a RCC (Replaceable Component Class). The functionality and features of an application can be partitioned in to disjoint set of features and functionality. Each RCC implements a disjoint set of self-contained features and functionality of the applications (e.g. CityATC or CityAmbulences). It must not require implementing any external communication code, except communication code implemented with-in the class definition to plug it into the software motherboard.
Why do you think I can’t customize each of the RCCs (e.g. CityATC or CityAmbulences) to satisfy often unpredictable future unique needs and test each individually outside of the product free from spaghetti code? The requirement for each RCC is that: It can be redesigned and tested individually any time in the future free from spaghetti code.
The custom application code implemented in each of the RCCs can be redesigned or refined and tested individually free from spaghetti code. Over 90% of the custom application code of a large software product can be redesigned or refined free from spaghetti code, if over 90% of the custom application code of the large software product can be implemented in such RCCs, where each object instance of the RCC can be plugged-in by implementing no more than just 3 lines.
Best Regards,
Raju
Dear Mr. Manfredi,
The first 11 minutes of the video https://www.youtube.com/watch?v=8a2lisF4XGg has three important points (1) climate of opinions (I prefer to call ecosystem of opinions, unconscious biases), dominant paradigm or unanimity of assumptions or biases considered to be objective, (2) the important function served by critical, decedent or heterodox views, and (3) why experts feel irritated by such critical, decedent or heterodox views and such how such irritation limits the ideological diversity essential for expanding boundaries of our knowledge.
The social sciences deal with subjective knowledge such as religion, economic or political ideology. In such disciplines, one ideology may be as good as the other (or as bad as the other) ideology. It is mainly influenced by subjective perceptions, cultural biases, preferences or perceived gains or losses etc. Hence objectivity might not be possible.
In case of hard sciences, properties for physical beginnings (e.g. animals, trees, birds, viruses or components) are not ideological choices. Unfortunately, software researchers assumed that the properties of components are ideological choice. My research spanning more than 16 years accumulated huge evidence to prove that the properties of components are not ideological choice.
I am requesting software researchers to conduct a simple investigation: Please list out a few dozen or even few hundred parts that are certainly good examples for components for the physical products that are built by using components (e.g. products such as cars, computers, airplanes or machinery etc.). Also pleases list out good examples for parts that are certainly not components for the physical products.
Even simple analysis proves that: The striking difference is that the parts designed or conducive to be assembling (or plugging-in) are components. The parts that are not assembled (or plugged-in) are not components. In other words, there exists special kinds of parts that are conducive to be assembled and disassembled. Such very special parts are known as components.
Hence, isn’t a error to insist reusable or standardized parts such as TMT-steel, 53-grade cement, standardized plastic sheets, bare semiconductor wafers or plates of alloys that are used for making cars, airplanes or machinery? All these parts are highly standardized for using across many product families and manufactured in advanced factories (so they are complex parts). Such parts are composed or mixed (but not assembled and cannot be disassembled).
Don’t we need to use apples to make apple juice? Can you make apple juice by using other kinds of fruits that are not apples? How can you call a method Component Based Engineering that only uses other kinds of parts that are certainly not components by any stretch of imagination (since other kind of parts that can never be assembled under any conditions are not components)?
I can train any software designer or engineer in COP (Component Oriented Programming) within few weeks as explained in above response to Mr. Garcia. But unfortunately, many software researchers feel irritated by my critical, decedent or heterodox views. It is wrong to kill ideological diversity just because certain ideas or views are perceived to be irritating or heresies.
Sir, I am not advocating re-inventing the wheal (i.e. components). I am only saying that right wheal (i.e. right components for right CBD) are not yet invented. Please kindly review the TwoPotentWeapons.pdf attached to main question. Also please see a sample CBD application: http://www.real-software-components.com/CBD/City_GIS.html.
The Replaceable Components Classes such as CityATC or CityLandmarks doesn’t exist today. Today no GUI technology (e.g. from Microsoft or Apple) in the world allows implementing mini applications such as CityATC as a class, so that it can be literally plugged-in to build component hierarchy.
Best Regards,
Raju Chiluvuri
Dear Friends,
The thing that pains me the most is: many respected researchers repeating mistakes that are well documented by most respected philosophers of science. For example, one of the greatest 20th century philosophers of science Dr. Kuhn summarized the following 3 mistakes (see first paragraph of this excellent synopsis): https://www.uky.edu/~eushe2/Pajares/kuhnsyn.html
A scientific community cannot practice its trade without some set of received beliefs. These beliefs form the foundation of the "educational initiation that prepares and licenses the student for professional practice". The nature of the "rigorous and rigid" preparation helps ensure that the received beliefs are firmly fixed in the student's mind. [Mistake-1] Scientists take great pains to defend the assumption that scientists know what the world is like... [Mistake-2] To this end, "normal science" will often suppress novelties which undermine its foundations. [Mistake-3] Research is therefore not about discovering the unknown, but rather "a strenuous and devoted attempt to force nature into the conceptual boxes supplied by professional education".
The first 11 minutes of this tape provides another perspective of the mistakes in the context of soft-sciences. The first 11 minutes of the video https://www.youtube.com/watch?v=8a2lisF4XGg has three important points (1) climate of opinions (I prefer to call ecosystem of opinions, unconscious biases), dominant paradigm or unanimity of assumptions or biases are considered to be objective, (2) the important function served by critical, decedent or heterodox views, and (3) why experts feel irritated by such critical, decedent or heterodox views and how such irritation limits the ideological diversity essential for expanding boundaries of our knowledge by poising open discourse.
P.S: One of the received beliefs at the root of our 16th century scientific BoK (Body of Knowledge) was that: The Earth is at the center. The evolution of BoK between 300BC and 16th century by relying on such flawed beliefs created unanimity of biases that were considered objective. The received beliefs at the root of our software engineering BoK include: “reusable software parts are components” and “CBD/CBE is using such fake components”. The evolution of BoK for past 50 years by relying on such flawed beliefs resulted in unanimity of biases that are being considered objective.
The nature and properties or characteristics of physical beings such as animals, mammals, trees, birds or bacteria cannot be subjective ideological choice by any stretch of imagination. Researchers (e.g. of botany or zoology) meticulously observe the reality and document what they observed – This documented observations are frequently tested independently and challenged in respective scientific disciplines to move the BoK of respective scientific disciplines closer to objective reality.
Likewise, the nature and properties or characteristics of components used in making component based products such as cars, computers, machines, airplanes or machinery cannot be subjective ideological choice by any stretch of imagination. But software researchers have been defining the nature and properties or characteristics of components for software based on their ideological preferences (by ignoring the objective reality). Today it is considered heresy to challenge the subjective definitions for software components and CBD/CBE.
Any piece of scientific knowledge must be open for testing and challenging either to falsify (in case it is flawed) or to bring our knowledge and wisdom closer to the Truth by improving our knowledge and understanding. Isn’t wrong, if researchers feel that it is heresy to either challenge or offer counter evidence to expose flawed beliefs.
Best Regards,
Raju Chiluvuri
- Badges
- Science topic
- Similar topics
- Geoscience
- Cartography
- Mapping