New ways of development
-
Hi, I always wondered why even the newest age development tools (like Visual C++) are still stuck with the old way of placing code into .h and .cpp files. Maybe ten years ago this technique was the only way of reusing code, but now it slows you down very much. I believe that giving up .h and .cpp files and instead keeping code in some kind of database would give you tremendous advantage. VC++ 6 keeps such a database to provide its edit & continue and incremental linking features. Some of these advantages would be: - Class view, edit&continue, incremental linking and compiling - Much more powerfull wizards; excellent manipulation of code: grouping by functionality, hiding private implementation and so on - code can be stored already preprocessed or even already compiled. This reduces the final compilation time dramatically - automatic generation and reverse engineering from/to a visual modeler. - it can even generate .cpp and .h files to compile them with a popular compiler like VC++. My vision of a future IDE is that of a visual UML modeler (component diagrams, activity diagrams and so on) that stores classes properties and methods together with the implementation code. What do you think?
-
Hi, I always wondered why even the newest age development tools (like Visual C++) are still stuck with the old way of placing code into .h and .cpp files. Maybe ten years ago this technique was the only way of reusing code, but now it slows you down very much. I believe that giving up .h and .cpp files and instead keeping code in some kind of database would give you tremendous advantage. VC++ 6 keeps such a database to provide its edit & continue and incremental linking features. Some of these advantages would be: - Class view, edit&continue, incremental linking and compiling - Much more powerfull wizards; excellent manipulation of code: grouping by functionality, hiding private implementation and so on - code can be stored already preprocessed or even already compiled. This reduces the final compilation time dramatically - automatic generation and reverse engineering from/to a visual modeler. - it can even generate .cpp and .h files to compile them with a popular compiler like VC++. My vision of a future IDE is that of a visual UML modeler (component diagrams, activity diagrams and so on) that stores classes properties and methods together with the implementation code. What do you think?
Actually, this has been tried several times before. Almost every product i've seen do this has failed in the marketplace. Most users want their code in some neutral format. They like using external editors, or running the code through 3rd party programs like Lint. And what happens if your software breaks (say an upgrade to the OS), users can no longer get at their code. Then we get into issues of cross platform compatibility. Your tool would have to exist on every platform that compiles code. Only 10% of the developer population would probably use any of these features, but most people like the security of having plain old text for their hard developed intellectual property. (Not to mention binary databases make it difficult to Diff changes and other sorts of operations).
-
Actually, this has been tried several times before. Almost every product i've seen do this has failed in the marketplace. Most users want their code in some neutral format. They like using external editors, or running the code through 3rd party programs like Lint. And what happens if your software breaks (say an upgrade to the OS), users can no longer get at their code. Then we get into issues of cross platform compatibility. Your tool would have to exist on every platform that compiles code. Only 10% of the developer population would probably use any of these features, but most people like the security of having plain old text for their hard developed intellectual property. (Not to mention binary databases make it difficult to Diff changes and other sorts of operations).
So you raised several problems: 1. Need code in plain text format. This is solved easily, because I already said we can build a tool that generates .cpp files so you can compile them with an existing compiler. 2. Software breaks. This should not be a problem if the tool that generates .cpp files is an external tool that works standalone (a simple .exe file). 3. Cross platform compatibility. This comes with time. If the tool is good, it will become popular. 4. Most people won't use it. I believe most people are beginners, and such a tool will hide most of the sintax workarounds and give them a better view over their application. 5. Difficult to Diff changes. It will be much easier to see the differences, at the module, component and even function level. The ideea is to see code more like a class diagram view rather than a text file. If you worked with a MSDOS compiler before switching to VC++ (where you have the most primitive class view and this makes your life a lot easier) you should know what I mean. It will be a lot easier to see the class dependencies, so it will be easier to extract components from your app and reuse them later. The more I think of it the more I feel that the plain text source code is obsolete. I begin to wonder if I could write such a tool that uses VC++'s compiler. It will be some kind of a plugin...
-
So you raised several problems: 1. Need code in plain text format. This is solved easily, because I already said we can build a tool that generates .cpp files so you can compile them with an existing compiler. 2. Software breaks. This should not be a problem if the tool that generates .cpp files is an external tool that works standalone (a simple .exe file). 3. Cross platform compatibility. This comes with time. If the tool is good, it will become popular. 4. Most people won't use it. I believe most people are beginners, and such a tool will hide most of the sintax workarounds and give them a better view over their application. 5. Difficult to Diff changes. It will be much easier to see the differences, at the module, component and even function level. The ideea is to see code more like a class diagram view rather than a text file. If you worked with a MSDOS compiler before switching to VC++ (where you have the most primitive class view and this makes your life a lot easier) you should know what I mean. It will be a lot easier to see the class dependencies, so it will be easier to extract components from your app and reuse them later. The more I think of it the more I feel that the plain text source code is obsolete. I begin to wonder if I could write such a tool that uses VC++'s compiler. It will be some kind of a plugin...
You aren't really listening. All you're doing is making up excuses for why your idea is cool. I'll say it again. This has been done before. Dozens of times on dozens of platforms. Every product that did this failed. Now, there could be any number of reasons for those failures, but you damn well better learn from history or you're going to repeat it. You're making a lot of assumptions: 1) People WANT to see their code in class diagrams. I don't think that's necessarily true. Class diagrams only show object structure, they don't show program flow. Object diagrams show message interaction, but do not show procedural code (of which everything always breaks down to). Source code is the lowest common denominator. Users simply don't want to be translating their code back and forth all the time. 2: You're assuming that beginning users will be able to understand class diagrams. UML is most definately not something which a user can pick up right away. And they have to have a good foundation in OO concepts and programming to make use of it. 3: You're assuming that UML is 'enough'. It's not. And you're forgetting that C++ is a superset of C, which has no representation in class or object diagrams.
-
You aren't really listening. All you're doing is making up excuses for why your idea is cool. I'll say it again. This has been done before. Dozens of times on dozens of platforms. Every product that did this failed. Now, there could be any number of reasons for those failures, but you damn well better learn from history or you're going to repeat it. You're making a lot of assumptions: 1) People WANT to see their code in class diagrams. I don't think that's necessarily true. Class diagrams only show object structure, they don't show program flow. Object diagrams show message interaction, but do not show procedural code (of which everything always breaks down to). Source code is the lowest common denominator. Users simply don't want to be translating their code back and forth all the time. 2: You're assuming that beginning users will be able to understand class diagrams. UML is most definately not something which a user can pick up right away. And they have to have a good foundation in OO concepts and programming to make use of it. 3: You're assuming that UML is 'enough'. It's not. And you're forgetting that C++ is a superset of C, which has no representation in class or object diagrams.
What if all the code were stored as XML? 1) Easy platform independence. 2) IDE / User could select and edit using the desired views (class diagrams, object diagrams, .c,.h format, etc.) all generated from the XML 'core' data. Each 'view' could be like a separate XSL file that processes the given XML source. This could make for some very effective code documentation without having to totally separate the documentation from the source code. 3) Text based format (even if it isn't 'plain' text). 4) Excellent search and wizard potential. 5) Excellent diff potential. 6) Include simple and robust utilities (both standalone and in the IDE) for converting back and forth between XML and .c/.h in case of 'emergencies' or the need to run through 3rd party editors and utilities. *** I suspect that meaningful .c/.h -> XML conversion could get tricky without some sort of comment cues. Just thinking out loud.
-
What if all the code were stored as XML? 1) Easy platform independence. 2) IDE / User could select and edit using the desired views (class diagrams, object diagrams, .c,.h format, etc.) all generated from the XML 'core' data. Each 'view' could be like a separate XSL file that processes the given XML source. This could make for some very effective code documentation without having to totally separate the documentation from the source code. 3) Text based format (even if it isn't 'plain' text). 4) Excellent search and wizard potential. 5) Excellent diff potential. 6) Include simple and robust utilities (both standalone and in the IDE) for converting back and forth between XML and .c/.h in case of 'emergencies' or the need to run through 3rd party editors and utilities. *** I suspect that meaningful .c/.h -> XML conversion could get tricky without some sort of comment cues. Just thinking out loud.
If we were REALLY ambitious, we could imagine a VERY well defined schema-like entity for the XML code such that the XML would itself be a sort of platform independent / language independent bytecode (a la .NET) with identifier names and comments included. Then, there could be separate XSL-like entities that could compile the bytecode into native machine code for different platforms. Also, separate XSL-like entities could render the bytecode in the user's language of choice. It would then require a sort of 'inverse-XSL' to take the user's edits and put them back into the XML source byte code. ...Just thinking out louder.
-
If we were REALLY ambitious, we could imagine a VERY well defined schema-like entity for the XML code such that the XML would itself be a sort of platform independent / language independent bytecode (a la .NET) with identifier names and comments included. Then, there could be separate XSL-like entities that could compile the bytecode into native machine code for different platforms. Also, separate XSL-like entities could render the bytecode in the user's language of choice. It would then require a sort of 'inverse-XSL' to take the user's edits and put them back into the XML source byte code. ...Just thinking out louder.
I think the problem would be that the XML would add a lot of overhead. Either you put all your code in a single entity (say one for each function) or you have an entity for each line or each statement. That could add many times more "code" to the already existing code. Although it would make commenting a little easier I think ;)