Exactly. Especially when considering that Signal was often advertised as that *one* privacy friendly open-source messaging solution in a world dominated by data-collecting demons like WhatsApp, etc. I don't think even WhatsApp let's such status details leak; notwithstanding whatever they might be doing with the user data on the backend.
There could be limitations on scaling the transistors as we approach nono-meter sizes, but there are other ways to sustain the Moore's Law and economies of scale; like 3D stacking, focus on specialized architectures like GPUs, TPUs, etc. and of course, the ongoing research on quantum computing which will also pay off some day.
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?
Keep up the good work. Both desktop and cloud apps solve problems for users, but there is no doubt a different kind of old school PC era charm in using the former. There is a sense of freedom that comes from the ownership of software and platform while you work with it.
Evolution theory is generally quite coherent and intuitive. But while it can explain how a monkey or ape turned into homo-sapien, it can't explain how an amoeba turned into human. It can't explain the consciousness aspect or how life ever came from the "life-less", or was life always there to begin with?
Of course evolution can explain how an amoeba turned into a human -- a series of steps, each driven by natural selection. Not all the steps are known yet, but there's no reason to think something else is needed. Complexity accumulates progressively.
The origin of life itself is a different matter. This is not well understood. There is a very large complexity gap to the smallest known organism and it's not at all clear how to bridge it. At best we can say we haven't ruled out various kinds of partial theories for how it might have happened.
Let us simplify our IT layers and stacks before it is too late.
It's time to introspect and ask those critical questions: Is it really necessary to install each one of these apps, every single one of these libraries and frameworks? How can I remove dependencies from these libs and do a little core work myself? And tell the same thing to your partners, colleagues, coworkers, etc. If you find 4-5 apps doing basically the same thing (like communication or productivity tool), see if you can consolidate them into one.
> If you find 4-5 apps doing basically the same thing (like communication or productivity tool), see if you can consolidate them into one.
If I could get all of my friends to switch to one communication app, that would be great, but that's only going to happen if they can get their friends to switch, and so on. Unfortunately, doing so requires them to install additional apps for communication, and no one can get everyone they talk to to switch, so they're just going to have more people on one app than another and in the end the problem gets worse.
Matrix bridges solve a lot of this problem, though... aren't really reducing complexity at all ends of the system. It does radically reduce end user app complexity, though.
I've been hosting a Matrix homeserver for... oh, 4-5 years, now, and I have bridges installed for my use and a few other people who use it that bridge Signal, Google Chat, Facebook Messenger, and maybe one or two other services into Matrix - so I almost never have to bother with the other clients, I just use a Matrix client everywhere. There are the occasional quirks you have to deal with, most of which are solved by upgrading your bridge (and the new bridges are a lot easier to deal with than the older ones).
As people decide to go Matrix-native, I can talk to them that way as well.
That said, as far as non-Matrix options go, Signal seems to be a fairly common one and easy enough to get people to switch to.
https://docs.mau.fi/bridges/go/setup.html?bridge=signal is the setup for the Signal bridge, and you'll also need to look at the initial config setup. Once you have a working Matrix homeserver, it's mostly "Create a new database table, point the bridge at it, add the proper incantations to your homeserver config so it knows the bridge is permitted, and start things up."
I don't find it bad in the slightest, but I'm also a legacy Linux sysadmin sort.
If you're a GUI-only sort, it will be painful. If you're competent with older styles of Linux sysadmin, it's fairly straightforward, though getting Matrix federation working reliably can be a slight pain. Just make sure your certs update...
Alright that doesn’t look too bad at all. I’m not at the level of sysadmin, but I do daily drive Debian and generally know my way around a terminal. I’ll give it a shot!
The press often does a great job of shielding those in power from reality, and that's what it did in most of the Biden term. Now, I also disagree with the other extreme view that press needs to be positioned so against the establishment that it conflates facts with fiction. Not taking the side of either ruling or opposition but pushing for society's interest is the real job of press.
WebSockets has become popular only due to this "instant" mindset. IRL, only a handful of messages or notifications need a truly real-time priority such as Bank OTPs, transaction notifs, etc. Others can wait for a few seconds, and other architectures like middleware, client-side AJAX polling, etc. could be both cheaper and sufficient there.
reply