Check Gambas if you're interested in a similar language/IDE concept. It's Linux only, but I thought it was pretty cool for quickly prototyping GUI applications, although I do prefer the more mature FreePascal/Lazarus combo.

http://gambas.sourceforge.net/en/main.html

The thing is, a real successor to VB wont be a programming language because VB's strength wasn't the programming language part (if anything, it was one of the weaker parts) but the ridiculously simple GUI designer and COM/ActiveX that allowed people to compose applications out of reusable components (be it controls or just pieces of code).

We don't have a real successor to VB (yet) because people always tend to overlook things and only focus on specific stuff, like the language or the form designer but those pieces weren't what made VB, it was the entire package - take a single element out and it falls apart.

Things i've seen people do in attempt to recapture VB:

* Start writing a compiler. The compiler part of VB was an afterthought (and wasn't even there in VB1-3), the important part is the IDE. Whenever i see someone trying to remake VB by even thinking about a compiler first, i'm certain that it'll fail (even if the project is made, it wont be VB, the developers' hearts are not in the right place).

* Ignore the "live" aspect of working with VB, like the ability to pause a program, modify it and continue or to execute statements, pause on errors, modify the code, continue, move the execution pointer around, modify variable values. You are interacting with a live system, there is no edit-compile-run cycle, it is just edit-run. Most attempts try to separate the IDE from the runtime, as if you were writing a C program with a form designer bolted on. A better system would try to eradicate the difference between designtime and runtime (e.g. allowing modifying forms while the program is running), not introduce additional steps or separation.

