5 ms·

What is your use case for BASIC?

Koshkin 5y ago
I fondly remember Visual Basic 6 as one of the best general purpose development tools for Windows I have ever seen. As to the “use case”, it still seems like a nice interpreted language for tiny computers based on microcontrollers and for embedded platforms in general.
- jamesdwilson 5y ago
  20 year developer here who's touched many many different software stacks. Still to this day, nothing has lived up to the hype that was actually delivered by VB5 and VB6. Insane productivity.
  - resoluteteeth 5y ago
    > Still to this day, nothing has lived up to the hype that was actually delivered by VB5 and VB6. Insane productivity. People seem to say this a lot but I don't really understand it, because if you use c# with winforms in visual studio it's basically the same thing but better.
    - laumars 5y ago
      Depends on the domain. C# is undoubtedly a lot more powerful and C# runs faster, but your average C# program requires writing a hell of a lot more boilerplate code than your average VB6 program. Visual Basic had its warts. C# is a better language from an academic perspective. But VB filled a niche that nothing else has come close to: it made desktop application software writing ridiculously quick and easy. While still being maintainable, readable, and fun. Electron is probably the closest thing we have to that in the desktop world these days but somehow that performs even worse than VB6 did. Python or Go is probably the most analogous, if you think about command line programs.
      - teh_klev 5y ago
        > but your average C# program requires writing a hell of a lot more boilerplate code than your average VB6 program Not actually true. I just created a new C# Windows Forms application in VS, dragged a button onto a form, double clicked and it took me right to the event handler ready for me to do something. There's no additional boilerplate or ceremony required. Now sure there may be a whole bunch of code sitting in the "Form1.Designer.cs" partial class, but that's for the designer to manage, not you. And VB had this as well but the VB environment hid this until you went looking for it. Writing Windows Forms apps in C#/VS2019 is as easy as it was back in the VB5/6 days. I say this as a former VB4/5/6 (and, cough, ahem, MS Access) user knocking out all sorts of stuff back in the 90's.
        laumars 5y ago
        There’s more to writing software than just dragging a button onto a form ;) at some point you’re going to want to write your own classes, or manage the existing automatically generated ones. I’ve written sizeable software in both VB6 and C# (both professionally too) and yes, what I said is true about C# being a more verbose language. This isn’t intended as a criticism of C# either. It’s just a natural side effect of C# giving the developers more control. Plus there’s also a C vs ALGOL type argument with regards to which is easier for a newbie to read and write. C# might produce highly readable code to those already familiar with C-syntax but VB6 is ostensibly executable pseudocode. That alone counts for a lot when talking about the accessibility of programming languages.
        teh_klev 5y ago
        > There’s more to writing software than just dragging a button onto a form Clearly, but that wasn't my point. C# isn't a more verbose language, if anything it's more concise. My point was to refute your assertion that "your average C# program requires writing a hell of a lot more boilerplate code than your average VB6 program"...which isn't true. The C vs ALGOL type argument doesn't really stand up for me. I have junior devs on my team who've arrived straight out of bootcamps, college, self-taught etc with a broad spectrum of shallow language skills (PHP, VB, VBA/Script, Java, Javascript), and none of them have trouble dropping into C# world when they've never used it before. C# isn't any more difficult to learn than VB or PHP. Getting up to speed with the .NET framework is a much larger challenge for them than picking up C#.
  - icedchai 5y ago
    It is sad to think we gave all that up for HTML/CSS/JS. Now, with "modern" tools, it takes a whole village to build and submit a simple form.
    - pjmlp 5y ago
      More insane are the younger generations that grew up with the Web, have no idea how productive native tooling can be and then give us Electron based crap.
    - littlecranky67 5y ago
      Its not HTML/CSS/JS that killed the RAD tools from the 90s/00s - it is security, multi-user and networking. I remember how quickly you can put together apps and forms using VB6 + visual designer. But security/permissions were mostly based on your Windows account user. I remember an ERP software that hardcoded the MySQL connection string with a god-mode user+password in a config file and relied on Windows permissions that only the ERP software itself (written in Delphi) could open it. User permissions were then encoded in that DB. Basically, one disassembly of the machine and extracting the config file from the harddrive would have allowed you full access to the db. Today, we use service layers (REST & Co.) to ensure permissions and access - something that would be equally complex when using VB/Lazarus today.
      - icedchai 5y ago
        I'm not convinced RAD tools couldn't have been made to work with REST services or something else, like SOAP. SOAP probably would've been better for this. As much as I hated the complexity of SOAP, being able to generate clients from a WSDL was pretty cool.
- spullara 5y ago
  Using Microsoft's Jview JVM COM-Java integration (this is like '98 time frame) you could more easily run VB 6 apps against Java application servers because you only needed to distribute the client jar to the VB app. Since there was no early binding you didn't need the code you were going to call remotely on the client, it could just download the classes at runtime and use reflection to make the required calls. Drastically reduced any sort of jar/dll hell.
mdp2021 5y ago
> your use case for BASIC Answering not really about 'BASIC', but "PureBasic" (it is not the abstract language but the product). Personally: Whenever I want to do some fast coding. And then, in my case, basically all of my personal desktop applications and compiled shell commands. Because really, it is so pleasant to code on it. In general: When you want a lightweight, efficient, specialized environment to quickly get things done, in a framework that is close to low-level (memory structures etc.) and want a compiled result. And about the "BASIC" part: the BASIC implementation of PureBasic is practically not that different from "reasoning in C" (and you can use the C libraries upon need), but the PB libraries and the IDE makes writing comfortable. I basically never found a better alternative around this concept: light, powerful, fast, low-level, comfortable.

