Just last week I had a requirement where a user at our company needs to run some commands on an embedded system to configure it before it is sent out to customers.
20 years ago I would've opened up VB6 and knocked out a quick GUI for that kind of work, but I never got on to the VB.NET train.
So I spent some time that evening looking at modern VB6 alternatives, but nothing satisfied me: Lazarus might be something I'd look to in the future, but I'm not too keen on Pascal, Gambas is not really suitable for Windows, then there is this and RADBasic that are incomplete.
In the end, I found a nice Tkinter tutorial [1] and managed to get the GUI I envisioned up in an hour.
I've played with Tkinter many years ago, but I basically had to learn from scratch. The speed at which I was able to get up and running led me to conclude that this is how I'll approach these types of requirements from now on.
The GUI didn't even look as bad as I remember Tkinter looking.
Qt (the legacy Qt::Widget variant) is quite productive for quick and dirty GUIs. You can do 95% of basic dialogs in QtDesigner and then connect the signals to your code and vice versa. The code can be Python or C++. It can also be mapped 1:1 into SQLite tables without any external libraries, which is handy for basic forms or data apps.
QML also has GUI design tools, but it takes much longer to learn and isn't very good at simple GUIs. However it's better when you need to deploy on Android (iOS requires the paid version).
One thing to keep in mind if the LGPL3 license. If the app isn't distributed, then it's fine, but if distributed, it has to be dynamically linked with some ways of swapping the .so/.dylib/.dll
Qt is fantastic, I've used it with Python using the semi-commercial PyQT and open source PySide which are largely mutually compatible. The example projects that come with it are a great way to get started and the documentation is world class. I found it much easier to work with than the native Windows options 10 years ago, but haven't really looked at anything from MS since.
That may be so, but I've used very performant software that used Qt. The desktop version of Google Earth was a Qt application and was amazing. The whole KDE desktop is Qt, as are Ableton Live, Mathematica, and several Adobe and Autodesk apps. If a Qt app has performance issues it's unlikely to be down to the UI layer, unless they're doing something particularly weird. Having said that I have no experience of QML or how it performs.
There is a rather unfortunate lack of such tools today, which is very annoying. GUIs are visual so creating and editing them visually should be the no-brainer "right way" to do it, but instead programmers have abandoned it and embraced gigantic slow overcomplicated webshit for GUIs.
If you have a visual WYSIWYG designer and, importantly, aren't stubbornly intent on reinventing the wheel, then GUI isn't actually that hard.
Why not looking into VB.net? I mean I know that Microsoft is trying to kill it so not sure it is a long term solution, though I would expect long term support even if you don’t get new features.
If you are familiar with VB6 there is not a lot of difference. Set keyword removed. All collection zero based instead of inconsistent 0 and 1 based. A null and empty string are two different things. Parameters are byval by default instead of byref by default. And you get lots of nice features: generic, linq, return keyword, try/catch, etc. Otherwise the syntax is the same, and winform also works in a very similar way.
I did the transition VB6 => VB.net => C# (the latter when VB got deprecated).
Nice project though as someone else said it basically replaces one proprietary commercial VBA with another proprietary commercial VBA. There have been at least a couple of those who ended up being abandoned.
Also the cost is both very high (after a handful of months you'd have paid more than what VB3 standard was sold for and the IDE certainly looks way less functional than VB3) and lacks any perpetual license. Also it isn't mentioned anywhere in the preorder page, but since it requires a subscription, that means that it most likely uses some form of online checking DRM, which in turn means that when the company shuts down and/or abandons the project, all that money would be lost forever.
That said i tried the demo version a bit and seemed to be ok, at least unlike other VB-clone attempts this one seems to have a visual designer (though very primitive). The IDE was a bit buggy and very sluggish and the theme felt very alien and not that well made. Why not use native controls like the applications themselves? The way it looks and feels now is like those early WPF demos, full with sluggish motion and blurry text.
> as someone else said it basically replaces one proprietary commercial VBA with another proprietary commercial VBA.
Yeah, that's definitely a downside. I appreciate the author believes they can commercialise this more successfully if it's proprietary, but /personally/ I'd prefer something open source. One day I'll finish my own open source VB6 clone.
> There have been at least a couple of those who ended up being abandoned.
You're right. History is littered with abandoned VB6 replacements. Anybody remember GNOME Basic?
Nonetheless, credit where credit is due. Technologically, it looks like TwinBASIC has good foundations. It had a language server, although the VSCode extension is on hold for now. It imports VB6 project files, unlike looser VB6 alternatives like Gambas. And a combined Dim / Let (=) statement is long overdue.
You'll also need a 100% compatible MS Access as well - in most cases they are used together.
The other key is being able to use all the custom controls etc. Hopefully, your legacy VB codebase had a fear of NIH and you don't have to worry about this.
I've seen a lot of clever systems made in VB, a combination of the developer not knowing any better, and having the perseverance to keep going until they got something that 'worked'.
Access was huge. About 6 years ago I had to fix up a predecessors custom data logging program written in VB6 that used an access database. I had to patch a few things to eliminate hard coded paths and a fix for windows 7. First and only time I used VB6 and it was easy to dive into and figure out.
I've been using/evaluating twinBASIC for a few months now (other than that I have no connection with the twinBASIC developers).
I've been very impressed with everything about twinBASIC so far.
There is a free (including commercial use and royalty free distribution) community edition (Windows only, 32bit and 64bit - though the 64bit has a nag screen).
The paid editions add optimised compilation, and (planned) support for Linux, Mac and Android (and possibly Web).
Compared against other products such as Gambas, Xojo (realbasic) or VB.Net it has the advantage of being able to import existing VB6 apps and run them as Windows 32bit apps (much of this is available now, but there is still some way to go for 100% compatibility). RAD Basic may offer compatibility too, but it seems difficult to find an up to date evaluation download.
twinBASIC also goes beyond what VB6 offered - 64bit compilation, multithreading, creating DLLs etc. (some of which could be done with hacks in VB6).
As for a potential market, that is difficult to say. There are still huge numbers of VB6 applications in use, having the ability to move easily to a new language may be attractive for whoever still supports those applications.
There is certainly interest, a thread about twinBASIC on VBForums has had almost 400,000 views.
It's an interesting question. It looks like TwinBASIC embraces the OLE/COM/ActiveX model as its native model. VARIANTS and BSTRs. This means advanced patterns like ObjPtr and StrPtr can work, assuming other compatibility is high.
I'm unsure about RAD Basic here, but a contentious thread of VBForums suggests it differs here.
Now, arguably ObjPtr and StrPtr aren't part of the semantics of VB6. Nonetheless, if you want compatibility with some real world code, it needs to work.
(I too have no connection with twinBASIC, except I'm a VB6 fan who is technologically impressed by it.)
This would be huge. Last time I was out field deploying a camera system, customer wanted a custom PVM (Public Viewing Monitor) with a few tweaks, I spun up VB, added the VLC component that gets installed anytime you put VLC on windows. Wrote a few lines of code and cleaned up my tools and left.
At some point Microsoft (who no longer support the IDE) will also stop supporting the VB runtime, and companies will have no choice but to convert those old apps.
I doubt if there will ever be a VB6 revival.
I think they should focus on 100% compatibility, and 64bit code generation.
Perhaps allow the new Apps to connect to modern cloud services instead of MS access, or on premises SQL, preferably without anyone having to touch any code.
Also some kind of project analysis and auto-documentation so the new developers can understand what the project does, would be useful.
>I think they should focus on 100% compatibility, and 64bit code generation.
100% compatibility seems to be the main focus of the twinBASIC developers.
64bit code is already available. One big issue is ActiveXs - they are supported, but there are few 64bit third-party ActiveXs. So the support of 32bit ActiveXs in 64bit twinBASIC apps is planned but not yet available.
Until Windows drops 32-bit compatibility, VB6 apps will continue to run fine even if they do look f'ugly against todays UI design. In fact there's probably still a significant amount of industrial/heavy-commercial in-house applications written in VB still in use.
I can see a use case for TwinBASIC in maintaining these legacy apps, as the VB6 IDE no longer behaves itself under Windows 10/11. If it offers compilation to 64-bit (pseudo)code, then these apps will gain an extension on their usable life.
Looks like you need to call InitCommonControls(Ex), in addtion to the manifest. https://jeffpar.github.io/kbarchive/kb/309/Q309366/ I'll forgive your slight misremembering, because it's probably been 20 years.
To be fair, it's been that way for a long time. VB6 (and VB5) compiled to machine code, unlike earlier versions which were criticised for interpreting bytecode ("P-code").
Now, VB required some runtime dlls, namely msvbvm60.dll, and several ActiveX controls, but that feels small compared to even the .NET Framework. And tiny compared to your implied comparison with Electron/Chromium.
And it doesn't even have true threading in the language, you can do it, but its not like a language construct. What is beautiful about VB6 is your ability to use native DLLs and parts of the Win32 API as well.
I've been wanting to see a VB6 successor for a long time. I have debated paying for Xojo but I'm not a fan of their docs and havent built anything worthwhile yet to justify buying a license.
Visual Basic was mostly just used for line-of-business software -- forms, reports, etc. That's mostly been moved to the web, but it was seldom used for anything where performance was important.
I'm not sure a BASIC compiler at twice the monthly cost of Photoshop is going to fly with anyone, but I'm definitely curious if there's a market out there for it.
I'm curious also, looking at their issue tracking (discord server invite looks like its gone stale... ) it seems like not a lot of interest at the moment. But it is weird how much old VB stuff is out there and because so few people put any effort into the old VB world, I think people would pay a premium for something that's useful. Having said that, their community edition probably would suit nearly everyone. I'm guessing a few people might want cross platform... So not sure how they make money, it seems like they'd need 1000ish customers to make it viable for 2 people. At the moment most of the things that have user counts related to the project (youtube etc) is much much less than that... but, maybe once they have a solid release a lot more people will come out of the woodwork. Anyways, interesting to see how they go.
As a VB6 fan I'm excited to have a couple credible looking alternatives finally crop up. Of course, there's the 80-20 rule, and history is littered with similar attempts.
Take a look at PureBasic . It is a mature product with a great developer and user community. It generates fast native code for Windows, Mac, Linux and RPi. I have used it for 15+ years.
It also has a sister product SpiderBasic that can convert most of PureBasic code to HTML, JavaScript for web deployment
Apparently it is fully compatible with vb6 (as also radbasic says they are). I never tried but long time ago I ported a slew of vb6 apps to Xojo (realbasic at the time) and that was not hard but it was definitely work and not fully compatible. I would use Xojo still though as it’s very mature and I trust them being around in a while.
I want something like VB6 but with Python instead of Basic, cross-platform and open source.
Lazarus comes close but it uses Free Pascal and (maybe because of that) is somewhat niche.
There are many GUI frameworks for Python, but I would like to have such a straightforward-to-use IDE. My current IDE is PyCharm, maybe there are some extensions? Maybe they are buggy?
In 1981 I (mostly) happily paid full price for Microsoft BASIC for Heathkit HDOS. In 1995 I was one of those fools lining up at midnight for Windows95.
In 1996 I had just about finished porting my primary consulting project from VB3 to VB4... when VB5 came out and changed everything again. That's when I realized I had been taken for a ride; I cancelled my MSDN membership and began exiting the Microsoft ecosystem for Linux. Haven't touched a Microsoft or Apple product for over twenty years now and life is good.
twinBASIC backer here. It's been many years since I wrote any VB6, or even VBA, but I got my start in software engineering that through classic VB and still hold deep affection for it. I'm happy to support it even if I never end up using it.
Please bear in mind that twinBASIC is still pre-release / v0.x, and has not been widely publicized yet. The IDE, and in particular the forms designer, is very recent. Originally an extension to VS Code was envisioned (it's currently paused), but VSC was not extensible enough.
It's under active and rapid development right now, please judge accordingly.
I had to write a little VB to maintain a legacy codebase at my first job. VB is long before my time, but at least from my perspective at that time, it was just a gross language to me. Who on Earth would rather have to end a function block by typing out "End Sub" instead of a curly brace? And case insensitive naming? I don't remember much else about VB, other than the immediate and visceral reaction that I needed to find a better gig.
I wouldn't be too quick to judge..... quick tell me what these braces close }}}} no idea huh? in VB, closing blocks will tell you what they are closing. So, not such a silly idea, just more verbose!
Closing blocks telling you what they are closing were a good idea in the era when programmers had to line up at a job submission window holding decks of punched cards.
The reason is that blocks indicating what they are closing can assist the compiler in reliably recovering after syntax errors, continue parsing, so that you get as many useful diagnostics from a single compiler pass as possible.
you may feel they are unnecessary, other people like it, and it definitely isn't from the age of punch cards. I like to watch people code on twitch, and the amount of times I see people get confused about what a particular closing bracket is closing is pretty regular. The other thing it allows is you can jump to all the closing tokens for IF statements in a file really easily. Way easier to write tools to extract certain things out of code files as well. While I don't mind curly brace blocks, I can definitely see the advantages of distinct tokens for different types of blocks
> Who on Earth would rather have to end a function block by typing out "End Sub" instead of a curly brace
It’s called BASIC because it’s more approachable to beginners. End Sub is not as strange to someone new to programming as a curly brace because it is almost English and less abstract.
When I first used C I wondered who in their right mind would start and end blocks with a curly brace when Pascal used BEGIN/END and other languages had other nicer and more easily glanceable structure markers.
You don't actually have to type out End Sub, the IDE does that for you.
You just type in the new procedure's name and the ide gives you the skeleton with the cursor inside.
There's COBOL code at least twice, and possibly three times as old, that still runs billion dollar businesses every day, and likely will until you retire.
VB has its quirks but during its heyday, it was substantially more productive and easier to use than pretty much anything else.
No it won’t because Cobol programmers are basically impossible to come by today; when I retire they will all be dead.
So unless you can somehow convince young talented programmers to abolish 50 years of advancements and go program in an antiquated language again, in a short while there will simply be no option but to finally migrate away.
> Who on Earth would rather have to end a function block by typing out "End Sub" instead of a curly brace?
Someone who has to wait 10 minutes in line before a job submission window, holding a deck of punched cards, just to find out their program has syntax errors, and then repair as many of them as possible before repunching the cards and lining up again.
There are a lot of eccentricities to complain about in VB, but somehow you have managed to only call out the features that were actually really common in a lot of other languages.
What about 1-based indexing and On Error Resume Next?
1-based indexing is pretty common among technical programming languages (R, Matlab, Julia, etc.) Not that VB is typically used for this, but people who think 0-based is universal have pretty much only been exposed to C and languages that copy its conventions.
Just last week I had a requirement where a user at our company needs to run some commands on an embedded system to configure it before it is sent out to customers.
20 years ago I would've opened up VB6 and knocked out a quick GUI for that kind of work, but I never got on to the VB.NET train.
So I spent some time that evening looking at modern VB6 alternatives, but nothing satisfied me: Lazarus might be something I'd look to in the future, but I'm not too keen on Pascal, Gambas is not really suitable for Windows, then there is this and RADBasic that are incomplete.
In the end, I found a nice Tkinter tutorial [1] and managed to get the GUI I envisioned up in an hour.
I've played with Tkinter many years ago, but I basically had to learn from scratch. The speed at which I was able to get up and running led me to conclude that this is how I'll approach these types of requirements from now on.
The GUI didn't even look as bad as I remember Tkinter looking.
[1] https://tkdocs.com/
Qt (the legacy Qt::Widget variant) is quite productive for quick and dirty GUIs. You can do 95% of basic dialogs in QtDesigner and then connect the signals to your code and vice versa. The code can be Python or C++. It can also be mapped 1:1 into SQLite tables without any external libraries, which is handy for basic forms or data apps.
QML also has GUI design tools, but it takes much longer to learn and isn't very good at simple GUIs. However it's better when you need to deploy on Android (iOS requires the paid version).
One thing to keep in mind if the LGPL3 license. If the app isn't distributed, then it's fine, but if distributed, it has to be dynamically linked with some ways of swapping the .so/.dylib/.dll
Qt is fantastic, I've used it with Python using the semi-commercial PyQT and open source PySide which are largely mutually compatible. The example projects that come with it are a great way to get started and the documentation is world class. I found it much easier to work with than the native Windows options 10 years ago, but haven't really looked at anything from MS since.
I've often found Qt GUIs to be bloated and slow. Not sure whether that's brought about by Qt inherent overheads or bad design by those using Qt.
That may be so, but I've used very performant software that used Qt. The desktop version of Google Earth was a Qt application and was amazing. The whole KDE desktop is Qt, as are Ableton Live, Mathematica, and several Adobe and Autodesk apps. If a Qt app has performance issues it's unlikely to be down to the UI layer, unless they're doing something particularly weird. Having said that I have no experience of QML or how it performs.
There is a rather unfortunate lack of such tools today, which is very annoying. GUIs are visual so creating and editing them visually should be the no-brainer "right way" to do it, but instead programmers have abandoned it and embraced gigantic slow overcomplicated webshit for GUIs.
If you have a visual WYSIWYG designer and, importantly, aren't stubbornly intent on reinventing the wheel, then GUI isn't actually that hard.
Plus Tk has bindings in about every language in existence, so you can choose your favourite : Tcl of course, but also C, C++, Python, Perl, PHP...
Why not looking into VB.net? I mean I know that Microsoft is trying to kill it so not sure it is a long term solution, though I would expect long term support even if you don’t get new features.
If you are familiar with VB6 there is not a lot of difference. Set keyword removed. All collection zero based instead of inconsistent 0 and 1 based. A null and empty string are two different things. Parameters are byval by default instead of byref by default. And you get lots of nice features: generic, linq, return keyword, try/catch, etc. Otherwise the syntax is the same, and winform also works in a very similar way.
I did the transition VB6 => VB.net => C# (the latter when VB got deprecated).
Glad I'm not the only one who has been avoiding Lazarus due to Pascal. Too many scars.
Nice project though as someone else said it basically replaces one proprietary commercial VBA with another proprietary commercial VBA. There have been at least a couple of those who ended up being abandoned.
Also the cost is both very high (after a handful of months you'd have paid more than what VB3 standard was sold for and the IDE certainly looks way less functional than VB3) and lacks any perpetual license. Also it isn't mentioned anywhere in the preorder page, but since it requires a subscription, that means that it most likely uses some form of online checking DRM, which in turn means that when the company shuts down and/or abandons the project, all that money would be lost forever.
That said i tried the demo version a bit and seemed to be ok, at least unlike other VB-clone attempts this one seems to have a visual designer (though very primitive). The IDE was a bit buggy and very sluggish and the theme felt very alien and not that well made. Why not use native controls like the applications themselves? The way it looks and feels now is like those early WPF demos, full with sluggish motion and blurry text.
> as someone else said it basically replaces one proprietary commercial VBA with another proprietary commercial VBA.
Yeah, that's definitely a downside. I appreciate the author believes they can commercialise this more successfully if it's proprietary, but /personally/ I'd prefer something open source. One day I'll finish my own open source VB6 clone.
> There have been at least a couple of those who ended up being abandoned.
You're right. History is littered with abandoned VB6 replacements. Anybody remember GNOME Basic?
Nonetheless, credit where credit is due. Technologically, it looks like TwinBASIC has good foundations. It had a language server, although the VSCode extension is on hold for now. It imports VB6 project files, unlike looser VB6 alternatives like Gambas. And a combined Dim / Let (=) statement is long overdue.
There is a free community edition, no?
With significant restrictions (most notably a nag screen at application startup).
It's still proprietary. It's just free as in beer.
At last, we can replace the aging proprietary, commercial implementation of VBA with... another proprietary, commercial implementation.
sums up my feelings exactly!
You'll also need a 100% compatible MS Access as well - in most cases they are used together.
The other key is being able to use all the custom controls etc. Hopefully, your legacy VB codebase had a fear of NIH and you don't have to worry about this.
I've seen a lot of clever systems made in VB, a combination of the developer not knowing any better, and having the perseverance to keep going until they got something that 'worked'.
Access was huge. About 6 years ago I had to fix up a predecessors custom data logging program written in VB6 that used an access database. I had to patch a few things to eliminate hard coded paths and a fix for windows 7. First and only time I used VB6 and it was easy to dive into and figure out.
I've been using/evaluating twinBASIC for a few months now (other than that I have no connection with the twinBASIC developers).
I've been very impressed with everything about twinBASIC so far. There is a free (including commercial use and royalty free distribution) community edition (Windows only, 32bit and 64bit - though the 64bit has a nag screen).
The paid editions add optimised compilation, and (planned) support for Linux, Mac and Android (and possibly Web).
Compared against other products such as Gambas, Xojo (realbasic) or VB.Net it has the advantage of being able to import existing VB6 apps and run them as Windows 32bit apps (much of this is available now, but there is still some way to go for 100% compatibility). RAD Basic may offer compatibility too, but it seems difficult to find an up to date evaluation download.
twinBASIC also goes beyond what VB6 offered - 64bit compilation, multithreading, creating DLLs etc. (some of which could be done with hacks in VB6).
As for a potential market, that is difficult to say. There are still huge numbers of VB6 applications in use, having the ability to move easily to a new language may be attractive for whoever still supports those applications. There is certainly interest, a thread about twinBASIC on VBForums has had almost 400,000 views.
> RAD Basic may offer compatibility too
It's an interesting question. It looks like TwinBASIC embraces the OLE/COM/ActiveX model as its native model. VARIANTS and BSTRs. This means advanced patterns like ObjPtr and StrPtr can work, assuming other compatibility is high.
I'm unsure about RAD Basic here, but a contentious thread of VBForums suggests it differs here.
Now, arguably ObjPtr and StrPtr aren't part of the semantics of VB6. Nonetheless, if you want compatibility with some real world code, it needs to work.
(I too have no connection with twinBASIC, except I'm a VB6 fan who is technologically impressed by it.)
This would be huge. Last time I was out field deploying a camera system, customer wanted a custom PVM (Public Viewing Monitor) with a few tweaks, I spun up VB, added the VLC component that gets installed anytime you put VLC on windows. Wrote a few lines of code and cleaned up my tools and left.
At some point Microsoft (who no longer support the IDE) will also stop supporting the VB runtime, and companies will have no choice but to convert those old apps.
I doubt if there will ever be a VB6 revival.
I think they should focus on 100% compatibility, and 64bit code generation.
Perhaps allow the new Apps to connect to modern cloud services instead of MS access, or on premises SQL, preferably without anyone having to touch any code.
Also some kind of project analysis and auto-documentation so the new developers can understand what the project does, would be useful.
>I think they should focus on 100% compatibility, and 64bit code generation.
100% compatibility seems to be the main focus of the twinBASIC developers. 64bit code is already available. One big issue is ActiveXs - they are supported, but there are few 64bit third-party ActiveXs. So the support of 32bit ActiveXs in 64bit twinBASIC apps is planned but not yet available.
By running them out-of-process, presumably?
That feeling when a VB6 application is more lightweight than most of today's "native" applications.
Until Windows drops 32-bit compatibility, VB6 apps will continue to run fine even if they do look f'ugly against todays UI design. In fact there's probably still a significant amount of industrial/heavy-commercial in-house applications written in VB still in use.
I can see a use case for TwinBASIC in maintaining these legacy apps, as the VB6 IDE no longer behaves itself under Windows 10/11. If it offers compilation to 64-bit (pseudo)code, then these apps will gain an extension on their usable life.
Given than VB6 mostly used native widgets, you can make apps written in it look modern simply by adding a manifest with the appropriate incantations.
True, but I think you also have to add a VisualStyles API call as well to the Form_Load() Sub ? It's been a long time since I've done it though.
Looks like you need to call InitCommonControls(Ex), in addtion to the manifest. https://jeffpar.github.io/kbarchive/kb/309/Q309366/ I'll forgive your slight misremembering, because it's probably been 20 years.
>Looks like you need to call InitCommonControls(Ex), in addtion to the manifest.
Often all you need is the manifest. If the app won't run at all after you have added the manifest, then add a call to InitCommonControls(Ex)
To be fair, it's been that way for a long time. VB6 (and VB5) compiled to machine code, unlike earlier versions which were criticised for interpreting bytecode ("P-code").
Now, VB required some runtime dlls, namely msvbvm60.dll, and several ActiveX controls, but that feels small compared to even the .NET Framework. And tiny compared to your implied comparison with Electron/Chromium.
And it doesn't even have true threading in the language, you can do it, but its not like a language construct. What is beautiful about VB6 is your ability to use native DLLs and parts of the Win32 API as well.
I've been wanting to see a VB6 successor for a long time. I have debated paying for Xojo but I'm not a fan of their docs and havent built anything worthwhile yet to justify buying a license.
Visual Basic was mostly just used for line-of-business software -- forms, reports, etc. That's mostly been moved to the web, but it was seldom used for anything where performance was important.
I'm not sure a BASIC compiler at twice the monthly cost of Photoshop is going to fly with anyone, but I'm definitely curious if there's a market out there for it.
I'm curious also, looking at their issue tracking (discord server invite looks like its gone stale... ) it seems like not a lot of interest at the moment. But it is weird how much old VB stuff is out there and because so few people put any effort into the old VB world, I think people would pay a premium for something that's useful. Having said that, their community edition probably would suit nearly everyone. I'm guessing a few people might want cross platform... So not sure how they make money, it seems like they'd need 1000ish customers to make it viable for 2 people. At the moment most of the things that have user counts related to the project (youtube etc) is much much less than that... but, maybe once they have a solid release a lot more people will come out of the woodwork. Anyways, interesting to see how they go.
The target market is companies that can't afford to migrate away from legacy VB6 applications.
This is a very captive audience.
I couldn’t find the exact license on their site, but it seems the subscription is per developer, not per user of the built executables.
In companies that deploy software for hundreds of users, that makes a huge difference.
It seems this is a competitor to RADbasic: https://www.radbasic.dev/
There's also Xojo which has quite a large community behind it.
As a VB6 fan I'm excited to have a couple credible looking alternatives finally crop up. Of course, there's the 80-20 rule, and history is littered with similar attempts.
Take a look at PureBasic . It is a mature product with a great developer and user community. It generates fast native code for Windows, Mac, Linux and RPi. I have used it for 15+ years.
It also has a sister product SpiderBasic that can convert most of PureBasic code to HTML, JavaScript for web deployment
https://www.purebasic.com/
I highly recommend it.
A recent talk with some good demos: https://www.youtube.com/watch?v=y4DRAcdH9tg
I am more of a Delphi/Lazarus guy myself, but can anybody who is actually considering using this compare it against Gambas, RAD Basic, Xojo, ...?
Apparently it is fully compatible with vb6 (as also radbasic says they are). I never tried but long time ago I ported a slew of vb6 apps to Xojo (realbasic at the time) and that was not hard but it was definitely work and not fully compatible. I would use Xojo still though as it’s very mature and I trust them being around in a while.
Xojo works and has a full time team working on it. It's not perfect but does the trick for me.
How long since you've used Xojo?
Over 15 years ago for sure.
I want something like VB6 but with Python instead of Basic, cross-platform and open source.
Lazarus comes close but it uses Free Pascal and (maybe because of that) is somewhat niche.
There are many GUI frameworks for Python, but I would like to have such a straightforward-to-use IDE. My current IDE is PyCharm, maybe there are some extensions? Maybe they are buggy?
Reminds me of Mosiac "Twin" spreadsheet: https://winworldpc.com/product/the-twin/1x
But surely Microsoft wouldn't indulge in malicious prosecutions over a market they already killed, right?
VB 6 is a scripting language for COM objects so 100% compatibility means having a 100% compatible Windows environment to run those COM objects in.
If this had been release 20 yrs ago, it would have been amazing. I left Windows when VB6 died.
In 1981 I (mostly) happily paid full price for Microsoft BASIC for Heathkit HDOS. In 1995 I was one of those fools lining up at midnight for Windows95.
In 1996 I had just about finished porting my primary consulting project from VB3 to VB4... when VB5 came out and changed everything again. That's when I realized I had been taken for a ride; I cancelled my MSDN membership and began exiting the Microsoft ecosystem for Linux. Haven't touched a Microsoft or Apple product for over twenty years now and life is good.
Wasn't VB5 backward-compatible? I thought VB.net was the first version that wasn't; what am I missing?
So missed on VB.NET and what was the replacement to beat VB productivity outside Windows?
twinBASIC backer here. It's been many years since I wrote any VB6, or even VBA, but I got my start in software engineering that through classic VB and still hold deep affection for it. I'm happy to support it even if I never end up using it.
Please bear in mind that twinBASIC is still pre-release / v0.x, and has not been widely publicized yet. The IDE, and in particular the forms designer, is very recent. Originally an extension to VS Code was envisioned (it's currently paused), but VSC was not extensible enough.
It's under active and rapid development right now, please judge accordingly.
I'd love to see the equivalent of VB6 for WASM.
It's been suggested: https://github.com/twinbasic/twinbasic/issues/570
This is a very niche tool. They may recover the investment made on it, but I don't see it as a growth market.
I had to write a little VB to maintain a legacy codebase at my first job. VB is long before my time, but at least from my perspective at that time, it was just a gross language to me. Who on Earth would rather have to end a function block by typing out "End Sub" instead of a curly brace? And case insensitive naming? I don't remember much else about VB, other than the immediate and visceral reaction that I needed to find a better gig.
Lua, Ada, COBOL, Pascal, etc. There's a long list of languages in use across the industry that don't use C-style bracing.
Then there are languages like Python that end without a statement due to differing whitespace.
In Lisp we use parentheses for that and no lisper ever complained.
With Scheme, you can also have whitespace [0], instead of parens, too.
[0] https://srfi.schemers.org/srfi-119/srfi-119.html
I wouldn't be too quick to judge..... quick tell me what these braces close }}}} no idea huh? in VB, closing blocks will tell you what they are closing. So, not such a silly idea, just more verbose!
> tell me what these braces close }}}}
The correct answer is: who cares.
Those who do care write them like this:
The editor lines it up with what it closes.Closing blocks telling you what they are closing were a good idea in the era when programmers had to line up at a job submission window holding decks of punched cards.
The reason is that blocks indicating what they are closing can assist the compiler in reliably recovering after syntax errors, continue parsing, so that you get as many useful diagnostics from a single compiler pass as possible.
That is almost entirely irrelevant today, though.
you may feel they are unnecessary, other people like it, and it definitely isn't from the age of punch cards. I like to watch people code on twitch, and the amount of times I see people get confused about what a particular closing bracket is closing is pretty regular. The other thing it allows is you can jump to all the closing tokens for IF statements in a file really easily. Way easier to write tools to extract certain things out of code files as well. While I don't mind curly brace blocks, I can definitely see the advantages of distinct tokens for different types of blocks
> Who on Earth would rather have to end a function block by typing out "End Sub" instead of a curly brace
It’s called BASIC because it’s more approachable to beginners. End Sub is not as strange to someone new to programming as a curly brace because it is almost English and less abstract.
When I first used C I wondered who in their right mind would start and end blocks with a curly brace when Pascal used BEGIN/END and other languages had other nicer and more easily glanceable structure markers.
You don't actually have to type out End Sub, the IDE does that for you. You just type in the new procedure's name and the ide gives you the skeleton with the cursor inside.
There's COBOL code at least twice, and possibly three times as old, that still runs billion dollar businesses every day, and likely will until you retire.
VB has its quirks but during its heyday, it was substantially more productive and easier to use than pretty much anything else.
No it won’t because Cobol programmers are basically impossible to come by today; when I retire they will all be dead.
So unless you can somehow convince young talented programmers to abolish 50 years of advancements and go program in an antiquated language again, in a short while there will simply be no option but to finally migrate away.
> Who on Earth would rather have to end a function block by typing out "End Sub" instead of a curly brace?
Someone who has to wait 10 minutes in line before a job submission window, holding a deck of punched cards, just to find out their program has syntax errors, and then repair as many of them as possible before repunching the cards and lining up again.
And that's about it.
There are a lot of eccentricities to complain about in VB, but somehow you have managed to only call out the features that were actually really common in a lot of other languages.
What about 1-based indexing and On Error Resume Next?
1-based indexing is pretty common among technical programming languages (R, Matlab, Julia, etc.) Not that VB is typically used for this, but people who think 0-based is universal have pretty much only been exposed to C and languages that copy its conventions.
It's 0 based by default, afaik, but you have the choice to make the lowest index whatever you want.
People who use national keyboard layouts in which {} is not easy to type, for example.