Microsoft Urged to Open Source Classic Visual Basic (i-programmer.info)

"On the 25th anniversary of classic Visual Basic, return it to its programmers..." reads the plea at UserVoice.com from Sue Gee -- drawing 85 upvotes. "The new Microsoft claims to back open source, why not in this case? There is no need for Microsoft to do any more work on the code base - simply open source it and allow the community to keep it alive."

In an essay at i-programmer.info, Gee shares a video of young Bill Gates building an app with Visual Basic in 1991, and complains that in the 25 years since Microsoft has open sourced .NET Core and the .NET Compiler Platform Roslyn, "but it has explicitly refused to open source VB6." She notes that Friday Visual Basic's program manager announced a "Visual Basic Silver Anniversary Celebratiathon," promising he's reaching out to the VB team members from the last 25 years for a behind-the-scenes retrospective, and adding "this is a party, so feel free to be interactive."

"What the post glosses over is that this history was blighted by the fork in the road that was .NET and that many Visual Basic fans are highly unsatisfied that the programming environment they cherished is lost to them..." writes Gee. "Vote for the proposal not because you want to use VB6 or that you think it is worth having -- Vote for it because a company like Microsoft should not take a language away from its users."

Comments

ummm.no.

[lord merlin]

Let it die. It's a terrible language and it should die a death. don't open source it or you'll just encourage a new wave of cheapskate programmers to start learning bad habits and producing crappy code.

Re:ummm.no.

[__aaclcg7560]

These are the same people who use IE6 for their intranet applications.

Re:ummm.no.

[jfdavis668]

God yes. I hated debugging long complicated mathematical calculations that returned "Q" under certain circumstances.

Re:ummm.no.

[U2xhc2hkb3QgU3Vja3M]

You never watched ST:TNG?

When something strange happens, it's always Q.

Re:ummm.no.

[scdeimos]

You never watched ST:TNG?

When something strange happens, it's always Q.

Or "the boy" Crusher zapping people away in warp bubbles and other such nonsense.

Re:ummm.no.

[Anonymous Coward]

"People" aren't passionate about VB6. Businesses who don't want to get their production code out of the 20th century, and they're out there, are passionate about VB6.

Re:ummm.no.

[rakslice]

Aren't these people or their successors busy doing the same thing already today in Ruby or Python or JavaScript? At least in VB6 you have the _possibility_ of declaring a variable type.

Re:ummm.no.

[Billly Gates]

Let it die. It's a terrible language and it should die a death. don't open source it or you'll just encourage a new wave of cheapskate programmers to start learning bad habits and producing crappy code.

I sooo agree man they shouldn't open it! Hold on let me finish this JavaScript project I am working on ....

Re:ummm.no.

[ArhcAngel]

Actually I think Mclaren is working on an upgrade for their F1 support PC and were hoping to use VB6.

Re: ummm.no.

[Anonymous Coward]

Or alternatively, encourage another generation of coders to blame their shit code on the language and not their lack of skill.

Re:ummm.no.

[hairyfeet]

Wow...elitist much? There is absolutely nothing wrong with VB6, just because you have seen sloppy VB code don't mean shit as I can go over to stack overflow and find examples of shitty code in any of the new hip languages that you like.

VB6 is great for one REALLY specific job, which just happens to be a job that small to medium businesses require quite often, which is "make a quick and simply GUI to a DB" and it does that job very very well. In fact I've never seen anything else that could whip off a GUI to a DB as easily or as quickly as VB.

So instead of being elitist why not just except that every language has a place and it serves NO purpose to not open up the code, or are you just against open source in general? Because frankly I find it quite shocking that so many here would actually be against opening the source to ANY code that is now proprietary,what happened to /. being a big pro FOSS site? I really can't picture someone asking RMS if VB should be released under say the GPL he would go "Naw fuck that shit man, some things shouldn't be given to the people!" can you?

Re:ummm.no.

[Sperbels]

What is with all the hate towards JavaScript and Python, especially JavaScript?

One could say the same thing about VB6. I discovered many years ago programmers are rather irrational and dogmatic about computer languages. Many of them are just repeating what others have said and don't have good explanations for believing the things they do.

Re:ummm.no.

[TheRaven64]

I have actually seen well-written VB6 code. Once. But it worked as an existence proof. It's actually quite a bit easier to write good VB6 code than it was in earlier versions of the language. Most of the VB hate comes from the fact that it was so easy to use that it attracted a load of really bad programmers. These days, most of those folks have moved on to Python.

Re:ummm.no.

[SuperDre]

Sorry, the language itself isn't bad, I've seen far worse code being done in (VB/C#,F#,whatever).NET or C(++), just like I have seen good code in both..
VB6 isn't the problem.. The mentality of people who think the language they use is much better, is even worse..
Yes you can write crap code in VB6, but you can write crap code in any language..
To be honest, I think the syntax of VB6 is one of the best/clean syntax around, BUT the compiler and lack of real OO certainly isn't (but as stories goes, VB7 was already feature ready (which did include real OO) but was canceled at the last moment because they wanted to push .NET).
I do think opensourcing VB6 (or rather the internal available VB7) would be a good thing, but I also think people should only use it for 'legacy' applications and not start a new big project using it, especially because everything is moving to 'the cloud' (whatever that exactly means)..

Re:ummm.no.

[silentcoder]

>A discarded napkin?

Personally I find discarded TP to have a higher throughput but that may be limited to MySQL post-Oracle.

Re:ummm.no.

[silentcoder]

>These days, most of those folks have moved on to Python.

Somehow I doubt that. The people who mostly used VB were not *just* looking for an easy language, they were looking for an easy language to write Windows GUI apps in. Python is decidedly difficult to do GUI work in as you need to learn a GUI library, and there is no common standard [well there's tikinter but nobody actually uses that and with good reason]. So you could use QT which works on all platforms but unless you want to GPL your code that costs a pretty penny, or GTK - and each time you're fighting with a library designed for a different language and badly integrated. Ubuntu had some project to try and make easy python GUI programs with but that only ran on Ubuntu desktops so... meh.
There is WX which is a wonderfully lovely library to code with - and has one of the most horrifying build and dependency chains I have ever had the horror of dealing with. KiVY has some of the ugliest interfaces I've ever coded to, tough it does have the advantage of being portable to the extent that you can write python apps for android with it (though in theory you could also do that with QT).

Of course, of all the platforms python runs on - the one it is *hardest* to write a GUI app for is Windows. If you want multiplatform you'll have to bundle your chosen library. Coding directly to the Win API in python is .... weakly supported at best, the runtime environment isn't present in general and in fact, it's so badly supported that most python devs who DO want to ship something for windows end up using a compiler that builds their entire application as well as the python interpreter into a self-contained EXE just to spare their users the horror of trying to install dependencies where every concept of a package manager is a badly designed bolt-on like NPM.

Simply put... for all it's wonders (I love python), it's a terrible fit if your goal is to write windows GUI programs. The language per se may be fine for it, but the support structures to make that easy simply does not exist. I suspect most former VB coders (and the people who followed in their footsteps) are coding in C# actually. That's the easy language to write a windows app in today, and if you're a diligent and disciplined coder you could even make it run in Linux with Mono. Not that many people do, mono isn't even installed by default by any distros I know about anymore (though most still include the open-source Java), but it at least exists and it did lead to things like the Unity engine being cross-platform.

Re:ummm.no.

[silentcoder]

On this point... whatever happened to BOA Constructor ? I guess RAD never really appealed to the python crowd since it seems to have died a quiet death.

Re: ummm.no.

[dunkelfalke]

Delphi can do everything VB6 can, but much better.

Re:ummm.no.

[segedunum]

It is not going to die I'm afraid. There are still countless applications written in it that will simply never be rewritten. Microsoft lost the backwards compatibility religion some time ago, as Joel Spolsky pointed out over ten years ago. People who say "Let it die" have absolutely no idea what is written in it, and what they actually depend on themselves if they've never even written a line of VB.

Re:ummm.no.

[segedunum]

"People" aren't passionate about VB6. Businesses who don't want to get their production code out of the 20th century, and they're out there, are passionate about VB6.

Look at COBOL. People do not rewrite their business applications just because you happen to think they should, nor will they spend money on developing a new application......that does exactly the same thing. Sorry, but that's not how the real world works.

Re:ummm.no.

[Big Hairy Ian]

Much as I hate all things VB there's still a lot of VB6 legacy code out there not to mention all the VBA. If they open source it perhaps it will breath life into all that code. Also if it's open sourced and maintained by passionate programmers perhaps it will cleanly evolve over time into something people actually like to use.

Re:ummm.no.

[DarkOx]

Nonsense, I can build a quick CRUD application in Ruby/RAILS just as a fast as anything could ever be built in VB5/6. It would be just as usable too.

With additional advantages of you don't need to figure out how to when you are going to update it on the desktops of the 20 users at that SMB where they certainly don't have any kind of standard image or patch/deployment management for the desktops. Nope much much easier to run one instance on some little department server they already have.

Second Advantage, single application interacting with the database rather than multiple clients each with their own connection. A perfectly average programmer will be able to manage concurrency and multiple changes in a shared environment that way. There was a lot of opportunity to get it wrong or do it badly with multiple fat clients all talking to the same DB.

Re:ummm.no.

[segedunum]

BUT the compiler and lack of real OO certainly isn't..

Everybody, including me, thought full OO in VB would be a good thing. As it turns out, it wasn't. All you really asked of VB was for it to handle memory management and keep all of the complex bits of OO away from you and leave that to C# or something. What they should have done was built VB.Net as a development environment on top of .Net, with backwards compatibility, so you could at least take existing code and recompile it with perhaps some small modifications.

Re:ummm.no.

[daid303]

It's fine. But it's not that there is nothing wrong with.

Simple example. Arrays start at 0, or 1, depending on where you found it.

Re:ummm.no.

[Dcnjoe60]

Let it die. It's a terrible language and it should die a death. don't open source it or you'll just encourage a new wave of cheapskate programmers to start learning bad habits and producing crappy code.

And what's the problem with that? After all, one can create crappy code with any language, Programming languages are simply a tool and a tool in the hands of craftsman can do wonderful things. Instead, without VB6, people have gone on to use VBA in MS Access and Excel. Cheapskate programmers, as you call them, will use whatever is available, even if it isn't the right tool for the job. However, it isn't your's or mine or Microsoft's responsibility to protect people from themselves.

So, what is the harm is it is released open-source? Either there is a market for it and people will use it or there isn't and it will die off. After all, the whole point of open source is about freedom. Why argue to limit it?

Re:ummm.no.

[Dcnjoe60]

"People" aren't passionate about VB6. Businesses who don't want to get their production code out of the 20th century, and they're out there, are passionate about VB6.

Or COBOL or FORTRAN or any other list of vertical applications. Business will run a piece of heavy equipment for decades because 1) it's costly to replace and 2) it still gets the job done. Why should software applications be any different? End-user software systems are the epitome of supply and demand. If the cost to upgrade is low enough, people will upgrade. If not, they won't. That's how a free market works.

Re:ummm.no.

[NotInHere]

These ones? http://saveie6.com/

Re:ummm.no.

[LWATCDR]

"VB6 is great for one REALLY specific job, which just happens to be a job that small to medium businesses require quite often, which is "make a quick and simply GUI to a DB" and it does that job very very well. In fact I've never seen anything else that could whip off a GUI to a DB as easily or as quickly as VB."
Might I suggest Java? It is also multi-platform.

You are correct in that VB was good for that very common task. Today they all seem to want to use a web interface but you know sometimes I do not want to have to set up a webserver and a database server. If you want to keep track of your record collection or books and do not want to have to use the internet and or setup a server then VB or java with a simple database like the access engine or sqllite can be a good solution.

Re:ummm.no.

[ripvlan]

Yes and... as a once-upon-a-time-ago VB6 programmer at a business I had lobbied to go C++. But the business decided that VB6 was easy and they didn't want to have highly trained people - VB6 was an easier uplift. Yes VB6 was simple but it got the job done. And yes it should be put to pasture.

However, I'm interested in open-source because many of those old corp products are stuck in VB6 for a variety of reasons. It is "too hard" to port to .NET/Java and when you have 1+ million lines of code "easy" goes a long way. If we had access to the parser or compiler modifications might be made to help ease the migration. Better COM support by the compiler (stop changing the interface UID on each recompile). Who knows the possibilities.

So I while don't want "a few more years" - being able to add/cleanup a few features to make migrating (wrapping) a few last components would be nice.

but yeah - no new VB6 code. Maybe that's the first PR --- can't create new projects only compile old ones :-)

