|
For maintenance some have to, but I don't think that people use it to write complete new apps these days.
Behind every great black man...
... is the police. - Conspiracy brother
Blog[^]
|
|
|
|
|
Bob Stanneveld wrote:
For maintenance some have to, but I don't think that people use it to write complete new apps these days.
I have to use/support VC++ 6 as it's the lowest version we intend to support for our products. There're too many devs out there that continue to use VC++ 6.
|
|
|
|
|
Nishant Sivakumar wrote:
I have to use/support VC++ 6 as it's the lowest version we intend to support for our products. There're too many devs out there that continue to use VC++ 6.
Here at the company where I do my internship, they still use VC6 to develop embedded systems. I wouldn't call the code that they write legacy code from the beginning.
A definition of legacy code could be:
Legacy code is code that is used in a project, but was first developed in (originally written) in a previous project.
Behind every great black man...
... is the police. - Conspiracy brother
Blog[^]
|
|
|
|
|
Bob Stanneveld wrote:
A definition of legacy code could be:
Legacy code is code that is used in a project, but was first developed in (originally written) in a previous project.
Sounds clear enough. 
|
|
|
|
|
I was using VC++ 1.52 just over a year ago!
Kevin
|
|
|
|
|
I was using it two weeks ago to check that the project I'm porting still rebuilt correctly for the original platform.
The project is porting a customer's software from Symbol's Series 3000 DOS terminals to new Windows CE-based Symbol MC3000 hardware. We still support Series 3000 hardware with our thin client software (for which I'm primary maintainer); new hardware is still being manufactured in some ranges (by which I mean new devices, not new designs).
It's a bit weird to be learning how to program for DOS in 2005!
The server side of that system is mostly VB6 with a bit of C++ here and there. We're still using VC6 too, at least partly so we're only shipping one version of the C runtime and MFC.
Stability. What an interesting concept. -- Chris Maunder
|
|
|
|
|
I was actually doing 16-bit MFC. This was part of a contract assignment. At the same site I also used VC++ 6 and 7.0, plus ASP and VB .NET/ASP.NET. So, quite a bit of variety!
I actually used the VC6 IDE to edit my VC 1.5 code, so I could get all the IntelliSense and other features of the IDE. Then I'd switch to VC 1.5 for the compile.
Kevin
|
|
|
|
|
You would be wrong. I still use VC6 every day. A large portion of what I do is building back-end systems to produce web-enabled presentations for reports, analysis, raw data, etc. I am still building new applications with VC6. I have a huge investment in C++ libraries (written by me and others) and some will not compile under VC.NET. I am slowly moving to VC.NET, but I will still be using C++ for the bulk of my work. I can't even imagine using C# or VB.NET for some of the stuff I have to build. I love ASP.NET for web front-ends, but for back end systems, C++ still is the best IMHO. As far as I know, for programming win32, non-mfc, non-gui C++, there are relatively few benefits to VC.NET.
However, I am not building shrink-wrapped applications which may be what you mean.
|
|
|
|
|
I wasn't talking there about C++ and VC6, but about building new apps with COBOL, Fortran, etc.. I write all my code in C++ using the beta of VC2005 and I can't imagine me moving to C# or whatever .NET language anytime soon...
Behind every great black man...
... is the police. - Conspiracy brother
Blog[^]
|
|
|
|
|
Same here... I use VS .NET to develop C++ applications using frameworks other then those developed by Microsoft. The truth is I am not taking full advantage of the .NET capibilities in any way.
|
|
|
|
|
If I'm not mistaken, VC++ 6 is a compiler not a language... So technically if you wrote something in C and compiled it with VC++ 6, what are the chances that it will compile with VC++ 18? As long as you don't have some #pragma in the code specific to VC++ 6 and perhaps unless the command line options change, you probably don't even have to change a makefile to get it to work!
Of course, there may be some incompatibilities which need to be ported here and there (especially when using a poorly portable langauge, I won't mention any names) but in general it should just work... So I don't see how you would judge legacy by the compiler used to build a binary but rather the coding methods, algorithms and implementation of the design (what APIs are being used, etc.).
As an example, using a single threaded implementation to get around an issue that a specific OS that doesn't support threading; however the OS does now support threading in the latest releases.
The other definition would simply be "code that was written before the current project" even if it was last month. Last month was a seperate project and it's already been released. Since it pre-exists your current code, it could technically be referred to as legacy.
8bc7c0ec02c0e404c0cc0680f7018827ebee
|
|
|
|
|
Despite my pleas, we still end up creating solutions using legacy code. Why we start a new project in ASP 3 is beyond me, but it still happens from time to time. It's partly because not everyone on the team is C# and ASP.NET ready. I was a fairly early adopter and I'm cringing as I see them begin to dabble in ASP.NET for the first time right as Whidbey is about to be released. 
|
|
|
|
|
I'm in the same boat but I actually prefer projects in the legacy code to the new stuff. It was better thought out, planned and written. Some of the code hasn't been changed since 1995 and it still works. It has been structured in a way that is easy to modify and easy to maintain.
State machines - they're really simple compared to the complex algorithms that needn't be complex. The 'kids' nowadays aren't taught state machines so the coding is unduly complex. One of them couldn't believe how simple the coding became when I showed him how to do it with a state machine. Legacy methods are great if someone bothers teaching them to the youngsters.
A lot of the C# stuff is coded on screen with very little planning. It is a nightmare to maintain even though it is less than 2 years old. There are no programming standards and you spend a quarter of the time battling with Visual Studio.
Legacy stuff loads up in 15 seconds. Non legacy stuff takes almost 5 minutes! For minor mods, it takes 30s to rebuild legacy stuff and almost 10-15 minutes to rebuild non-legacy. I'm sticking to legacy for now.
|
|
|
|
|
I have to admit that I'm one of those 'kids' you speak of. I'm working hard to more about the design principles that will help me write more maintainable code.
For us youngsters, have you got any favorite URLs that will help us with, for instance, state machines?
|
|
|
|
|
cup wrote:
Some of the code hasn't been changed since 1995 and it still works
Maybe that could be rewritten as "Some of the code hasn't been changed since 1995 and that's why it still works"
I see dead pixels
Yes, even I am blogging now!
|
|
|
|
|
Behind every great black man...
... is the police. - Conspiracy brother
Blog[^]
|
|
|
|
|
I have written legacy (forth and C) code as well as new software using .NET. My experiance has been that language and age of code (or the programmer ) don't matter. Design, quality control, and coding style (i.e. readability) are the important factors.
As far as coding style is concerned, people must realize that code was meant to be read by people. If we wanted code to be dense and efficient, we would write in hex. So don't do something like this...
if((c=getchar())!='\n')
...and if you do, COMMENT COMMENT COMMENT!!!!!!!!! 
-SHaroz
|
|
|
|
|
Recently I was involved in a new project launch with legacy developers in charge The lead "architect" insisted the only dependable tool is ....  .... VC++6. He informed the project sponsor "it is quicker than learning new technolgies". I feel your pain and distress....
|
|
|
|
|
I selected "more than 80%", but it is very close to 100%. I maintain:
- A 15 years old machine translation library: old-style C++
- Applications that go with above-mentioned library: MFC
- A couple of years old terminology extraction library: modern C++ with lots of Boost and STL (I love this one )
- An overdesigned and bloated CAT application (C#)
- A machine translation web farm, or what's left of it (mostly C++)
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
Anyone who selected less than 80% isn't a real programmer. 
|
|
|
|
|
NO, most likely they are doing new work in .net. My answer would have been 90% before .net came along, now we are re-writing every app in .net, down the road my answer will flip to supporting legacy code again. It's the cycle of things, any "real programmer" who spends 80% of their time supporting legacy code forever isn't really a programmer, more of a caretaker.
"A preoccupation with the next world pretty clearly signals an inability to cope credibly with this one."
|
|
|
|
|
CP Visitor wrote:
Anyone who selected less than 80% isn't a real programmer.
I suggest the opposite! Everyone who selected more than 80% has bad luck or isn't a good enough programmer to do new code.
Behind every great black man...
... is the police. - Conspiracy brother
Blog[^]
|
|
|
|
|
Isn't there a point in the lifecycle where you should say: "Ok, it's bugfree or i'ts dead...". You can't support your old creations forever. This would stop you from beginning something new and better.
WM.
What about weapons of mass-construction?
|
|
|
|
|
True, but some companies have one or more main products that they keep upgrading. These companies would have to maintain the code for every major change they make.
Behind every great black man...
... is the police. - Conspiracy brother
Blog[^]
|
|
|
|
|
I selected "I don't touch legacy code" because, in my current job, I am the first developer they've had. There was no legacy code. I guess if I go back and update any of my projects, I'm working on legacy code.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
