Hacker News Reader

I work in industrial automation, and you really don't want to know what an awesome impact VB6 had on manufacturing. As `sjm-lbm noted below [0], it fills that essential niche between stuff that's useful and stuff that's too important to kludge. And I think as programmers/engineers, we should all kinda grok that you can get away with a lot of kludge before the world ends.

My favorite take on this idea is a guy in a forum replying about how vilified VBA is. I can't find the note for the life of me, but basically he said "You may work out and find the perfect tool for the job, but sometimes you just need a turbo-powered pneumatic nail gun to bang out something that mostly works." Skilled carpentry is a thing of beauty, but sometimes you just want the goddam floorboard held in place so the painter can get to work.

[0] https://news.ycombinator.com/item?id=11756195

PS: I've perpetrated my own intellectual violence upon the world via VB, and generally it's what got me programming in my job. I learned C in high school, did some C++ in college, but I really got started in VB6. Eventually I escaped to Python, but man, I still appreciate how ubiquitous VB is. In Windows land, you can always fail back to some absurd version of VB (either in some VBA in a remnant Office installation, or VBscript, or the like - they're all a bit different, but not enough to stop an enterprising hacker).

fail back?

Yup. You've heard of defense in layers? Well, VB is a leaky sieve that you can try from different angles as each layer fails.

So... you didn't hear this from me. This certainly was from some other engineer tasked with getting $THING done in a corporate environment where everything was locked down and noone had admin. (Never mind that anything on the floor had to have the password taped under the keyboard - or to save time, monitor.) I mean, someone had admin, but it wasn't really obvious who in the plant did and the ones who supposedly did had bad privileges set.

So you try to do something absurd like copy a log file automatically in the event of a line crash to a network store. But you can't run the nice application that shadow copies without admin. So you try a batch file, but no dice. Then you try VBA via Excel, and that sorta works, but now you've got to keep Excel running as a monitor, and that garfs up occasionally when the operator alt-tab-resets-power-to-everything. So you try a VBscript, and find that you can plonk that down in the Windows Startup folder and it sorta just works and thank god that's not an issue anymore we can just get back to fixing the line.

Every time it fails you can try again from a slightly different vantage point, retreating further as it fails, perhaps appropriately, you need to spend a day on the phone with tech support and get the damn thing done right.

Sounds like horror stories I have heard about working in investment banks (or non-tech companies in general...)

Microsoft actually did release a good tool for the non-professional segment for writing database apps called lightswitch, that was better, higher level than VB. But they stopped selling it after some time. Shame.

It's actually a general problem in the market for software development tools, somehow the market for them isn't functioning well, and some great tools that we know how to build aren't produced.

Lightswitch was an amazing example of poor positioning. If you looked at the marketing material for it, it was positioned as a tool to "build three tier web applications" followed by a bunch of words that I didn't really understand.

It's really sad, because the tech there was really impressive.

Was that the tool that always tried to install with VS?

For a very brief period of time it was actually a standalone product that was being developed when I was at MSFT (2010ish), but eventually they just rolled it into VS.

Lightswitch was also tightly coupled with Silverlight when first released. The death of Silverlight doomed it. I believe that there is an HTML output version, but I doubt there is much interest.

I taught myself to program at a professional level working on VB.NET. nothing i'd ever tried "clicked" with me until i could see all the pieces coming together. The syntax reminded me of old VBA macros I'd built, and there was a great online support community. (Stack Overflow is an incredible resource). I still work in VB.NET but i also use C#, R, and a bit of Python.

And of course, my VB.NET usage was all industrial test automation, it's the closest language to the VBA/VB6 that all the engineers were familiar with, easiest way for them to get comfortable with our solution.

Agreed. My start as a professional developer was an internal tracking tool that started as an Excel spreadsheet, which I turned into an Access database... added numerous VBA macros... once I'd hit that limit I created an entire frontend in VB.NET, which led me to C#...

I've left it all long behind now, but those were some great building blocks. It was around a decade ago, and when I left the company they had announced plans to replace everything (my code included) with SAP. Last time I spoke to someone there (about three years ago) that plan has still not been completed.

My journey into programming is exactly the same.

My first real desktop application written in VB .Net has been used once a month for 6 years, and is still going strong, even after I've left the company.

Like a dead relative, when I think of VB6 I look back fondly on being able to edit live code at a breakpoint without having to restart the debugger, and ignore the traumas like the interface to the win32 API and the half-baked error handling.

What is "real programming" anyways? What separates VB6 from the "real programming" languages? Try to answer this question not from the perspective of an opinionated programmer, but in the general framework of "what it takes to make a working product using VB6 versus other things out there"?

VB6 is basically as simple as a form builder to start with. You start with designing forms for every screen you need and then write logic for specific events, like a button click event etc. It was much more simpler than say a modern framework based on MVC.

I don't see why you couldn't still do this with WinForms in VB.NET or C#

You can, but it's not as simple.

VB6 would spit out an exe that could often be installed by just copying it to the client machine.

You could also generate DLLs that other applications could easily load and use. These days you can still do it, but it's much more complicated (i.e. registration-free COM).

I'm pretty sure that Windows Forms in C# is still pretty lenient in this regard. It'll give you an .exe file that, if you only reference a single project in your solution, you can copy directly onto a target machine and run. If you're referencing multiple projects, it'll compile DLLs from them and you'll need to copy over those as well.

I love Windows Forms for prototyping stuff for this reason. There's much less overhead and GUI prototyping is super fast. It falls apart if you have a complex application that needs to be maintained over time by multiple people, but it's great for just getting some simple task done. I think the current generation of web programmers miss out on some really useful tools by always thinking in terms of client/server. It's not always that you want or need a webapp to solve your problem.

All of what you mention is doable in VB.net.

VB.net introduces a few rough edges, everything is class based, you have namespaces, lambdas, etc. But honestly the step from VB6 to VB.net is a pretty modest step, and when you have tasted generics, linq and its collection extensions functions (OrderBy, First, Last, Max, etc), a consistent collection indexing (VB6 switches between 0 based and 1 based), got rid of that useless "set" keyword, made all function parameters byval by default, which avoids having to write byval before every parameter, used lambdas (there are quite many problems where it is just nice to give a callback as a parameter), type inference, initializing a variable on the same line it is declared, multi-threading, etc, you won't go back to VB6.

I fully accept the non backward compatibility of the code argument. If it's a big project, and it's working, and it's in VB6, I can understand not upgrading it. But in term of functionality VB6 is way behind modern VB.Net.

It's been a while since I've dealt with them, but I know we had a bunch of DLLs written with VB6 that we could use the standard way:

LoadLibrary load the DLL, then GetProcAddress to find the function, then call it.

We converted some of these to VB.Net and then had to jump through a bunch of hoops (reg-free COM) to use it in that way.

I guess it depends what you want to consume your DLL from. A .net DLL can be consumed by a .net application without any form of registration, and I would assume this would be the typical use case. It's only if you want to expose your DLL with a COM interface to be used by other languages that you need a COM registration.

The step from VB6 to VB.NET is far from “modest”. There are many fundamental differences between the two. For the most part VB.NET is a strict improvement over VB6, but there are a few things VB6 does better than VB.NET:

(0) Reference counting: VB6 cleans up arbitrary resources (not just memory) in a deterministic fashion. Think RAII, minus the dangling references and associated gotchas. In business application programming, not worrying whether you closed database connections in the right places is a major productivity boost.

(1) Programmer-defined lower and upper array bounds. You iterate an array's index range with `For idx = LBound(arr) To UBound(arr)`. It's as clear as it gets.

(2) Dyamically resizable arrays. VB6's `ReDim` doesn't give you a new array object - it really changes the size of the existing one. By contrast, VB.NET's `ReDim` is just sugar for replacing a fixed-size array with another, which is why it can only be used locally inside a method. The officially sactioned solution is to use `List`s, but `List`s can't be multidimensional.

(0) In VB.net:

Using Cn as new SqlConnection()

End Using

Will release the connection as soon as you get out of the using. Actually better than that, ADO.net will keep the connection alive for a few seconds such that if you make another connection to the same server, it reuses connections. I think VB.net still uses reference counting. But it does full garbage collections in addition to that.

(1) The syntax has changed but does the same thing: For Idx = arr.GetLowerBound(0) To arr.GetUpperBound(0).

(2) I don't think VB6's redim preserves the array. It resets it to its default values. You have to use "ReDim Preserve" instead, which has the same behavior in VB6 and VB.net. And I think I remember that either way you can only Redim the last dimension of the array.

I think list feels more natural, I don't see a lot of value in writing explicitly the redim part of the code. I'd rather my code to focus on what I am trying to achieve, not some low level plumbing.

(0) The problem with `Using` is that you can forget to use it. Or you can use it with the wrong object. It's no better than `free()` in C. On the other hand, you when you program in VB6, you can't forget to reference-count your objects, because the language implementation does it for you.

(1) Noted.

(2) I know the difference between `ReDim` and `ReDim Preserve`. And I'm not talking about the array's contents, I'm talking about the array's object identity. In VB6, both `ReDim` and `ReDim Preserve` preserve the array's identity in spite of the size change. .NET arrays don't support resizing at all, so VB.NET hides the limitation by only allowing `ReDim` on local array variables, and implementing it internally in terms of swapping array objects.

And `List` stops being natural when you want it to be multidimensional.

(0) you can forget to call "Dispose" but the benefit of using "using" is that Dispose will get called whichever way you get out of the scope. Using "using" for disposable types ends up being some reflex and it would seem odd to me to see new SqlConnection without a using.

(2) I am not sure I agree with that either. The following in VB6 returns 10, i.e. the second redim has created a new instance of an array:

Dim V() As String, W() As String

ReDim V(10)

W = V

ReDim V(20)

MsgBox UBound(W)

(0) You can't forget to call “Dispose” if you need objects to be cleaned up in a specific order.

(2) Try this:

    Dim V() As Long, W() As Long, i As Long
    
    ReDim V(1 To 10)
    For i = LBound(V) To UBound(V)
        V(i) = i
    Next i
    
    W = V
    For i = LBound(W) To UBound(W)
        W(i) = 2 * i
    Next i
    
    Call MsgBox(V(5))
    Call MsgBox(W(5))

You can do this in Windows Forms. You can (or could) drag a DB connection onto a form, hook it up to a grid, and have a CRUD app out in minutes. You could even do that in ASP.NET Webforms. But for cultural and technical reasons, it is frowned upon, even when wholly appropriate.

The biggest knock against VB6 being a "real programming" language has much to do with its pedigree as a proprietary language largely meant for a proprietary platform evolved from earlier language designs meant for 8-bit (GW-BASIC) and 16-bit (QuickBASIC/QBASIC) systems. There never was a committee to guide its development and set standards, and hardly any competing implementations to a standard for it. Furthermore, there's barely a community that can regularly voice their concerns and desires (beyond whatever forum Microsoft may provide) in regards to its evolution.

The various warts of VB6 (such as ON ERROR GOTO, lack of function pointers, GOSUB/RETURN, lack of equivalents to the +=, && and || operators of C, etc.) weren't beyond repair (after all, VB.NET is a great language taken on its own merits, with a few warts intentionally retained), but the true owner of Visual Basic apparently wanted to do a dramatic reboot of things and otherwise retire VB6. And it could and did so quite easily, there being no standards committee to answer to, and no community to negotiate with.

Don't get me wrong, VB6 is real enough in that people were able to do a lot of cool and useful things with it, and even took it levels way beyond the originally intended by Microsoft. So yeah it's a real programming language. Just not "real" enough for some.

And, for me, using Bruce McKinney's stuff[1] really helped fill the gaps. One of the things he said that really stuck with me was "Visual Basic makes 95% of the work really easy and 5% of the work impossible" (probably paraphrasing a bit). And then he'd go on to show you how to make a DLL in C++ that took care of the 5% and link it to your VB program. I stopped free lancing and making money off of VB somewhere between 5 and 6 so I wasn't really there for the whole transition to .Net. But before I found GNU and Linux I had a lot of fun with VB 4 and 5 and even managed to make a decent living from it for a while.

[1] Bruce McKinney, Hard Core Visual Basic http://vb.mvps.org/hardweb/mckinney.htm

VB6 is/was certainly "real programming". I took that line in the post to be kind of mocking to people that would say that it wasn't.

I did a lot of programming in Classic Visual BASIC and VB 6.0 was my favorite version of it. I was disapointed with the changes made in VB.Net because I had co-workers that didn't know how to program and VB 6.0 was easier for them to learn and be trained by me to use.

If you want to convert some VB 6.0 code to another language consider Jabaco: http://www.jabaco.org/

It will compile to a JAR file and it is based on VB 6.0 syntax. People asked Microsoft to open source VB 6.0 but Jabaco is as close as you can get to that without being sued by Microsoft.

Unfortunately jabaco is both closed-source and dead

http://www.jabaco.org/board/1411-jabaco-lifetime.html

I think we can apply basic lessons from VB6 now. 25 years later and we can't design Web UIs with the same simplicity.

I'd kill to be able to use a form designer like VB6's, with a better language, like Haskell or Python. Present-day Visual Studio's form designer isn't good enough.

I'd love a python-backed form designer. I've been wanting one for ages. I've experimented with making GUI's with wxPython before but it's pretty clunky. I would have loved a good form designer to help accelerate it and take care of the basics.

But nowadays everyone wants to make all GUI's everywhere web-based, it seems like. Which is okay, but much more to learn.

VB was to the desktop what PHP was for the web. An accessible and easy to learn platform that got a lot of people into building shit quickly. Hopefully most moved on since.

yeah, PHP is atrocious

I only used VB5 in the late 90s, but yes, absolutely.

When I was doing GUI stuff in Java (Netbeans and eclipse) in the mid 2000s... yes, all the OO stuff was better but boy did I miss that interface designer that just worked.

I remember a byte magazine article (maybe it was even on the cover) around the time of VB3 about how OO had failed in terms of what it had promised: re-use, productivity etc. But VB had more than succeeded on these fronts. Millions of programme were re-using these black box components. Not just the Microsoft ones. There was a big third party market as well. But it wasn't as sexy as OO. I think the article was wise enough to point out that it was OO but better than most implementations because of what it left out.

VB6 is still used in Indian Schools to teach programming. And it definitely is simpler than VB.NET for newbies.

Vb6 was before my time, but I think autohotkey has filled the vacuum pretty well. There are a bunch of alternatives still around, like autoit, quick macros...

In the '90s, we were all supposed to look forward to a "marketplace of pre-built objects," which could be bolted together to build applications. That didn't materialize, because (as I understood it) of the industry's failure to standardize compiler output so that object libraries written in C++ could be binarily compatible with other software (someone can elaborate on this if they have more details).

But there was one exception: VBXs. We did indeed write a lot of software for some very high-profile clients using drag-&-drop VBX controls, especially things like data grids. VBXs did largely deliver on the promises we all heard at the time.

The other big hype at the time was how the newly unified UNIX camps were going to wrest the desktop from Microsoft. We all know how that turned out (except the people who are still saying the same about Linux...)

I am a huge fan of the Microsoft ecosystem, and I spent a great many hours developing VB.NET code at the beginning of my career.

VB6 is a scourge. The fact that Joe in HR threw together an application in a weekend in a testament not to its accessibility but to its abject lack of maintainability.

I'm not sure I understand your position.

I mean, yeah, unmaintainable code sucks. But I think this highlights the need for more accessible coding. The web became huge because it was so accessible. Yes, it generated a lot of crap code, but if 10% of projects add value to society, the more projects, the more valuable projects.

> The fact that Joe in HR threw together an application in a weekend in a testament not to its accessibility but to its abject lack of maintainability.

I don't see how "easy/fast to create" necessitates lack of maintainability, nor that it is a statement AGAINST accessibility. (without regard to the quality of VB6)

I think the important part here is that (in your example), Joe in HR wrote an application that is important enough to be used but not important enough to be professionally rewritten in a "better" language. I don't really think that speaks to faults in VB6, but to a sizable and interesting market for a product that allows non-programmers to write simple programs.

I have known people writing apps in MS-Office like Access, Word, or Excel using VBA, and I was assigned to convert it to VB 6.0 and SQL Server.

Usually the over the weekend projects need debugging and error trapping and other things to it. I can't tell you how many Invalid Use of Null errors where avoided by using the trim function and adding a blank quote "" next to the variable that held data:

result = trim("" & RS(index))

Just a simple modification that new programmers didn't know.

That's sort of like applauding your neighbor for training his dog to always shit on your lawn

Of course it isn't. Some of the stuff people wrote in VB6 was (and still is) enormously productive.

Sure, and shit is productive in a biological sense. Doesn't mean I want to work with it.

You remind me of programmers who will bill a client $50k for a $2k problem under the guise of it being done "properly"...oh, and keeping it a secret that an "improper" $2k implementation was an option.

People heap scorn on auto mechanics (for example) that pad bills, but many people whose work doesn't get their hands dirty seem to think they are subject to a different moral code.

It depends on the client, and whether you're going to be on the hook (phone wise or legal wise) for the future of whatever you create.

The $2k prototype/hack has a way of becoming a business-critical thing when you're not watching.

> many people whose work doesn't get their hands dirty seem to think they are subject to a different moral code

Let's not try to turn this into some "workers unite!" nonsense. I don't think how dirty someone's hands get have anything to do with what we're talking about.

Using your extreme example, the the $2k option is wrapping half a roll of duct tape around a leak. The $50k option is buying warrantied parts directly from the factory (not OEM).

What both you and the parent ignore is that there's usually a perfectly valid $20k option (OEM) that is a fair middle ground.

> Using your extreme example, the the $2k option is wrapping half a roll of duct tape around a leak. The $50k option is buying warrantied parts directly from the factory (not OEM).

You haven't seen some of the things I have. There are some extremely dishonest people in this industry that would literally be in prison if they pulled financially comparable stunts in an industry that isn't so opaque.

He reminds me of an entire team of programmers who turned up their noses at VB, insisting that they work in VC instead. When, predictably, the VB prototype of the product worked perfectly well (the whole app was database-driven)... they were all fired and the product was finished by one designer and a team of contractors instead.

I think there is much to be said about Jack in IT who spent 6 months working on a program that doesn't even meet the business' needs in the end, for something Joe could have done over a week end.

Well if Joe in HR can throw it together in a weekend, surely a 'proper' programmer like you could replace it in one?

You seem to think that I'm making some sort of judgment against Joe, or that I think I'm better, or something of that sort. I didn't say or imply anything like that.

Oh?

> abject lack of maintainability

The judgement is against the platform, not Joe.

Implying VB6 code is intrinsically unmaintainable, which is obviously false.

Sir, you jest. However I have indeed seen Joe in HR throw stuff together in a weekend, and it worked, mainly because Joe knew his business intimately and Googleing VBA was easier than writing a business requirement.

Yes and it does the job. If it's unmaintainable as alleged then that's a refactoring job which is a lot easier imo than starting from scratch.

Joe from HR has given him his UI and undeniably laid out everything the code needs to do. Mr Real Programmer should just then get on, stick in his tests, refactor and quit whining about Joe's code.

After all what's he there for, did he expect Joe to do everything?