Re:ummm.no.

[Billly Gates]

Go write something besides a cute short VB client/server app and you will see problems? It is very odd and different from C style languages. It is not object oriented but object based with cutsey drag and drops. Need a few thousand functions? WOW, where do you begin.

VB is this.button1 add code here. this.button2 add other code here.

Doesn't work when you need to engineer and not put together a simple script with some gui components which is what VB really is.

Re:ummm.no.

[chr1st1anSoldier]

Jeebus, why stop there? Let's just break out Netscape Communicator 4 or hell, let just go with the granddaddy of them all, mosiac.

Re:ummm.no.

[tehlinux]

You never watched Xena: Warrior Princess?

Whenever you notice something like that, a wizard did it.

Re:ummm.no.

[Grishnakh]

So you could use QT which works on all platforms but unless you want to GPL your code that costs a pretty penny

Then GPL your code. It's stupid not to.

If your whole goal is to create software in-house, for in-house use only, there's no reason not to use GPL. Its only requirement is that you provide source code to anyone that you provide the binaries to. If you're only providing the binaries to yourself, then you only have to provide the source code to yourself. Is that really such a problem?

Re: ummm.no.

[Tablizer]

I'd argue Delphi has a longer learning curve. You are probably more productive once you master Delphi, but there is a trade-off in the ramp-up time.

Note the Lazarus project is more or less an OSS Delphi clone. Haven't used it myself and thus won't comment on it compared to Delphi in terms of quality or learning curve.

Re:ummm.no.

[allquixotic]

I use telnet as my web browser, you insensitive clod!

Re: ummm.no.

[dunkelfalke]

Hm, probably depends on what one used to learn. My first language was Turbo Pascal, so Delphi was quite natural for me, far easier than any Basic dialect.

Re:ummm.no.

[Dogers]

But then you're into the utter hell of trying to get RoR working on a webserver, plus getting a new database server installed.

VB6 just needs a folder copying about, pointing at either an Access database (lordy, no) or a MSSQL/Express server, which an SMB likely already has running somewhere..

Re:ummm.no.

[shutdown -p now]

Given that VB would happily try to implicitly convert pretty much everything to everything in any context where it was even remotely plausible, those type declarations didn't do as much good as one would expect.

Re: ummm.no.

[shutdown -p now]

I used both for their stated purpose (RAD, aka quickly duck-tape a bunch of shit together) back when they were popular, and knew a few people who used either.

The learning curve was actually pretty similar for both. Pascal is a more rigid language, but it's also more regular, and so easier to pick up. It also had more verbiage (e.g. you had to explicitly connect handlers to events, whereas in VB it would be implicit based on handler name), but the visual designers took care of all that stuff for you.

On the other hand, once you ventured into more advanced stuff - e.g. anything requiring working directly with Win32 API - Delphi was hands down better. It also had a full-fledged class and object system, unlike VB (which had classes, but no inheritance - only interfaces). Basically, it had way more room to grow into.

Overall, though, the popularity of either depended largely on geography - some markets had VB dominate (e.g. US), others had Delphi dominate (e.g. Europe and Russia). Once there was a critical mass established in either, everyone else just stuck to it as a de facto standard.

Re: ummm.no.

[silentcoder]

I GPL everything I write. But I was thinkking of typical windows devs not speaking for myself. Many of them (amd their bosses) are quite anti-GPL.

Re:ummm.no.

[filesiteguy]

...actually it is valid for quick prototyping. Though client/server is very old-school (not as old as cobol) at least for a quick-and-dirty app, it can work.

I would love to see it become OSS and then have it running under the radar like IBM sort of did with eComStation.

Of course, being a PHB, i don't actually do any programming any more, so I have no stake in this. All our stuff is either Java or C# these days.

Re:ummm.no.

[thewolfkin]

I use telnet as my web browser, you insensitive clod!

all your base are belong to Lynx

Re:ummm.no.

[Pikoro]

MS Access!

Re:ummm.no.

[fafalone]

I'm a "people". I'm very passionate about VB6. And I only work with it as a hobby, it's unrelated to my job. Here the thing: For standard Windows GUI-focused apps, there's nothing better. VB.NET might as well be something entirely different and basic tasks are far more complex. VB is still relevant not only because of the business case, but because there's all the benefits it originally had and it's still capably of making modern apps.
The power of VB6 is always understated. People think of ugly, old GUIs but it also lets you make GUIs with the latest Common Controls version and also lets you access all the modern shell features. There's plenty of room to be passionate about a language where all basic functionality is fast and easy, yet it provides virtually no upper limit to how complex you can get if you need to: I don't use the Win3.1-ish drive list and dropdown, I use the introduced-in-Vista IFileDialog. Why heck, VB6 will even allow you to use in-line assembly if you need to. Multi-threading? An actively developing frontier, just in the past year making true multithreaded apps has been made much easier.
Modernizing VB6 is in fact my biggest programming passion. There's a special joy that certainly inspires passion in bringing all the shell goodies that have been introduced in XP, Vista, 7, etc into a language from the 90s. My latest project was making the full suite of Core Audio (introduced in Vista) interfaces usable in VB6. Other people have brought in long-missing support for modern alpha-blended graphics/icons.
Have a look see on a site like vbforums.com, there's huge amounts of passion from real people, and huge amounts of quality code. The applications being made today can't even be visually distinguished from VB.NET.

Re:ummm.no.

[fafalone]

These days, most of those folks have moved on to Python.

And the flip side of that is many of the people still coding in VB6 write excellent code. Most samples being posted today have full sanity checks and error handling, are very easy to follow, support Unicode, have documentation and commenting... just what do you think makes 'good code' that VB6 programmers aren't generally doing these days? Sure there's still lots of people very new to it and writing terrible code (lots of new users coming from non-english speaking countries actually)... but I have a hard time believing good code is as rare as you're making it out to be these days.

Re: ummm.no.

[Grishnakh]

Then they're idiots. The license is easy to understand, and if you're just writing your own in-house software that's never going to be sold outside the company (which is typical of in-house software; it's downright useless outside of the company that wrote it because it's too specialized for that company's business), there's no legal problems with just keeping it GPLed. Heck, you don't even have to keep the GPL notice on it; it's not like the police are going to raid the place and check for GPL compliance. The only time you have to deal with licensing issues with open-source or Free software is if you distribute. Inside your own organization doesn't count.

If some Windows devs and their bosses are too stupid to understand this, then they deserve to keep using VB on Windows XP no matter how much trouble that is.

Re: ummm.no.

[Dr_Barnowl]

You know you can stop the compiler changing IUUIDs by setting a compatibility component, no?

(And following the rules - if you change the interface, well yes, it wants to add new IUUIDs.)

And make it a separate file, not the default output path of the compiler, and check it into source control.

Re:ummm.no.

[MrDoh!]

Was in a company when the decision to go either the new Visual .net Basic or C# came up. Most of the coders wanted to stick to VB, even though the company was willing to shell out decent money for training for all of us. The ONLY way I got sense into them was saying "that'd be great, because if you look at the job sites, it looks like VB .net coders earn a lot less than C# coders, so we can get contractors at a far better rate to help us out with this big project" and even then I had to let it sit with a few of them for some time before they got it.

Re:ummm.no.

[ripvlan]

ah yes. That was a sneaky way to put that in front of them.

We came to the same question when (finally) switching from VB6 to .NET. By this time enough normal software engineers were on the job - so it wasn't a big discussion. But the answer that won for us was...most samples on the web are in C#. The industry has gone with C# and if we want to hire people in the future VB.NET probably won't be on as many resumes as C#. And C# looks a lot like Java - so lower retrain lift.

Therefore - for efficiency sake, it'll be faster/cheaper to find people who know C# and folks reading "the web" looking for help will find samples also in C#.

Re: ummm.no.

[ripvlan]

Yes - thanks for pointing that out. I didn't want to go into details, maybe I should have put a " * VB6 folks know otherwise." As you know that switch has to be turned off once in awhile (when making a breaking change to the interface -- or just sometimes VB6 wouldn't compile child projects for unknown reasons). But for our internal code a breaking change was a refactoring effort - so we dealt with it (this wasn't a public API).

Yes - the rules of COM say you need to redo the IUUIDS blah blah. Couldn't link DLLs together - so VB6 forces the rules of COM on to you. Then having to update the referenced projects....Another "arrgg I hate VB" frustration. VB6 as a core language was short and simple getting the job done. But these little things around the edges was very frustrating.

Another way we did it (esp for public interfaces) was to write the interface in IDL as a C++ project - compile (MIDL) it to a DLL. Then reference the project and "Implement" that interface. Nice thing was - if we wanted to break the rules of COM and redefine the interface - VB6 played along.

Re: ummm.no.

[MTBaldwin]

Am partial to webcrawler...lol

Re: ummm.no.

[Dr_Barnowl]

Never went as far as that C++ method but I did write a program specifically for building VB6 dependency sets that would go through and check all the type UUIDs (and intentionally break, build, read the new type library, and reset the UUID in all the dependent projects.

It was probably the worst thing about doing "enterprise" VB6 as you note...

Re:ummm.no.

[DES]

If your whole goal is to create software in-house, for in-house use only, there's no reason not to use GPL.

If you're writing software in-house, for in-house use only, there's no distribution, and no need to slap a license on it.

Re:ummm.no.

[Grishnakh]

Right, but if you're using GPL-licensed components, those do require you to follow the terms of the GPL. Now of course, if you're not distributing, then it really doesn't apply, but this simple fact doesn't seem to be understood at all within many companies. They just automatically discard it, much like Americans whenever they hear the word "socialism" (meanwhile, they scream if anyone touches their Social Security...).

Re:ummm.no.

[chochos]

Let it die. It's a terrible language and it should die a death. don't open source it or you'll just encourage a new wave of cheapskate programmers to start learning bad habits and producing crappy code.

Right. We already have PHP for that.

While we're at it...

[AmazingRuss]

... lets let smallpox out of those freezers.

Re:While we're at it...

[ColdWetDog]

At least smallpox doesn't always cause permanent brain damage.

Re:While we're at it...

[silentcoder]

>At least smallpox doesn't always cause permanent brain damage.

Some would argue that death is a form of permanent brain damage... though less severe than what VB causes.

Maybe it's a good thing

[Anonymous Coward]

All the .NET apps i've ever had to use (and install huge runtimes for) have been glorified VisualBasic applications.

VB DOS

[dosius]

I for one would like to see "Visual Basic 1.0 for MS-DOS" opened up.

Re:VB DOS

[Anonymous Coward]

The versions of BASIC that shipped with MS-DOS were "gwbasic" and later "qbasic", IIRC.

Re:VB DOS

[Anonymous Coward]

Thanks Grandpa for saying something irrelevant. Microsoft had two separate lines of non-free Basic compilers for DOS, QuickBasic and PDS. Microsoft shipped one last version which superceded both, called Visual Basic for DOS 1.0, in standard and professional editions.

Re:VB DOS

[Bing Tsher E]

I didn't know there was anybody else who has that. It's kind of fun.

Re:VB DOS

[johanw]

For that, we already have the source of Turbo Pascal, which is much more usefull (although not very adaptable being almost 100% inline assembler).

Re:VB DOS

[silentcoder]

I don't see how that's useful at all actually. We've had FreePascal for almost 20 years now, which is complete, has replacements for every signficant TP library and even a complete replacement for the Delphi libraries (with full comprehension of the ObjectPascal dialect) which has been used to implement Lazarus - a complete free Delphi replacement.

Now I have't coded with any of these things for well over 10 years but they do exist and frankly if you need them (for example to port an old TP or Delphi app to a new platform) they are right there for the downloading. They give you everything the TP source does, plus everything you would have gotten out of the Delphi source and a huge deal more (since FP can link to C libraries so you effectively have access to every shared library out there). Porting an old DOS program to Linux with that is ridiculously easy.

Re:VB DOS

[dosius]

VBDOS is a descendant of QuickBasic Extended 7.1, and QBasic is a nerfed version of QuickBasic 4.5. I'm well aware of the history of Microsoft BASIC on MS-DOS.

For the record, a buildable source tree to QBasic 1.1 is out there.

Re: VB DOS

[shutdown -p now]

He said "two lines", not "two versions". VB/DOS was the last version in both lines, merging the two.

Sorry For This Post

[fuo]

I Just Felt The Need To Make A Post With The First Letter Of Every Word Capitalized.

Re:Sorry For This Post

[segedunum]

Come on. We're on to camelCase now.

Re:Sorry For This Post

[shutdown -p now]

Not In VB, We'Re Not.

Should have done it a long time ago

[phantomfive]

If you're not going to maintain a platform, you should open-source it so people who care about it aren't abandoned without hope. I don't like VB but the way Microsoft dropped it was not good.

Re:Should have done it a long time ago

[Dutch Gun]

I can sort of understand why some companies aren't so eager to open source dead code. Open sourcing it means that anyone can look at the code and check to see if it used someone else's patented algorithm, or happened to use source from a non-permissive license which wasn't disclosed, or any number of other issues...

Legal issues tend to kill a lot of good ideas and intentions. MS is fine with open-sourcing their active concerns when it will help promote their own products, but I wouldn't hold my breath for something like this to ever happen. It would involve sticking their neck out (legally speaking) for no perceivable gains.

Some people predict that Windows will eventually go open source. My bet is that it will never happen simply for legal reasons.

Re:Should have done it a long time ago

[phantomfive]

Some people predict that Windows will eventually go open source.

Hmmmm. What could Microsoft possibly gain from that? Even hypothetically in the future, I can't see it.

Re:Should have done it a long time ago

[sad_]

they can hire some poor skilled soul to do that work for them.

Re:Should have done it a long time ago

[segedunum]

The already kind of are. We have Bash integration and a lot of integration for things like Rails. When they do that, and few are writing Windows applications any more, what is the point of Windows? The reason why is because they flushed the Windows API away and forced developers on to other alternatives. Getting rid of VB will be seen as a pivotal moment in Microsoft's history. Few moved on to .Net and the Windows API ceased to matter for anything new that was developed.

Re:Should have done it a long time ago

[bill_mcgonigle]

Ad revenue, increased Office sales, a very slight chance of making it in "the Cloud".

Re:Should have done it a long time ago

[phantomfive]

Hmmmm, what Joel says here definitely supports your point.

Re:Should have done it a long time ago

[phantomfive]

a very slight chance of making it in "the Cloud".

It's hard to believe but they are rocking in the cloud; the cloud and server division is the biggest revenue maker for Microsoft. Here are better numbers.

Here's how the cloud landscape is shaping up: AWS (and to a smaller degree Google's cloud) is getting popular among startup types, and people with deeper technical knowledge. IBM's cloud is getting popular among giant fortune 500 companies that don't care about technology and just want someone else to take care of it. Microsoft's cloud is gaining popularity among boring, mid-sized businesses who just want something easy (and who frankly, probably don't need a cloud). HP is dead in the water.

