The Silent Majority: Why Visual Basic 6 Still Thrives
msdn.microsoft.com
msdn.microsoft.com
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.
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 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.
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 :)
Terminal scraping is "universal" (it is language agnostic; it's much easier to get a system emulator working perfectly than multiple compilers/language environments).
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
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_(); }[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!]
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.
It's works better than expected. You avoid the costs and risks of re-writing the application and re-training your personnel.
The false dichotomy is the idea that you can have either well engineered and powerful systems that are complex and difficult to program, or you can have poorly engineered, simple systems that are easy to program.
There is a conflict here which is a little bit like the inherent opposition of technology and business (most people aren't aware of this issue either, of course, but that's a whole other comment for people to dismiss). The tools which make software development easier and more efficient, both for experienced professionals as well as for beginners, also make software development more accessible, reduce the amount of traditional programming being done and therefore mean it requires less programming skill to accomplish the same thing.
This means that as new, more powerful programming tools appear, you can actually be fairly sure that the programmers who have only used those tools have less experience than programmers who use older, less powerful tools. Even worse, since everyone knows the tools are easier to use, there is a social dynamic and pressure warning programmers off of them: its basically cheating.
Many programmers are still acting like calligraphers in an area where the printing press has just recently been introduced. What self-respecting calligrapher uses a machine to print text? Its not even calligraphy.
I had to stop using Visual Basic anything just because I knew people would judge me as being a lesser programmer if I took advantage of the easier and more productive tool.
Peer pressure, pretty much at the level of 12-year-olds, is the main thing holding back deployment and advancement of technology in all aspects of our 'society'.
Peer pressure is certainly not zero - but hackers are pragmatists. If the tool really was easier and made a coder more productive, they'd be making money with it and that would be its reputation right there. The thing you call "cheating" is celebrated and encouraged. Better tools improve the whole community.
>>> "I had to stop using Visual Basic anything just because I knew people would judge me as being a lesser programmer if I took advantage of the easier and more productive tool."
This says far, far more about you than about the people around you.
Not necessarily. In my MS past I also had to defend my VB.Net experience in interviews, being perceived as a low-threshold toy language. And peer pressure matters in your network: how much reach-out would you get, as self described VB wizard or a SQL master?
Fashion rules, as PL topics on HN show regularly. A PL survey [1] was linked from an article some hours ago; it shows interesting answers: just compare the language list of "I know many people who use this language" to "I would use this language on my resumee"
That said, of course you are right: If you stay out of the fashion circuit and produce some value with tools you know, then nothing else matters...
[1] http://www.eecs.berkeley.edu/~lmeyerov/projects/socioplt/viz...
Are you sure about that? On HN it's very easy to find an attitude in the comments and article selection that if you even use C#, you're just an enterprise boiler plate programmer that sucks. The "Leaving .NET" stories typically easily make the front page.
In fact this article made it twice on HN:
http://news.ycombinator.com/item?id=1719277 http://news.ycombinator.com/item?id=2005867
http://news.ycombinator.com/item?id=2370022
And another ~100 articles and thousand comments which I don't have the time to link.
You should go read some of these articles and comments.
Sites like StackOverflow, Newegg, Plentyoffish show that many of these commenters are wrong, but each to their own biases.
I wanted to build GUI apps and wasn't fond of all the C/C++ books I could get my hands on just having console mode apps. People always find it funny that I started writing VB6 code and with every step, always seemed to move down the stack, to writing kernel mode code at one point - people usually move in the other direction.
The non-MSFT world underestimates the power of VB6 (as they do Delphi) - you could build some really complex apps and by calling Win32 APIs you could do a lot of what pure Win32/MFC got you.
MSFT completely messed up the move to .NET and fundamentally misunderstood what the VB6 devs wanted. I saw them try and correct this for many years internally but it never really worked. VB6 could have become PHP if Microsoft had played their cards correctly.
You could create a form in 30 seconds, drag a couple of buttons onto it, and start sticking code behind them.
It was _incredibly_ easy to go from nothing to an app that did something useful and was easy to use.
(I haven't kept up with .NET desktop development, but in the 1.1-era, MS Office stuff was painful.)
XAML or WinForms still rock.
It was a learning process for all of us :)
Sencha architect is trying to do some of the same things as well.
And like Access or VB6 it's great while you colour inside the lines. You can use it to smash together small LOB CRUB apps together in hours, even minutes for the smallest ones.
VB6 is also quite fast, all things considered, and runs on lots of fairly old hardware.
Don't get me wrong, I'd never choose to use it, but for those who use it day to day it offers overall simplicity and flexibility that few mainstream languages can match.
Not the famous Ruby language though, it came years later ;)
Of course, you can put side effects anywhere, and in most VB code it seems that a big ball of global variables is the dominant paradigm.
A small example: in the VB6 debugger, when you hit a breakpoint, you can drag the program counter/execution point around willy-nilly in the method, while changing the code around. No hotswapping, no dropping call frames, no hitting refresh in a browser. Just change the code, drag the PC up a few lines, and step back over it. Amazing.
I mean, you can kinda do it in java (drop frames, add conditional expressions, etc.) but in VB... It just works.
Credit where credit is due.
Somewhat misleading, as the .NET framework is still supported and will run older binaries.
We just pulled one of our apps up to .Net 4.0 and it took about 5 minutes. Not a small one either: 350kloc.
Maybe we will stop the PHP hate as well and move on to a new language to kick around.
Of course, there were a lot of good things about the VB environment, and Microsoft could have straightened-out the syntax without throwing the baby out with the bathwater. But the strategy was to legacy the whole heap of VB/COM/etc.
IMO VB.net offers almost everything that VB6 has plus extra features of .net libraries. It can also do project conversion from VB to vb.net (upto extent) but as fellow commenters have mentioned there's cost of jumping from VB to VB.NET based windows app. Therefore VB6 will continue to thrive until corporation justify that cost.
"I also disagree that it is not believable that the vast majority of programmers have been boneheaded for 40 years."
http://paulgraham.com/icadmore.html
The "success" of a language is determined by what the language can do, not what programmers manage to do with it.
It is entirely possible there is a language that exists that can do more and do it faster than any other language in existence, but "most programmers", the ones who make a language "popular", either don't know about it or don't want to learn it.
...and the maintainer of the Vim syntax highlighting module for Bourne Shell scripts still refuses to default to POSIX mode, because some OSs still ship with a pre-POSIX /bin/sh. grumble grumble grumble
As a dumb example, if a language fails at its stated goals, then that's not successful. Another dumb example might be a language which tries to incorporate FP patterns but implements lambda syntax or semantics quite poorly.
Unfortunately people conflate success and merit. Maybe that's not so bad. What's worse is when they often go a step further and assume anything that is not successful by this metric is lousy. Hackers look at other forms of success, though, include things like clarity/expressivity or, perhaps more generally, programmer productivity/happiness.
Java or VB6 are examples where merit is orthogonal to success--- disproportionately so, let's say--- so I'm not sure it's hard to admit, as you suggest. :) It may be hard to accept though! People will choose stuff without thinking much about it because it's the default and popular and therefore it can't be lousy. This might not be so bad if hackers didn't occasionally have to interact with lousy tech chosen by other people...
This is part of why pg's blub programming piece[1] appeals to me so much. Living far outside the mainstream comes with its own perils, but being able to do handily stuff other people can can barely grasp can be a competitive advantage.
Some things i remember about VB6: 50kb binary with a GUI that ran on anything from 95 through 7. Trying to modernise the UI even in the XP era (getting fast images in menu items without owner-drawing the whole thing, getting the default windows font on form controls, vbAccelerator controls, finding the right-looking tab control..). OCX deployment. Manually adding manifests for comctl6. IDE plugins to make DLL and console-mode projects that worked by relinking the compiled binary. Jumping through hoops to handle events for an array of objects. Using CopyMemory() to copy a pointer to a UDT. Not being able to get the AddressOf a class method without some assembly. No threads. Edit & continue becoming unsafe when subclassing your form window without some third-party dll.
I love this line because it implies that you can actually become a good VB6 programmer. Sure, you may not be able to sort a linked list, but you can still learn about encapsulation and ... actually, just start with encapsulation; that's going to make your code SO much easier to read :-)
Regardless of which of those meanings were intended, I disagree. I find denying any of the three to be dismissive and just plain wrong. I should be clear: I hate VB6. I really do. But I'd stop far short of the arrogant suggestion that it's not possible to do good work in it, or that it's not possible to learn an enormous amount about what it takes to make great software while writing it.
I started off in VBA hacking recorded macros. I would then write hundreds of lines of code into a single function (usually named "DoSomething" or something equally vague) and then I would live and die by the VBA debugger, tweaking the function when it broke. Over time, I learned the value of encapsulation and how much easier it was to debug my code if used smaller, well-named, functions.
When I started a different job and ended up doing a lot of VB6 programming, I ended up reading a lot of others' code. I would stare at functions that were literally 1000+ lines of code an painfully difficult to debug. The purpose of the VB6 code was to print barcoded shipping labels in a specified format, but the ZPL print instructions were heavily mixed with business logic. It was a nasty mess. The single greatest thing that would have helped me would have been encapsulation. Even if the developer hadn't separated the business logic from the ZPL code (which would have been very nice), small, well-named functions would have made the program so much easier to follow.
The reason I mention encapsulation specifically is because of how much you gain as a developer. If you learn nothing more than basic encapsulation as a VBA/VB6 developer, you'll do wonders for the readability and maintainability of your code.
I have done more than my fair share of VB programming from version 2 when it was new up until 98 or so. I even got my MCP certification on VB3... It was the quickest tool to build a Windows application at the time.
In fact, at least here in Brazil, the rise of Windows as a corporate OS coincides with a rapid adoption of VB for in-company development and the fall of Clipper under DOS. I saw it first hand because it happened while I was helping write a huge console-based app in Dataflex. The app is still used by more than a hundred municipalities in Brazil and I learned the master thesis of a colleague was about automatically porting it to something more modern (the project more or less failed).
There's plenty of "VB Gods" around then. I suspect many C/C++ programmers one way or another found themselves working in a business that had VB as the shop standard? I know I did. I wrote good solid, readable, maintainable, stable code, including DLLs and OCXs - they're nothing special. Some of the projects I did are _still_ in use 10 years later at one location.
Was VB my tool of choice? Certainly not, but it was what I was required to use, with few exceptions. A good craftsman can succeed with an inferior tool. Just watch - The well crafted VB apps will have a half life similar to COBOL.
Also true of at least one place in the USA. A few thousand Macs went into the dumpster so they could roll-out shiny new VB client-server applications to replace terminal stuff. (Ironically, they were rolling out Netscape 1.1 at the same time.)
I'd contrast this with languages that enforce a certain style or paradigm in an effort to improve reliability: Erlang, Haskell, Prolog, F#, Smalltalk (to a point). All fine languages but none have quite caught the imagination of the mass of developers.
Microsoft just dropped the ball by making it too hard to upgrade to VB.Net. For some projects, you could port to a different language for the same effort.
a really great piece of work.