5 ms·
You're still not getting it. You constructed a set of components, and are now assembling them together to create an application. That's great, as long as all
by michael_dorfman 17y ago
You're still not getting it.
You constructed a set of components, and are now assembling them together to create an application.
That's great, as long as all of the functionality that you want to include in the application is exposed in the components, in a way that is intuitive to assemble, and flexible enough to handle future changes/debugging.
The car analogy is not appropriate; once you create all of the components of a car, you can make as many instances of that particular car as you like. But only that car. You can't reassemble them to make, say, a pick-up truck, or an airplane.
If you want to create a bunch of applications that are all very similar, and only superficially different, you can create a Domain Specific Language. And it appears that that is what you have done. But this is different than a General Purpose Language, and there still will likely be times when you need to go back and create new components, so the separation between coding and assembly is far from pure.
Just out of curiosity, where did you study Computer Science?
- srid68 17y agoSorry I am a Mechanical Engineer. You are right that is similiar to a Domain Specific language without any Domain dependency. It is basically a simple language of assembly which can be used to build complex software as long as you have components. Regarding my analogy of a Car which i illustrated to show having assembly as part of product development is how they have handled complexity of the car manufacture and this has been followed by every industry other than software. When a specific product is development, specifically to handle complexity and productivity, other industries separate manufacturing of components from assembly and assemble to create a finished product. Here assembly and manufacture is different and can be done by separate teams/companies without any problem even when both are clearly dependent. In software this is still not the case. I have handled Outsources teams/Insourced teams for development of enterprise software and allways found it is not easy even when my projects have been very successfull. Basically it involved too tight control and sleepless nights. That is why I have to still learn and code instead of concentrating on managing projects like typical project managers. If we split software development into software assembly and software coding, i thought i should have higher order of productivity and separate domain from code. Any way i will try this on a new project and find out whether it works. May be or May be not. Anyway thanks for your comments.