Re:Should have done it a long time ago

[iampiti]

Yeah, legal difficulties is one big reason Windows will never be open source but the real deal breaker are commercial reasons: Windows 10 has been designed to be a vehicle for data-gathering, publicity for Microsoft's sw and services including the Windows Store from which Ms stands to gain a lot of money.
If Windows were open source people could remove all of that (and create a sane Windows like 7) and obviously Ms won't allow that.

Sense of entitlement, anyone?

[BarbaraHudson]

Vote for it because a company like Microsoft should not take a language away from its users

If you bought a copy, you can still use it if you also bought a copy of the OS it ran on. Nobody is taking anything away from it's users. Same as I've got old copies of dBASEIV and dBASE5 that still work just fine, even though they aren't officially supported any more. I can even make redistributables with dBASE5 without a per-user-count limit.

Not that I would - it's as dead as VB - though of the two, VB is the more deserving of death.

Re:Sense of entitlement, anyone?

[FlyHelicopters]

without the possibility to patch and recompile the old environment for new hardware you are stuck with an impaired development tool.

Who is sitting on 15 year old code that has had no effort to keep it current made?

This is one of the problems, people leave stuff too long and then it becomes a monster job to move to something newer.

Imagine sticking around on Windows 3.1 for too long, until Windows XP came out. That isn't just a monster jump, that might as well be a brand new OS from a brand new company.

VB6 should have been left years ago, with plans and efforts in place to move to .net or something else long before today.

If you wait 15 years to move in the tech world, you're in for some pain. (yes, there are exceptions, but they are the exceptions that prove the rule)

Re:Sense of entitlement, anyone?

[TheRaven64]

If you wait 15 years to move in the tech world, you're in for some pain

The problem with this argument is that most of the companies that built systems with VB6 aren't in the tech world. They're in a host of other fields and used VB with some database (possible Access, hopefully SQL Server) for a load of custom workflow automation. They don't want to replace it after 5 years, because writing software is not part of their business and is just a cost centre. They'll replace computers when they become too slow for new software or physically break. They expect their computer systems to have the same reliability as their physical systems. VB was probably entirely the wrong tool for the job for many of these companies given those requirements, but it's too late now.

As for Windows 3.1, you might have missed it but one of the big reasons that 64-bit Windows took so long to reach mainstream was that it couldn't run Win16 programs. That killed it for a huge number of companies that had programs written for Windows 3.1 (or even 3.0) that they depended on and which still worked fine in 32-bit XP.

Re:Sense of entitlement, anyone?

[NJRoadfan]

LHArc compression tools were available on MS-DOS. id Software was quite fond of using it to compress their software.

Re:Sense of entitlement, anyone?

[segedunum]

Indeed. Even those who do have large tech departments, like large banks, used VB extensively for desktop apps and still have decades old COBOL code. Legacy stuff like COBOL, VB, JavaScript and other things don't disappear because some people have an idealistic notion that there is always money available for a migration project not to mention the inertia.

Re:Sense of entitlement, anyone?

[Eravnrekaree]

This isnt necessarily true. Sometimes, licensing can make software non transferable between computers. Some software might require online registration to work. Not that this is common but shows a possible problem. I would recommend staying away from proprietary software and instead building on open source solutions you have complete control over.

Re:Sense of entitlement, anyone?

[luis_a_espinal]

without the possibility to patch and recompile the old environment for new hardware you are stuck with an impaired development tool.

Who is sitting on 15 year old code that has had no effort to keep it current made?

A system or code base that can run for 15 years is something I would rather consider a success. I get and understand fully the need to keep things up to date, but more often than not all I see are upgrades just done for shits and giggles and a desire to pad one's resumes (and very little to do with valid business/technical requirements.)

Re:Sense of entitlement, anyone?

[FlyHelicopters]

The problem with this argument is that most of the companies that built systems with VB6 aren't in the tech world.

Ahh, that is their mistake... YES THEY ARE...

Everyone is in the tech world today, that is the viewpoint that has to change.

They're in a host of other fields

What, like moving dirt?

http://www.equipmentworld.com/...

Why Caterpillar's autonomous mining tech is "completely different from anything" itâ(TM)s ever done

Guess what... dirt movers are now in the tech business, and actually have been for awhile now.

They don't want to replace it after 5 years, because writing software is not part of their business and is just a cost centre.

Not wanting to, and needing to, are two different things.

Perhaps every 5 years is too often, but every 15+ years might not be often enough, it depends on the application.

If you're running desktop programs on a Windows PC that is connected to the Internet, then you need to keep that machine updated. It is simply not safe to run Windows XP on the Internet anymore. If your business can't handle bringing your technology up to date, then you have a business problem.

VB was probably entirely the wrong tool for the job for many of these companies given those requirements, but it's too late now.

You may be right about VB... but it isn't too late, money will fix this problem. As a business, you have to invest in your technology from time to time to keep it current. A little bit every year goes a long way to avoiding huge expenses all at once.

Re:Sense of entitlement, anyone?

[FlyHelicopters]

The irony is that COBOL is actually easier to use long term than VB is, given the systems that it runs on.

Windows 9x and Windows XP are not systems you want to be married to. One of the benefits of mini-computers and mainframes is that you are spared some of the headaches of running consumer desktop operating systems, abit at a higher up front cost.

If VB6 doesn't run on Windows 10, then you need to find a solution, because keeping your whole bank on Windows XP is simply not an option.

Whoever made that decision 15 years ago probably isn't even in the position to be fired for it anymore, but future decisions should not be made the same way, that's for sure.

Re:Sense of entitlement, anyone?

[FlyHelicopters]

I understand your point... too many upgrades too often is just churning money...

A ton of businesses skipped Vista and stayed on Windows XP. Which would have been fine, had Vista not been so delayed.

But then those same businesses delayed going to Windows 7, to the point where Windows 8 came out. But they didn't like 8, so many companies just finished their Windows 7 transition and don't want to move to Windows 10 just yet.

By the time they are ready, Windows 11 (or whatever) will be out.

Part of the pain here was the 6 years between XP and Vista, that is far longer than normal for MS and it is still something they are recovering from. The failure to make XP SP2 a "new OS" was their big mistake. SP2 was probably enough of a change to make it a new OS, slap a new shiny on the front, and offer cheap upgrades.

Vista wasn't actually that bad, once SP1 came out and some better hardware came out. Put Vista RTM on a Pentium 4 or even Pentium D and it sucks. Put Vista SP1 on a Core2Duo with 4GB of RAM and it is actually pretty good.

Re:Sense of entitlement, anyone?

[BarbaraHudson]

Fired it up a couple of years ago under linux using dosbox - uses 16 meg of ram just like the manuals (which I still have) said it would. Gotta love programs that just keep on working :-)

Re:Sense of entitlement, anyone?

[BarbaraHudson]

First, dBase/xBase is not a proprietary language. Hasn't been for decades (ask anyone who used Clipper).

Second, the original executables work just fine today under dosbox, and there's no reason not to expect them to.

Third, updated releases are still being made, though not by ashton-tate or borland. dBASE 10.3 can be had from dbase llc, and they work under Windows 64bit.

Re:Sense of entitlement, anyone?

[BarbaraHudson]

You don't "have complete control over open source solutions." Not unless you're ready to devote time going over the code yourself and understand what you're doing. And even then ...

Let it fade into memory

[LesFerg]

Let it become a fond memory for those who loved it, and forgotten by those that didn't.
We seriously don't need it. It was an interesting emulator of OO but not really OO, lacked a lot of features that are now-days built in such as a simple dictionary type, and required a lot of tedious coding which languages like C# have reduced and improved on.

I'm not a VB hater, I used it when my job required it, still have a legacy code base to support until we get round to replacing the old DLLs with some C# alternatives, and I feel that I have a fairly comprehensive knowledge of VB, but it is no longer pleasant or preferable to code in it.

Re:Let it fade into memory

[eWarz]

While I do disagree with the proposal in general, VB wasn't about OO, it was about "getting shit done". For the same reason that a lot of people did bat-shit insane stuff in excel, in VB you could whip out an app in record time compared to other languages and frameworks. Note that this niche has been filled, NOT by anything Microsoft or fan-made, but by none other than Ruby on Rails. The same reason why VB is popular (quickly and easily able to build apps while also having the ability to access the low level API) is also why RoR practically dominates Agile development and why companies continue to pay record breaking salaries to RoR developers today.

Re:Let it fade into memory

[Tablizer]

Those who complain often wanted to build their own framework or wrappers for sometimes legitimate reasons and sometimes because they just wanted to re-shape VB to fit their personal head model.

