11 ms·

For me VB6 was the pinnacle of GUI design/rapid prototyping. I know that many people are going to say I'm wrong and that VB6 was a cancer, but hear me out: o

For me VB6 was the pinnacle of GUI design/rapid prototyping. I know that many people are going to say I'm wrong and that VB6 was a cancer, but hear me out: o Drag and drop GUI designer o action oriented language o surprisingly advanced integrated IDE o It was easy, simple and reasonably fun to learn I know why QT/GTK and various other GUI systems use a HTML-y grid layout, but for me personally, I always struggle to make nice looking, well laid out, functional GUIs with them. just give me drag and drop, and ideally a python backend

secondcoming 5y ago
And the UI elements were all proper Win32 UI controls. I learned to program on VB6, and almost peed my pants when I got ownerdraw menus to work.
pjmlp 5y ago
I don' fully agree, only because I was rather on the other side of the fence with Delphi/C++ Builder. :) I always considered .NET a step backwards, versus doing something similar to what Borland was doing with Delphi/C++ Builder, meaning C# and VC++ should have provided better tooling based on COM, and then follow up with VB7. Ironically, when they tried to actually do that, with WinRT, they messed up the whole execution.
- fwsgonzo 5y ago
  VB6 was the last "real" VB program before .NET obsoleted it. I used it for decades when I was young, and I have never again used anything that was as good, as simple, as precise and as feature-complete. Debugging in VB6 was incredible. An incredible feat that I'm not sure has been repeated since? Perhaps the debugging capabilities of MSVC has caught up these days, in which case, kudos to them. Maybe something exists today in the form of webdev? I wouldn't know as I'm stuck in the deep-end (backend). I have used .NET the last few years. I made a full desktop application for someone, and I also wrote a map/level editor for a game in it. I have to say that I like C# a lot, but I don't like the editor, I don't like the graphical construction source file, because it's so easy to break your GUI. And I also hated the fact that drawing was slow on .NET no matter how hard I tried to make it fast.
  - pjmlp 5y ago
    For the Web have a look at OutSystems for example, it doesn't come as free beer though. Debugging in .NET is just as it used to be on VB6, not sure what you would still be missing from those days. As for breaking the GUI, it wasn't as if frm files were foolproof.
    - alex_hitchins 5y ago
      If I recall correctly, you could write new code during debugging sessions, move the pointer to it and run it. Very dynamic. We can now do some of these things in VS or other tools with .Net, however VB was much more powerful in this regard. I can only recall there being one statement that required a rebuild - was it CreateObject or similar?
      - zozbot234 5y ago
        You can do the same thing in many languages derived from LISP, but supporting all that runtime monkey patching requires having dynamic indirections everywhere which add a ton of overhead.
      - pjmlp 5y ago
        VS has been offering that since at least 2015 version, and improving on it since then.
        alex_hitchins 5y ago
        Indeed, it's come along way and I'm not knocking it. Point is thought this was there out the box with VB.
        pjmlp 5y ago
        Agreed, at least they eventually added it back, even the Me like objects.
  - projektfu 5y ago
- kej 5y ago
  Delphi 8 could have eaten then whole native Windows pie if they hadn't tried to chase Microsoft into the .Net world. It wasn't always pretty but it was so easy to throw together business apps that got the job done.
badsectoracula 5y ago
VB6 had several positives but i'd put the "mostly live" (e.g. modifying the code while it is running/debugged) features it had - more a dynamic scripting language and less a static compiled programming language - rather than those you mentioned since Delphi and C++ Builder did those better (i learned Delphi just by playing around with it when i was a teenager in the 90s - i barely even understood English at the time, so i'd say Delphi was also easy enough). > just give me drag and drop, and ideally a python backend There is Boa Constructor[0] which is a very Delphi/C++ Builder inspired IDE that uses Python and wxPython for the GUI. Sadly it seems to be abandoned with the last release being in 2005. For a modern (or at least still under active development) approach i'd suggest Lazarus[1], which is essentially a cross platform (works on Windows, Linux, Mac and a bunch of other OSes with Win32, Gtk1/2/3, Carbon, Cocoa and even Amiga GUI backends) open source Delphi written in Free Pascal. To see it in action, here is a video i made with it 7 years ago, making a 2D tilemap editor (the IDE is mostly the same, there have been a couple of minor changes but not anything big)[2]. [0] http://boa-constructor.sourceforge.net/Screenshots/ http://boa-constructor.sourceforge.net/Screenshots/ [1] https://www.lazarus-ide.org/ https://www.lazarus-ide.org/ [2] https://www.youtube.com/watch?v=_3JgeIUo1X0 https://www.youtube.com/watch?v=_3JgeIUo1X0
- ale42 5y ago
  Thanks for sharing these links! I also learned Delphi in the late '90s as a teenager, and still find Lazarus to be very useful to rapidly develop simple applications that have a GUI!
GekkePrutser 5y ago
I agree, it was super useful.i also loved the way you could call any DLL function on the system, making it very useful as 'glue' However it severely missed multi threading. You could make things semi -multithreaded by making sure everything was event-based but there were still so many calls that would lock the UI.
- shireboy 5y ago
  You’d just pepper Doevents() everywhere and it almost seemed multithreaded.
  - nedsma 5y ago
    I have forgotten that trick. Good ol' times. :)
  - GekkePrutser 5y ago
    I did, but many operations would still lock. Database operations in particular. But yeah DoEvents ftw.
  - ptx 5y ago
    Since win32 requires customizing the main event loop to handle e.g. non-modal dialogs, doesn't running nested event loops all over the place (which diverts the messages away from the custom main loop) break things like that?
- layer8 5y ago
  You could run stuff asynchronously using a hidden window. Basically you could use the full win32 API and use VB procedures as callbacks (e.g. as window procedures for your own window subclass). The book “Hardcore Visual Basic” explained how to do it: https://classicvb.net/hardweb/hardbook.htm https://classicvb.net/hardweb/hardbook.htm
matwood 5y ago
My first paid programming job while in college was writing VB5 (then VB6) Windows CRUD apps. Given the built in controls and controls packs one could purchase, I made some amazing looking GUIs that were pixel perfect. I think even now, it's hard to find something better for that narrow use case. VB.Net IMO was a step back. VB wasn't some great language, but the entire system was very productive and worked well with other MS technology of the time like MSSQL and Access.
- jenscow 5y ago
  VB.net was just awful. Only existed for a migration path, but the learning curve from VB6->VB.net is roughly the same as going to C#.
  - pjmlp 5y ago
    They improved it later with some VB6 compatibility packs, but yes, that should have been there from the beginning. Or as I mention on another thread, .NET should have been what was later WinRT, by improving COM tooling and that was it, but now we are 20 years too late to fix that.
    - 7thaccount 5y ago
      Can you be more specific on the 2nd paragraph for someone ignorant like myself?
      - pjmlp 5y ago
        You can start here for a complete picture, https://arstechnica.com/features/2012/10/windows-8-and-winrt-everything-old-is-new-again/ https://arstechnica.com/features/2012/10/windows-8-and-winrt...
    - jenscow 5y ago
      You're right, WinRT should have been much sooner. However, there wouldn't have been much hope for a cross-platform .NET if it were COM based... and cross-platform is one of the things keeping .NET relevant - Personally, I was (reluctantly) about to ditch .net until that.
