Re: [Flightgear-devel] C++ for Simulation
One more "job hat" response: good that you have tests. Without tests, change will always be scary. It doesn't have to be. Yes, they take time to write, perhaps more time than the code itself, but the alternative is even worse. Tests are an executable specification. As for the move from C to C++... depends on what kind of future you envisage for the system. The managerial persepctive is often quite short-term, but good system can live for decades. /JanM 2010/9/17 Jon S. Berndt : > I should mention that the code in question is being rewritten, anyhow - and > we have a good set of regression tests already. > > Jon > > > -Original Message- > From: Christian Mayer > Sent: Friday, September 17, 2010 12:48 PM > To: FlightGear developers discussions > Subject: Re: [Flightgear-devel] C++ for Simulation > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Jon S. Berndt schrieb: >> If cost is an issue (isn't it always?), is it worth >> it to expend the resources to clean up code that may have been gathering >> flotsam and jetsam for years - particularly if you want to add some new >> features (base on new requirements), anyhow? > > I'm sure you know the "never change a running system". This is IMHO > responsible for the many old fashioned Fortan stuff that's still used > today (although modern C++ would give better performance, etc. pp.) > > On the other hand at my day job the embedded software development team > next to me does change languages (from hand coded C to ASCET to > TargetLink to Simulink Embedded Coder) - but that's a slow process and > only parts that need a redesign are affected. The parts that need only > minor additions will stay in the same language unless there's a big need to > -- > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novell-sfdev2dev > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] C++ for Simulation
I should mention that the code in question is being rewritten, anyhow - and we have a good set of regression tests already. Jon -Original Message- From: Christian Mayer Sent: Friday, September 17, 2010 12:48 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] C++ for Simulation -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jon S. Berndt schrieb: > If cost is an issue (isn't it always?), is it worth > it to expend the resources to clean up code that may have been gathering > flotsam and jetsam for years - particularly if you want to add some new > features (base on new requirements), anyhow? I'm sure you know the "never change a running system". This is IMHO responsible for the many old fashioned Fortan stuff that's still used today (although modern C++ would give better performance, etc. pp.) On the other hand at my day job the embedded software development team next to me does change languages (from hand coded C to ASCET to TargetLink to Simulink Embedded Coder) - but that's a slow process and only parts that need a redesign are affected. The parts that need only minor additions will stay in the same language unless there's a big need to -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] C++ for Simulation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jon S. Berndt schrieb: > If cost is an issue (isn't it always?), is it worth > it to expend the resources to clean up code that may have been gathering > flotsam and jetsam for years - particularly if you want to add some new > features (base on new requirements), anyhow? I'm sure you know the "never change a running system". This is IMHO responsible for the many old fashioned Fortan stuff that's still used today (although modern C++ would give better performance, etc. pp.) On the other hand at my day job the embedded software development team next to me does change languages (from hand coded C to ASCET to TargetLink to Simulink Embedded Coder) - but that's a slow process and only parts that need a redesign are affected. The parts that need only minor additions will stay in the same language unless there's a big need to. So what would I do in your case (except that I don't know it ;): Stay with the C code, write unit tests that cover the interface of the C modules (anyway a good idea) and then switch to C++ module by module when that module needs a major change. Use the unit tests to make sure the C++ behaves the same as the C. Sometime inbetween you might change from C with C++ moduled over to the C++ with C modules (what I guess would be the major benefit by that language change). CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEAREIAAYFAkyTqdwACgkQoWM1JLkHou3aZACgjP4tIAno2/KyuNMSUXdksd9I HNAAn2+FhLzf7mTaM+swWH+0Ubu5BnDx =eBIT -END PGP SIGNATURE- -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] C++ for Simulation
On 17 Sep 2010, at 11:09, Stuart Buchanan wrote: > The project was also a lot larger than it looked at first glance, > particularly the amount of time required to create a good regression suite. >> From memory, I think we spent significantly more time creating the regression > suite than we did actually coding. Wearing my day-job hat, I can only echo everything Stuart said - unless the old code is very bad, or you already have good regression coverage for it, you will expend considerable effort for little outward (revenue-generating) gain. On the other hard, I have done 're-architectures' where an old design (in C/C++) was totoally replaced with a new one (in pure C++) - that was mostly successful, but took a long time (multiple years), and with understanding that the old design could not possibly deliver on a wide range of areas that would be important for the business. All the comments about regressions still apply - and in the end, some of those areas weren't as business critical as they appeared - but the new code still had to deliver 100% parity with the old. 80:20 rule applies - you can easily get to 80% parity (in features) with the old code - that last 20% that'll kill you. There's a reason the banks emulate VMS running COBOL rather than re-writing in C++ :) James -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] C++ for Simulation
On Fri, Sep 17, 2010 at 4:26 AM, Jon S. Berndt wrote: > Guys, I've got a question that's come up in my day job. I'd like to ask for > your opinion. If you had to justify to your boss the rewrite of old C code > in C++, could you do it? If cost is an issue (isn't it always?), is it worth > it to expend the resources to clean up code that may have been gathering > flotsam and jetsam for years - particularly if you want to add some new > features (base on new requirements), anyhow? In my limited experience, unless you're going to be re-writing large amounts of the code anyway, and have a very clear specification for the existing component, I don't think it's justifiable. My day job is as a manager of a software development team, and I'd be very sceptical of anyone proposing to do so without very strong arguments and some extremely thorough testing planned. Cleaning up cruft is good, but there's a high risk that you clean up too much or remove some oddity that someone is relying on. I have been involved in one re-write from C to Java, which was forced due to very strong external requirements. The C code was old and didn't have a clear specification, and the main requirement for the development was to duplicate the existing external behaviour. We built a new suite of automated regression so we would have some idea of how the Java code measured up. This was good as far as it went, but really wasn't sufficient, and we had a higher than normal defect rate as a result. The project was also a lot larger than it looked at first glance, particularly the amount of time required to create a good regression suite. >From memory, I think we spent significantly more time creating the regression suite than we did actually coding. -Stuart -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] C++ for Simulation
Guys, I've got a question that's come up in my day job. I'd like to ask for your opinion. If you had to justify to your boss the rewrite of old C code in C++, could you do it? If cost is an issue (isn't it always?), is it worth it to expend the resources to clean up code that may have been gathering flotsam and jetsam for years - particularly if you want to add some new features (base on new requirements), anyhow? Jon -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