If you used it to simply build an app and move on, it was quick and easy to use (aside from DLL hell). If you wanted to reshape it or wrap it to resemble something else, its OO model was indeed limited.

For in-house programs from multi-hat IT people who wanted a quick learning curve, it was great. For a software house who wanted a streamlined framework to quicken aggregate productivity and could spend the training time for such a framework, it was indeed limited.

Delphi and Delphi clones may be a better choice for a mass-programming shop or department (per desktop software).

Re:Let it fade into memory

[shutdown -p now]

This is orthogonal to having it open sourced, though. No-one is using the original K&R C, for example, but its source has been released, and adds to that nostalgic value.

Heck, you can even find source for BCPL (actively maintained even!), and for various ancient Algol-60 implementations from back in the day.

If nothing else, that stuff has historical value.

They may not be able to open source it

[jonwil]

Its entirely possible classic VB contains code that Microsoft licensed from 3rd parties and is unable to open source.

Re:They may not be able to open source it

[Anonymous Coward]

Its entirely possible classic VB contains code that Microsoft stole from 3rd parties and is unable to open source.

Fixed that for ya.

You've watched Antitrust too many times.

Re:They may not be able to open source it

[Ailicec]

I vaguely remember discussion of some technical issue that was a big deal around the time of Win 3.0, that Alan Cooper solved in the Tripod prototypet.. Something like the "CX/DX register problem" (problem with calling conventions, DLL/OLE stuff maybe?). Might be interesting (ok, to a very, very small number of people) to see it. Maybe somebody else remembers the issue and can describe it better than me. Knowledge is much more widespread now, though, so whatever this was, its probably well known now if there's any value to it.

Re:They may not be able to open source it

[MightyMartian]

And not to mention that VBA still appears in a lot of places, so I imagine the libraries are at least in some level of maintenance.

Re:They may not be able to open source it

[m.alessandrini]

Or that they feel ashamed of how the code looks like.

Re:They may not be able to open source it

[jonwil]

Yeah that's the other problem for Microsoft in open sourcing VB. Even if its not using 3rd party code that Microsoft cant legally open source, its using all sorts of code shared with other components that Microsoft doesn't want to open source. The IDE and tools likely share a bunch of code with other things in Visual Studio. The compiler engine for VB (the native-code compiler specifically) is using the same C2 compiler back-end as Visual C++. Code in VB may also be shared with code in its office products (including VBA stuff). Not to mention all the database integration stuff is heavily tied into the Access JET database engine and related components which would need to be open sourced as well.

Re:They may not be able to open source it

[Anonymous Coward]

You've watched Antitrust [imdb.com] too many times.

Or the Stacker vs Microsoft lawsuit.

Re:They may not be able to open source it

[jonwil]

Everyone keeps talking about Microsoft stealing code yet to the best of my knowledge there has never been any actual instances of Microsoft intentionally stealing code and using it contrary to the terms of the license.

And I doubt anyone will ever find any since Microsoft is not stupid enough to do something like that.

Re:They may not be able to open source it

[PincushionMan]

Why be ashamed? Is it written in VB 5? Or is it Win32 C with loads of Assembly language?

I thought that MS made a VB6 to VB.NET 1.0 code converter as part of Visual Studio 2002? I know it couldn't have been perfect, but wouldn't it get the code 90% of the way there?

Even slightly sorrier

[fyngyrz]

I'mJustHereToTellYouThatYou'reWastingSpace.

Re:Even slightly sorrier

[U2xhc2hkb3QgU3Vja3M]

AndYouReWastingSpaceWithYourPunctuation

Re:Even slightly sorrier

[Anonymous Coward]

Stp t! Nbd ss vwls nmr.

Too many floppies?

[Anonymous Coward]

Maybe the source is just too large to distribute??

Re:Too many floppies?

[Z80a]

Just put it on a Magneto-optical disc or two and bob's your uncle.

Re:Too many floppies?

[Buchenskjoll]

and bob's your uncle.

In this day and age it might as well be Alice.

Stahp

[PopeRatzo]

The word "Classic" is way overused.

Re:Wherefore?

[pz]

The -- and really, the ONLY -- thing going for VB6 is the ease of integrating rudimentary visual controls to create a GUI with minimal effort. You can get a pretty sophisticated GUI (I'm embarrassed to say that I have maxed out the number of available widgets -- text boxes, labels, drop-down selection lists, etc -- on more than one application) in nearly no time. The code that gets generated is incredibly slow, but if you're super-duper careful, you can squeeze reasonable performance out of the compiler. It never gets above reasonable, though.

I've tried writing a GUI in C, and it was an awful experience. Same for MATLAB. If you allows me to call web pages a GUI, then same for PHP / Perl, and it was only slightly less painful.

I wrote a very simple GUI in Visual Studio 2010 C, and it was ... OK. Wouldn't want to make a really complex one, though.

So, in the end, there is a reason to use VB6, sort-of. Kinda. Maybe. If it ran on Win7, there'd be a stronger case for using it.

I agree, FOSS It!

[Anonymous Coward]

Most /.'ers on here will spout off at how bad visual basic is/was. They'll lean on their programmer armchairs and say it was a horrible language let it die.

But in reality most of these /.'er probably haven't touched code in their life. VB targets someone who wants to make a graphical Windows program without much fuss. Sure, some people can spend 3 years of their life learning C/C++ then another year or two learning a Graphical API to produce a Windows program. (Or pay someone $100k a year to do it.) Or they can learn python in a year and a python API in another 6 months. (Or pay someone $75k/year to do it.) But for many programs this is overkill. That's why Basic exists, this is why VB, Gambius, QTBasic, beOS-Basic and many more existed. Sometimes you don't need a scalpel to do the job of a hammer.

Was VB6 over used? Yes. The real issue with VB stemmed from the corporate environment. The problem was two fold, firstly you never got fired for using Microsoft, and secondly, VB programmers were much cheaper than C/C++/Java etc. There are many complex programs out there in VB that should have been done in a lower language. Specially in the business world. But that does not make VB bad. VB is quite useful for 'basic' programs. .Net failed to understand this. I believe Microsoft saw how many complex VB applications existed in the business world. So they made .net more complex than it needed to be. In doing so it lost its point.

All of this said, I believe Microsoft should FOSS VB6. But I also believe that if the VB community wants VB, they need to make their own VB. A free, cross-platform, basic with a visual editor using QT or wxwidgets would be far more useful for many over the long haul than trying to revive a dead language for an extremely slowly dying OS.

(Disclaimer, I used VB5 in high school school to write IRC clients and Trojans before moving on to C++ for the last 20 years or so. ;) )

Re:Wherefore?

[NormalVisual]

I've likened working with VB6 to trying to perform surgery with boxing gloves on. It's great for building UIs, but for getting anything of real substance done I either had to write a DLL in C/C++ that got called from VB code, or write an OCX/ActiveX control if it needed to have some kind of UI. It worked reasonably well, but could sometimes be a pain to maintain. Probably the most frustrating thing about VB6 was the total lack of support for unsigned integers, which made writing bit-manipulation code tedious at times.

85 upvotes?!

[ihop0]

Stop the presses! 85 upvotes is MADNESS!

Re:Of two minds

[ChunderDownunder]

"extend it and add modern constructs to make this a less painful framework to deal with."

Like VB 14, included in VS2015? :)

According to the article runtime support is still available in Win 10 until 2025. Does the IDE itself no longer work in Windows 10, or is it just that developers are pushing for an updated toolchain that emits binaries optimised for armv8 (surface phone) or x86_64?

Re:Wherefore?

[sg_oneill]

Delphi absolutely killed VB on this front. It had all the visual drop and drag chops , tied to perfectly servicable modernization of Pascal that dropped all the "crap at IO" features of old Pascal, and added a robust C++ like object model. Plus if you really had to you could still use those VB active-x controls. But more often then not more competently implemented alternatives where available in Delphis vast open source ecosystem.

Unfortunately Borland was/is a horrible company that continuously canibalized its own developer base with its horrific licensing fees and unwillingness to service the student market (Meaning no new delphi devs coming online).

So C# / VB.net it is.

Re: Of two minds

[dg41]

Correct. The IDE runs only on WinXP. 7, 8, 10, no go.

Re:Wherefore?

[Bing Tsher E]

Borland wasn't always like that. Something had changed in the Delphi era.

Turbo Pascal and Turbo Basic were extremely accessible back when a compiler from most vendors was the opposite of accessible and affordable.

Re: Of two minds

[Bing Tsher E]

Why would one need more than a VirtualBox instance of XP to run VB6?? You don't even need to throw it many resources.

I'll go you one up

[fnj]