samtheprogram 5y ago
Mirrors how I felt about iOS development through the 2010s for the same reasons, with the exception that the language, Objective-C, was likely holding it back in a way Visual Basic did not. I’ll always have an affinity for Objective-C but obviously a C-based language with pointers everywhere came with a learning curve. Swift could have solved this but the APIs were not stable at the time (I used it around 2.1) and the compiler sometimes would choke with somewhat hard to diagnose errors. It seems Interface Builder and Storyboards are getting replaced by SwiftUI these days (inspired by Elm/React).
- Cthulhu_ 5y ago
  I think I have the same experience; it was definitely a step up from what I've done most of my career (webapps), mainly because it was all integrated and unified. I didn't mind objective-C, we did run into tons of crashes due to e.g. http requests coming in for screens that were gone already, but that was a matter of sticking to some stricter coding standards. But as another commenter mentioned, it declines with scale; this is why Facebook spent so much resources into trying to make webapps on mobile work, because their application size and compile times just got out of hand. It's possibly also a reason why they split off Messenger from the main app at some point.
mysterydip 5y ago
Nothing I've used since has the same level of rapid prototyping and development VB6 made possible with its GUI. Debugging as well was a breeze. VB's inherited commands of string manipulation made possible a lot of niche parsing/conversion utilities I wrote for companies.
- 7thaccount 5y ago
  You should check out Rebol. You can do Tetris in like half a page of code.
  - exikyut 5y ago
    *Idly checks out where it's at* :( Last modified March 2014: https://github.com/rebol/rebol https://github.com/rebol/rebol And that's still just REBOL/Core, not REBOL/View.
    - Rexxar 5y ago
      It seems there is a very active fork : https://github.com/metaeducation/ren-c https://github.com/metaeducation/ren-c The merge request will be a little challenging if someone dares to try : "This branch is 6513 commits ahead, 14 commits behind rebolsource/r3:master"
    - 7thaccount 5y ago
      http://rebol.com/pre-view.html http://rebol.com/pre-view.html This is all I was trying to convey. Yes, it's not getting as much love and care as it deserves.
- JohnBooty 5y ago
  Back in the 90s fresh out of college I remember writing routines to validate phone numbers and email addresses and stuff like that in VisualBasic. Yeah, I didn't know about regular expressions at the time.... (facepalm) ...I was really just writing these things in straight up VB. I'm not knocking what you were doing; I'm sure you had the sense to use regex or something. I did not. lol
