This seems like the thread to confess that I still spend a lot of time developing in VB6, it's open on my screen right now. I do a lot of custom back-end corporate applications and still actively support many I did back in the 90's. One is a tailored project tracking system that manages one of the largest telecoms in North America, client/server, 350 users all day long. It just runs. At the time VB6 was the best way to get them out and if you were careful it was perfectly solid. Fast forward 15 years and here we are, these applications still exist, and until they clear budgets to re-develop them in something more modern, they will continue to be updated.
Now don't get me wrong, everything new is all web based product, but these older apps keep running and we keep updating them. Until they _need_ to be replaced entirely, well, there just isn't a business case for the expense. No doubt it'll happen... I've been mentally preparing clients for years... but most of them dodged expense of a .NET rewrite and will move right into Web apps when that day comes.
> Until they _need_ to be replaced entirely, well, there just isn't a business case for the expense. No doubt it'll happen...
Ask those maintaining COBOL applications inherited straight from the 70s :) There are even people selling toolkits to convert 5250/3270 applications to web apps through "terminal scraping" (uuugh). No doubt in 20 years we'll have some equivalent windows+VB monstrosity :)
If you run into anyone still doing scaping, you might suggest Microfocus COBOL. It's a lot less painful to recompile for x86 and .NET than it is to deal with terminal scraping.
But that only solves the COBOL aspect. There's are many cases in which assembly, FORTRAN and who-knows-what-else is involved.
Terminal scraping is "universal" (it is language agnostic; it's much easier to get a system emulator working perfectly than multiple compilers/language environments).
FORTRAN isn't scary. C was designed to be compatible with FORTRAN so it just works in most situations. Most people don't realize that if you declare variables non-extern without a value in different compilation units, they actually have "common" linkage to be compatible with FORTRAN "common" memory.
a.c: int a;
$ cc -c -o a.o a.c; nm a.o
0000000000000004 C _a <-- "common"
a.c: int a = 1;
$ cc -c -o a.o a.c; nm a.o
0000000100001040 D _a
FORTRAN functions can be called from and call into C or C++ (extern "C"'d) without any issue. Simplified example:
foo.f:SUBROUTINE FOO
foo.f:CHARACTER*80 LINE
foo.f:INTEGER*4 NUM
foo.f:CALL BAR(LINE, NUM)
foo.f:END
bar.c:void bar_(const char *line, int *num, int len) {
bar.c: /* implicit length for string arguments, values as pointers */
bar.c:}
foo.f:SUBROUTINE FOO
foo.f:END
bar.c:extern void foo_(void);
bar.c:void bar(void) { foo_(); }
Fortran isn't scary, but porting a system from one architecture to another, when that system includes Fortran, Assembly, Cobol and other parts IS scary, which makes emulation (and terminal scraping) a robust solution, and recompilation/porting an expensive one.
[And Fortran does have scary aspects: from the 25 year old hacker's test: "Did you ever change the value of 4? In a language other than Fortran?" - numeric literals in fortran aren't constant!]
I haven't seen many cross-platform issues with FORTRAN. (If you redefine 4 on any platform, it will be bad.) IMO, C is much more time consuming to port to a different platform due to system headers and inevitably different system APIs. POSIX helps, but certain parts of the system aren't covered by POSIX and so you wind up with #ifdef platform support where new support needs to be added.
> I haven't seen many cross-platform issues with FORTRAN.
Most fortran floating around is cross-platform fortran, and that is quite easy to port. However, legacy systems are usually very much platform dependent. I was once hired to port something in Fortran from a System 3090 (or was it 390? That would be more than 20 years ago now) to an SGI workstation, and it took several weeks of full time work.
And you're ignoring the subject under discussion: Porting a working system comprised of multiple parts in multiple languages (COBOL, Fortran, ASM, REXX, ....) is a much harder than the sum of porting individual programs - which is why emulation + terminal scraping is the cheaper, more robust solution.
One problem is that cobol is not that standard many uses proprietary extensions for cics and xml and all sorts of stuff that may not be available on the microfocus platform.
"Visual Basic 6 did what its creators intended for its market niche: enable very rapid development of limited programs by programmers of lesser experience. It was never meant for heavy-duty coders developing complex applications."
This pretty much sums up my experience with legacy VB6 code. I've re-written a fairly large system that was entirely in VB6 and some of the code I encountered there was astoundingly bad.
I do agree that the low entry point in VB did raise the percentage of bad code due to inexperienced coders. This ultimately damaged its rep as many experienced what you have. In turn a hammer also has a low entry point for use, but I can't blame it when I make a mess driving a nail. A good developer could do good things with it (and very very quickly), but unless you had learned and worked in other languages, VB itself wouldn't push you into proper practices. And that was a problem.
Could one argue that a good developer could do good things, but they would then be at the stage where they could realise the same thing could be done better in another language of their choosing?
I only say this because the story is pretty analogous to PHP's. And I'm not saying that to bitch about the language; it's just the way it's gone.
You're very correct, it depends what tools are available. For Win apps in the late 90's there wasn't much that touched some of VB's qualities... reasonable performance, full API access, rapid turn around, good dev environment. For custom software rapid turn around is a huge factor. Delphi was another option but we weren't a Pascal shop. Most of our Win apps then were VB6 sitting on top of home grown C++ DLLs as needed. And you're right, it's very analogous to PHP.
Now don't get me wrong, everything new is all web based product, but these older apps keep running and we keep updating them. Until they _need_ to be replaced entirely, well, there just isn't a business case for the expense. No doubt it'll happen... I've been mentally preparing clients for years... but most of them dodged expense of a .NET rewrite and will move right into Web apps when that day comes.