* Ignore the IDE. It was named "Visual" Basic for a reason. The documentation calls editing the forms as "painting the GUI" because it is a visual process. The IDE tries to make things as visually seamless (not always with success, TBH) - the form designer is the form itself, placed wherever you place the form (later this was diluted a bit in VB5 but you could switch to SDI to get the real deal), double clicking a button has you typing the code immediately for that button (or any other control's default event), you get a property panel with live editing of properties and in later versions (VB5, VB6) you even get those properties categorized, etc. You get a visual browser for every available class, method, function, etc available even with some brief documentation.

* Ignore extensions and composition. The entire reason Visual Basic exists is that Windows 3.0 got DLLs and someone (Alan Cooper) came up with the idea of using those DLLs to create reusable visual components. While Visual Basic does have a handful of "internal" controls (labels, listboxes, scrollbars, edit fields and a couple of others), most people using VB use external components.

* Try to make it possible to do everything in it with the apex of that being trying to write the language in the language itself. VB was the best example of a right tool for the right job - and an example that was very often ignored. VB's best use when was it was used to create front ends to machinery written in other languages that were better suited for the task. Sadly Microsoft dropped the ball here and made it too hard to expose components to VB since COM/ActiveX was a PITA and the only alternative was using DLLs (something they made way worse with VB.NET and C# by allowing only DLLs). This is something i never understood - they had their own C/C++ compiler, this was their own language, why couldn't they add an "add C++ header" (or just C header) command in the project window and have the IDE automatically parse and expose to VB whatever defined in the header? Even if it was only a subset of it (i wouldn't expect macros to work for example) it would be much easier. I believe that this is what led many people who otherwise should have known better to try and do too much in VB - because using another language had a lot of friction - and as a result, people who want to "revive" VB, try to solve the issue by improving the "do everything in VB" part instead of making interfacing with other languages easier.

* Focus too much on the language. This is really related to the first part, but really, i just cannot stress how often people miss the forest for the tree when it comes to VB - many programmers are attracted to VB's language like moths to flame. Originally VB was supposed to have pluggable languages and i don't know why this idea was scrapped - i'd guess it would make learning the system harder - but it is a testament to how unimportant the language was to the entire package.

* Try to bolt an existing language that simply doesn't fit. I'm not going to give examples for those because i don't want people to focus too much on defending their favorite language, but while the language isn't that important, it still needs to feel right at home with the rest of the package - especially the IDE. Every feature of the language needs to be able to be represented in the GUI itself and that without being overwhelming (to understand what i mean with overwhelming, imagine working on an XML document produced with LibreOffice with a plain text editor - the document is technically a text file and you can technically edit and even write new parts on it with the text editor, but it is clearly not a good fit. Similarly it isn't enough to be able to represent the language in a GUI, its features also need to be a good fit for visual representation through a GUI). Note BTW that taking an existing language and altering it to make it a better fit might work (after all that is what Microsoft did with BASIC).

There are other things of course (and i certainly do not include the most common case of people starting with an idea and going nowhere - but i suspect an easy language like VB attracted a lot of people who simply didn't know what they couldn't do), but the above are some of the main stuff in my mind (and this post is already too long).

Personally i find the desktop development process today a broken mess and most "modern" approaches to really be rooted in 70s mindset. GUI is by its nature graphical, making GUIs should be graphical itself - yet most systems regressed to text based descriptions.

The best system in active development today is Lazarus with Free Pascal. It is far from a VB alternative (despite how much people compared Delphi - Lazarus is practically an open source cross platform Delphi - and Visual Basic back in the 90s, the only common those two systems have is that they use form designers that if you squint hard enough look kinda similar - everything else is different) and IMO doesn't even reach Delphi 1's level of integration, it is kind of a mess in several places (some due to Free Pascal having a kitchensink philosophy, but also some due to just plain old sloppiness) and its cross platform support while there, has issues on anything except Windows (and personally i dislike how the only backend that really works on Linux is Gtk+ 2 and that they do not focus on their own backend - but that issue i have has a lot to do with how broken and hostile to backward compatibility is desktop development on Linux).

Still, i do all my complex GUI stuff on Lazarus. Now and then i also work on a GUI toolkit that i hope one day to use to build my dream GUI development environment on Linux (so i can finally get rid of any Windows dependencies) although the entire Wayland story with all of its limitations and other issues puts a major block there (and makes me lose my interest on Linux desktop altogether).

Interesting comment. Lazarus and Free Pascal are good, alright. (With some issues, as any software has).

IIRC, VB's initial code name was Thunder. I worked on VB in a few commercial projects. Alan Cooper demoed VB 1 to Microsoft and they bought it.

Alan Cooper has written about the early history of Visual Basic and how it came to be [1]. Two things i always find interesting was that in his original prototype he didn't use a language at all, but instead used arrows between controls to connect events with methods (i remember seen something similar in an ancient version of Smalltalk for Windows 3.1 that i found in a magazine cover disk back in the 90s) and that in the original version after Microsoft started working on it, it wasn't only the controls that could be extended via DLLs, but also the language itself. Both of those didn't make the cut for VB1, but personally i find them interesting as ideas since they seem to fit well with the overall theme extensibility VB had.

[1] https://www.cooper.com/alan/father_of_vb.html

Interesting info. I remember reading parts of this, but not about the multiple languages (from your previous comment) and other stuff, like extending the language itself. Thanks.

Wish I could give this comment +10.

I expect something equivalent or better to come out of what is happening with WASM in next year or so.

So many people are talking about missing the power of VB, early Delphi, Turbo Pascal etc. and WASM is first tech for a while that looks like it could take that power to the browser.

Sure, there's going to be a bloom of compilers of anything to WASM, but what's discussed here is the opposite technology: lean native applications.

The reason these post-2005 cross-platform envs have gained no traction is because so many devs won't move away from browser - or even consider alts to a browser exist. Suggesting something not SAAS, PAAS etc. right now in most enterprises won't do much for your career.

WASM kind of fixes that - it takes that 90s/00s native speed into the frontend of the moment and makes complex UIs more viable. Any dev with more than 20 years experience shakes their head that it takes WASM to make that happen - but I'm just grateful it is.

Last I looked I could not find a garbage collection solution for wasm, and that seems to be a barrier to entry. I know the mono-team has had some success by porting all of Mono to Wasm but that seems a bit heavy handed just to get VB.Net or C# language to compile down to wasm.

It's not a now solution - but from the trajectory you can see where this likely ends. It may even be the case that the current WASM specification does not support everything needed for that to happen.

But if you look at the DOM and what Anders Hejlsberg was working on 25+ years ago with early Delphi - you can see a potential real step change from WASM - especially for enterprise tech to bring back some of that VB magic.

As I mention in my other comment, take a look at Delphi/Lazarus for the VB heir!

Lazarus, Xojo, Gambas to name a few.

A lot can also be done with an interface designer like Glade.

Delphi is still around.

I would use Xojo for a "successor".

The syntax of Rebol, its predecessor, was an inspiration for the Mathematica language.

According to Wikipedia, Mathematica was initially released in 1988. Rebol was first released in 1997.

Maybe Rebol inspired some part of Mathematica that came later, like the manipulate/dynamic system?

Rebol also influenced JSON, according to some people, per links in this post (on my blog):

https://jugad2.blogspot.in/2012/12/rebol-language-that-influ...