- 5y ago
Siira 5y ago
I think Windows Forms (C#/VB.NET) is still as easy.
- grujicd 5y ago
  Agreed. And now we also have edit and continue for .Net while debugging. Another thing, GUI libraries for Winforms like Devexpress are super rich and offer a lot out of the box.
- criddell 5y ago
  MFC is still around as well. I've been using it for 25 years now. Its drag-n-drop GUI builder is similar to the one in VB6.
  - pjmlp 5y ago
    And as surprisingly as it may seem, its tooling in Visual Studio is still way better than C++/WinRT after 5 years being pushed as the "future".
rco8786 5y ago
BASIC was my first language and VB6 was shortly after my first intro to GUI programming. I tend to agree with all your points, but I've never been able to fully convince myself that VB6 was just objectively "good" or if it was a first skill/nostalgia effect. I still think there is a really successful app ecosystem waiting to be built that is semantically similar to VB6 + Access but built with a more modern stack like SQLite + Electron + TypeScript.
- jenscow 5y ago
  > objectively "good" or if it was a first skill/nostalgia effect. When you consider the mainstream alternatives back then, by the time you've got the message-loop boilerplate working... in VB6 you've already created a functioning form with a database connection.
  - JohnBooty 5y ago
    When you consider the mainstream alternatives back then What were the mainstream alternatives? Folks always seemed to rave about Delphi. That seemed like the "grown up", "better" version of VB, though I never used it.
    - jenscow 5y ago
      MFC, or plain C/C++ win32. But yeh, Delphi was much better than VB (like how turbo pascal was better than QBasic), however it was more of a niche environment used mostly by independent vendors making consumer apps.
      - pjmlp 5y ago
        Niche where? It was everywhere in Europe. There is a reason why we still have Delphi conferences over here.
  - skeeter2020 5y ago
    You were almost writing full-fledged VB apps if you started with MS Access, made some forms and had a switchboard menu. A little VB Script and you were there.
kitd 5y ago
It was almost too good. It encouraged a load of professionals who, though talented in their own field, should never have been near an IDE, to "knock up" a quick GUI, hand it over to the dev team, and say "Here you go. Support this." ... in my experience.
- zozbot234 5y ago
  > "knock up" a quick GUI, hand it over to the dev team, and say "Here you go. Support this." Isn't a GUI mockup one of the best ways to come up with a consistent set of requirements for software? At least by making the mockup in VB rather than drawing it on paper, it can serve as a start for the actual GUI part of the program.
  - kitd 5y ago
    You're speaking as a pro software dev (presumably), and yes, VB was great for prototyping. The people I'm referring to didn't realise that such esoteric things as "requirements" or "prototype GUIs" were a thing, and just handed over a ball of spaghetti for us to support.
  - alex_hitchins 5y ago
    Thing is it was never a prototype, always the end product. Had a lot of Access systems that were created by people in their roles that got widespread use then grandfathered into general dev support too. These were always horrible but too big to change.
  - dokka 5y ago
    There have a few times that I presented a VB6 prototype along with a price and had my prototype purchased on the spot. Sometimes when a client says "We need this software now", they really mean it.
- heelix 5y ago
  It was useful for more than that. We built most of our COM components in C++. As we started prototyping COM components in VB... and discovered they were only about 5% slower and very easy to crank out. It was a heretical discovery kept very quiet.
zozbot234 5y ago
> I know why QT/GTK and various other GUI systems use a HTML-y grid layout, but for me personally, I always struggle to make nice looking, well laid out, functional GUIs with them. There's a very intuitive drag-drop GUI designer for GTK+, namely Glade. Sadly, it was abandoned as GTK+ transitioned to 3.x and 4.x. So the only supported workflow now is laying out your GUI in code. The intuitive "action-oriented" language should not be underestimated either. Though I assume it could be made idiomatic even in modern languages, by leveraging their support for the async programming model.
- MadcapJake 5y ago
  There is some work going into a new RAD tool that will support 3 and 4. https://gitlab.gnome.org/jpu/cambalache https://gitlab.gnome.org/jpu/cambalache
  - zozbot234 5y ago
    The Linux desktop's CADT syndrome strikes again. Why not just pick up maintenance of Glade itself? Why do we get this constant churn?
    - anthk 5y ago
      >Linux More like Gnome and RedHat. In the BSD-y world and people akin on GNU (Alpine, Hyperbola, Parabola...) people loves the CLI and some stuff like TCL/TK or even Perl/Tk / Perl/GTK2. And the tools work well and fast enough.
    - MadcapJake 5y ago
      If I had to guess I would say: more fun to develop a new system without any legacy code maintenance (GTK4 is a significant change in API). The idea with the new tool is to decouple the toolkit too so it will be fundamentally more resilient to churn.
    - supercheetah 5y ago
      Glade had a lot of problems, and core Gnomes devs really recommended against it[1]. I think that dev for Cambalache didn't want to try to figure that out. 1. https://blogs.gnome.org/christopherdavis/2020/11/19/glade-not-recommended/ https://blogs.gnome.org/christopherdavis/2020/11/19/glade-no...
dsugarman 5y ago
I agree. I knew I wanted to start programming in 3rd grade and it was such an intuitive way for me to learn. It let me spin up cool shit without a ton of overhead. Now I have 2 kids and I'm wondering what will be the equivalent for them when they're a little older. It seems like there's a lot out there designed for kids but it all seems so rigid like program your character instead of make your own program.
- zozbot234 5y ago
  Scratch is rather VBish in that you can endow "characters" with their own behavior and have them "react" to asynchronous events.
  - skeeter2020 5y ago
    Scratch is great for understanding a lot of the concepts like properties, branching and loops but IMO goes too far towards the visual side. I liked the paradigm of "perform the action on the object" then "write the code in the container" that gets created or linked. We didn't really have formal "user stories" back then but programming essentially walked you through the "when I ... then ..." process.
    - zozbot234 5y ago
      Typing text is a nuisance at a young age. Visual interaction makes sense as a starting point.
Dave3of5 5y ago
Problem with VB6 was that for small projects it was fine but for medium to large projects it gets out of hand very quickly. For example when you drag and drop toolbar items onto your form it automatically gives them a boilerplate name. You can rename these but you tend to find devs would forget so after a while just looking at the code you started to get Label1.Text = "blah". I seen that in just about every project and one I remember done by a Chinese dev with poor English he left all the controls with the boilerplate names and so it was impossible to reason about what was happening. Componentisation was also a problem in that you tended to have all your code connected directly to the form. So if you had a large form that done complex stuff it wasn't unusual to have a multi thousand line long form file. Separation of concerns was a problem in that again the code was attached to a form so you found UI code mixed in with proper business logic. This becomes very messy over time and tends to create very large event handlers the more a project grows. It was basically impossible to unit test which makes refactoring very risky. On large projects what generally happens then is that no one is willing to refactor anything as they don't really know all the scenarios. Over time this leads to code rot. It only ran on windows, while I'm sure there are ways to make it run under linux the main support was for windows and most orgs stuck to that. This ties in with the fact that you had to install the thing on your P.C. businesses hated this and still do. Things like people uninstalling it or problems locally with permissions and suchlike were rampant. Similarly updating was a pain on large projects you have to have something central install and do the update. Scalability was problematic on large projects especially since the forms app would often directly connect to the database. That meant the more user = more connections which on large project meant problems. The "solution" was some service or api which the app talked to but at that point it's no longer vb6 doing the heavy lifting and it's just become a UI. Small little tools or prototype apps was were vb6 shined brightly.
- zozbot234 5y ago
  > but for medium to large projects it gets out of hand very quickly. Yup, it was really built without sufficient attention to the "programming in the large" featureset, much like those BASICs of old. Of course this became less of an issue in VB.NET that was pretty much a C# equivalent. > it automatically gives them a boilerplate name. You can rename these but you tend to find devs would forget The "Object Inspector" interface to form-element properties (including its identifier in code!) was very unintuitive, so this was a predictable outcome. > Componentisation was also a problem in that you tended to have all your code connected directly to the form. Yes, because it was difficult to have a full global view of the code that might drive a refactoring. Each form element and event would bring up its own tiny window of code.
AnIdiotOnTheNet 5y ago
It is very sad that the idea of easy WYSIWYG GUI application development has pretty much disappeared since the 90s. It enabled so many things to happen that wouldn't have otherwise. Hypercard, VB, Delphi... At least there's still Lazarus.
- forgotpwd16 5y ago
  Delphi still exists and they recently added Linux support.
TrackerFF 5y ago
We had a class in college where we used VB.NET, and Visual Studio designer for GUI. It was a breeze, and most people had working applications up and running within days of class start. End project was to build a control/monitoring application for an electric motor. Sure, there were some hard limitations compared to "modern" GUI design tools, but for the domain (industrial machines), these things worked just fine.
- skeeter2020 5y ago
  > End project was to build a control/monitoring application for an electric motor This is actually a funny use-case for .NET as anything low-level and hardware oriented tended to be harder to do without the libraries, which (if they existed) weren't .NET Not sure what the hard limitations were that you refer to; VB.NET / C# where always the easiest way to get a windows GUI (WinForms) app running. For industrial computing solutions tended to use Windows CE and Windows XP with COM apps.
  - TrackerFF 5y ago
    This is ages ago - but IIRC, we did it something like this Motor - VFD - PLC - OPC server - OPC client The .NET Application worked purely as a GUI read/write data from/to the PLC. But of course there were other things involved, like database programming, API service, webdev. We made a very, very simple API in ASP.NET I think, and some website in PHP which would just plot the various motor values.
analog31 5y ago
I've still got VB6 apps running in the factory, that have required virtually zero maintenance in 14 years. I originally wrote them for testing during product development with the promise that "the dev team will write proper apps before we go into production." Famous last words. ;-) Then along came VB.NET, and I switched to Python. The big epiphany for me is that I no longer lay out GUI's. I let Tkinter lay them out for me. My realization is that anything I do deliberately other than just a simple vertical arrangement of widgets is likely to make things worse. What VB6 was letting me do, was to create GUIs that are no better than most industrial Crapware. I've also learned for the simplest things, not to make a GUI at all. People can modify some entries at the top of a text script and run it in the interpreter. At first glance, you'd think a GUI would make it easier, but people struggle with most custom GUI's anyway -- evidenced by noticing a sheet of paper at the work bench with handwritten instructions for using the software, whether it's something I wrote, or a professionally written app.
- gamblor956 5y ago
  Your "industrial crapware" survived for 14 years with basically no maintenance. Most software today can't even go a week without bugs. I think VB6 let you create some incredibly powerful, stable, useful programs, and everything you've done since has taken you further away from this ideal state. People can modify some entries at the top of a text script and run it in the interpreter. That is significantly harder for most people than just clicking on buttons.
  - analog31 5y ago
    >>> I think VB6 let you create some incredibly powerful, stable, useful programs, and everything you've done since has taken you further away from this ideal state. That's certainly possible. My job has changed since then, so I'm no longer in a position to write that kind of stuff any more. My present "clientele" tolerates the Python ecosystem well enough.
- cxr 5y ago
  > I've also learned for the simplest things, not to make a GUI at all[...] you'd think a GUI would make it easier, but people struggle with most custom GUI's anyway -- evidenced by noticing a sheet of paper at the work bench with handwritten instructions for using the software This is an advantage that the Web browser has that is sadly under-appreciated and under-utilized (even from Web developers). Many traditional desktop GUIs and modern Web applications would be better suited for their audience if they were instead executable SOPs. Think: a manual for how to use a given system, except at the point in the instructions where it's describing a certain feature, or where it calls for a certain step to be performed, there is some on-screen affordance that allows the reader to take care of it right there—right at the spot they're already looking at. Some programming notebooks try to do something like this, but they usually get it wrong. Raskin seemed to have the same epiphany (albeit pre-WWW) and wrote about GUIs being a "dead end".
bmn__ 5y ago
> just give me drag and drop `designer` does this. Instead of assuming Qt doesn't come with a RAD drag & drop, you could have spend two minutes to verify. > python backend https://doc.qt.io/qt-6/designer-using-a-ui-file-python.html https://doc.qt.io/qt-6/designer-using-a-ui-file-python.html
- hamstrung 5y ago
  The first sentence of your message is helpful and appropriate. The second sentence is unnecessary and rude. Relevant: https://xkcd.com/1053/ https://xkcd.com/1053/
nickstinemates 5y ago
VB4->VB6 was the golden age of GUI development.
mring33621 5y ago
Visual J++ All the good VB6 parts, plus a better language for any code needed.
- pjmlp 5y ago
  Minus AOT compilation, though.
beamatronic 5y ago
This, but on Linux, would change the world.
specialist 5y ago
> pinnacle of GUI design/rapid prototyping Ditto database work. The client/server paradigm is the corpus calloscotomy (split brain surgery) of our industry. Begetting ORMs, LINQ, ActiveRecord, chaotic mutant query language templating system of the week, and other well-intentioned but ultimately detrimental efforts. All being unwitting attempts to regain what was lost. Famously described by Ted Neward's "Vietnam of Computer Science" rant. http://blogs.tedneward.com/post/the-vietnam-of-computer-science/ http://blogs.tedneward.com/post/the-vietnam-of-computer-scie... Though Neward somehow avoids identifying the root cause (client/server). FWIW, I did a bunch of R:Base, dBase/FoxPro, Access, and FileMaker (ahem) projects, back in the day. Sadly never had an excuse to use Paradox in anger, which I understand was the pinnacle for "workgroup" apps (LAN-based, meaning shared access thru file locking).
burnte 5y ago
It was great for rapid prototyping. the problem was when people then shipped those prototypes to billions of users. :P
selykg 5y ago
VB6 was the thing that got me so interested in development. I honestly miss it a ton. Everything now requires so much more to just make a simple app for something, and I'm on a Mac so it's even more of a pain.
ivanhoe 5y ago
VB was basically the MS response to Borland's Delphi, which had all this but better, plus Pascal was way more powerful and mature language than Basic. That said, both Delphi and VB (and VC++ to some extent) were IMHO far superior tools for RAD building of GUI apps than any web-oriented tool that I've later seen. In web development we're still in Turbo Pascal and Quick Basic days, we've got good IDEs and helpers but you still have to write everything by hand.
- deleted 5y ago
  [deleted]
- jasode 5y ago
  >VB was basically the MS response to Borland's Delphi, No, that wasn't the timeline. Visual Basic came out in 1991. Borland Delphi was +4 years later in 1995. (Borland Turbo Pascal for Windows was 1991 but Microsoft VB's internal product development codename "Thunder" was already started in 1990.) Visual Basic (especially the GUI forms IDE paradigm and VBX components) was built on earlier ideas in 1988 by Alan Cooper : https://en.wikipedia.org/wiki/Alan_Cooper#Visual_Basic https://en.wikipedia.org/wiki/Alan_Cooper#Visual_Basic
  - jhbadger 5y ago
    And earlier than this, there was Apple's HyperCard in 1987 which I'm sure both the creators of VB and Delphi were familiar with. HyperCard had buttons and fields that you dragged onto a window to make an interface, and then by clicking on these widgets you had access to their properties and could write code to have them do something.
  - Stratoscope 5y ago
    This brings back fond memories. The wiki page does have a few inaccuracies. Here is a more detailed article from Alan himself: https://onezero.medium.com/my-one-phrase-resum%C3%A9-98776ef8a6fa https://onezero.medium.com/my-one-phrase-resum%C3%A9-98776ef... (Try an incognito window if Medium blocks you.) That article has a few inaccuracies too, but as the events were over 30 years ago, this can be forgiven. Read Alan's article and then come back for this followup. Alan mentioned the "gizmos". He actually originally called them "waldos", named after these: https://en.wikipedia.org/wiki/Remote_manipulator https://en.wikipedia.org/wiki/Remote_manipulator I couldn't make sense of that name, so I suggested "gizmo", which seemed fun and more descriptive. That name stuck - for a while. Microsoft later renamed them to "controls". How boring! I also developed the "gizmo interface", which Microsoft renamed to VBX. (They were really not into fun names at the time.) It has sometimes been said that Bill Gates was the one who insisted that VB have an extension interface like this. The truth is more subtle. We had the gizmo interface all along. It was obvious that we would need it for our own gizmos, and that we should allow other developers to build their own gizmos. Apparently, the Microsoft team that turned Ruby+Basic into VB was going to keep the gizmo interface private and only let Microsoft developers use it, at least at first to save time on the schedule. Bill quite rightly saw the power of exposing the interface to outside developers and decided to make it part of the product - just as we had planned all along. And I built the "event arrows" that Alan mentioned. He originally called an event a "flimsy" (a British term for "lightweight paper used especially for multiple copies"). I couldn't make sense of that name either, so we kicked it around and settled on "event". This left a problem of what to name the act of sending an event from one gizmo to another. I was familiar with the term "trigger" from SQL, but that didn't seem quite right, and we were into fun names. But I couldn't think of one! At the time, when I got frustrated with a coding or naming problem, I had a habit of firing rubber bands at my IBM Monochrome Display to shake up my thinking. (Don't try this with a modern flat panel.) That didn't give me any ideas. So I decided to fire up a doobie and see if that would help. As I flicked my lighter and looked at the fire, it all came together: Fire a rubber band. Fire up a doobie. Fire an event! AMA, and I will see if I can remember...
markus_zhang 5y ago
UnrealEd 1 was coded in Visual Basic. I was very surprised when heard about this. The core rendering part was probably done in another language though.
andi999 5y ago
Why are there no visual development tools (drag n drop) for web? Or are there?
- zubairq 5y ago
  Yes I built one at yazz.com
- haunter 5y ago
  Elementor https://elementor.com/ https://elementor.com/ https://github.com/elementor/elementor https://github.com/elementor/elementor
- pjmlp 5y ago
  OutSytems, one of the best out there. https://www.outsystems.com/p/modern-development/ https://www.outsystems.com/p/modern-development/
bitwize 5y ago
I'm the opposite. Anything I create in a GUI builder is going to look like ass, with potentially misaligned widgets unless there's automatic widget alignment. And of course, things built in VB did not handle window resizing or different resolutions/DPI very well... Now, Tcl/Tk... which lets me just code up a GUI declaratively, feed it to a REPL, and get results that look... less like ass... that's a JATO bottle for UI productivity that's unmatched by anything.

secondcoming 5y ago

And the UI elements were all proper Win32 UI controls. I learned to program on VB6, and almost peed my pants when I got ownerdraw menus to work.

pjmlp 5y ago

I don' fully agree, only because I was rather on the other side of the fence with Delphi/C++ Builder. :) I always considered .NET a step backwards, versus doing something similar to what Borland was doing with Delphi/C++ Builder, meaning C# and VC++ should have provided better tooling based on COM, and then follow up with VB7. Ironically, when they tried to actually do that, with WinRT, they messed up the whole execution.

fwsgonzo 5y ago
VB6 was the last "real" VB program before .NET obsoleted it. I used it for decades when I was young, and I have never again used anything that was as good, as simple, as precise and as feature-complete. Debugging in VB6 was incredible. An incredible feat that I'm not sure has been repeated since? Perhaps the debugging capabilities of MSVC has caught up these days, in which case, kudos to them. Maybe something exists today in the form of webdev? I wouldn't know as I'm stuck in the deep-end (backend). I have used .NET the last few years. I made a full desktop application for someone, and I also wrote a map/level editor for a game in it. I have to say that I like C# a lot, but I don't like the editor, I don't like the graphical construction source file, because it's so easy to break your GUI. And I also hated the fact that drawing was slow on .NET no matter how hard I tried to make it fast.
- pjmlp 5y ago
  For the Web have a look at OutSystems for example, it doesn't come as free beer though. Debugging in .NET is just as it used to be on VB6, not sure what you would still be missing from those days. As for breaking the GUI, it wasn't as if frm files were foolproof.
  - alex_hitchins 5y ago
    If I recall correctly, you could write new code during debugging sessions, move the pointer to it and run it. Very dynamic. We can now do some of these things in VS or other tools with .Net, however VB was much more powerful in this regard. I can only recall there being one statement that required a rebuild - was it CreateObject or similar?
    - zozbot234 5y ago
      You can do the same thing in many languages derived from LISP, but supporting all that runtime monkey patching requires having dynamic indirections everywhere which add a ton of overhead.
    - pjmlp 5y ago
      VS has been offering that since at least 2015 version, and improving on it since then.
      - alex_hitchins 5y ago
        Indeed, it's come along way and I'm not knocking it. Point is thought this was there out the box with VB.
        pjmlp 5y ago
        Agreed, at least they eventually added it back, even the Me like objects.
- projektfu 5y ago
kej 5y ago
Delphi 8 could have eaten then whole native Windows pie if they hadn't tried to chase Microsoft into the .Net world. It wasn't always pretty but it was so easy to throw together business apps that got the job done.

badsectoracula 5y ago

VB6 had several positives but i'd put the "mostly live" (e.g. modifying the code while it is running/debugged) features it had - more a dynamic scripting language and less a static compiled programming language - rather than those you mentioned since Delphi and C++ Builder did those better (i learned Delphi just by playing around with it when i was a teenager in the 90s - i barely even understood English at the time, so i'd say Delphi was also easy enough). > just give me drag and drop, and ideally a python backend There is Boa Constructor[0] which is a very Delphi/C++ Builder inspired IDE that uses Python and wxPython for the GUI. Sadly it seems to be abandoned with the last release being in 2005. For a modern (or at least still under active development) approach i'd suggest Lazarus[1], which is essentially a cross platform (works on Windows, Linux, Mac and a bunch of other OSes with Win32, Gtk1/2/3, Carbon, Cocoa and even Amiga GUI backends) open source Delphi written in Free Pascal. To see it in action, here is a video i made with it 7 years ago, making a 2D tilemap editor (the IDE is mostly the same, there have been a couple of minor changes but not anything big)[2]. [0] http://boa-constructor.sourceforge.net/Screenshots/ http://boa-constructor.sourceforge.net/Screenshots/ [1] https://www.lazarus-ide.org/ https://www.lazarus-ide.org/ [2] https://www.youtube.com/watch?v=_3JgeIUo1X0 https://www.youtube.com/watch?v=_3JgeIUo1X0

ale42 5y ago
Thanks for sharing these links! I also learned Delphi in the late '90s as a teenager, and still find Lazarus to be very useful to rapidly develop simple applications that have a GUI!

GekkePrutser 5y ago

I agree, it was super useful.i also loved the way you could call any DLL function on the system, making it very useful as 'glue' However it severely missed multi threading. You could make things semi -multithreaded by making sure everything was event-based but there were still so many calls that would lock the UI.

shireboy 5y ago
You’d just pepper Doevents() everywhere and it almost seemed multithreaded.
- nedsma 5y ago
  I have forgotten that trick. Good ol' times. :)
- GekkePrutser 5y ago
  I did, but many operations would still lock. Database operations in particular. But yeah DoEvents ftw.
- ptx 5y ago
  Since win32 requires customizing the main event loop to handle e.g. non-modal dialogs, doesn't running nested event loops all over the place (which diverts the messages away from the custom main loop) break things like that?
layer8 5y ago
You could run stuff asynchronously using a hidden window. Basically you could use the full win32 API and use VB procedures as callbacks (e.g. as window procedures for your own window subclass). The book “Hardcore Visual Basic” explained how to do it: https://classicvb.net/hardweb/hardbook.htm https://classicvb.net/hardweb/hardbook.htm

matwood 5y ago

My first paid programming job while in college was writing VB5 (then VB6) Windows CRUD apps. Given the built in controls and controls packs one could purchase, I made some amazing looking GUIs that were pixel perfect. I think even now, it's hard to find something better for that narrow use case. VB.Net IMO was a step back. VB wasn't some great language, but the entire system was very productive and worked well with other MS technology of the time like MSSQL and Access.

jenscow 5y ago
VB.net was just awful. Only existed for a migration path, but the learning curve from VB6->VB.net is roughly the same as going to C#.
- pjmlp 5y ago
  They improved it later with some VB6 compatibility packs, but yes, that should have been there from the beginning. Or as I mention on another thread, .NET should have been what was later WinRT, by improving COM tooling and that was it, but now we are 20 years too late to fix that.
  - 7thaccount 5y ago
    Can you be more specific on the 2nd paragraph for someone ignorant like myself?
    - pjmlp 5y ago
      You can start here for a complete picture, https://arstechnica.com/features/2012/10/windows-8-and-winrt-everything-old-is-new-again/ https://arstechnica.com/features/2012/10/windows-8-and-winrt...
  - jenscow 5y ago
    You're right, WinRT should have been much sooner. However, there wouldn't have been much hope for a cross-platform .NET if it were COM based... and cross-platform is one of the things keeping .NET relevant - Personally, I was (reluctantly) about to ditch .net until that.

samtheprogram 5y ago

Mirrors how I felt about iOS development through the 2010s for the same reasons, with the exception that the language, Objective-C, was likely holding it back in a way Visual Basic did not. I’ll always have an affinity for Objective-C but obviously a C-based language with pointers everywhere came with a learning curve. Swift could have solved this but the APIs were not stable at the time (I used it around 2.1) and the compiler sometimes would choke with somewhat hard to diagnose errors. It seems Interface Builder and Storyboards are getting replaced by SwiftUI these days (inspired by Elm/React).

Cthulhu_ 5y ago
I think I have the same experience; it was definitely a step up from what I've done most of my career (webapps), mainly because it was all integrated and unified. I didn't mind objective-C, we did run into tons of crashes due to e.g. http requests coming in for screens that were gone already, but that was a matter of sticking to some stricter coding standards. But as another commenter mentioned, it declines with scale; this is why Facebook spent so much resources into trying to make webapps on mobile work, because their application size and compile times just got out of hand. It's possibly also a reason why they split off Messenger from the main app at some point.

mysterydip 5y ago

Nothing I've used since has the same level of rapid prototyping and development VB6 made possible with its GUI. Debugging as well was a breeze. VB's inherited commands of string manipulation made possible a lot of niche parsing/conversion utilities I wrote for companies.

7thaccount 5y ago
You should check out Rebol. You can do Tetris in like half a page of code.
- exikyut 5y ago
  *Idly checks out where it's at* :( Last modified March 2014: https://github.com/rebol/rebol https://github.com/rebol/rebol And that's still just REBOL/Core, not REBOL/View.
  - Rexxar 5y ago
    It seems there is a very active fork : https://github.com/metaeducation/ren-c https://github.com/metaeducation/ren-c The merge request will be a little challenging if someone dares to try : "This branch is 6513 commits ahead, 14 commits behind rebolsource/r3:master"
  - 7thaccount 5y ago
    http://rebol.com/pre-view.html http://rebol.com/pre-view.html This is all I was trying to convey. Yes, it's not getting as much love and care as it deserves.
JohnBooty 5y ago
Back in the 90s fresh out of college I remember writing routines to validate phone numbers and email addresses and stuff like that in VisualBasic. Yeah, I didn't know about regular expressions at the time.... (facepalm) ...I was really just writing these things in straight up VB. I'm not knocking what you were doing; I'm sure you had the sense to use regex or something. I did not. lol
5y ago

Siira 5y ago

I think Windows Forms (C#/VB.NET) is still as easy.

grujicd 5y ago
Agreed. And now we also have edit and continue for .Net while debugging. Another thing, GUI libraries for Winforms like Devexpress are super rich and offer a lot out of the box.
criddell 5y ago
MFC is still around as well. I've been using it for 25 years now. Its drag-n-drop GUI builder is similar to the one in VB6.
- pjmlp 5y ago
  And as surprisingly as it may seem, its tooling in Visual Studio is still way better than C++/WinRT after 5 years being pushed as the "future".

rco8786 5y ago

BASIC was my first language and VB6 was shortly after my first intro to GUI programming. I tend to agree with all your points, but I've never been able to fully convince myself that VB6 was just objectively "good" or if it was a first skill/nostalgia effect. I still think there is a really successful app ecosystem waiting to be built that is semantically similar to VB6 + Access but built with a more modern stack like SQLite + Electron + TypeScript.

jenscow 5y ago
> objectively "good" or if it was a first skill/nostalgia effect. When you consider the mainstream alternatives back then, by the time you've got the message-loop boilerplate working... in VB6 you've already created a functioning form with a database connection.
- JohnBooty 5y ago
  When you consider the mainstream alternatives back then What were the mainstream alternatives? Folks always seemed to rave about Delphi. That seemed like the "grown up", "better" version of VB, though I never used it.
  - jenscow 5y ago
    MFC, or plain C/C++ win32. But yeh, Delphi was much better than VB (like how turbo pascal was better than QBasic), however it was more of a niche environment used mostly by independent vendors making consumer apps.
    - pjmlp 5y ago
      Niche where? It was everywhere in Europe. There is a reason why we still have Delphi conferences over here.
- skeeter2020 5y ago
  You were almost writing full-fledged VB apps if you started with MS Access, made some forms and had a switchboard menu. A little VB Script and you were there.

kitd 5y ago

It was almost too good. It encouraged a load of professionals who, though talented in their own field, should never have been near an IDE, to "knock up" a quick GUI, hand it over to the dev team, and say "Here you go. Support this." ... in my experience.

zozbot234 5y ago
> "knock up" a quick GUI, hand it over to the dev team, and say "Here you go. Support this." Isn't a GUI mockup one of the best ways to come up with a consistent set of requirements for software? At least by making the mockup in VB rather than drawing it on paper, it can serve as a start for the actual GUI part of the program.
- kitd 5y ago
  You're speaking as a pro software dev (presumably), and yes, VB was great for prototyping. The people I'm referring to didn't realise that such esoteric things as "requirements" or "prototype GUIs" were a thing, and just handed over a ball of spaghetti for us to support.
- alex_hitchins 5y ago
  Thing is it was never a prototype, always the end product. Had a lot of Access systems that were created by people in their roles that got widespread use then grandfathered into general dev support too. These were always horrible but too big to change.
- dokka 5y ago
  There have a few times that I presented a VB6 prototype along with a price and had my prototype purchased on the spot. Sometimes when a client says "We need this software now", they really mean it.
heelix 5y ago
It was useful for more than that. We built most of our COM components in C++. As we started prototyping COM components in VB... and discovered they were only about 5% slower and very easy to crank out. It was a heretical discovery kept very quiet.

zozbot234 5y ago

> I know why QT/GTK and various other GUI systems use a HTML-y grid layout, but for me personally, I always struggle to make nice looking, well laid out, functional GUIs with them. There's a very intuitive drag-drop GUI designer for GTK+, namely Glade. Sadly, it was abandoned as GTK+ transitioned to 3.x and 4.x. So the only supported workflow now is laying out your GUI in code. The intuitive "action-oriented" language should not be underestimated either. Though I assume it could be made idiomatic even in modern languages, by leveraging their support for the async programming model.

MadcapJake 5y ago
There is some work going into a new RAD tool that will support 3 and 4. https://gitlab.gnome.org/jpu/cambalache https://gitlab.gnome.org/jpu/cambalache
- zozbot234 5y ago
  The Linux desktop's CADT syndrome strikes again. Why not just pick up maintenance of Glade itself? Why do we get this constant churn?
  - anthk 5y ago
    >Linux More like Gnome and RedHat. In the BSD-y world and people akin on GNU (Alpine, Hyperbola, Parabola...) people loves the CLI and some stuff like TCL/TK or even Perl/Tk / Perl/GTK2. And the tools work well and fast enough.
  - MadcapJake 5y ago
    If I had to guess I would say: more fun to develop a new system without any legacy code maintenance (GTK4 is a significant change in API). The idea with the new tool is to decouple the toolkit too so it will be fundamentally more resilient to churn.
  - supercheetah 5y ago
    Glade had a lot of problems, and core Gnomes devs really recommended against it[1]. I think that dev for Cambalache didn't want to try to figure that out. 1. https://blogs.gnome.org/christopherdavis/2020/11/19/glade-not-recommended/ https://blogs.gnome.org/christopherdavis/2020/11/19/glade-no...

dsugarman 5y ago

I agree. I knew I wanted to start programming in 3rd grade and it was such an intuitive way for me to learn. It let me spin up cool shit without a ton of overhead. Now I have 2 kids and I'm wondering what will be the equivalent for them when they're a little older. It seems like there's a lot out there designed for kids but it all seems so rigid like program your character instead of make your own program.

zozbot234 5y ago
Scratch is rather VBish in that you can endow "characters" with their own behavior and have them "react" to asynchronous events.
- skeeter2020 5y ago
  Scratch is great for understanding a lot of the concepts like properties, branching and loops but IMO goes too far towards the visual side. I liked the paradigm of "perform the action on the object" then "write the code in the container" that gets created or linked. We didn't really have formal "user stories" back then but programming essentially walked you through the "when I ... then ..." process.
  - zozbot234 5y ago
    Typing text is a nuisance at a young age. Visual interaction makes sense as a starting point.

Dave3of5 5y ago

Problem with VB6 was that for small projects it was fine but for medium to large projects it gets out of hand very quickly. For example when you drag and drop toolbar items onto your form it automatically gives them a boilerplate name. You can rename these but you tend to find devs would forget so after a while just looking at the code you started to get Label1.Text = "blah". I seen that in just about every project and one I remember done by a Chinese dev with poor English he left all the controls with the boilerplate names and so it was impossible to reason about what was happening. Componentisation was also a problem in that you tended to have all your code connected directly to the form. So if you had a large form that done complex stuff it wasn't unusual to have a multi thousand line long form file. Separation of concerns was a problem in that again the code was attached to a form so you found UI code mixed in with proper business logic. This becomes very messy over time and tends to create very large event handlers the more a project grows. It was basically impossible to unit test which makes refactoring very risky. On large projects what generally happens then is that no one is willing to refactor anything as they don't really know all the scenarios. Over time this leads to code rot. It only ran on windows, while I'm sure there are ways to make it run under linux the main support was for windows and most orgs stuck to that. This ties in with the fact that you had to install the thing on your P.C. businesses hated this and still do. Things like people uninstalling it or problems locally with permissions and suchlike were rampant. Similarly updating was a pain on large projects you have to have something central install and do the update. Scalability was problematic on large projects especially since the forms app would often directly connect to the database. That meant the more user = more connections which on large project meant problems. The "solution" was some service or api which the app talked to but at that point it's no longer vb6 doing the heavy lifting and it's just become a UI. Small little tools or prototype apps was were vb6 shined brightly.

zozbot234 5y ago
> but for medium to large projects it gets out of hand very quickly. Yup, it was really built without sufficient attention to the "programming in the large" featureset, much like those BASICs of old. Of course this became less of an issue in VB.NET that was pretty much a C# equivalent. > it automatically gives them a boilerplate name. You can rename these but you tend to find devs would forget The "Object Inspector" interface to form-element properties (including its identifier in code!) was very unintuitive, so this was a predictable outcome. > Componentisation was also a problem in that you tended to have all your code connected directly to the form. Yes, because it was difficult to have a full global view of the code that might drive a refactoring. Each form element and event would bring up its own tiny window of code.

AnIdiotOnTheNet 5y ago

It is very sad that the idea of easy WYSIWYG GUI application development has pretty much disappeared since the 90s. It enabled so many things to happen that wouldn't have otherwise. Hypercard, VB, Delphi... At least there's still Lazarus.

forgotpwd16 5y ago
Delphi still exists and they recently added Linux support.

TrackerFF 5y ago

We had a class in college where we used VB.NET, and Visual Studio designer for GUI. It was a breeze, and most people had working applications up and running within days of class start. End project was to build a control/monitoring application for an electric motor. Sure, there were some hard limitations compared to "modern" GUI design tools, but for the domain (industrial machines), these things worked just fine.

skeeter2020 5y ago
> End project was to build a control/monitoring application for an electric motor This is actually a funny use-case for .NET as anything low-level and hardware oriented tended to be harder to do without the libraries, which (if they existed) weren't .NET Not sure what the hard limitations were that you refer to; VB.NET / C# where always the easiest way to get a windows GUI (WinForms) app running. For industrial computing solutions tended to use Windows CE and Windows XP with COM apps.
- TrackerFF 5y ago
  This is ages ago - but IIRC, we did it something like this Motor - VFD - PLC - OPC server - OPC client The .NET Application worked purely as a GUI read/write data from/to the PLC. But of course there were other things involved, like database programming, API service, webdev. We made a very, very simple API in ASP.NET I think, and some website in PHP which would just plot the various motor values.

analog31 5y ago

I've still got VB6 apps running in the factory, that have required virtually zero maintenance in 14 years. I originally wrote them for testing during product development with the promise that "the dev team will write proper apps before we go into production." Famous last words. ;-) Then along came VB.NET, and I switched to Python. The big epiphany for me is that I no longer lay out GUI's. I let Tkinter lay them out for me. My realization is that anything I do deliberately other than just a simple vertical arrangement of widgets is likely to make things worse. What VB6 was letting me do, was to create GUIs that are no better than most industrial Crapware. I've also learned for the simplest things, not to make a GUI at all. People can modify some entries at the top of a text script and run it in the interpreter. At first glance, you'd think a GUI would make it easier, but people struggle with most custom GUI's anyway -- evidenced by noticing a sheet of paper at the work bench with handwritten instructions for using the software, whether it's something I wrote, or a professionally written app.

gamblor956 5y ago
Your "industrial crapware" survived for 14 years with basically no maintenance. Most software today can't even go a week without bugs. I think VB6 let you create some incredibly powerful, stable, useful programs, and everything you've done since has taken you further away from this ideal state. People can modify some entries at the top of a text script and run it in the interpreter. That is significantly harder for most people than just clicking on buttons.
- analog31 5y ago
  >>> I think VB6 let you create some incredibly powerful, stable, useful programs, and everything you've done since has taken you further away from this ideal state. That's certainly possible. My job has changed since then, so I'm no longer in a position to write that kind of stuff any more. My present "clientele" tolerates the Python ecosystem well enough.
cxr 5y ago
> I've also learned for the simplest things, not to make a GUI at all[...] you'd think a GUI would make it easier, but people struggle with most custom GUI's anyway -- evidenced by noticing a sheet of paper at the work bench with handwritten instructions for using the software This is an advantage that the Web browser has that is sadly under-appreciated and under-utilized (even from Web developers). Many traditional desktop GUIs and modern Web applications would be better suited for their audience if they were instead executable SOPs. Think: a manual for how to use a given system, except at the point in the instructions where it's describing a certain feature, or where it calls for a certain step to be performed, there is some on-screen affordance that allows the reader to take care of it right there—right at the spot they're already looking at. Some programming notebooks try to do something like this, but they usually get it wrong. Raskin seemed to have the same epiphany (albeit pre-WWW) and wrote about GUIs being a "dead end".

bmn__ 5y ago

> just give me drag and drop `designer` does this. Instead of assuming Qt doesn't come with a RAD drag & drop, you could have spend two minutes to verify. > python backend https://doc.qt.io/qt-6/designer-using-a-ui-file-python.html https://doc.qt.io/qt-6/designer-using-a-ui-file-python.html

hamstrung 5y ago
The first sentence of your message is helpful and appropriate. The second sentence is unnecessary and rude. Relevant: https://xkcd.com/1053/ https://xkcd.com/1053/

nickstinemates 5y ago

VB4->VB6 was the golden age of GUI development.

mring33621 5y ago

Visual J++ All the good VB6 parts, plus a better language for any code needed.

pjmlp 5y ago
Minus AOT compilation, though.

beamatronic 5y ago

This, but on Linux, would change the world.

specialist 5y ago

> pinnacle of GUI design/rapid prototyping Ditto database work. The client/server paradigm is the corpus calloscotomy (split brain surgery) of our industry. Begetting ORMs, LINQ, ActiveRecord, chaotic mutant query language templating system of the week, and other well-intentioned but ultimately detrimental efforts. All being unwitting attempts to regain what was lost. Famously described by Ted Neward's "Vietnam of Computer Science" rant. http://blogs.tedneward.com/post/the-vietnam-of-computer-science/ http://blogs.tedneward.com/post/the-vietnam-of-computer-scie... Though Neward somehow avoids identifying the root cause (client/server). FWIW, I did a bunch of R:Base, dBase/FoxPro, Access, and FileMaker (ahem) projects, back in the day. Sadly never had an excuse to use Paradox in anger, which I understand was the pinnacle for "workgroup" apps (LAN-based, meaning shared access thru file locking).

burnte 5y ago

It was great for rapid prototyping. the problem was when people then shipped those prototypes to billions of users. :P

selykg 5y ago

VB6 was the thing that got me so interested in development. I honestly miss it a ton. Everything now requires so much more to just make a simple app for something, and I'm on a Mac so it's even more of a pain.

ivanhoe 5y ago

VB was basically the MS response to Borland's Delphi, which had all this but better, plus Pascal was way more powerful and mature language than Basic. That said, both Delphi and VB (and VC++ to some extent) were IMHO far superior tools for RAD building of GUI apps than any web-oriented tool that I've later seen. In web development we're still in Turbo Pascal and Quick Basic days, we've got good IDEs and helpers but you still have to write everything by hand.

deleted 5y ago
[deleted]
jasode 5y ago
>VB was basically the MS response to Borland's Delphi, No, that wasn't the timeline. Visual Basic came out in 1991. Borland Delphi was +4 years later in 1995. (Borland Turbo Pascal for Windows was 1991 but Microsoft VB's internal product development codename "Thunder" was already started in 1990.) Visual Basic (especially the GUI forms IDE paradigm and VBX components) was built on earlier ideas in 1988 by Alan Cooper : https://en.wikipedia.org/wiki/Alan_Cooper#Visual_Basic https://en.wikipedia.org/wiki/Alan_Cooper#Visual_Basic
- jhbadger 5y ago
  And earlier than this, there was Apple's HyperCard in 1987 which I'm sure both the creators of VB and Delphi were familiar with. HyperCard had buttons and fields that you dragged onto a window to make an interface, and then by clicking on these widgets you had access to their properties and could write code to have them do something.
- Stratoscope 5y ago
  This brings back fond memories. The wiki page does have a few inaccuracies. Here is a more detailed article from Alan himself: https://onezero.medium.com/my-one-phrase-resum%C3%A9-98776ef8a6fa https://onezero.medium.com/my-one-phrase-resum%C3%A9-98776ef... (Try an incognito window if Medium blocks you.) That article has a few inaccuracies too, but as the events were over 30 years ago, this can be forgiven. Read Alan's article and then come back for this followup. Alan mentioned the "gizmos". He actually originally called them "waldos", named after these: https://en.wikipedia.org/wiki/Remote_manipulator https://en.wikipedia.org/wiki/Remote_manipulator I couldn't make sense of that name, so I suggested "gizmo", which seemed fun and more descriptive. That name stuck - for a while. Microsoft later renamed them to "controls". How boring! I also developed the "gizmo interface", which Microsoft renamed to VBX. (They were really not into fun names at the time.) It has sometimes been said that Bill Gates was the one who insisted that VB have an extension interface like this. The truth is more subtle. We had the gizmo interface all along. It was obvious that we would need it for our own gizmos, and that we should allow other developers to build their own gizmos. Apparently, the Microsoft team that turned Ruby+Basic into VB was going to keep the gizmo interface private and only let Microsoft developers use it, at least at first to save time on the schedule. Bill quite rightly saw the power of exposing the interface to outside developers and decided to make it part of the product - just as we had planned all along. And I built the "event arrows" that Alan mentioned. He originally called an event a "flimsy" (a British term for "lightweight paper used especially for multiple copies"). I couldn't make sense of that name either, so we kicked it around and settled on "event". This left a problem of what to name the act of sending an event from one gizmo to another. I was familiar with the term "trigger" from SQL, but that didn't seem quite right, and we were into fun names. But I couldn't think of one! At the time, when I got frustrated with a coding or naming problem, I had a habit of firing rubber bands at my IBM Monochrome Display to shake up my thinking. (Don't try this with a modern flat panel.) That didn't give me any ideas. So I decided to fire up a doobie and see if that would help. As I flicked my lighter and looked at the fire, it all came together: Fire a rubber band. Fire up a doobie. Fire an event! AMA, and I will see if I can remember...

markus_zhang 5y ago

UnrealEd 1 was coded in Visual Basic. I was very surprised when heard about this. The core rendering part was probably done in another language though.

andi999 5y ago

Why are there no visual development tools (drag n drop) for web? Or are there?

zubairq 5y ago
Yes I built one at yazz.com
haunter 5y ago
Elementor https://elementor.com/ https://elementor.com/ https://github.com/elementor/elementor https://github.com/elementor/elementor
pjmlp 5y ago
OutSytems, one of the best out there. https://www.outsystems.com/p/modern-development/ https://www.outsystems.com/p/modern-development/

bitwize 5y ago

I'm the opposite. Anything I create in a GUI builder is going to look like ass, with potentially misaligned widgets unless there's automatic widget alignment. And of course, things built in VB did not handle window resizing or different resolutions/DPI very well... Now, Tcl/Tk... which lets me just code up a GUI declaratively, feed it to a REPL, and get results that look... less like ass... that's a JATO bottle for UI productivity that's unmatched by anything.