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.
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.
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.
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".
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.
If anything some aren't even issues but features - e.g. being able to have code attached directly to events speeds up development a lot and if you need to put it somewhere else (IME the case where this isn't necessary is more common than the case where it is) you can simply have your handler call some method in another file so you can keep those separate.
Just a small quibble - you would typically move shared-code into seperate module files.
The other biggest challenge we had was when trying to build a larger solution that worked with COM dependencies amongst multiple projects, you would occasionally have to do a clean-build which break binary compatibility (don't forget to do a registry cleanup!), and that mean "compiling" your tree manually, from the base level components upwards. That got much easier if you could get your hands on a Microsoft MCS tool called, VBBuilder. (I can't remember if it ever was available for open/free download)
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.
> 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/
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.
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.
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.
Also see MAUI versus Swing/Qt, one needs to go for Uno/Avalonia instead.
https://arstechnica.com/features/2012/10/windows-8-and-winrt...
If I'm quickly knocking up a small GUI utility then the drag-drop building nature of a vb.net forms app is a real time saver - but in contrast you have more flexibility if you build controls via code like C# does.... horses for courses really.
Bizarrely, I've recently started exploring using C# as a CGI back-end via .NET core on Linux... for the simple reason that I can. Apparently it can be quite performant.
Roslyn for VB.NET still gets more love than F# across .NET workloads.
Now it is true that they could rename CLR into C# Language Runtime, given the extent of effort that C# gets, versus VB.NET, F# and C++/CLI.
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
Also, modern Free Pascal has OOP classes and methods if you like these. If you run software made in Free Pascal like Cartes Du Ciel and them some Java one like Sweet Home 3D, the first one will run circles on snappiness and speed over the second one.
IDK how Java can be appreciated, most of its desktop software runs far worse than AMSN over TCL/TK in early/mid 00's under an Athlon.
The predecessors of Free Pascal had those since the 1980s, it isn't particularly a “modern Free Pascal” innovation.
FWIW AFAIK Free Pascal got its OOP stuff from Delphi (almost, but that is historical details) which in turn is an extension to Turbo Pascal's OOP stuff introduced in TP5.5 which in turn was based on Apple's Object Pascal extensions that (AFAIK) were designed with Niklaus Wirth's help during the late 80s. The OOP functionality Free Pascal has and mainly uses started with Delphi 1 though (which already had things like properties and reflection - this is how the form designer worked) in 1995.
Of course i wouldn't call those modern any more than i'd call structured programming elements like 'procedure' and 'while' modern in 1995 :-P.
https://www.amazon.com/Filthy-Rich-Clients-Developing-Applic...
1. the inconsistent padding around the focus rectangle (which even touches the outer border on one side!) on that toolbar button to the left in the screenshot,
2. that whoever redesigned the Metal theme some years ago decided to make the selected tab visually connect to the content by using the same background color (good idea, by itself) but apparently didn't notice that every application wraps the content in a widget that draws its own background, resulting in what you see on the screenshot: the tab color continuing for a few pixels into the content and then awkwardly bumping up against the content's background without a border.
Also, IntelliJ IDEA has to implement its own menu bar because Swing's built-in one can't do submenus properly.
[1] https://upload.wikimedia.org/wikipedia/commons/c/cc/Gui-widg...
:(
Last modified March 2014: https://github.com/rebol/rebol
And that's still just REBOL/Core, not REBOL/View.
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"
This is all I was trying to convey. Yes, it's not getting as much love and care as it deserves.
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.
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.
Apparently last modified 8 days ago, with a history of infrequent but steady commits.
Caveat: Unfortunately only talks about Windows.
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.
Point is thought this was there out the box with VB.
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.
[1] https://github.com/mhammond/pywin32/
[2] https://www.amazon.com/Python-Programming-Win32-Windows-Prog...
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.
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.
So he had this good idea of creating a simple application that would allow him to enter his data in the computer without having to move his eyes out of the microscope. He did this with a keyboard numpad and a quick VB6 prototype (which I finished the coding part for).
Those are the kind of great small programs that VB5/6 allowed people to do. And there were a lot of those small utilities all over the internet. No paywall, no ads, no subscriptions. I miss those days of creativity and sharing for the sake of it. Now the internet is all just SEO, ads and greed. What happened to kids/young Millenials and Zs?
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.
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://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
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...
> Just WTF were those Microsoft guys smoking when they designed this shit?
<g>
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.
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.
1. https://blogs.gnome.org/christopherdavis/2020/11/19/glade-no...
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.
But yeah DoEvents ftw.
At least there's still Lazarus.
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.
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.
When you consider the mainstream alternatives back then
Folks always seemed to rave about Delphi. That seemed like the "grown up", "better" version of VB, though I never used it.
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.
There is a reason why we still have Delphi conferences over here.
I think Angular has a way to intercept http calls but you would need to build a translation layer. None of this is obvious to someone picking this up for the first time.
The whole paradigm is a hack that requires a very experienced dev to navigate.
Maybe I'm missing something.
That part won't change AFAICT, but you can imagine a reasonable abstraction over it as part of a "batteries included" ecosystem in which events from the UI (button press, keyboard capture, scroll event, etc) are mapped seemlessly via configuration to user-defined functions that happen to run within the nodejs process with an SDK that allows developers to interact back w/ the UI in a similar manner. Resulting in a developer experience very similar to what you got with VB6.
`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
Relevant: https://xkcd.com/1053/
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).
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.
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.
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.
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.
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.
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-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).
All the good VB6 parts, plus a better language for any code needed.
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