Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: Why did Visual Basic die?

news.ycombinator.com

Post reply on HN
Print view View original

501–510 of 535 posts

Re: Ask HN: Why did Visual Basic die?

#501

Post by emodendroket »

Khartoum wrote: post #478
Spooky23 wrote: post #381

Earlier quoted context omitted.

The issue is there’s no engineering process around it, even in a shitty organization where the “engineering” is garbage. One place I helped out at had a pretty awesome access app for doing some business functions. Way better than the Oracle whatever they failed to replace it with. The problem was, nobody was willing to claim ownership. The business guy who wrote it was long gone, and IT would not accept an Access app…

> The problem was, nobody was willing to claim ownership. The business guy who wrote it was long gone, and IT would not accept an Access app. If the business relies upon that Access app, and IT refuses to accept it, then it's a failure of IT to accept it and then replace it. IT exists to serve the business.

OK but does IT exist to serve the business by accepting responsibility for stuff that doesn’t meet their standards and they can’t really support? Why have qualified people at all then?

Re: Ask HN: Why did Visual Basic die?

#502

Post by emodendroket »

MichaelZuo wrote: post #491
emodendroket wrote: post #386

Earlier quoted context omitted.

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.?

Database corruption, unexpected bugs, inability to account for new desired behaviors… have you worked on software before?

Re: Ask HN: Why did Visual Basic die?

#503

Post by mike_hearn »

walnutclosefarm wrote: post #492
mike_hearn wrote: post #466

Earlier quoted context omitted.

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 s…

If you have an ability to force web-style updates on the client apps (which a tool like Conveyor supports, see my other posts or profile), then all you need is a database that supports many connections. You can then atomically upgrade all the clients by e.g. writing a version number to a db table that's checked as part of each transaction, if the version doesn't match the app proceeds to upgrade itself before continuing (unless it's marked as a soft update, i.e. not worth interrupting the user for). The versioning issues aren't much different to the ones you face once you decide to have multiple web servers and rolling upgrades.

Re: Ask HN: Why did Visual Basic die?

#504

Post by resoluteteeth »

C# with winforms in visual studio using the gui builder is basically the same experience as vb6 but better in every way. I'm honestly not sure why complaints about legacy vb6 being killed tend to overlook this, but I think it's because there are lots of people who have fond memories of vb6 but have simply never tried c# with winforms. If you want that experience, you can literally get it right now as long as you're ok making desktop apps that will only run on windows and don't mind that it may look somewhat out of place among more recent windows apps using WPF and its successors.

The real question then isn't why microsoft "abandoned" visual basic (they replaced it with something that is strictly better), but why people aren't using winforms or something similar in 2023. I think that's because 1) it isn't cross platform and 2) people have lots of other requirements that are difficult in winforms.

Aside from being cross-platform, I guess the winforms api requires you to manage a lot of stuff like data bindings by hand that people are used to having work automatically. People also want good support for various monitor sizes, although .net winforms is actually much better about that than vb6 because it has pretty decent layout controls so you don't have to write code to handle resizes to the same extent.

The fact is, the vb6 gui builder worked best if you just ignored resizing and only had to worry about one screen resolution, and even though .net winforms is better about that, it's still fairly complicated to use the layout controls to handle resizing properly

I think there was actually a project that was attempting to make a winforms-style api for Avalonia which would actually fix some of the problems including cross-platform support (including mobile; avalonia is pretty slick and it's unfortunate that microsoft hasn't just hired the people making it rather than focusing on stuff like winui and maui), but I think it stalled because among people making desktop windows applications there simply isn't that much interest in using a winforms style api in 2023.

Re: Ask HN: Why did Visual Basic die?

#505

Post by mike_hearn »

wkat4242 wrote: post #495
mike_hearn wrote: post #490

Earlier quoted context omitted.

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…

I thought there were JS style worker threads:

https://learn.microsoft.com/en-us/previous-versions/visualst...

but from looking it seems like people were doing it by writing VB that ran in a separate EXE and then indeed, COM would let you do RPCs between the different processes. So multi-processing rather than multi-threading.

Re: Ask HN: Why did Visual Basic die?

#507

Post by pillefitz »

harry8 wrote: post #483
rvba wrote: post #461

Earlier quoted context omitted.

It is funny how you talk tjat Excel is bad and the examples just dont work. Also lack of accuracy in calculating some complicated statistics that "nobody" uses is not really a calculation bug. Also most of those come from the fact that Excel has a precision of 15 digits.

My fav was when ms announced they'd paid an academic to fix =rand(), ignoring all the others. Let's see it. Fill the visible part of a sheet with it, conditional format the cells, red for negative etc. hit f9 to recalc and see a big bunches of cells turn red. Fixed random function to return a random number between 0 and 1. I haven't worked on gnumeric for a long time - examples came from gnumeric.org Excel was really…

First rule of Excel development: Don't use sheet formulas, stick to VBA and apply normal dev practices

Re: Ask HN: Why did Visual Basic die?

#508

Post by walnutclosefarm »

mike_hearn wrote: post #503
walnutclosefarm wrote: post #492

Earlier quoted context omitted.

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 s…

If you have an ability to force web-style updates on the client apps (which a tool like Conveyor supports, see my other posts or profile), then all you need is a database that supports many connections. You can then atomically upgrade all the clients by e.g. writing a version number to a db table that's checked as part of each transaction, if the version doesn't match the app proceeds to upgrade itself before continu…

I'm happy for you if that's working out in your enterprise. It was not our experience in the time frame we're talking about (VB was sunset over 20 years ago), and frankly it was not our experience 5 years ago - when we were running skads of applications on Citrix servers so we could have absolute control over the "client" runtime environment, and have the actual on-the-glass experience be thin client.

Re: Ask HN: Why did Visual Basic die?

#509

Post by SoftTalker »

mike_hearn wrote: post #503
walnutclosefarm wrote: post #492

Earlier quoted context omitted.

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 s…

If you have an ability to force web-style updates on the client apps (which a tool like Conveyor supports, see my other posts or profile), then all you need is a database that supports many connections. You can then atomically upgrade all the clients by e.g. writing a version number to a db table that's checked as part of each transaction, if the version doesn't match the app proceeds to upgrade itself before continu…

IIRC back in the day, Windows could not replace a file if the file was open by any process. So an application could not update itself, without doing something like launching a separate "updater" and then exiting.

Another thing people tried was putting the VB app on a network share so it wasn't installed on each machine, but I think all the ODBC and other config still had to be local on each client.

Powerbuilder apps were similar.

Re: Ask HN: Why did Visual Basic die?

#510

Post by ralphc »

jacquesm wrote: post #300
analog31 wrote: post #295

Earlier quoted context omitted.

That was me. I wrote what I affectionately call "crapware," which are small apps that solve a problem but are not intended for use at scale. There was a lot of this stuff, such as little database queries, or hacking together a few industrial sensors with a crude display. Businesses ran on crapware. Maybe they still do. A few thousand lines of code that I wrote for a manufacturing fixture ran bug-free for more than a…

I came across such a project recently built using FileMaker in 2001 or so. On the original hardware, no less.

Please encourage them to make a backup and get it into a VM. You should be able to find Windows 2000 if it will run on that.
Post reply on HN