I'll copy one of my recent comments with some minor changes:
I still sometimes program in Classic VB, (aka VB6). Each year it is more difficult to install the IDE, but the runtime is still installed by default.
It is incredible easy to build a nice one screen application with not very a very complicated background logic. Normal people like a nice graphical interface with a few buttons, and with Classic VB you can create them very easily and iterate and customize the form.
My last big problem was that it doesn't have a build in sort function, so you can use a n^2 sort or write a good sorting function by hand :( . When the logic start to be not so easy, there begin to apear problems.
--
About the article: I agree with most of it.
> Also on the big side: There was no more edit-and-continue feature.
I still miss that when I program in other languages. It kills so many (all!) optimizations possibilities, but it's extremely handy.
The first money I made using a computer was writing simple business automation apps in VB, first 5 and for a short while 6. I also dabbled in Access Basic and then VBA when all the office apps standardized on it instead of each having their own flavor.
VB was great like you said until you needed to do something difficult. I remember Bruce McKinny’s Hardcore Visual Basic book being my best friend for a little while. It thought me I could do the hard stuff in C, make a DLL and drop that into my VB project.
Bruce had a saying, VB makes 95% of the job easy and the other 5% impossible.
I was going to make a reference to "Hardcore Visual Basic" but you beat me to it. Fantastic book, it's hard to find a tech book that is that useful and fun at the same time.
My first job started out with mostly Visual Basic 6. One of the modules written in VC++ by a bunch of guys who were looking to get that on their resume (they had since departed). It probably should have just been in VB as well and was always a nightmare to debug and enhance.
Once .net was prominent we mostly moved to C#. There didn't seem to be much of a reason to go with VB.Net, C# seemed more "legitimate" and without the hassles of Visual C++/MFC.
Decades later and I still find myself writing an Excel macro in VBA now and then but I've largely moved on.
Matt Curland's "Advanced Visual Basic 6: Power Techniques for Everyday Programs: Hardcore Programming Techniques" was a cracker of a book as well back in the day:
Maybe I'm missing something since I haven't touched any of this in years but isn't .net winforms builder the same experience but with a saner language ?
Agree. To me the VB.net improvement all made sense. But it is true that VB.net introduced a few complexities as well. Like strings can be null, so checking for emptyness is a bit more complicated. But also simplified other things, like I believe VB6 was using only reference counting for its garbage collection so it was important not to create circular references.
Visual Studio doesn't support edit and continue for 64 bit applications. I guess you can do your debugging in 32 bit but if that means compiling 32 bit versions of all your native libraries too, it's a giant pain.
I didn't know that, but I assume you're referring to native instead of .NET based? Java definitely supports editing while debugging so fairly sure MS would in C# and VB.net
It's more than a decade old. I doubt it's going to work with modern versions of Python and libraries. It's very sad it has been abandoned. The fact it has been probably means it was very difficult to maintain.
I always liked the Collection object in VB but for large number of items access by index was very slow. And Scripting.Dictionary couldn't access by index. So I wrote "DictCollection", a mix of Collection and Dictionary that can emulate both. With sorting, filtering, subcollection nesting, .Copy(), .Clone(), .ToArray(), .ToTable() and lots of String/Array manipulation functions. It's a universal data structure just like the JavaScript object or LUA table. It can act as a list/array, a key-value-store or an object tree. Take a look here https://github.com/karstenheld3/WhizzyVBA
>And though historians love to talk about the visual part of Visual Basic, its signature ability had nothing to do with graphical widgets. Instead, VB became famous for a legendary feature called edit-and-continue, which allowed developers to run their programs, find problems, fix them, and then keep going with the new code.
I agree that Edit-&-Continue was a nice debugging feature but I disagree that it was the main draw to VB. The main attraction to VB really was the easy-to-use graphical widgets which was exposed to the programmer via an abstraction called "windows forms".
If one takes a look at a 1990s era Win32 "hello world" app[0] written in raw C Language, it has tons of complicated boilerplate.
Lots of complexity with CreateWindow(param1, param2, etc, param11), GetMessage() loop, WndProc() callback. The Win32 HelloWorld example doesn't even handle a click event. One would have to add a switch case statement for the "WM_LBUTTONDOWN" message.
The VB "winforms" IDE eliminated all that and let a programmer "drag & drop" UI elements onto a "form" and put code on a "click" event. It was a clever simplification of raw Win32 API calls for business-oriented user interfaces. In the ~1991 era, the winforms abstraction empowered a bunch of 1980s 4GL programmers (e.g. dBase, Clipper, Foxpro) and business language programmers (e.g. COBOL) to immediately be productive writing apps for Windows -- without the steep learning curve of C/C++ and the raw Win32 API.
A lot of VB programmers I knew were not even aware of Edit&Continue but they nevertheless were able to drag a command button from the UI toolbox and add code to the button_click() event.
Another VB feature that I believe was more utilized than Edit&Continue was the VBX components ecosystem. Lots of programmers would buy add-on VBX widgets from various companies to enhance the UI such as calendar date picker, datagrids, charts & graphs, etc.
> I agree that Edit-&-Continue was a nice debugging feature but I disagree that it was the main draw to VB. The main attraction to VB really was the easy-to-use graphical widgets which was exposed to the programmer via an abstraction called "windows forms".
I'd disagree with both of you! VB's draw wasn't the edit-and-continue nor the drag-and-drop WYSIWYG GUI builder, it was all of the above plus more in a single self-contained package. VB was popular because you could do a lot of things using it, even if the depth provided by it was rather shallow (most people are fine with that). And if that wasn't enough, just grab some ActiveX control and it'll do what you want. VB was also built on the "common ground" of Windows tech, COM, essentially being the scripting language glue for Windows (yes Windows had a real scripting language - two in fact - but especially in the 90s, Windows=GUIs so it makes sense that The scripting language for Windows to be a one dedicated to GUIs).
It could have been better though, for example databases feel bolted-on instead of an inherent part of it, but i suppose if they added native database support (to the same level as native GUI support, not just talking to databases) it would cannibalize Access sales.
After a stint with VB 3.0, I focused into Delphi and C++ Builder as they were more in sync with my background and what I wanted from a programming language development environment.
It was only with VB 6.0 that VB finally got competitive regarding native code generation and ability to write OCX controls in VB itself.
Still, I do find VB.NET quite good even without the QuickBasic compatibility features, and the fact that I still see people move from VBA into VB.NET proves it is still approachable as on the old days.
For me it was the uncomplicated way of popping up a message box. Something which you cannot in most other stacks. Alert/console.log is also what makes JavaScript so accessible.
ActiveX and OCX was a generalization of VBX using OLE, a document embedding standard built on top of object-oriented RPC (COM), but with simplified typing (Variant rather than the full gamut of RPC native types).
The concept of drag and drop components, and the PME (Property / Method / Event) programming paradigm is what made VB a success. VBX and OCX were implementation technologies and not really the secret sauce, except to the degree that they made the system extensible so it wouldn't be forever a toy with a fixed set of building blocks.
[...]VBX components ecosystem. Lots of programmers would buy add-on VBX widgets from various companies to enhance the UI such as calendar date picker, datagrids, charts & graphs, etc
There was a lot of optimism at the time about how much of the more mundane software development would become the assembly pre-defined components and there'd be marketplaces of components. That's mostly not how things worked out but they did, for a while, for VBX. Seems like a bigger, more startling achievement than 'Edit & Continue' to me as well.
I remember getting catalogs in the mail with a huge list of VBX controls and all the amazing things it could add to your programs. It was a pretty amazing time.
>It is just UNIX world is still busy replicating text terminals and daemons.
We got TCL/Tk in the 90's and right now I am doing some TCL code with the help of expect and some TK UI.
Those replicating terminal and daemons forever and ever are just CADT Linux users who are trying to reimplement Unix poorly.
For everything else, TCL C bindings rock. Also, tcllib is pretty nice feature wise, too. For everyting else, as a RAD, TCL + SQLite, which is superior to Access on the DB field.
BTW, SQLite was born from a TCL developer, in TCL. Guess what's still used today, and which language, don't. Not even Access with VBA can match SQLite3's implementation.
Simplicity won in the end. The baroque interface of MS IDE's always gave a me a sense of innecesary bloat.
How did that vision not work out? Seems pretty on the money to me - only difference between then and now is that we ship components as JARs or node_modules etc, and the components are mostly free and open source vs proprietary products.
The basic vision that mundane programming would become the assembly of pre-built components has worked out astonishingly well though, to the extent that now many developers actually get upset if they're asked to write a program in an interview that isn't an assembly of pre-built components. They go on HN or reddit and post diatribes about how they should be asked to do "real" work, instead of coding up things they can just grab a component off github to do.
Arbitrary chunks of source or object code are not 'components' in a usefully meaningful way. You're not firing up Reactant IDE and making things out of Enterprise Java Beans and ACME WebWidgets.
> The main attraction to VB really was the easy-to-use graphical widgets which was exposed to the programmer via an abstraction called "windows forms".
This could be but it is worth noting that this style of development wasn't unique to VB. Turbo Pascal and later Delphi pioneered this style of development in the same era as VB, each with their own inventions in an arms race towards easy-to-use.
Yes, the ability to drag-and-drop widgets on to a form (essentailly a window or screen in your app) to contsruct a GUI was the killer feature of Visual Basic.
But Visual Basic couldn't create self-contained executables. You needed to distribute an accompanying runtime dll. This was often a source of frustration for Visual Basic programmers when distributing their programmes: users didn't sometimes have the right runtime dll installed.
In contrast, Delphi, which also had a drag-and-drop interface builder was more powerful, faster and created self-contained executables with no external dependencies. My impression (which may be wrong) was that there wasn't much cross-over between VB and Delphi users. I think many VB programmers found Delphi's Object Pascal too complicated compared to the simplicity of the VB language so there was never an exodus of VB users to Delphi.
Also the runtime.dll is not any different from having the right MSVCRT.dll around, all programming languages need some kind of runtime, even if a very basic one.
The difference is that in MSVC (as well as in most other compiled languages) you can statically link to the runtime. In many cases having a single self-contained EXE file is very convenient.
AFAIK OCXs need an installer, though you could stay within the limits of what is provided by the VB6 runtime that is already part of Windows. But it might be a better idea to not do that in the long term as Windows dropping VB6 support is more likely than dropping all Win32 support so at some point you may need to have a proper installer.
Regardless, i'm was referring to single executable cases where you just download an EXE file and run it without the need for some sort of decompressing an archive to a temporary folder (especially considering that most people nowadays use 7zip which has broken behavior when it comes to running executables from an archive: unlike WinRAR it only extracts the EXE file, not any other files the archive may have and the application may need).
Many Delphi VCL implementations are also COM objects, and even COM can be loaded via xcopy deployments, they don't need necessarily the register, it is called Side-by-Side Assemblies in modern Windows dev speak.
For very simple applications you can get with just the VB6 VM DLL but anything practical needs a bunch of OCX controls - even if you stick with the stock stuff you get with Visual Studio 6. AFAIK those OCX controls come with Windows for some years now so you can give someone a VB6 .exe and it'll work, but if you need anything outside of that you need to register them (unless i am wrong and VB6 can freeform OCX files directly but i'm almost certain it can only use stuff registered with the system).
Delphi VCL can use COM objects but on Delphi this is an exception rather than the norm, components on Delphi are (or can be) statically linked with the application. For VB6 the norm is using OCX controls... actually, i do not think it is possible to do anything else (outside of manually calling DLL functions of course, but even that is relying on a separate DLL).
That’s true if you didn’t use Visual C++ and its forms. They were click to edit and worked on a lookup table that was maintained by the wizard. But when things go wrong they are hard to debug.
Visual C++ and MFC were much better than raw Win32 API programming in this regard but they were still worlds more effort than VB. Honestly I still don't know of a development environment to this day which gives the same level of "just git 'er done" for hacking up small disposable applications.
Yeah, and after Windows API you'd probably try MFC. It was easier than WinAPI for nicer looking apps, but was hell compared to the nicer WinForms code/layout that VB got.
I’m so glad people are finally talking about VB! For a certain subset of programming, VB is very effective.
I’ve been working on “VB, but hosted in the cloud, and built specifically for developers”: https://tryretool.com. We’re still early, so I'd appreciate any feedback :). To use Retool, you’re ideally an engineer who knows both SQL and JS. We connect to most databases, as well as any arbitrary REST / GraphQL APIs.
"As the essay notes though, I think VB possibly made programming _too_ easy, which led to poorly built and poorly maintained apps."
This feels a little elitist to me. VB (and Access) allowed a lot of people to develop mission critical things rapidly they would never have been able to afford before.
When I look at the complex monstrosities we develop these days I don't know if they are in any way more maintainable or well-built. Yes the people who created them know them in and out but give them a few years to become legacy and outdated and they will become a maintenance nightmare.
Started programming with BASIC on a graphing calculator and it was easy to move on to C and Java from there. The use of english words over symbols and a lack of boiler plate and "concept clutter" is beginner friendly.
VB was the greatest thing I'd seen (before I saw SmallTalk or NeXTSTEP). I preferred the 1.0 'edit on your desktop' over the later nested window UX.
I had recently taken OS/2 Presentation Manager courses at Microsoft and started to tinker with making an OS/2 version. The toy turned into a client/server product for the company that produced code generator and analysis tools for enterprise. It eventually because a cross-platform tool running on OS/2 or Win NT and targeting OS/2 and Win32/Win16. A separate X11 editor targeted several Unixes using the same document format and generator templates.
VB and Delphi as well as other 'RAD' software from the 90's still has its fans, and some of these systems power very large installations even today. You wouldn't know about it because all you see is the outside but behind the scenes you'd be surprised what is running.
I think VB dead just because RAD is dead just like the article states:
Careless newbies, bored company workers, and summer students trampled in, solving challenges that would have been much more difficult on any other platform, and spraying spaghetti code everywhere.
In other words, because VB was easy enough to use even if you weren’t a trained coder, it was used by plenty of people who weren’t trained coders. And VB did nothing to encourage them to correct their bad habits.
As I recall, Kernighan and Ritchie in The C Programming Language admitted that C had "idiosyncratic syntax" (with lots of results on Google and I'll save time by not searching the book itself). Then C++ used that, and C# borrowed some of it.
The .NET version of Visual Basic, VB.NET, seems to be about as good as C# for getting at the .NET Framework and taking advantage of the "common language runtime" (CLR) but with more traditional syntax (Kemeny, Kurtz Basic, Algol, Fortran, Pascal, PL/I, etc.) easier to teach, learn, read, write, and debug. So, shock, I wrote the code for my startup in VB.NET! But, IIRC, there's a translator to convert at least one way between C# and VB.NET!
I've used this a number of times, it has its limitations and faults, but it's usually pretty good for sharing C# code example to a vb. Net dev http://converter.telerik.com/
Most enterprises still don't care for .NET Core due to lack of support for WCF, EF6 (including VS UI tooling) and third party libraries from component vendors.
In fact we just moved into .NET 4.7.1 this year for our greenfield applications.
And the way the whole WCF vs gRPC has been dealt with, might mean some will even wait longer than .NET 5, so not a big deal.
For most enterprises stale=stable and stable=good, so i'm certain as long as it works, they'll keep using it. Also see the topic of this submission (yes, some still use VB6).
Run existing code I am sure. But write new code for it I don't think so. Not the least because even in large organisations, devs like to use the latest and greatest.
> .Net full will become stale and legacy. I doubt enterprises will write new stuff on .Net full.
Sorry for the misunderstanding. I agree that Windows programmers will eventually migrate to .NET Core v5+. My comment was meant to be limited to the Linux scenario. I should have written "Linux" again in the 2nd sentence so that was more obvious:
- "It seems like the people embracing .NET Core on Linux are using it for writing backend services (scenarios where it competes with Golang usage)."
Microsoft has no plans to include the desktop UI technology of WPF & Winforms on Linux... even in the future unified .NET Core 5+ that deprecates classic .NET Full. Because the Linux side doesn't include all the Windows tech, it doesn't quite have the same 1st class status as Windows. But that limitation does not prevent C# programmers that want to use Linux from using it to write server-side network services (because no GUI required) where others might use Golang.
Given Go's features I doubt many .NET devs would feel like using it, instead of dropping into alternative languages with C#, VB.NET, F#, C++/CLI feature level.
Where I am, when .NET is not possible, the alternatives are either the JVM languages or C++, no one ever thinks of Go.
> Also remember that VB.NET, contrary to F#, enjoys equal footing with C# across all .NET deployment scenarios and Visual Studio graphical tooling.
enjoyed. Microsoft pretty much annonced it was a legacy technology and that they will not maintain parity going forward. Which is the only reason I switched to C#.
Microsoft made it very clear that VB.Net will not have equal footing with C# across all .NET deployment scenarios. The VB.Net being deliberately left behind for some future scenarios is a separate issue from your comparison with F#.
Just like VB did not had and equal footing with C (VBX) and C++ (OCX), yet it did not bothered many non programmers to pick it up.
This is the audience that Microsoft cares about.
The kind of employees that outgrows their Office VBA macros, did not had any kind of CS background, and just wants to do some applications without having to create a custom IT order procurement for it, writing some code and dragging stuff out of the toolbox.
The first version of the software that made our company launch back in the 90’s was made with Delphi with a browser like component that we discovered, after making successful demos to French historic telco leading to more visible demos, was a 30 days demo and that we couldn’t compile anymore without a message box stating that.
So due to emergency we rewrote all in a week in VB6 (or maybe it was 4 or 5 I don’t really remember) with the Internet Explorer browser object.
And thanks to the simplicity of Visual Basic it was possible to do so !
And then the demos lead to sales and we are still here 22 years later
I think it was Borland Delphi 3 or 4, and there where a browser object, perhaps based on IE, but demo.
It was in 1997 and it was not possible to order via Internet so the times the letter with the licence number arrive from US to France and we would have missed the important demo.
Plus, to be completely honest, we were totally broke !
Yet another interesting benefit of/interesting feature of VB is that it was the Python of its day in terms of the "there's a library to do that" factor. Not only was it easy to pick up, but (while not built-in like Python) it had access to thousands and thousands of easy to install and easy to use ActiveX libraries. There was almost always an ActiveX Library to suit your needs, ready to literally drop into the WYSIWYG editor and use.
That combined with the easy to use WYSIWYG editor and the edit and continue functionality were, to me, what made it such an amazingly useful language for creating quick utilities or small programs. It was truly a "Rapid Application Development" language.
I also saw some nightmares in my days, though I don't blame VB as much as the people who created the app. The most notable one was a document management system that I'd been asked to port from VB3 to VB6 (so that it could run on win32 among other reasons) and to turn the system from a batch system for document processing facilities into a desktop DMS for home use. I will never forget when I opened up the project and there were 60 some-odd "forms" in it, and when I opened any one of them up not a single one defined a variable. They all - every last one - was defined as a global variable in a single globals.bas file. There were thousands of global variables. Every single one in the entire application declared there, and edited at will in any of the myriad forms wherever they fancied. My first task became "untangle the global variable mess."
I learned BASIC in the late eighties. When VB appeared it was close, but not really BASIC. When VB.NET and Visual Basic for Applications (Excel/Access/etc version of VB) forked in all directions I had to write some VBA, but I ran away as soon as possible: from one language it forked to too many dialects that were too incompatible to matter. Divide and conquer transformed in divide and destroy. Now I use C# whenever VB would be a choice, I am not Microsoft's puppet to put up with the VB mess.
The people still developing in vb6 are a pretty relaxed lot these days, no one worries any more that the apps won't run in windows, they will, forever. It's still possible to get new activex components for skinning or whatever and if all else fails there's always interops with .net. Meanwhile the vb6 ide is lightning quick, designed as it was back in win 95 days, and with a couple of add ons can be very up to date.
I don’t get the appreciation for it. Back in those days every time I tried to do something in VB it felt like I was wearing oven mitts. Everything was so clumsy, “easy” in the wrong ways.
Something went wrong? No worries, we have `on error resume next`.
I still have two products in production that I am supporting, both written in Office Basic on Access - It's been over 10 years now.
And my search through FOSS has been for a similar environment, preferably supporting Python 3, now that I reflect upon it. Kind of a hold-over from working in Borland's ObjectVision back in the day, or FoxPro before that (the jump to Visual FoxPro caused me to stumble), or Paradox before that (as well as Ashton-Tate's DB2-3 and variants).
And yes, I am a hack who still manages to comment my code, at least at first. One of those "bad examples" I imagine c-corp professional programmers cite in TedX talks. But I do get paid :)
My first "real" job was fixing a VB6 app used in a manufacturing setting that consisted of one 3,000 line function, and one 2,000 line function.
And this was a critical system. It certified the units we made were configured correctly-- which were then installed in semiconductor fabs.
Also, VB6 is responsible for my favorite bug ever-- an if statement: no more than "if count=0 then" that opened a dialog box, somehow. It was reproducible as well.
I was shocked how fast it actually was. In the VB6 days, it was only slightly slower than the lovingly crafted ATL C++ code for some of the COM component development. It was crazy - rough out a VB component in a few hours, then spend a better bit of the week making it 'real'.
I learned to "seriously" program in VB. First in 6, then every version up through 2018. It was easy to get into because the hard parts (gui programming) were not done with code—or at least, not done with code you ever needed to look at. The error messages helped young me worry about logic and control flow instead of memory management. I got to learn how to build software that was good to _use_, practice algorithms with the insanely good debugger, and build actual executables that I could share.
This led me to JS and PHP (asp.net drove me away from .NET for web) which ultimately led to my current career.
Granted, there was a lot to learn after I left VB, but for a self-directed ten year old, it was the perfect tool. Whenever I see someone trying to teach a youngster C or C++ instead of VB, JS, or Python (or Ruby) I cringe because there's so much there that they don't seriously need to learn, especially if they're just interested in dipping their toes in software.
As a kid I dabbled with BASIC on an MSX, but the first real desktop app I made was with VB on Windows 98 if memory doesn't fail me. It was a catalog of Starcraft units.
152 comments
[ 3.4 ms ] story [ 176 ms ] threadI still sometimes program in Classic VB, (aka VB6). Each year it is more difficult to install the IDE, but the runtime is still installed by default.
It is incredible easy to build a nice one screen application with not very a very complicated background logic. Normal people like a nice graphical interface with a few buttons, and with Classic VB you can create them very easily and iterate and customize the form.
My last big problem was that it doesn't have a build in sort function, so you can use a n^2 sort or write a good sorting function by hand :( . When the logic start to be not so easy, there begin to apear problems.
--
About the article: I agree with most of it.
> Also on the big side: There was no more edit-and-continue feature.
I still miss that when I program in other languages. It kills so many (all!) optimizations possibilities, but it's extremely handy.
> VB.Fred and the .NET Solution
I call it VB# or VB#.Net instead of VB.Fred.
VB was great like you said until you needed to do something difficult. I remember Bruce McKinny’s Hardcore Visual Basic book being my best friend for a little while. It thought me I could do the hard stuff in C, make a DLL and drop that into my VB project.
Bruce had a saying, VB makes 95% of the job easy and the other 5% impossible.
My first job started out with mostly Visual Basic 6. One of the modules written in VC++ by a bunch of guys who were looking to get that on their resume (they had since departed). It probably should have just been in VB as well and was always a nightmare to debug and enhance.
Once .net was prominent we mostly moved to C#. There didn't seem to be much of a reason to go with VB.Net, C# seemed more "legitimate" and without the hassles of Visual C++/MFC.
Decades later and I still find myself writing an Excel macro in VBA now and then but I've largely moved on.
https://www.amazon.co.uk/dp/0201707128
Though it has been a while since its last update.
[1] https://en.wikipedia.org/wiki/Boa_constrictor
http://gambas.sourceforge.net/en/main.html
I agree that Edit-&-Continue was a nice debugging feature but I disagree that it was the main draw to VB. The main attraction to VB really was the easy-to-use graphical widgets which was exposed to the programmer via an abstraction called "windows forms".
If one takes a look at a 1990s era Win32 "hello world" app[0] written in raw C Language, it has tons of complicated boilerplate. Lots of complexity with CreateWindow(param1, param2, etc, param11), GetMessage() loop, WndProc() callback. The Win32 HelloWorld example doesn't even handle a click event. One would have to add a switch case statement for the "WM_LBUTTONDOWN" message.
The VB "winforms" IDE eliminated all that and let a programmer "drag & drop" UI elements onto a "form" and put code on a "click" event. It was a clever simplification of raw Win32 API calls for business-oriented user interfaces. In the ~1991 era, the winforms abstraction empowered a bunch of 1980s 4GL programmers (e.g. dBase, Clipper, Foxpro) and business language programmers (e.g. COBOL) to immediately be productive writing apps for Windows -- without the steep learning curve of C/C++ and the raw Win32 API.
A lot of VB programmers I knew were not even aware of Edit&Continue but they nevertheless were able to drag a command button from the UI toolbox and add code to the button_click() event.
Another VB feature that I believe was more utilized than Edit&Continue was the VBX components ecosystem. Lots of programmers would buy add-on VBX widgets from various companies to enhance the UI such as calendar date picker, datagrids, charts & graphs, etc.
[0] http://www.prowaretech.com/Computer/Windows/WinApiHello
I'd disagree with both of you! VB's draw wasn't the edit-and-continue nor the drag-and-drop WYSIWYG GUI builder, it was all of the above plus more in a single self-contained package. VB was popular because you could do a lot of things using it, even if the depth provided by it was rather shallow (most people are fine with that). And if that wasn't enough, just grab some ActiveX control and it'll do what you want. VB was also built on the "common ground" of Windows tech, COM, essentially being the scripting language glue for Windows (yes Windows had a real scripting language - two in fact - but especially in the 90s, Windows=GUIs so it makes sense that The scripting language for Windows to be a one dedicated to GUIs).
It could have been better though, for example databases feel bolted-on instead of an inherent part of it, but i suppose if they added native database support (to the same level as native GUI support, not just talking to databases) it would cannibalize Access sales.
It was only with VB 6.0 that VB finally got competitive regarding native code generation and ability to write OCX controls in VB itself.
Still, I do find VB.NET quite good even without the QuickBasic compatibility features, and the fact that I still see people move from VBA into VB.NET proves it is still approachable as on the old days.
The concept of drag and drop components, and the PME (Property / Method / Event) programming paradigm is what made VB a success. VBX and OCX were implementation technologies and not really the secret sauce, except to the degree that they made the system extensible so it wouldn't be forever a toy with a fixed set of building blocks.
There was a lot of optimism at the time about how much of the more mundane software development would become the assembly pre-defined components and there'd be marketplaces of components. That's mostly not how things worked out but they did, for a while, for VBX. Seems like a bigger, more startling achievement than 'Edit & Continue' to me as well.
https://www.devexpress.com/
https://www.grapecity.com/componentone-studio
https://www.componentsource.com/
https://www.tmssoftware.com/site/tmspack.asp
It is just UNIX world is still busy replicating text terminals and daemons.
We got TCL/Tk in the 90's and right now I am doing some TCL code with the help of expect and some TK UI. Those replicating terminal and daemons forever and ever are just CADT Linux users who are trying to reimplement Unix poorly.
For everything else, TCL C bindings rock. Also, tcllib is pretty nice feature wise, too. For everyting else, as a RAD, TCL + SQLite, which is superior to Access on the DB field.
BTW, SQLite was born from a TCL developer, in TCL. Guess what's still used today, and which language, don't. Not even Access with VBA can match SQLite3's implementation.
Simplicity won in the end. The baroque interface of MS IDE's always gave a me a sense of innecesary bloat.
It wasn't a match for anything related to GUI RAD tools.
In fact it teached me to never use a programming language without either JIT or AOT as part of their default toolchain.
And the Tk L&F back in 2000 would make any UI/UX just cry.
For example, https://www.devexpress.com/
The basic vision that mundane programming would become the assembly of pre-built components has worked out astonishingly well though, to the extent that now many developers actually get upset if they're asked to write a program in an interview that isn't an assembly of pre-built components. They go on HN or reddit and post diatribes about how they should be asked to do "real" work, instead of coding up things they can just grab a component off github to do.
This could be but it is worth noting that this style of development wasn't unique to VB. Turbo Pascal and later Delphi pioneered this style of development in the same era as VB, each with their own inventions in an arms race towards easy-to-use.
But Visual Basic couldn't create self-contained executables. You needed to distribute an accompanying runtime dll. This was often a source of frustration for Visual Basic programmers when distributing their programmes: users didn't sometimes have the right runtime dll installed.
In contrast, Delphi, which also had a drag-and-drop interface builder was more powerful, faster and created self-contained executables with no external dependencies. My impression (which may be wrong) was that there wasn't much cross-over between VB and Delphi users. I think many VB programmers found Delphi's Object Pascal too complicated compared to the simplicity of the VB language so there was never an exodus of VB users to Delphi.
Also the runtime.dll is not any different from having the right MSVCRT.dll around, all programming languages need some kind of runtime, even if a very basic one.
Regardless, i'm was referring to single executable cases where you just download an EXE file and run it without the need for some sort of decompressing an archive to a temporary folder (especially considering that most people nowadays use 7zip which has broken behavior when it comes to running executables from an archive: unlike WinRAR it only extracts the EXE file, not any other files the archive may have and the application may need).
Many Delphi VCL implementations are also COM objects, and even COM can be loaded via xcopy deployments, they don't need necessarily the register, it is called Side-by-Side Assemblies in modern Windows dev speak.
Delphi VCL can use COM objects but on Delphi this is an exception rather than the norm, components on Delphi are (or can be) statically linked with the application. For VB6 the norm is using OCX controls... actually, i do not think it is possible to do anything else (outside of manually calling DLL functions of course, but even that is relying on a separate DLL).
Though none of them are as seamless as VB but then again, they are more powerful as languages, so you get some and lose some.
VB only really died when C# WinForms came along.
I’ve been working on “VB, but hosted in the cloud, and built specifically for developers”: https://tryretool.com. We’re still early, so I'd appreciate any feedback :). To use Retool, you’re ideally an engineer who knows both SQL and JS. We connect to most databases, as well as any arbitrary REST / GraphQL APIs.
(Our docs are at https://docs.tryretool.com.)
Edit: removed a part I didn’t fully agree with, but paraphrased.
This feels a little elitist to me. VB (and Access) allowed a lot of people to develop mission critical things rapidly they would never have been able to afford before.
When I look at the complex monstrosities we develop these days I don't know if they are in any way more maintainable or well-built. Yes the people who created them know them in and out but give them a few years to become legacy and outdated and they will become a maintenance nightmare.
Looking around, I don't think these needed any help from VB to exist.
What's your front end stack?
I had recently taken OS/2 Presentation Manager courses at Microsoft and started to tinker with making an OS/2 version. The toy turned into a client/server product for the company that produced code generator and analysis tools for enterprise. It eventually because a cross-platform tool running on OS/2 or Win NT and targeting OS/2 and Win32/Win16. A separate X11 editor targeted several Unixes using the same document format and generator templates.
Good times.
Later versions including 6 could be switched back to SDI mode. I never liked it though, too confusing if you had stuff open in the background.
Their researchers aren't using R, Python or even eyeing on Julia.
They use Excel with VB macros and those skillful enough, get IT to install them Visual Studio Professional and carry on using VB.NET.
Also remember that VB.NET, contrary to F#, enjoys equal footing with C# across all .NET deployment scenarios and Visual Studio graphical tooling.
The .NET version of Visual Basic, VB.NET, seems to be about as good as C# for getting at the .NET Framework and taking advantage of the "common language runtime" (CLR) but with more traditional syntax (Kemeny, Kurtz Basic, Algol, Fortran, Pascal, PL/I, etc.) easier to teach, learn, read, write, and debug. So, shock, I wrote the code for my startup in VB.NET! But, IIRC, there's a translator to convert at least one way between C# and VB.NET!
C# <--> VB
In fact we just moved into .NET 4.7.1 this year for our greenfield applications.
And the way the whole WCF vs gRPC has been dealt with, might mean some will even wait longer than .NET 5, so not a big deal.
Yes, also the UI technologies of WPF and Winforms are not getting ported to Linux: https://github.com/dotnet/wpf/issues/607#issuecomment-487360...
It seems like the people embracing .NET Core are using it for writing backend services (scenarios where it competes with Golang usage).
Sorry for the misunderstanding. I agree that Windows programmers will eventually migrate to .NET Core v5+. My comment was meant to be limited to the Linux scenario. I should have written "Linux" again in the 2nd sentence so that was more obvious:
- "It seems like the people embracing .NET Core on Linux are using it for writing backend services (scenarios where it competes with Golang usage)."
Microsoft has no plans to include the desktop UI technology of WPF & Winforms on Linux... even in the future unified .NET Core 5+ that deprecates classic .NET Full. Because the Linux side doesn't include all the Windows tech, it doesn't quite have the same 1st class status as Windows. But that limitation does not prevent C# programmers that want to use Linux from using it to write server-side network services (because no GUI required) where others might use Golang.
Where I am, when .NET is not possible, the alternatives are either the JVM languages or C++, no one ever thinks of Go.
enjoyed. Microsoft pretty much annonced it was a legacy technology and that they will not maintain parity going forward. Which is the only reason I switched to C#.
Excerpt from https://devblogs.microsoft.com/vbteam/digging-deeper-into-th... : "But with regard to the cloud and mobile, development beyond Visual Studio on Windows and for non-Windows platforms, and bleeding edge technologies we are leading with C#."
Microsoft made it very clear that VB.Net will not have equal footing with C# across all .NET deployment scenarios. The VB.Net being deliberately left behind for some future scenarios is a separate issue from your comparison with F#.
This is the audience that Microsoft cares about.
The kind of employees that outgrows their Office VBA macros, did not had any kind of CS background, and just wants to do some applications without having to create a custom IT order procurement for it, writing some code and dragging stuff out of the toolbox.
So due to emergency we rewrote all in a week in VB6 (or maybe it was 4 or 5 I don’t really remember) with the Internet Explorer browser object.
And thanks to the simplicity of Visual Basic it was possible to do so !
And then the demos lead to sales and we are still here 22 years later
Why was it easier to rewrite all your code than just buy a license to the component though?
It was in 1997 and it was not possible to order via Internet so the times the letter with the licence number arrive from US to France and we would have missed the important demo.
Plus, to be completely honest, we were totally broke !
(Full disclosure: I work at Red Hat but my views do not necessarily reflect my employers views)
That combined with the easy to use WYSIWYG editor and the edit and continue functionality were, to me, what made it such an amazingly useful language for creating quick utilities or small programs. It was truly a "Rapid Application Development" language.
I also saw some nightmares in my days, though I don't blame VB as much as the people who created the app. The most notable one was a document management system that I'd been asked to port from VB3 to VB6 (so that it could run on win32 among other reasons) and to turn the system from a batch system for document processing facilities into a desktop DMS for home use. I will never forget when I opened up the project and there were 60 some-odd "forms" in it, and when I opened any one of them up not a single one defined a variable. They all - every last one - was defined as a global variable in a single globals.bas file. There were thousands of global variables. Every single one in the entire application declared there, and edited at will in any of the myriad forms wherever they fancied. My first task became "untangle the global variable mess."
Something went wrong? No worries, we have `on error resume next`.
With the Regex and Scripting runtim COM objects, tools like a string interpolator are within reach.
Then the company decides to bend it out of shape or slow down the development. People cannot do anything about it because it's corporate-driven.
And yet, people have not learnt the lesson.
And my search through FOSS has been for a similar environment, preferably supporting Python 3, now that I reflect upon it. Kind of a hold-over from working in Borland's ObjectVision back in the day, or FoxPro before that (the jump to Visual FoxPro caused me to stumble), or Paradox before that (as well as Ashton-Tate's DB2-3 and variants).
And yes, I am a hack who still manages to comment my code, at least at first. One of those "bad examples" I imagine c-corp professional programmers cite in TedX talks. But I do get paid :)
And this was a critical system. It certified the units we made were configured correctly-- which were then installed in semiconductor fabs.
Also, VB6 is responsible for my favorite bug ever-- an if statement: no more than "if count=0 then" that opened a dialog box, somehow. It was reproducible as well.
This led me to JS and PHP (asp.net drove me away from .NET for web) which ultimately led to my current career.
Granted, there was a lot to learn after I left VB, but for a self-directed ten year old, it was the perfect tool. Whenever I see someone trying to teach a youngster C or C++ instead of VB, JS, or Python (or Ruby) I cringe because there's so much there that they don't seriously need to learn, especially if they're just interested in dipping their toes in software.