Live data from Hacker News

Ask HN: Why did Visual Basic die?

news.ycombinator.com

491–500 of 535 posts

Re: Ask HN: Why did Visual Basic die?

#491

Earlier quoted context omitted.

I don't get the relation here?, most businesses care somewhat, and certainly the better run businesses do quite a bit, so they'll make sure to record down everything important about the software.

So when it goes wrong in many predictable ways it’s a nightmare. All the stuff software engineers put around software to make it reliable, fault tolerant, and generally having the expected behavior is not just for laughs but the result of hard-won experience.

Why would it be a 'nightmare' if they recorded everything down and understand their software, what it does, what it doesn't do, how it operates, etc.?

Re: Ask HN: Why did Visual Basic die?

#492

Earlier quoted context omitted.

Well, that, and all those wonderful apps were inherently client-server architectures, with the business logic on the client. Nobody ever built a properly factored, with stateless layering, and high-end scalability on such an architecture. Just trying to keep 1000 clients in sync, so your business logic remained consistent could drive you to distraction; in a truly distributed product with tens or hundreds of thousand…

Nothing about two-tier architecture prevents you from keeping clients in sync, scaling up or implementing business logic. Consider that scaling your database has to be done anyway. Your web app will bottleneck on the DB too. The only difference is number of connections assuming you keep them open (but there are multiplexers for that, and many business apps don't need them anyway, RAM is cheap enough). With stored pro…

Of course, if you want to twist VB, or Delphi, or any of the client-server construction sets into pretzels, you could build a well-factored system. And yes, your data has to scale to your system size, regardless of the architecture. But if you use any of those tools (the article was about VB, after all) as designed, you cannot escape the problems I outlined. Your business logic will be either entirely on-client, or split between the client and the database, and it won't be stateless. You will have database connections and transactions spanning thousands of client processes directly to the database, with all the scaling and contention problems that introduces. And you will have an update problem, because updating business logic requires you to push changes to thousands of client machines, which may or may not be available and updatable when you go to deploy your new version.

Can you still build a system, and operate it? Sure. A lot of us did. For small to medium scale systems, it was manageable. But there is a reason we abandond 2-tier client server 20 years ago. While it made building CRUDy business applications vastly easier for the developer, it was a systems nightmare.

(It also led to crappy user experience for any application that wasn't itself inherently a CRUD record keeping job, because it inhibited application designers from thinking of the application as anything other than CRUD. But that's a different argument for a different day).

Re: Ask HN: Why did Visual Basic die?

#493

Earlier quoted context omitted.

I was with you until "... so is writing a React frontend". No. No it's not. Making a functional UI in visual basic is childs play compared to the absolute cesspit of NIH and feature treadmill that frontend web development has become. You are gatekeeping with strawmen.

A better comparison is with VB’a spiritual successor: Power Apps. Not sure, but I think VB is still responsible for most of MS’s security threats even now. It makes sense for MS to try to EOL

I saw a talk on Power Apps at ATL DEV CON this weekend and was blown away. The only downside is it can only be used internally, with AD M365 logins. It won't work with B2Clogin, and it won't work without authentication.

But, that's the only way I used VB6 - for internal software.

Re: Ask HN: Why did Visual Basic die?

#495

Earlier quoted context omitted.

But the whole thing of the UI being on the same thread was a really big problem. You could get around it by calling the Win32 Threads API but that would quickly lead to a crashfest due to the no shared memory thing. Electron doesn't have this problem because the UI is handled by the renderer, not the JS engine. So in that sense the UI is in a separate thread. This wasn't the case for VB6. And events in VB6 were not g…

I don't quite understand what you mean by UI being in a separate thread. You could have background threads in VB from what I recall (it's been a while...). The only difference is that Electron/JS forces you to do your own IPC messages whereas Windows would abstract that out.

