Ask HN: Seeking Comments: Holy Grail of Software | Hacker News Reader

Ask HN: Seeking Comments: Holy Grail of Software

2 pointssrid688 comments

I have created a test of my below Hypothesis @ www.arshu.com. Please note it is 0.1 version and tested using Firefox only. Download if have .NET to run the whole site in your PC.

Hypothesis :

Complex software has to be done by assembling reusable components to have the following advantage. 1) High Productivity 2) High Flexibility/Changeability 3) Low Cost. This is how other Industries have managed complexity/productive and cost. Even Fast Food industries like KFC etc, assemble food instead of making food.

This is not my original thought, but I found this approach has been discussed even in mainframe era. I consider this as the Holy Grail of Software.

Loose Coupling/SOA/Struts/Spring/Dependency Injection are various approaches to acheive the above. I have seen Mashups/Popfly/SharePoint WebParts Framework implementing this type of approach even though it is not fully separating assembly and coding.

In connection with testing the above Hypothesis, I started working on a Framework where I can clearly separate Assembly and coding.

I have recently started work on mini ERP like workflow and document management product for Architecture Industry and going to use this Framework to really find the benefit.

In the mean time I would like to hear any comments from others. Do you think this Hypothesis is valid. Have you come across any other way to separate assembly and coding.

The "Holy Grail of Software" is an illusion. Sorry to burst your bubble.

How are you distinguishing "coding" from "assembly"? What is code, if not a series of instructions assmbled together in a sequence? What is the assembly of components, if not writing code using designated primitives?

Turing showed that it's possible to write almost anything with a tiny number of primitives. If you have some kind of means of combination and means of abstraction built into your language, you can generate new objects from the primitives, which can then be combined and abstracted, ad infinitum.

In other words: you're doing nothing new.

The problem you are going to run into is that there is no magic set of components which will meet all needs for all purposes, at the appropriate level of abstraction.

If you want to build a Domain Specific Language for creating ERP systems, more power to you. That's a worthwhile project.

But don't go mistaking that for "the Holy Grail of Software".

Agreed it is a illusion till date.

When Ford what to separate assembly from manufacture every one critized it but today that is the method used by major industries.

Why is software still not done like that. Why we mix assembly and coding. Why can these two things be separate and distinct steps. Since this is a fundamental problem which has still eluded for so long, which is why i call this as the Holy Grail of Software.

I am not tring to create a magical components as the building blocks for creating any software, if that is the case the binary number 0 and 1 is currently used to build everything in software.

I am just saying that separating assembly from coding cleanly similiar to how assembly of a car is different from the manufacture of components of a car, then we will be able to achieve high productivity/high flexibility and lower cost.

This is a hypothesis, it can be used for doing a ERP type of system or even a single web page. It does not matter.

My question is not whether it is a illusion since i have achieved clean separation, but will there be a benefit if this hypothesis can be implemented.

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?

Sorry 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.

Charles Simonyi (the guy that caused us all to use Hungarian Notation in the 90s) seems to think it's a big deal:

http://www.intentsoft.com/

Martin Fowler on the subject: http://martinfowler.com/bliki/IntentionalSoftware.html

And a wikipedia entry on the concept: http://en.wikipedia.org/wiki/Intentional_programming

It's certainly an interesting approach, but there will always be edge cases... How will you handle them?

From my research in Software Factory/Domain Specific Languages/Frameworks i crystalized certain rules for assembly and the funny thing is it is simple and not domain specific and should be implementable in any language.

Rule 1 - Define a context - Give it a name Rule 2 - Add Components into that context Rule 3 - Configure those Components in that context Rule 4 - Link those Components in that context

If i create a assembly framework which understand the above 4 simple rules, i should be able to assemble components into applications thereby separating assembly from coding.

Assembling components implicitly gives meaning (domain) functionality to an application where the components may be generic or specific and can be rewired to give different meaning.

The edge cases will be that the components are very specific for a very narrow functional area which is like a single large component. Even in these case, no component is standalone and can provide all the functionality, even specific components will need to link to generic components to provide all the desired funtionality.

To prove to myself this is possible is why I created my website www.arshu.com using an assembled approach. If you visit my site and move the cursor to the top right hand site [red mark] of a page, i will tell you how many components this page uses, how many properties is being set and how many links i am creating.

Thanks for the links

Your "Holy Grail" is what Fred Brooks called a "Silver Bullet":

http://en.wikipedia.org/wiki/No_Silver_Bullet

I have seen this before and this is what i have tried to solve. Cannot today say i am successfully but I can see some light.

As Fred Brooks noted Software has to be Organically grown through Incremental development.

Currently this leads to most software becoming a Ball of Mud through continuous change/fixes.

It is allready well established that loose coupling between components will lead to better systems, then it means that no coupling will also lead to better but useless systems since a single component may not have all the features required.

If I can take the coupling and abstract it out from the component, then i should be able to build a framework which uses a meta data of coupling to create useful functionality from zero coupled components.

This way i can grow the complexity of the component organically and replace components.

This is what I have achieved using my experimental rudimentary framework by taking a simple domain as a web page, but hoping to extend it for building a new contract job work which involves building our own simple document management system/simple workflow management system for the Architecture firm.

My question is why is tough? sorry for being Naive.

Then how

Reply on news.ycombinator.com