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.
This brings up a very prevalent false dichotomy and some interesting psychological issues that are holding back software development.
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'.
I argue that Silicon Valley startup culture's existence and profitability disproves the point you're attempting to make here. Haven't we all read pg's "Beating the Averages"? Haven't we all heard a hundred startup founders say "I used the tool that was closest to hand, and customers didn't care what I used as long as my service met their needs"? Haven't we all seen the companies with printing presses handily beating the calligraphers both in the Iron Age assembler-versus-C contest and the modern contest of web startups with FOSS stacks beating companies burdened with compiled languages and expensive licenses?
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.
>>> 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...
>This says far, far more about you than about the people around you.
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.
I have a soft spot for VB6 - I learnt to code using VB6 back in school. I had loads of fun building these simple apps that I then distributed to my friends. The highlight was when a magazine (PCQuest? Digit?) distributed one of my apps on their CDs. Ah, those were the days.
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.
Same here, Visual Basic 6 was my entry point into programming. I had lots of fun coding and was able to learn a lot. Then they brought out VB.NET. It just seemed distant and bloated from VB6. After so many years of not touching VB6, it is interesting to know that windows still supports it.
Ms never misunderstood anything. Their goal just was another one. "people love it? Great, take all away and include a bit of that in the ultimate pro product tier. The rest will be available in an add on"
To that I would add 1) various database glue allowing drag-n-drop bindings, 2) Incredibly good MS Office integration (or anything COM), and 3) Huge library of third-party components
(I haven't kept up with .NET desktop development, but in the 1.1-era, MS Office stuff was painful.)
I agree wholeheartedly. Almost all of the abstractions in WebForms are leaky, and the think that it's abstracting... HTML, isn't so complex that it benefits from being abstracted.
When I explain ApEx I usually describe it as "Access, for Oracle, but with web pages".
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.
You can take a look at RealStudio. The Web Edition is in the early versions and is still a little rough around the edges though their Mac/Windows desktop development environments are much better and have been around for many years.
It wasn't always that easy. Integrating Office apps prior to the introduction of VSTO was ugly and fraught with incompatible types. Especially if you were using a language other than VB.NET, which generally meant a whole lot of Type.Missing argument entries in every other line of code in addition to creating marginally machine-to-machine compatible COM interop wrappers. Getting beyond the "Works on My Machine" certification wasn't always an easy thing in VS 2003/Framework 1.x.
I never had much of a problem to be honest and I built some behemoths which involved ASP.Net, .Net CF, remoting and all sorts of other junk in the same app.
There are a lot of not-programmers who thrived doing just this, and some of them are still around, getting programming jobs based off of that experience that doesn't translate at all to modern frameworks.
For those who have never used it, VB6 syntax is actually very similar to Ruby. It uses English language words instead of braces, does not require parentheses, and uses dynamic typing.
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.
VB has a nice separation between procedures and functions, too. I actually like that they are declared and called differently to highlight where side effects can be expected and where a result is expected.
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.
Every time I type 'end' in Ruby I think of VB. Like Python better as a scripting language though. However, Ruby is a bit like VB in that it inspired many to get into programming for the web like VB did for desktop/office apps. http://tssblog.blogs.techtarget.com/2007/10/30/is-ruby-the-n... VB was a stepping stone in the path when desktop ruled and everyone had windows and office before mobile. Now it is EOL.
The VB6 development environment from the late 90's is still better in some ways than my current development environment (IntelliJ+(JVM|ruby|javascript)).
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.
There's some changes[1] you can't make in Edit and Continue without a full restart. This has bitten me a bit with NancyFx, as all of your routes are defined as lambdas (thus can't edit anything live).
IIRC, Edit and Continue in Visual Studio products (I believe it was there in VC++ as well as VB when it was first introduced) was a feature in at least one Lisp version (maybe Franz Lisp or another popular commercial Lisp product at the time) - before it was introduced in VS. I remember this because I had been trying out either or both of those Lisps at the time, and soon after that, I read about the Edit and Continue feature in the next-released VS product. I think I emailed about it to a friend at the time.
"Visual Basic 6 first shipped in 1998, so its apps will have at least 24 years of supported lifetime. Contrast that with the Microsoft .NET Framework 1.0 (2002), which is incompatible with Windows 7 (2009)."
Somewhat misleading, as the .NET framework is still supported and will run older binaries.
I think its kind of funny that Visual Basic doesn't inspire the kind of hatred that it once did. Now PHP has taken its place. Reading through the comments there seems to be a level of fond remembrance going on. In the past, if you used VB 6 or lesser, you were not seen as a real programmer.
Maybe we will stop the PHP hate as well and move on to a new language to kick around.
People have forgotten all the terrible language warts all over VB. (From what little I can recall, the hatred is slowly seething back upward.) PHP might lack any sense of style but it's nowhere near as bad as VB.
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.
I started with VB6 Back in 2000. It was easy to pickup as my first programming language was gwbasic/qbasic. I really loved event driven development, IDE and easy Compile and run procedure.
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.
Hackers who love to learn the latest and use the best often seem to be angered by this kind of thing. But isn’t its continued existence evidence of its success? Maybe it’s just hard to admit that a language’s success doesn’t depend solely on its quality.
Mind you, while I think this definition of success is fair, it is fairly specific. The implication is that success means "widespread adoption." That is a property which correlates with properties of the language or technology, but they are not inherently related, IMO.
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.
I think that's exactly what annoys people--that language "success" is not dependent on quality. It's particularly annoying because a lot of people assume a language is well designed just because it is popular.
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.
It's not limited to MS either. Running "cc" on a modern linux box still accepts 35+ year old K&R code by default. The bourne shell has been officially standardized since POSIX 25 years ago, and as a practical matter has been backwards compatible much longer than that. Xlib code from 1987 still runs unmodified...
Yeah, and I don’t actually believe in backward compatibility when it comes to programming languages. If you want forward compatibility, make a good cross compiler from n to n + 1. If you want backward compatibility, make one from n + 1 to n, if it’s reasonable.
The bourne shell has been officially standardized since POSIX 25 years ago...
...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
I’m not sure what you mean. First, do you define linguistic success using anything other than entrenchment? We say a (natural) language is “dead” when no one speaks it anymore. Second, I was saying that the quality (that is, power) of a language is not the only factor in its success.
Setting aside the fact that I think entrenchment is a reasonable definition of success, I imagine most hackers don't judge a technology's success based solely on that metric.
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.
That’s true. But most languages fail at their stated goals to a certain extent, usually by finding an unanticipated niche in which they thrive. What a language is good for is often something you discover, not something you design.
I spent a lot of time writing VB6... it took many years to get to the same level of just being able to sit down and make something with C++, but i'm happier being on more solid foundations now. I do have some fond memories of it but i don't miss the syntax (feels like a cross between Python and Excel).
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.
"Becoming a good Visual Basic 6 programmer took much less time than becoming a good C++ programmer."
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 :-)
You either mean that it implies that you can become a good programmer while writing VB6, or that you can become someone good at writing VB6 programs, or that you can become someone who writes VB6 programs that are good.
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.
Sorry if my comments were confusing. I intended no sarcasm nor arrogance.
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.
That's probably because a good VB6 programmer would still be a terrible C++ programmer. There are too many ideas VB programmers will never encounter. In order to be a good C++ programmer you'd be a VB god (rolling out your own DLLs and OCXs).
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).
> the rise of Windows as a corporate OS coincides with a rapid adoption of VB for in-company development
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.)
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.
Most of the languages that have caught the public's imagination support and don't actively discourage developers writing really horrible code but then provide the facilities for people to use as they get better. Python, Ruby, PHP (especially), VB, JavaScript and C++ all come to mind in this regard.
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.
Funny that so many posts here are in the past tense. I still write brand new VB6 code every other day and I suspect that there are many thousands like me that have a large and old codebase that needs to be extended because the users keep asking for new features (and couldn't care less about how it is done).
VB6 is a nice prototyping/quick app language. It's not suited for every job but you can optimize around many weaknesses and it complemented early ASP projects well.
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.
I've been trying to find a way to put in proper words why PHP is still this big in webdev and this article just gave me the explanation I was looking for all this time.
I learned to program in c, then one time when i had this project to work in VB6, i am really impressived by how easy it is to put something on the screen. syntax check is very useful for beginners. and the UI is clean, no unnecessary parts. vb6 community loves sharing code and it is very easy to use other people's code too. no compiler hell to deal with.
I do wish the silent majority would shut up occasionally. You hear them on the telly all the time, and read about them in print. Going on and on and on about how no-one ever hears them or allows them any airtime.
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.