5 ms·
>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 fa
by jasode 7y ago
>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.
[0] http://www.prowaretech.com/Computer/Windows/WinApiHello http://www.prowaretech.com/Computer/Windows/WinApiHello
- badsectoracula 7y ago> 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.
- pjmlp 7y agoAfter 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.
- oaiey 7y agoFor 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.
- EdgarVerona 7y agoYes, ActiveX was the sauce that made VB quick and even fun to use! I tell people it was the Python of its day.
- barrkel 7y agoActiveX 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.
- pjmlp 7y agoAlso an idea that was explored in other 4GL tools of the day.
- pvg 7y ago[...]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.
- protomyth 7y agoI 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.
- pjmlp 7y agoYou can still get them https://www.devexpress.com/ https://www.devexpress.com/ https://www.grapecity.com/componentone-studio https://www.grapecity.com/componentone-studio https://www.componentsource.com/ https://www.componentsource.com/ https://www.tmssoftware.com/site/tmspack.asp https://www.tmssoftware.com/site/tmspack.asp It is just UNIX world is still busy replicating text terminals and daemons.
- anthk 7y ago>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.
- tomtomtom777 7y ago> 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.
- open-source-ux 7y agoYes, 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.
- pjmlp 7y agoIt could with version 6. 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.
- Crinus 7y agoThe 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.
- pjmlp 7y agoTrue, but hardly any different when doing xcopy deployments.
- Crinus 7y agoAFAIK 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).
- projektfu 7y agoThat’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.
- taneq 7y agoVisual 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.
- animal531 7y agoYeah, 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. VB only really died when C# WinForms came along.