Slashdot Mirror
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."
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."
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.
All the .NET apps i've ever had to use (and install huge runtimes for) have been glorified VisualBasic applications.
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.
"First they came for the slanderers and i said nothing."
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.
"Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
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.
If I had a DeLorean... I would probably only drive it from time to time.
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 .NET (hope it works!) .NET, pay someone to rewrite them from scratch
* Have to have someone "upgrade" their entire business IT infrastructure to
* Re-buy all the components they were using
* For the components they were using that aren't available on
* 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?!?!?
Since when does "someone posted on a forum begging for something" count as news?
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.
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.
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.
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.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
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.
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.