It's a good proposal. I'll give you an even better one. OPEN SOURCE WINDOWS XP (or 2000, or 4.0; I don't care, any of them would be golden, but XP has a better starting point for supporting newer classes of devices). If Microsoft is too goddam flaming stupid and helpless to carry forward support and patching and implementing support for newer devices, to hell with the bastards. Let the community do it.

OK, look, I know why they would never do it. They bloody well know they couldn't sell their shitty newer OSs, because XP is far superior, whether or not it is free as in beer.

Good! Teach the LLVM folks a thing or two

[Anonymous Coward]

I hope they will study this and learn how to write quality compilers from it.

Exactly!

[tlambert]

Businesses aren't the ones demanding the source for VB6.

Exactly! What cashflow strapped small business with 15 employees running on Windows XP with a hardware firewall between them and the net, with a huge amount of Microsoft and third party components, all glued together with VB6, wouldn't want to:

* Upgrade 15 old machines so they could install a 16th machine
* Have to have someone "upgrade" their entire business IT infrastructure to .NET (hope it works!)
* Re-buy all the components they were using
* For the components they were using that aren't available on .NET, pay someone to rewrite them from scratch
* Convert all their historical data
* Replace all their old printers, since old printers never have drivers in new OS's
* Retrain all their employees on the new stuff
* Hope there aren't any business-ending "quirks" in the new code

I mean who wouldn't love that?!?!?

...wait. I'm beginning to see the problem here...

Re:Exactly!

[rtb61]

Such is life, if you keep wanting to produce buggy whips when there no horses on the streets expect to fail. If you took on computers early, you ended up having to make a lot of changes over the years, that's just the way it is. Basis is just so done, accept it, if changing causes you to fail, then accept failure, there is no escape.

Re:Exactly!

[Dutch Gun]

VB6 is simply a tool to get shit done, quickly and easily. If you couldn't do it quickly and easily, then it was the wrong tool for the job. People in the real world use software to get their real work done. You're thinking of VB6 as an end-product rather than as a tool, which is where your analogy goes off the rails.

Re:Exactly!

[Stonent1]

I took a VB4 class 20 years ago and just didn't really get it. I knew regular BASIC fairly well. But now, C# and PowerShell are the tools to get things done in windows in my opinion.

Re:Exactly!

[Dutch Gun]

Oh, don't get me wrong... I agree with you. I probably should have said *was* rather than *is*. It's certainly not anything you'd want to use for a new project, of course, but there are very likely a lot of legacy projects that are still being maintained that rely on it.

Re:Exactly!

[segedunum]

Such is life

Not going to happen. Such is life I'm afraid.

Re:Exactly!

[Anonymous Coward]

What cashflow strapped small business with 15 employees running on Windows XP with a hardware firewall between them and the net, with a huge amount of Microsoft and third party components, all glued together with VB6

The VB6 applications will still run, even on Windows 10. The VB IDE hasn't been supported since 2008, so surely you aren't still using that, are you? In addition, Windows 7 has been around since 2009. Is this business so cashflow strapped that it hasn't been able to afford a new machine in over five years? Let's assume those employees are all making minimum wage ($7.25?), work 40 hours per week, and work 48 weeks a year, and somehow the business has no extra costs at all for the employees. That means each employee will have earned almost $70k over those five years. Buying each employee a new machine every five years means the 'upgrade machines every five years' budget could remain at 1% of the wage budget. If the company can't afford this, is the company really viable? In addition, I imagine the power savings alone would recoup the investment in new machines in a year or two.

* Upgrade 15 old machines so they could install a 16th machine

Which you probably want to do anyway, see above.

* Have to have someone "upgrade" their entire business IT infrastructure to .NET (hope it works!)

Yeah, .NET has only been around since 2002. If only you had started slowly converting individual components 10 years ago, you wouldn't have this problem now. Failing to plan is planning to fail.

Re-buy all the components they were using

I imagine you wouldn't be able to buy new licenses for some of those components anymore anyway. And if the companies that made those components moved on to VB.NET, perhaps they have some upgrade plan in place? If only you hadn't delayed investigating this issue until 8 years after your IDE stopped being supported!

* For the components they were using that aren't available on .NET, pay someone to rewrite them from scratch

Ensure they're written in c# while you're at it, you'll thank yourself later.

* Convert all their historical data

Why? I imagine in most cases you can keep the same data storage format as you were doing before, unless you were serializing objects to disk (is that even a thing in VB6?).

* Replace all their old printers, since old printers never have drivers in new OS's

If the poor company has only 15 computers, why would they even have multiple printers? Regardless, you can still keep a Windows XP machine around to control the printer, if that's what you really want.

* Retrain all their employees on the new stuff

Yes, that sucks. If only you had started replacing stuff piece by piece years ago, then it wouldn't be such a shock.

* Hope there aren't any business-ending "quirks" in the new code

Yes, that can happen. On the other hand, perhaps the new code has new features that make your employees much more efficient.

...wait. I'm beginning to see the problem here...

If only you had anticipated this problem ten years ago, then you wouldn't have it now. The best time to plant a tree was 20 years ago. The second best time is now. So it is with updates (although perhaps '5 to 10 years' is more reasonable).

Re:Exactly!

[segedunum]

Yeah, .NET has only been around since 2002. If only you had started slowly converting individual components 10 years ago, you wouldn't have this problem now. Failing to plan is planning to fail.

Not going to happen, and it never was. The rules that applied then apply now. Companies do not pay to rewrite all their applications in the latest new technology which does all the same stuff their old one did - and nothing more. In fact, .Net applications generally run slower. Great. It makes *zero* sense. Only a developer living in an idealistic fantasy world thinks that, which is exactly how Microsoft thought with .Net and VB.Net.

I'm afraid you're simply someone with no knowledge or experience of what happens with legacy applications and why they simply don't get rewritten in the latest and coolest technology. There are fundamental reasons why we are still talking about classical VB and why we still talk about COBOL. Hell, we're still talking about bloody JavaScript after all these years. Your idealistic and simplistic notion of how organisations operate will not change that.

Re:Exactly!

[RabidReindeer]

Quicky, easily, and sloppily

That's the problem with not only VB, but similar quick-and-dirty platforms such as PHP and almost anything scripting-based. Because today's business values "git 'er Dun!" over getting it done right: producing a secure and reliable product. Because that would take time and cost money.

Re:Exactly!

[nine-times]

See, on the one hand, what you're describing is exactly why I think FOSS is so important. Rather than getting held hostage in the upgrade treadmill, you could just pay a programmer to maintain your current codebase. Your business is stuck running on Windows XP? If it were open source, some programmers could make a business out of providing required patched and updates. Great.

On the other hand, as an IT person, I have violent hatred towards companies who run their business on a jenky old custom app that only runs on out-of-date systems. Yes, it's a big, expensive, complex, scary project to take your business-critical application that hasn't been touched since 1996 and make it run on modern infrastructure. That's why you never should have let it get to this point. If you have a business-critical custom-built application, you should have a plan for keeping it updated and running on modern infrastructure. You should not be waiting 20 years before you invest money into updating it. If it's too fragile to migrate to a new server running a new OS, then it's too fragile to be business-critical. If you can't run your business without that fragile and terrifying app, then you should not feel good about the way you're running your business.

Re:Exactly!

[Sperbels]

over getting it done right

In my experience, there is no "right" way to do it. There is merely a multitude of inexpensive ways and a multitude of expensive ways. The expensive ways don't necessarily produce better code.

Re:Exactly!

[bondsbw]

In fact, .Net applications generally run slower.

Even if this were true*, .NET runs on powerful, modern commodity hardware. If you were to start a software project from scratch, it would cost orders of magnitude more to build it using a mainframe system than a .NET based system with similar performance characteristics.

* which it isn't, it's decently performant with JIT and quite speedy with .NET native, even compared with new language compilers and frameworks and .NET code is certainly optimized much better than code run through ancient compilers

Re:Exactly!

[Thiez]

Not going to happen, and it never was. The rules that applied then apply now. Companies do not pay to rewrite all their applications in the latest new technology which does all the same stuff their old one did - and nothing more.

So be it, if that is what these companies desire. But they should keep in mind that it will become increasingly expensive to keep their software running on newer machines (and their old ones will fail, eventually), and if they even require new features, it might be very hard and expensive to find someone who is willing and able to implement them. I'm not saying they should rewrite everything in a new language every few years (which would be expensive and foolish busywork), but if you're stuck to one vendor and they announce they will no longer support the language you're using, that seems like a great time to start moving on. The longer you delay updating, the more expensive it gets.

Hell, we're still talking about bloody JavaScript after all these years.

How is JavaScript even remotely comparable to a dead languages like VB or COBOL? Sure, no language will truly be dead as long as there are still applications running and being supported, but nobody in their right mind would start a new project in 'classic' VB or COBOL. Some might say the same about JavaScript, but even they must admit they hate JavaScript for a different reason.

Re:Exactly!

[BitZtream]

Terry, are you seriously behaving this way? This is incredible inaccurate/wrong for someone like you.

* Have to have someone "upgrade" their entire business IT infrastructure to .NET (hope it works!)

Seriously, you know better than to say something as silly as this. You can run VB6 and .NET side by side, its not all or nothing. Pretending it is ... well thats boarding on a lie. Are you trying to blame some shitty dev who wrote a crappy monolithic app due to horrible coding practices on the language? Thats what it sounds like.

* Re-buy all the components they were using

Old VB components are OLE or ActiveX. These work perfectly fine with .NET in 32 bit. You can't use a 32 bit DLL in a 64bit .NET process, but just switching to .NET doesn't actually require upgrading components.

* For the components they were using that aren't available on .NET, pay someone to rewrite them from scratch

Or just keep using the old ones.

* Convert all their historical data

Why? Changing languages makes your data the wrong format? Whats the logic here?

* Replace all their old printers, since old printers never have drivers in new OS's

How does installing the .NET framework break your printers or drivers?

Retrain all their employees on the new stuff

... why? If you change the way the app works ... sure, but then you aren't just porting to the new language are you?

* Hope there aren't any business-ending "quirks" in the new code

, , , Again ... SERIOUSLY? You're playing that card? ALL DEVELOPMENT FALLS UNDER THIS CATEGORY. If you need to change the code, this issue exists, VB/.NET are irrelevant. When you commit to the FBSD svn repo ... this applies, even in C, and you of all people damn well know it.

Re:Exactly!

[segedunum]

So be it, if that is what these companies desire. But they should keep in mind that it will become increasingly expensive to keep their software running on newer machines (and their old ones will fail, eventually), and if they even require new features, it might be very hard and expensive to find someone who is willing and able to implement them.

Still not going to change anything. That's why virtualisation got popular as well. You can still run old operating systems in virtual machines, so the failing machines argument that people used to use to get paid doesn't work either.

How is JavaScript even remotely comparable to a dead languages like VB or COBOL?

It shows you the inertia in legacy languages and technology. Lots of people would like to replace JavaScript but there is just too much code written in it.

Re:Exactly!

[segedunum]

Even if this were true*, .NET runs on powerful, modern commodity hardware. If you were to start a software project from scratch, it would cost orders of magnitude more to build it using a mainframe system than a .NET based system with similar performance characteristics.

Factoring in rewriting millions of lines of code for no reason? I don't think so.

Re:Exactly!

[bondsbw]

Factoring in rewriting millions of lines of code for no reason?

Perhaps, perhaps not. It requires a cost-benefit analysis. My point is that you can't just assume that it is always more cost effective to throw money at continued maintenance of your mainframe system.

For that matter, software maintenance for mainframes is becoming more and more costly as the supply of developers who know how to work with their software gets older and shrinks toward zero.

Re: Wherefore?

[reanjr]

But most people aren't trying to perform surgury. Many are just trying to beat something into a useful shape.

Nope, nope, nope. NOPE!

[rakslice]

I'm starting to remember the godawful jump label based error handling.

That would be better left sealed off in whatever depths it is currently in.

I can understand if there are organizations around who still have VB6 projects they are trying to preserve their investment in and would like the tools to be maintained going forward, but I think this request is more coming from people who are nostalgic for the visual IDE with its shallow learning curve and relatively comprehensive coverage of the widget set for the platform, and for those people what you really want is a better IDE for a different programming language.

Re:Nope, nope, nope. NOPE!

[l0n3s0m3phr34k]

It must remained buried in the depths of the non-Eclucid geometrical catacombs beneath R'lyeh. If released it will consume all our souls!

Re:Nope, nope, nope. NOPE!

[Sperbels]

Why is "On Error Goto label" any worse than try/catch?

Re:Nope, nope, nope. NOPE!

[serviscope_minor]

Why is "On Error Goto label" any worse than try/catch?

For the same goto is generally considered worse than function calls: it's all about the structure imposed. With try/catch you can only catch up the call stack. With on error goto, you can wind up anywhere you choose. Also, the try/catch is local: you get an error in this try block it's handled in the attached catch block. With on error goto, the where is set by that command (essentially a global) and it doesn't nest either.

Re:Nope, nope, nope. NOPE!

[Dr_Barnowl]

I'd agree with that.

Used to use a library to handle errors ; it would produce a nice stack trace with parameter values and everything. With no syntactic sugar or reflection available the best way to do this was to use an IDE plugin to insert the code. It depended on On Error Goto but the structure was consistent and rigid.

And of course, for some of the core libraries, you needed to catch errors... because that was the only way, for example, that you knew a Collection was missing a particular key...

Re:Nope, nope, nope. NOPE!

[Sperbels]

Try/Catch is essentially the same thing as a goto. And your error handler's label must be within scope. You cannot 'wind up anywhere'.

Re:Nope, nope, nope. NOPE!

[rakslice]

Well, the scope of an On Error Goto Label handler is a single procedure/function. So for instance, to do the equivalent of what would be a top level unhandled exception logger in a language with exceptions that bubble (pretty typical in well-behaved software with resources to spare) you end up copy-pasting an error handler into every single procedure.

Is there not enough happening in the world?

[rebelwarlock]

Since when does "someone posted on a forum begging for something" count as news?

Re:Is there not enough happening in the world?

[thegarbz]

Admit it, you had fun reading these comments and it lightened your Monday morning.

Re:Is there not enough happening in the world?

[tommeke100]

It had 85 upvotes, dude!

Re: Of two minds

[xvan]

The IDE works on windows 7, 8 and 10 (after some patches are installed).
Shameful disclaimer: I work for a company that refuses to burn C++ 6, VB6 and .Net 4.0 Frankenstein and rewrite it from scratch.

Re:Stahp [classic, and WYSIWYG]

[Tablizer]

The word "Classic" is way overused.

Why do you say that? When there is a major overhaul of a tool or language, the pre-overhaul versions are typically called "classic". It's convenient. Using version number ranges is harder to remember for both the speaker and the listener.

One thing I liked about VB classic and Delphi is that they are pretty much WYSIWYG (at least in the 90's, I haven't tested them on newer OS). With the web stack, different browser brands and versions and OS settings will make stuff shift all funny unless you leave fat ugly margins. You have to test on like 25 browser/OS variations or more to rule out funny shuffling. I FUCKING HATE THAT!

WYSIWYG is a good invention, it's why PDF's live. Please bring it back. Our tools de-volved. Auto-flow is evil; I spit on it daily; I use to have nice hair, and now it looks like Bernie Sander's hair.

Re:it's source code

[GrahamCox]

Certainly as embarrassing as your grammar.

Re:Stahp [classic, and WYSIWYG]

[drinkypoo]

WYSIWYG is a good invention, it's why PDF's live. Please bring it back. Our tools de-volved. Auto-flow is evil; I spit on it daily; I use to have nice hair, and now it looks like Bernie Sander's hair.

There's hope for you yet, so long as it doesn't look like Trump's Tribble.

Why Mainframes Live [Re:Exactly!]

[Tablizer]

Not necessarily.

Most Mainframe programs from the late 1960's work with little or no changes. You can complain about COBOL and JCL, but at least a mainframe shop doesn't have to rewrite programs from scratch every 15 years or so for every new programming or UI fad style that comes along.

Maybe it cost more up-front to use the clunky mainframe languages, but if you factor in the cost of rewriting every 15 years to keep up with the Joneses, then the mainframe approach perhaps is cheaper over the long run. And more reliable.

Re:Why Mainframes Live [Re:Exactly!]

[Anonymous Coward]

Sure it's much cheaper finding COBOL, JCL and PL/1 programmers that maintain 50 year old crap that nobody is sure if it's still used and how it all works together and poop even more of it, right?

Hell, rewriting stuff every now and then gives you a chance get rid of legacy!

Re:Why Mainframes Live [Re:Exactly!]

[DarkOx]

if you factor in the cost of rewriting every 15 years to keep up with the Joneses

I am not so sure about this. Most business change enough over the course of 15 years that there are probably efficiencies to had with a new solution that would improve the bottom line over continuing to bolt onto their initial investment.

I have tons of small SMBs for example with a situation like this. They have some seriously downlevel ERP system running on a dusty AS/400 in the corner. Non of their IT staff touches except with great reluctance when the have to. The internet happened. So they hired some guys to build a fancy website with .Net MVC/razor and biztalk behind it. They want to get the site live as a fast as possible, the .Net guys do all the public facing parts and the stuff they actually know how to do first. Someone that last step of getting the orders into the ERP system never happens. A stop gap of e-mail the orders to the same CSRs who would keying fax orders back in 1992 is employed.

Now if someone would just upgrade that ERP (painful as that might be) it would be possible to integrate stuff like the website and all those webservices the suppliers are exposing to re-order and what not quickly. They could probably automate more take on more clients or cut staffing costs considerable. Someone just needs to be willing to sign that 200k check and get some new technology in the door.

Re:Why Mainframes Live [Re:Exactly!]

[neilo_1701D]

Now if someone would just upgrade that ERP (painful as that might be) it would be possible to integrate stuff like the website and all those webservices the suppliers are exposing to re-order and what not quickly. They could probably automate more take on more clients or cut staffing costs considerable. Someone just needs to be willing to sign that 200k check and get some new technology in the door.

I do ERP systems for a living: Microsoft Dynamics AX, and I work for one of the top Microsoft partners in AX space.

$200K is pretty much your consulting fee for what you propose. $2 million is probably the implementation cost for a replacement ERP system. But that's only the beginning of it. Since ERP is so fundamental o an organization, replacing an ERP system with something totally different (and be it SAP, AX, or any of the other solutions out there) to what runs on an AS/400 is going to require a complete rethink of the organizational processes.

You replace an ERP (or even just upgrade your existing one) when your business demands it, and for no other reason. It's simply too costly in terms of money, time, retraining, and the inevitable go-live issues that happen.

Heck; I've been assigned a new client to sort out their database because the go-live went so bad: the initial data load was bad data, and there are bugs throughout the system because the client never tested but pushed for a go-live before they were ready. For the last 9 months they can't run an AP aging report!

Replacing an ERP system is not like replacing Word Perfect with Word. It takes a serious commitment of time, money, and most importantly of all client buy-in: if the client's employees haven't bought in for the need for change, your ERP project is dead in the water.

Re: Why Mainframes Live [Re:Exactly!]

[Anonymous Coward]

Rewriting 17,500,000 lines of code "occasionally" isn't possible. It would take decades to reengineer most large legacy Cobol projects from scratch, it would take dozens of engineers, and it would probably get screwed up.

Corrections [Re:Why Mainframes Live]

[Tablizer]

I accidentally bumped Submit prematurely. Sorry about the bold font.

And it should be "fad or style" instead of "fad style".

Re: Corrections [Re:Why Mainframes Live]

[ADRA]

For someone so incredibly naive about the world of business, how do you expect to be competitive? Out-smug the competition?

Re: Corrections [Re:Why Mainframes Live]

[Tablizer]

Please elaborate. Finance and banking co's are heavy COBOL users, for example, and they are not shrinking (unfortunately).

Re: Corrections [Re:Why Mainframes Live]

[serviscope_minor]

If you're still running COBOL code you're probably part of the 50% of the economy that will be replaced by robots in the next 20 years.

If you're still running COBOL you already are part of the community which was replaced with robots 50 years ago.

Re: Corrections [Re:Why Mainframes Live]

[segedunum]

If you're still running COBOL code you're probably part of the 50% of the economy that will be replaced by robots in the next 20 years. Change or die.

Dream on.

Re: Corrections [Re:Why Mainframes Live]

[Anonymous Coward]

Bullshit. Whether or not you will be replaced depends on the task you do. Not the specific language used to build the tool to do so. If it works that is all you need. If you replace purely for the sake of it you are throwing profit away and introducing new bugs and problems when your existing software already solved them all years ago. Upgrading for security reasons (OS, firewall, openssl version etc) has value. Changing implementation language does not. That doesnt mean you shouldnt use a modern language for genuinely new projects.

Re: Corrections [Re:Why Mainframes Live]

[LWATCDR]

Probably not.
You will find COBOL in a lot of banks and other companies that computerized a long time ago. This is all back end code that runs things like accounting. The code works and has for decades. It was well written and updated over time very carefully.
As for UIs you will often see web based UIs to this back end code. So you have a stable well tested foundation and an easy to update light UI. The hardware on a mainframe is super stable and highly reliable.
If you want to migrate from a mainframe simply recompile.

Re: Corrections [Re:Why Mainframes Live]

[RabidReindeer]

If you're still running COBOL code you're probably part of the 50% of the economy that will be replaced by robots in the next 20 years. Change or die.

Don't be a fool.

I'm one of those people who sneer at the "if it ain't broke, don't fix it" mentality that causes PHBs, CEOs and other clueless/wishful people to treat their IT assets as fixed one-time-costs, but there are some computer applications that simply don't need to be based on the fad-of-the-moment technology.

Accounting systems have been pretty much the same since at least the time of Scrooge and Marley, if not all the way back to ancient Sumeria. Payroll, pretty much the same. The old "Data Processing" stuff doesn't need a total re-architecting and companies have better things to spend their money on. Such as overpriced consultants peddling overpriced technological "solutions".

These days "DP" systems have a lot of interaction with "IT", as we do things like run Big Data analysis on the Accounts Receivable. But the virtue of the old mainframe systems is that it's a lot easier to ETL data off the AR masterfiles and into your MongoDB database than to keep redesigning the accounting system every time some new externality is needed.

Re: Corrections [Re:Why Mainframes Live]

[Xest]

This meme needs to die, it was a reasonable comment to a degree about 10 years ago, but financial institutions have been phasing out COBOL since before the turn of the millenium, some did so before succesfully, others had to pay a fortune to COBOL developers to get them into the 21st century okay, but recognised the need to dispatch those old systems soon after. The amount that remain are few and far between.

This isn't to say there aren't COBOL systems out there, of course there are, but most banks and other financial institutions have phased out old COBOL systems with stuff written in languages like C++, Java, and even C#.

Many of the companies that used to be depended on for mainframe support and development just don't even exist now, or don't even support mainframes any longer and so it's just not tenable for many of those systems to still be around and depended on. It's all well and good having a 40 year old system tried and tested, running well, but if it fails, and it will eventually fail, and you can no longer get parts or support then you've basically just lost your whole business. That's not a risk banks can take morally, or legally - it would be a breach of the regulatory requirements surrounding risk management placed upon banks in most countries.

Note: I replace old systems in financial institutions for a living, so actually know something about this particular topic.

Re:Vulnerabilities

[Sperbels]

Gaping holes? I've found VB6 code to be extremely reliable and stable and easy to install. Opening sourcing .NET was done for one obvious reason. They want .NET running on Linux because Microsoft has be unable to conquer the server.

VB had its place

[Fencepost]

But in 25 years things have improved quite a bit, and there are things in old-style VB that I can't imagine having come back. I honestly don't remember which version of VB some of them were in (3? 4? 6?)

DoEvents anyone? On Error Resume Next? On Error Goto?

Re:VB had its place

[blueryu]

Yeah, for sure "On Error Resume Next" is terrible. I did a conversion to C# of classic VB with COM Interop code. It's hard to convert into something current because of so many unhandled errors due to "On Error Resume Next". Sadly even the application's API interfacing examples in their documentation used it, so I can't blame the VB programmer.

I'd rather....

[niittyniemi]

I'd rather Microsoft open sourced Bill Gates' latest bowel movement.

It would smell considerably better than this stinkfest of a language but it would probably be about as much use. None at all.

Young Bill Gates building an app with Visual Basic

[tetraverse]

Can't help but reminds me of Peter Gregory from Silicon Valley :)

VB

[ledow]

VB6? Nah.
VB5? Nah.

VB4 / 3 - Actually, that would be quite fun. The days of a single simple toolbar, an MDI layout (wasn't MDI, but multi-window, but it was pretty usefully laid out), stupendously fast form creation and prototyping, simple language not cluttered with class-based junk, and a simple runtime.

Those early versions of VB were great. Especially when I was younger. You could get results faster than any other language (let's not get into "BASIC programmers are shite", because when you're a kid you're not interested in perfect syntax anyway).

It was literally a WYSIWYG environment inside the first major desktop GUI's that you could arrange a form in seconds, and then double-clicking any element and you could program quickly against it. It wasn't fast, it wasn't fabulous, it wasn't state-of-the-art, but boy did it teach you how to get things going quickly. And the event-driven auto-created subroutine stuff was the quickest, most useful way to get things interacting with the user. (I think that's it, actually - it was programmed with the focus on the user (the forms they see, the layout of controls, what happens when they touch them) rather than the programmer.)

BASIC was designed for one thing - to be able to learn it fast. Working in schools, I guarantee you that it does just that. Python etc. can't come close, even with prep school kids. Maybe Python etc. are more modern, better represent modern programming, have syntax that tends towards "better" programming, etc. but BASIC you can pick up in an afternoon. I know, I've got kids to do just that. Python, you're lucky if they can get the compiler/interpreter working at home in that time.

VB3 / 4 was my prototyping even as a kid. I was already doing Z80 and x86 assembler, C on the side and a myriad languages as I was exposed to them. But VB3 / 4 would let me knock up something to show someone the viability in a couple of hours, if not minutes. My friends were trying to write games for their A-Level projects, they couldn't work out how to lay them out. We did it in VB3 in minutes, including the game code which I quickly knocked up, and they saw the best way without wasting time re-writing all their code.

People really knock VB3/4 but it was the first mass-market rapid prototyping tool, which is why a lot of business apps ended up in it. Literally, ODBC integration was "drop a database control on the form". I'm sure big, expensive tools that could do that pre-dated it, but most people never saw them. VB was sold in computer stores next to business apps made with it, though.

I would love - just for "Look, this is how it would work" purposes - a VB3 / 4 that runs on modern windows, even if it didn't "compile" or anything like that. Just a quick language that you have a syntax you can use to open up the controls and make them interact. Also my first intro to in-execution debugging. The VB debugger looked like magic when it first came out, because we couldn't previously afford tools like that.

And a manual that reminded me of those early computer manuals that told you EVERY SINGLE COMMAND in the language, full syntax, restrictions, examples, etc. It was great just reading through it and thinking "Woah, I can use that".

People knock VB a lot. I'm sure it's not great for production use. But in terms of a language that entices you in and makes it easy enough for you to WANT to learn it, it's probably the last one I saw.

Re:VB

[TuringTest]

But in terms of a language that entices you in and makes it easy enough for you to WANT to learn it, it's probably the last one I saw.

Certainly the last popular one, side by side with Hypercard. Which is utterly sad, as we could build much better environments like those nowadays for easy prototyping and easy distribution, with everything we have learned since then.

But it just seem that developers are not interested in creating those tools anymore, programming environments for people who will never learn how to program complex systems; any novice tool is oriented to teaching the first steps towards becoming a full-blown professional, and there's a glaring hole for a tool helping people write simple and easy applications that go beyond the "if-this-then-that" trivial rules.

Re:VB

[Dr_Barnowl]

VB3 was horrible for a lot of reasons....

Change the case of a variable, even accidentally, while typing it? Enjoy the case being flipped in every source file you have open! (I actually wrote tools to right-case VB code in a hook before they got checked in, this was so annoying).

Lots of reasons tied to it being a 16-bit environment.

Limited string table size (we would have to carefully manage the number of static strings we compiled into executables). Limited global variable count. No arrays with more than 2^15 elements, meaning we had to write complex routines to sort records on disk rather than in memory... on modern 32-bit machines with hundreds of megabytes of RAM.

VB6 was eminently superior but our cash-cow product was in VB3 (and had been in QBasic before then, I think). I even wrote a somewhat limited XML parser for VB3 once....

Re:VB

[ledow]

Those are all bug / technical limitations. There's no reason they couldn't be fixed quite quickly, in fact.

VB4 fixed many of the 16/32 bit problems, for instance, before the VB5 OO-injection.

no, they have no obligation to open it

[dominux]

the lesson here isn't that Microsoft should open source their old and unmaintained stuff. The lesson here is that if you are thinking of using a new tool, consider whether the publisher is in a position to abandon it and you in the future, or whether it is Free Software that can't be unilaterally withdrawn by the publisher leaving you without the freedom to continue it yourself or find someone else to work with it.
I think we need to get out the world's smallest open source violin for those requesting the opening of visual basic.

Wow! 85 upvotes!

[wonkey_monkey]

drawing 85 upvotes

Telling the world you accidentally pooped out of a window would get you a hundred times as many on Reddit.

Bigger Problem

[Anonymous Coward]

This is a *HUGE* problem not only with VB6. it should be a legally enforceable condition of being able to sell software that when you no longer wish to support it you *HAVE* to open source it. It's obscene that users can quite literally have the tools they use to make a living taken away from them by arbitary third parties.

I'm in this position as I have 20 years worth of work that I've done in Logic Audio for Windows which I can no longer access as the version of Logic for Windows that I have will not run on my current PC hardware (the old motherboard died) Can't rework anything on a Mac version as there's no support for the VSTs I used.

It's a complete disgrace companies are allowed to treat users in this way.

Re:Wherefore?

[Dr_Barnowl]

The main thing that sucked in VB6 was the string handling. It had no equivalent of StringBuilder, and String was an immutable class, so every time you concatenated two strings of length N it allocated a 2N buffer to hold them and copied the data.

You could get around this by rolling your own string handling routines to compensate for this.

The other main thing that sucked was a lack of decent error handling, but with some good libraries and an IDE plugin to make using them less tedious you could have proper stack-based exception handling, almost.

With a few libraries in your toolkit (I wrote a useful object persistence library that handled most of the bother of Class state with a variety of targets, flat files, SQL, XML, etc), you could knock up a useful program faster than most C programmers could write their makefile. With discipline and a few more libraries, you could write very robust and professional code, and yes, even high performance programs - the compiler was the same one that shipped with Visual Studio 6, you just had to avoid using the expensive bits of the VB runtime for performance-critical things. You could even compile VB6 code without the array bounds checking and such, although it was rarely worth it.

bit manipulation code

Yeah, that was tedious. I had to do it for some smartcard authoring software (lots of cards like Mifare 1k have pitiful amounts of space available so you end up using tricks like 6-bit date types and then have to pack them on arbitrary bit offsets), so again, I wrote a library to do it.

VB6 had a low barrier to entry that got it a reputation for amateurish programs - entirely justified.

I would argue that C# is just as good as VB6 for the same role though - the thing that made VB6 shine was the form editor in the IDE. Even the FOSS one - SharpDevelop - has a form editor that makes the VB6 one look tired and old.

I refuse to learn VB.NET, because it's almost but not entirely different and will probably overrwrite my VB6 knowledge, and that, like COBOL, will probably be worth something in the future.

WHY?

[Lumpy]

XOJO is better than it and is cross platform. Who really gives a rats turd if VB5 is released as open source. it was locked HARD to the windows ecosystem and incredibly quirky. it then compiled pseudocode to be run by the interpreter.

The only people that want to continue it is PHB's that have some ancient apps written by other PHB's that were abominations.

Re:I was around then. VB6 is terrible

[Dr_Barnowl]

It felt like I was the only person with a CS degree who tried to use classes in VB6 and had some idea what was going on.

Hahaha, yes, I had co-workers who looked at me like I was some kind of lunatic for using the "Implements" keyword for it's intended purpose of polymorphism.

"Well, I can see it's elegant, but will people be able to understand it...."

JavaScript / python / enterprise env.

[yuvcifjt]

Python is a beautiful 25-year-old language being used in enterprise environments;
and as the wikipedia article summarises, the core of the language is about: -

* Beautiful is better than ugly
* Explicit is better than implicit
* Simple is better than complex
* Complex is better than complicated
* Readability counts

... which is a philosophy any developer working in a corporate environment should take to heart, especially readability, simplicity, and maintainability!

Whereas, the reason javascript is still somewhat of a joke is because of it's past and starting as a scripting/"dhtml" language;
and thus the reason why any mature/wise developer with over 10 years of experience can't take crud like AngularJS and Node.js seriously, along with countless other frameworks released monthly for the kiddy hipster.
i.e. the language, and especially frameworks, need time to mature before being adopted in enterprise and large corporate environments where it needs to scale while maintaining performance.

In the grand scheme of things, javascript is still a very very young language, especially since ajax and ES5/6 and JIT compilation came along.

Re:JavaScript / python / enterprise env.

[s4m7]

How do you say stuff like:

In the grand scheme of things, javascript is still a very very young language, especially since ajax and ES5/6 and JIT compilation came along.

with a straight face? Javascript has been an ISO standard since 1997! It's just a few years younger than python FFS.

AJAX is a pattern used within in-browser javascript, having nothing to do with the language itself, and yes, 5/6 look much different than 1.... much like you can't run python 3 code in a python 1 interpreter.

Re:JavaScript / python / enterprise env.

[yuvcifjt]

Wow, I'm surprised by your comment.

Yes, javascript is a young language, as it started out for doing the most basic of things.
Even object-orientation which was latched-on to the ECMA standard was conceived recently and when you code it, especially if you've done Java or C++, it seems like a joke. For example, a minor difference in a function vs a method?! I mean really, there's not even a keyword to describe a method or to do overrides. Just like private vs public methods seem like an after-thought, a hack.

Erm, AJAX isn't a "pattern", it's a description of technologies, at the core of which is the XmlHttpRequest API.

Re:JavaScript / python / enterprise env.

[s4m7]

You're surprised because you don't know your history. You should really read and learn about what you're talking about before making obviously false declarations.

Re:Of two minds

[NormalVisual]

Like VB 14, included in VS2015? :)

The .NET versions of VB were VB in name only. You generally couldn't just load a VB6 program into VB7 or subsequent versions and have it run as-is, even with the upgrade wizard. That's not to say that the newer versions weren't a lot more useful, though.

Re:Wherefore?

[NormalVisual]

And if you needed more than what the Turbo line offered, Borland C++ was a much easier product to work with than the early versions of Visual C++. It made a huge difference being able to run the debugger on a second (text-only) display when working with Windows code.

Re:I was around then. VB6 is terrible

[ChunderDownunder]

I did a Java 1.1 programming course alongside a VB expert back in 1998 - he crashed and burned after not comprehending OO at all.

VB6 the Language wasn't the problem...

[Carcass666]

Its reliance on COM/ActiveX was. It was ground zero for DLL Hell.

Re:VB6 the Language wasn't the problem...

[Sperbels]

COM DLL hell was nothing compared to the hell that is .NET's DLL hell.

Re:VB6 the Language wasn't the problem...

[Carcass666]

COM DLL hell was nothing compared to the hell that is .NET's DLL hell.

With .NET, at least you often (but not always) have the option of including the assembly DLLs with your distribution, without blowing up everything else in the destination system. You generally do not need to globally register (or rely upon globally registered) libraries. EntityFramework is an example. Going this route, though, make the software distributor responsible for providing application updates when the underlying libraries need updating. Both COM and .NET suffer from very poor versioning capabilities, but at least you're not forced to into continual regsvr32 tug-of-war with .NET.

Missing comma, silly claim.

[sabbede]

First:

In an essay at i-programmer.info, Gee shares a video of young Bill Gates building an app with Visual Basic in 1991, and complains that in the 25 years since Microsoft has open sourced .NET Core and the .NET Compiler Platform Roslyn, "but it has explicitly refused to open source VB6."

There's a comma missing before the italicized clause. As it stands, the sentence means they open sourced .NET 25 years ago.

a company like Microsoft should not take a language away from its users.

Now that's just silly. It's theirs. Microsoft wrote it, Microsoft owns the code, Microsoft can do whatever the hell it wants with it.

Re:Missing comma, silly claim.

[sabbede]

Oops, I typoed myself and put the italics too far over. Should have started at Microsoft so that it would read," ..in the 25 years since, Microsoft has..."

Licensing issues

[zyzko]

Not going to happen. Microsoft even removed VB6 from MSDN downloads years ago citing expired licenses as a reason and said that it's ok to use it as long as you have the license and got it for an example on MSDN CD set, but no downloads any more. If they can't even keep the thing downloadable for their paying customers I bet it is going to be "a little bit" far fetched to think that they would go through the trouble of open-sourcing it.

Re:Licensing issues

[neilo_1701D]

Not going to happen. Microsoft even removed VB6 from MSDN downloads years ago citing expired licenses as a reason and said that it's ok to use it as long as you have the license and got it for an example on MSDN CD set, but no downloads any more. If they can't even keep the thing downloadable for their paying customers I bet it is going to be "a little bit" far fetched to think that they would go through the trouble of open-sourcing it.

Microsoft removed Visual Studio 6 from MSDN ages ago. Visual Basic 6 is still there.

How about using Gambas?

[Qbertino]

We already have a nice FOSS VB replacement: Gambas.

If Basic is your thing, you should use that.

Re: Of two minds

[segedunum]

I'm pretty sure I've had it running under 7.

Re:Wherefore?

[NormalVisual]

I had to do it for some smartcard authoring software

My particular cross to bear was talking to a bunch of custom onboard hardware and external industrial hardware (PLCs and such), but the need for bit-level coding was pretty similar. I haven't made any real effort to learn/use VB.NET simply because it doesn't do anything C# doesn't, isn't used nearly as much, and as you mention, it's not the same language as VB6, so why bother?

Although I don't regret seeing VB6 go away, I will say that I never experienced any compiler/environment bugs with it, and generating a setup file was absolute cake. The VBRUN dependency wasn't too bad, either - it sure beat having to pull an entire .NET distribution down if the machine didn't have whatever version you targeted.

Re: Of two minds

[DarkLordBelial]

I currently run it on Windows 8.1 and have successfully run it on Vista, 7 and 8. I've yet to try it on 10 but my hope is that it won't work so I can finally have an excuse to get rid of it.

Re:Stahp [classic, and WYSIWYG]

[PopeRatzo]

Here is the dictionary definition of "classic":

adjective
1.
judged over a period of time to be of the highest quality and outstanding of its kind.
"a classic novel"
synonyms: definitive, authoritative; More
noun
1.
a work of art of recognized and established value.
"his books have become classics"
synonyms: definitive example, model, epitome, paradigm, exemplar;

Calling Visual Basic 6 "classic" is a misuse. It's a common misuse, mind you. And that's why I say that the word "classic" is overused.

Microsoft Bob

[backslashdot]

I am holding out for them to open source Microsoft Bob and Clippy. They were awesome personal assistants, long before the likes of Siri and Google Now. Clippy was especially useful when sending an important letter.

Not awful language, but awful MS Office API

[damaki]

Visual Basic 6 was an acceptable procedural language, nothing to see there.
But usually, VB6 developers did not use solely VB6, they had to use the awful and crufty MS Office controls and APIs. The damn thing crashes for no reason, had awful performance on MS Access queries (a smoking pile of whatever is you hate the most), everything around MS Office to VB6 connectivity was terrible. And worse than terrible, it usually did not even work and was heavily under-documented. Random crashes, crazy behaviors, name your nightmare; it was in there too.
So no, I do not see the point of open sourcing VB6 as it will give us no access to all these APIs that may have be useful if they were working properly.

NoScript as a security measure

[tepples]

What is with all the hate towards JavaScript and Python, especially JavaScript?

Criminals have used major web advertisement networks to push ransomware to machines running web browsers. Blocking execution of JavaScript blocks the execution of the script that surreptitiously downloads and installs the malware.

mypy static type checker

[tepples]

At least in VB6 you have the _possibility_ of declaring a variable type.

The same is true of mypy, a static type checker for Python.

Personal use, sure, never again for business

[blueryu]

VB was the first programming language I had seriously gotten into back in ~1996. In that respect, I see it fondly and wouldn't mind having a open source version of the language and IDE I could use to poke around some of my oldest projects. Though from every other aspect, I feel that the language is antiquated and there are much better options out there. Winforms .NET is just fine for graphical business applications, which I do a lot of in contacting situations. Just recently I was asked to convert around 20 classic VB projects into .NET. That was a quick reminder that the language could be easily abused and used to produce garbage code. The jewel of that project was a 5000 line program that was basically a single sub program loaded with goto statements, classic VB specific functions, and COM interop code.

Re:Stahp [classic, and WYSIWYG]

[Tablizer]

Usually PDF publishers don't want people messing around with copies of their documents anyhow.

There are ways to mitigate such anyhow with certain internal markers to delimit paragraphs etc. That is, visuals splits versus semantics splits, as illustrated below, but so far there is not much demand for such, except maybe for accessibility purposes.

<p>
  <line attribute="etc">This is one visual line.</line>
  <line attribute="etc">This is another visual line.</line>
</p>

Think of the Children!

[xanthos]

If VB were to be open sourced some poor misguided fool might start using it to teach kids how to code in a simple point and click environment when they could be learning how to create responsive web pages! Why bother learning to do it yourself when you can just pull in megabytes of other peoples code to do your left padding!

Pascal already open source

[OrangeTide]

FPC - GPL, a very complete environment (Lazarus offers a nicer IDE)
P5 Pascal - public domain (fork of one of the original Pascal systems)
GNU Pascal
IP Pascal
etc

All of which are more powerful than VisualBasic and not really any more difficult to use. (my opinion)

Classic VB should be open sourced

[Orion Blastar]

Microsoft is not making any money off Classic VB anymore, and there is a lot of libraries and source code examples for it.

I made my living writing in Classic VB in the 1990s and up to 2002. It was easy to learn because it was like every other form of BASIC from the 8 bit era. VB.Net changed things and made it more like Java.

For those who have Classic VB projects and want to convert it to run on JRE look at Jabaco which can convert some Classic VB code to a JAR file. It is like Java based on Classic VB but misses some parts of Classic VB so you have to convert some code.

Re:Stahp [classic, and WYSIWYG]

[Tablizer]

A lot of sites/apps get auto-flow wrong. Maybe a UI expert or top guru can figure out how to get auto-flow to work properly on all devices, but us mere mortals struggle with it. Any overly-complicated tech can be "justified" with "if you were just smart enough and/or spent enough time learning it, it will work".

That's a crock. Presentation of everyday things should NOT require rocket science.

To use hypothetical numbers, let's say WYSIWYG takes 10 units of learning to master, while auto-flow takes 200 units to master. It's not worth 20x the learning cost to gain the SMALL benefits auto-flow have over WYSIWYG.

The costs are not economically logical in my book. It's a lot of resources spent for very minor gains, and if a shop skips the additional effort, they will have screwy interfaces that wrap wrong or have blanked out overlaps of CSS collisions, which is what is often found.

I suspect auto-flow is being protected by those who want job security dealing with its finicky intricacies. Similar arguments were used by assembler coders against higher-level languages.

F auto-flow!
 

So... why not...

[bmo]

... use Gambas as a replacement? If there's sufficient demand for a replacement for Classic VB, then there should be enough people interested in contributing to Gambas.

Seriously.

--
BMO

Re:So... why not...

[DerekLyons]

If there's sufficient demand for a replacement for Classic VB, then there should be enough people interested in contributing to Gambas.

The folks whining that corporations should give away their software aren't interested in contributing - they're interested in handouts.

"Young" Bill Gates?

[mattack2]

"Young" Bill Gates in 1991? He was about 36 at the time. Yes, in some contexts that is young, but I would say not in the context of a tech article, especially since MS was about 16 years old at the time.

Because if it's not C++ or assembly, it's not code

[gestalt_n_pepper]

I get so sick of these 90s era C++ programmers and their BS about VB6. Look guys, programming is about money or masturbation. Not everyone aspires to a clear, comprehensive, abstract understanding of the world of software development where we can admire our perfectly formed programs in a clean platonic space.

Most of us are or weren't academics at all. We were grunts who have to get shit done. We weren't architects. We were bricklayers and carpenters. For us, VB6 fit the bill. It was scaffolding for databases and anything else you needed that was quick and dirty. When you needed something better, you moved to C, C++ and later, Python.

Like C / C++ inertia.

[aberglas]

There is indeed a lot of inertia.

C / C++ are far worse languages than VB6. No garbage collection, not even a real concept of an array. Every other line a potential buffer overflow. And older than VB6.

But people continue to use this archaic technology today, despite it being so unproductive. That is because of legacy and inertia. And most C / C++ programmers do not even realize how bad it is.

VB6 is not that bad for what it is used for. Efficiency is not so important. It has features like keyword parameters that are Still not in C++. And ti is certainly much, much more productive than C/ C++. .Net is better and has modern compilers that produce code that is often better than C / C++. But it is also a huge monster. And not actually much more productive for simple business apps.

The big one is Excel. Microsoft would love to kill of VBA that is in it. But as a professional developer, I can an VBA ap going much quicker than a .Net one. And end users have no hope of dealing with .Net deployment issues.

Re:Like C / C++ inertia.

[david_thornley]

C++, properly written*, has memory management and real arrays. Most non-C++ programmers do not even realize how good it is.

*Properly written here means code that does nothing obviously bad, rather than code that is perfectly written. Code reviews are adequate to enforce the "properly written" part.

VB6 is a much better language than Python

[aberglas]

Because it has static typing. End of story.

Re:VB6 is a much better language than Python

[silentcoder]

Found the zealot.

IDE simplicity

[PJ6]

Not that I like or condone the language, but the old VB6 (and .NET WinForms) front-end designers (aside from missing CSS-like styling) remain better than what MS offers now... WPF, which is a total mess in terms of unnecessary complexity, or anything AT ALL targeting the train wreck we call HTML.

I'm talking in terms of applications where someone's trying to actually perform useful work, not "content consumption" / etc.

And don't give me that straw-man argument that you can't achieve good SoC without MVVM / MVC / M** and point to something from coding horror as an example.

Re:Stahp [classic, and WYSIWYG]

[Tablizer]

PDF's transfer better than HTML in my experience.

Actually people generally don't even try to use HTML documents for formal printing and publishing, unless backed into a corner. It's because it's so unpredictable.

Tools vs VB6 (lock-in)

[DrYak]

And your analogy shows even better the problems of VB6.

A tool is a tool. And can easily be used with your bare hands.
A hammer is still a hammer, no matter what.
If you have a nail that you need to hammer into a wall, you can go to any hardware store and buy one. And you know that you'll be able to use it.
You have the confidence that you'll be able to user it.
It might be an expensive solid tool that will last a quater of centurs. Or a cheap one that will break by the end of the third nail. But you know how to use it.
(unless it's a PHP Hammer :-P)

Standard language (like C/C++ when standard compliant) are like this.

If Bjarne Stroustrup goes banana and decides that the next version of C++ standard will be a mix of (worsts parts of) Java / PHP / COBOL and BrainFuck.
You can still ignore him and use any sane compiler implementing a standard that you like (say C++11)

VB6 is as much of a tool as a razor with a custom head that you can swap instead of more or less rasor blade.
Yes, you can also do things with it.
But you're at the mercy of the brand making these razors. Maybe tomorrow they'll decide to change everything or plain stop producing razors and you'll be left alone with a useless razor handle that you can't use with any other razor heads (Unless you go for some cheap chinese clone from some shaddy part of TaoBao), (or unless you've stashed a huge supply of replacement heads in case this happens).
It's not a tool, it's an embodiment of the lock-in marketing trick (and rasors with weird heads is a common metaphor for it).

You're at mercy of whatever goes through the head of Microsoft's heads.
And Microsoft *has gone* bonkers and *DID* decide to throw away VB6 and bet everything on VB.Net (a distant cousin of Java, but instead with a much more verbose syntax than C# - the flahship language of Microsoft's "I can't believe it's not Java" .NET platform).
And now you're left with a huge bunch of legacy code that contains all your important business logic that you've painstakingly build over years, investing huge amounts of money to get more or less into a working state.
Your only solution is trying to improvise something with one of the approximately "more-or-less comptaible" open source re-implementation like Gambas. And hope that fixing your VB6 code to work under these conditions won't cost way much more than paying for a full re-write (and re-testing / re-certifying the rewritten shit).
Or alternatively, learn the necessary necromancy skills, to be still able to keep the old hardware alive, so you can run the older Windows XP on it that seems to be the only one on which you can run your VB6 monstruosity.

Yup, VB6 doesn't have much the same portability and absence of lock-in that hammer has.

Getting things done in Windows

[DrYak]

But now, C# and PowerShell are the tools to get things done in windows in my opinion.

Nope. Bash is.

25 Years

[steven.blom]

"...complains that in the 25 years since Microsoft has open sourced .NET Core and the .NET Compiler Platform Roslyn..." Has it really been 25 years since .NET Core and Roslyn? I must have been in a coma for most of it.

Re:Wherefore?

[Bing Tsher E]

You're speaking more of what the Turbo line grew into, after Borland came out with their full-bore C++. In that later period they had light and inexpensive Turbo products, and the very powerful Borland C++. In the earlier time Turbo Pascal was a really lightweight DOS development product.

I ran my BBS using the WWIV 3.2.1 BBS package, which was only distributed as Turbo Pascal source code. The early Turbo Pascal development environment (3.0) was a DOS text-mode arrangement, not a bordered Windows-like IDE. The WWIV BBS compiled into a binary that only needed about 192K of RAM to run. On my 640K 8088 DOS machine, I used a TSR-based disk cache to allocate 320K of the RAM to a cache that made it run smoother with fewer disk hits. I ran a fairly popular single-line BBS running on that hardware with a snappy fast 1200 baud modem.

Turbo Pascal and Turbo Basic and shortly thereafter Turbo C were light and fast development tools with a lot of power (relative to the DOS environment they ran in). I also think there were Boreland Turbo products for other machines (Apple 2?), though I'm not that familiar with them.

Re:Wherefore?

[NormalVisual]

You're speaking more of what the Turbo line grew into, after Borland came out with their full-bore C++. In that later period they had light and inexpensive Turbo products, and the very powerful Borland C++. In the earlier time Turbo Pascal was a really lightweight DOS development product.

Right. The earliest Turbo Pascal that you're speaking of was the one that had the really hokey ads in Byte and PC Magazine, with a ridiculously too-low-to-be-true price tag. The problem for other compiler vendors was that it was a serious compiler that worked like a champ.