6 ms·

What is "real programming" anyways? What separates VB6 from the "real programming" languages? Try to answer this question not from the perspective of an opinion

by lxe 10y ago

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"?

murukesh_s 10y ago
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.
- douche 10y ago
  I don't see why you couldn't still do this with WinForms in VB.NET or C#
  - criddell 10y ago
    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).
    - marvin 10y ago
      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.
    - cm2187 10y ago
      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.
      - criddell 10y ago
        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.
        cm2187 10y ago
        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.
        deleted 10y ago
        [deleted]
      - catnaroek 10y ago
        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.
    - ern 10y ago
      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.
- deleted 10y ago
  [deleted]
rskar 10y ago
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.
- smhenderson 10y ago
  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 http://vb.mvps.org/hardweb/mckinney.htm
khedoros 10y ago
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.

by lxe 10y ago

murukesh_s 10y ago

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.

douche 10y ago
I don't see why you couldn't still do this with WinForms in VB.NET or C#
- criddell 10y ago
  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).
  - marvin 10y ago
    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.
  - cm2187 10y ago
    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.
    - criddell 10y ago
      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.
      - cm2187 10y ago
        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.
        deleted 10y ago
        [deleted]
    - catnaroek 10y ago
      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.
  - ern 10y ago
    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.
deleted 10y ago
[deleted]

rskar 10y ago

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.

smhenderson 10y ago
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 http://vb.mvps.org/hardweb/mckinney.htm

khedoros 10y ago

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.