I fondly remember Visual Basic 6 as one of the best general purpose development tools for Windows I have ever seen. As to the “use case”, it still seems like a nice interpreted language for tiny computers based on microcontrollers and for embedded platforms in general.

jamesdwilson 5y ago
20 year developer here who's touched many many different software stacks. Still to this day, nothing has lived up to the hype that was actually delivered by VB5 and VB6. Insane productivity.
- resoluteteeth 5y ago
  > Still to this day, nothing has lived up to the hype that was actually delivered by VB5 and VB6. Insane productivity. People seem to say this a lot but I don't really understand it, because if you use c# with winforms in visual studio it's basically the same thing but better.
  - laumars 5y ago
    Depends on the domain. C# is undoubtedly a lot more powerful and C# runs faster, but your average C# program requires writing a hell of a lot more boilerplate code than your average VB6 program. Visual Basic had its warts. C# is a better language from an academic perspective. But VB filled a niche that nothing else has come close to: it made desktop application software writing ridiculously quick and easy. While still being maintainable, readable, and fun. Electron is probably the closest thing we have to that in the desktop world these days but somehow that performs even worse than VB6 did. Python or Go is probably the most analogous, if you think about command line programs.
    - teh_klev 5y ago
      > but your average C# program requires writing a hell of a lot more boilerplate code than your average VB6 program Not actually true. I just created a new C# Windows Forms application in VS, dragged a button onto a form, double clicked and it took me right to the event handler ready for me to do something. There's no additional boilerplate or ceremony required. Now sure there may be a whole bunch of code sitting in the "Form1.Designer.cs" partial class, but that's for the designer to manage, not you. And VB had this as well but the VB environment hid this until you went looking for it. Writing Windows Forms apps in C#/VS2019 is as easy as it was back in the VB5/6 days. I say this as a former VB4/5/6 (and, cough, ahem, MS Access) user knocking out all sorts of stuff back in the 90's.
      - laumars 5y ago
        There’s more to writing software than just dragging a button onto a form ;) at some point you’re going to want to write your own classes, or manage the existing automatically generated ones. I’ve written sizeable software in both VB6 and C# (both professionally too) and yes, what I said is true about C# being a more verbose language. This isn’t intended as a criticism of C# either. It’s just a natural side effect of C# giving the developers more control. Plus there’s also a C vs ALGOL type argument with regards to which is easier for a newbie to read and write. C# might produce highly readable code to those already familiar with C-syntax but VB6 is ostensibly executable pseudocode. That alone counts for a lot when talking about the accessibility of programming languages.
        teh_klev 5y ago
        > There’s more to writing software than just dragging a button onto a form Clearly, but that wasn't my point. C# isn't a more verbose language, if anything it's more concise. My point was to refute your assertion that "your average C# program requires writing a hell of a lot more boilerplate code than your average VB6 program"...which isn't true. The C vs ALGOL type argument doesn't really stand up for me. I have junior devs on my team who've arrived straight out of bootcamps, college, self-taught etc with a broad spectrum of shallow language skills (PHP, VB, VBA/Script, Java, Javascript), and none of them have trouble dropping into C# world when they've never used it before. C# isn't any more difficult to learn than VB or PHP. Getting up to speed with the .NET framework is a much larger challenge for them than picking up C#.
- icedchai 5y ago
  It is sad to think we gave all that up for HTML/CSS/JS. Now, with "modern" tools, it takes a whole village to build and submit a simple form.
  - pjmlp 5y ago
    More insane are the younger generations that grew up with the Web, have no idea how productive native tooling can be and then give us Electron based crap.
  - littlecranky67 5y ago
    Its not HTML/CSS/JS that killed the RAD tools from the 90s/00s - it is security, multi-user and networking. I remember how quickly you can put together apps and forms using VB6 + visual designer. But security/permissions were mostly based on your Windows account user. I remember an ERP software that hardcoded the MySQL connection string with a god-mode user+password in a config file and relied on Windows permissions that only the ERP software itself (written in Delphi) could open it. User permissions were then encoded in that DB. Basically, one disassembly of the machine and extracting the config file from the harddrive would have allowed you full access to the db. Today, we use service layers (REST & Co.) to ensure permissions and access - something that would be equally complex when using VB/Lazarus today.
    - icedchai 5y ago
      I'm not convinced RAD tools couldn't have been made to work with REST services or something else, like SOAP. SOAP probably would've been better for this. As much as I hated the complexity of SOAP, being able to generate clients from a WSDL was pretty cool.
spullara 5y ago
Using Microsoft's Jview JVM COM-Java integration (this is like '98 time frame) you could more easily run VB 6 apps against Java application servers because you only needed to distribute the client jar to the VB app. Since there was no early binding you didn't need the code you were going to call remotely on the client, it could just download the classes at runtime and use reflection to make the required calls. Drastically reduced any sort of jar/dll hell.

mdp2021 5y ago

> your use case for BASIC Answering not really about 'BASIC', but "PureBasic" (it is not the abstract language but the product). Personally: Whenever I want to do some fast coding. And then, in my case, basically all of my personal desktop applications and compiled shell commands. Because really, it is so pleasant to code on it. In general: When you want a lightweight, efficient, specialized environment to quickly get things done, in a framework that is close to low-level (memory structures etc.) and want a compiled result. And about the "BASIC" part: the BASIC implementation of PureBasic is practically not that different from "reasoning in C" (and you can use the C libraries upon need), but the PB libraries and the IDE makes writing comfortable. I basically never found a better alternative around this concept: light, powerful, fast, low-level, comfortable.