Delphi, maybe, sure. But starting a new project with vb6 is just weird unless it's the only language someone is familiar with. It's a dead end, even on the only platform where it makes sense to use it.
FreePascal/Delphi and VB6 are entirely different beasts. For one, FreePascal and Delphi are still under development. Delphi had the following language features added since 1998 (this is just a small selection):
Extension methods/properties ("class helpers"), generics, enum types, for..in loops, static methods, closures, smart pointers, value types ("records"[1]), attributes, variables can be declared anywhere (removing Pascal's limitation), type inference, multiline strings.
Besides all of this, modern Delphi can compile code for Windows, Linux and Mac, as well as Android and iOS. It seems like there's even a cross-platform library for writing apps that can run on both Mobile and Desktop called FireMonkey.
VB6, on the other hand, is a language frozen in time. It never supported any other platform than 32-bit Windows[2]. It only really works on the new Microsoft Surface Laptops thanks to emulation, but I can also run Nintendo 8-bit games on a Surface Pro 11 using an emulator — that doesn't say much.
Unicode support is also a mess. VB6 always used Unicode internally, but this was implementing during the UCS-2 heyday (so you need hacks to use Emoji for instance). Worse yet, is that VB6 was never really designed to run natively on Windows NT, so it's mostly using using the XxxYyyA family of APIs instead of the XxxYyyW family of APIs. This means that you can only display text in a non-English writing if your system's ANSI codpeage is set to that language (in the past you had to restart Windows to change this, not sure if it has improved). To make things worse, some languages (from countries that were too pair to get ANSI pages in Microsoft during the 1990s). So no Ethiopian languages or Mongolian as the author claims. Windows ANSI codpeages also do not "fully support" Japanese and Chinese as the author claims. Over the years the governments of Japan, China, Taiwan and Hong Kong have updated their national standards (which defined tables of characters that should be digitally encodable) and introduced more characters that were previously not mapped. These characters were not new or fake[3] — they were just less common, but still in use. All of these various government standards (like JIS X 0213, GB 18030, Big5-2003) got quickly incorporated into newer versions of Unicode, but the Windows ANSI codepages stagnated and they don't support some of the characters in these codepages. I'm not sure how it's going to affect VB6, but I'm pretty sure that some Unicode CJK characters would just not map into ANSI and would not be displayed even if your system code page is set correctly.
With all of these things considered, no developer who cares about their users should choose VB6 for writing a modern app. I'd also argue that no developer who cares about themselves would do that. VB6 wasn't a great language to begin with. It was better than VB3, but it was still inferior to Delphi even when it was out. Customizing the UI beyond the basics, often needed custom ActiveX components written in C++ or messing around with a lot of raw Windows API calls. Error handling was very painful too. It was never a great developer experience even back of the day if you wanted to do anything beyond the basics.
---
[1] To be fair, Borland's Pascal dialects had value types support since they've implemented object oriented programming (that came in either Turbo Pascal 5.5 or 6.0, I don't exactly remember). Turbo Pascal "objects" could be put on the stack or as pointers like in C++. They even had destructors that would be invoked automatically when the object went out-of-scope, again like C++'s RAII. But the old "objects" kinda botched polymorphism (I don't even remember the details), so when Delphi came out they've been replaced with "classes" that are Reference-only (like Java, but initially without any form of automatic memory management).
[2] VBA was originally ported to Mac, but it is not exactly the same language, lacks the GUI designer and can't run most VB6 apps
People have been writing Unicode supporting VB6 apps for decades now. There's a very popular project called VBCCR that provides reimplementations of all the VB6 UI controls with full Unicode support and additional features. It's not "a mess", it's standard for any VB6 code written by a decent programmer in the past 15+ years and works fine because under the hood it's UCS-2. So everyone now just uses xxxW APIs passing strings by direct pointer. And supporting extended characters is a standard 5 line rewrite of ChrW.
Now the backwards compatible successor being talked about for the new XYPlorer versions support Unicode everything from the ground up.
And since this is discussing twinBASIC now, the new version of the language, you've got all your additions. tB has native Unicode everywhere (hell, you can even make your function names and variables emojis), generics, type inference, attributes, declaring module-level stuff anywhere, not to mention all the things you listed that were supported to begin with like enums and for loops and dozens of others like delegates for calling by pointer, defining interfaces/coclasses in the project, multithreading support, 64bit support, etc. The language is now no longer frozen in time with a backwards compatible successor with tons of new language features and cross platform support one of the major future plans.
People's knowledge of VB6 seems to be also "frozen in time", unaware of what modern use of it is really like.
Delphi pricing is USD1400 for the developer edition and they are corporately mercenary chasing their payment. In 1996 Delphi 2 was released at USD500 for the cheapest Desktop version (which is ==USD1000 accounting CPI). Edit: I converted from NZD to get the USD1400 figure - the actual USD cost will be less in USD without our GST/VAT.
I really don't see how this invalidates the statement, regarding that VB's primary domain is rapid CRUD application development. Those applications usually don't use >2GBs of RAM, at least from what I've seen working on several old ones written in VB6, Delphi, PowerBuilder... Is a 64-bit Electron CRUD app that much more capable/better in getting the job done than a 32-bit VB6 equivalent? Both are merely an SQL client in the end.
Yeah, I used VB5 as one of my first languages and today did half a day of VBA. Definitely enough to quickly make me want to raise my hourly rate. Esp. in that office macro editor.
Btw and totally unrelated office can now interpret VBA, (office)TypeScript and Python. Did I miss any?
