4 ms·

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 corpo

• j-b 14y ago
  "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.
  • 51Cards 14y ago
    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.
    • FuzzyDunlop 14y ago
      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.
      • 51Cards 14y ago
        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.
• wazoox 14y ago
  > 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 :)
  • Spearchucker 14y ago
    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.
    • beagle3 14y ago
      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).
      • apaprocki 14y ago
        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_(); }