What I mean was that if you ran a large function that would take a few seconds, any UI redraw would be blocked completely for that time. So resizing a window would not cause a redraw of the UI until it came out of the function, pressing a button would not visually reflect the button status, basically it would seem like the application was hanging.

You could avoid this by peppering DoEvents in your loop. However, this was not always possible like if you were calling an external DLL function. I had an application that would talk to a Kodak digital camera by using their DLL and that would take considerable time.

It's really what separates a serious programming language from a toy, or at most a prototyping tool. Like Fisher Price, you can make something quick but it's not capable of actual use.

I think people have this rose-colored view because back in those days UX standards sucked and many apps had a lot of quirkiness. But times were changing and even a few years later this was unacceptable.

There were no official background threads, you could use the Win32 Threads API but it would cause instability due to not having memory protection.

But this "hanging" behaviour was really not suitable for a general purpose application. Electron doesn't have this issue because the renderer is independent from the javascript code.

Re: Ask HN: Why did Visual Basic die?

#496

Earlier quoted context omitted.

I was with you until "... so is writing a React frontend". No. No it's not. Making a functional UI in visual basic is childs play compared to the absolute cesspit of NIH and feature treadmill that frontend web development has become. You are gatekeeping with strawmen.

A better comparison is with VB’a spiritual successor: Power Apps. Not sure, but I think VB is still responsible for most of MS’s security threats even now. It makes sense for MS to try to EOL

[dead]

Re: Ask HN: Why did Visual Basic die?

#498
post #242

Earlier quoted context omitted.

While maybe that's true, that doesn't map to my experience very well. After QBasic, I wrote a lot of Visual Basic 5 and 6. I had poked at C, but would not say I knew it, and had never done anything useful in the language. But I did exactly one thing in VB.NET before trying C# and realizing that it really did encapsulate and present a better way to think about code. It's not perfect, but it's much, much better--and in…

I've worked with a ton (too many) VB programmers by virtue of the work that I do (UI automation). My experience all suggests that pure-VB (even .NET) is a treacherous dead-end, because it doesn't scale in terms of complexity and project size, and the point at which is stops scaling is often unrealized by its developers. - VB(.NET) is amazing for small, simple gadgets. - VB(.NET) is terrible for large or complex syste…

> - VB(.NET) is terrible for large or complex systems.

I can't say I agree with this. My experience has been that developers who write things in VB tend to be self-taught and don't know how to scale up small gadgets into large systems.

Re: Ask HN: Why did Visual Basic die?

#499

Earlier quoted context omitted.

What's the bottleneck to build a modern VB6? Just curious.

There are VB like tools. These days they're all SaaS though. Oracle APEX is one well known one, there are plenty of others out there. There are at least three massive problems faced by anyone who wants to hew closer to the VB6 model: 1. Deployment tech. 2. Getting people to pay for it. 3. Developer culture. In order: Deployment. There are tools and UI toolkits today that support VB6/Delphi-like development, but they…

Amazing reply, includes a lot of information that I wasn't aware of even though I was the OP there! Thanks.

Re: Ask HN: Why did Visual Basic die?

#500
A few thoughts as I was a VBA developer at the time .net was released. 1. VB was deliberatly killed off by M$ in order to get .net going and the resulting vb.net was horrible to use. 2. C# was the new kid on the block and acted enough like C++ to not totally alienate C developers even though the library was terrible. 3. Security was becoming an issue as applications moved to the internet. Since VB and all the classic ASP tools used com they were deprecated in favor of .net runtimes.

Meanwhile VBA was running many business solutions and supporting multi user applications, reporting applications. I developed many apps in Access and Excel that were business critical and are still in use today. IT management wanted these to be re written in .net and found it nearly impossible from a budget standpoint and those that were converted we slow and clunky since the Office interface from .net is slow. Last thought... VB was always the poor step child to fully compiled languages like C and C++. And VB developers were looked at poorly as undisciplined which many were. Looking at the online apps today where Java script is used with undeclared variables tells me that no one's cares about that anymore.

Post reply on HN