Live data from Hacker News

Ask HN: Why did Visual Basic die?

news.ycombinator.com

471–480 of 535 posts

Re: Ask HN: Why did Visual Basic die?

#471
post #441

Earlier quoted context omitted.

Vb.net was a bit weird yes but visual basic did need work. Vb6 did not have multithreading which was really starting to hurt its efficacy by 2002. You could work around it by using events as much as possible but there were still some things that were blocking. Also the events were not even on a separate thread either leading to the need to pepper DoEvents everywhere. This was a dealbreaker for vb to ever become a ser…

Electron seems successful regardless of lack of multithreading on the language level? I don't buy this one.

Javascript is better at asynchronism than VB was, and in Electron the user interface does run in a separate process. Unlike Visual Basic 6, where the UI would completely hang when you were busy with some external function call.

Re: Ask HN: Why did Visual Basic die?

#472
post #441

Earlier quoted context omitted.

Electron seems successful regardless of lack of multithreading on the language level? I don't buy this one.

Correct, nobody cared about "true" VB multithreading. Besides VB supported multi-processing very well, much better than the JS world does today. You could call objects between threads no problem. Behind the scenes it was using DCOM, so if you passed an object from one thread to another, the other thread would get a proxy that'd do RPCs to the first thread. So there was no true shared memory multithreading, but for VB…

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 great. They were good for the time, sure. Because they had to be. If you'd write an app in it today with lots of external API calls it'd be a mess.

VB6 was serviceable at the time but without multithreading support it didn't have a future in an ever more API-driven environment.

Re: Ask HN: Why did Visual Basic die?

#473
post #371

Not just VB, but also things like Borland Delphi. 25 years ago, you could visually compose a UI using standardized components, including advanced concepts like a layout manager. You could do data-binding visually by navigating a linked database. You can write logic/events just by double-clicking a button and the event is created. Here you'd write your code which would typically be pretty easy because all contextual o…

And everything looked like the same unusable mess with 25 nested tab groups and tree views

I'd take a Delphi/Lazarus UI over most Electron apps. They started fast, took little RAM or disk space, used very little CPU, had fast response times, supported standard UI conventions.

Today, we have endless options. But most are not as comprehensive as what Delphi is/was. I'd rather write a UI in Delphi/Lazarus (LCL/VCL/FireMonkey) than any other UI framework even today. The trouble is, I don't want to use it for anything else other than the UI.

UI design and data binding should be a simple mouse driven activity. That's adequate for most designs. Why do we need code? It's like expecting everyone to use LaTeX than RTF. Sure, it's more flexible, but an overkill.

I wish there are more integrations with modern languages than 20 types of grids with overlapping functionality. I'd write my code in a language appropriate for the task and just use Lazarus for the UI. Currently, Python (Python4Delphi) seems to be the only one with components for that, but even that needs more polish (and largely stagnant for over 20 years). Most I can do is do shared libraries and call in.

Re: Ask HN: Why did Visual Basic die?

#475
post #42

Earlier quoted context omitted.

I can write HTML/CSS/JS and a few back-end languages like PHP in my sleep but there's no way I could hand-code a web app as fast as I could a desktop app in 1997 using VB. I would LOVE it if I could, though.

Have you tried https://anvil.works ? (I'm a founder!) It's quite explicitly VB-esque (only using Python), and having a single paradigm rather than stitching together several different programs speeds things up even for those who can write HTML/JS/CSS in their sleep. (And of course, you can drop out to JS/CSS/HTML if you want.) Overall I think the development speed is comparable to VB6.

I started with Delphi 5 and completely share the sentiment of OP, development experience (mainly when building GUIs) was way better back then. For anyone who feels similarly I can only recommend you to look into Anvil. It is a fantastic tool, under active development and with a helpful and supporting community. It allowed me to build web apps by myself that I previously thought about hiring someone for. Very enjoyable experience and of course the fact that I am building web apps instead of desktop apps is a big plus in many scenarios today.

Great to see you here, Merdedydd! I was thinking about sending this thread to you. I discovered Anvil in a similar thread years ago and am very happy I did.

Re: Ask HN: Why did Visual Basic die?

#476

Earlier quoted context omitted.

Have you tried https://anvil.works ? (I'm a founder!) It's quite explicitly VB-esque (only using Python), and having a single paradigm rather than stitching together several different programs speeds things up even for those who can write HTML/JS/CSS in their sleep. (And of course, you can drop out to JS/CSS/HTML if you want.) Overall I think the development speed is comparable to VB6.

I tried it out and followed the entire tutorial, but the compulsory 'anvil' branding on every free published app kinda killed it for me. VB never had that.

But VB also didn't host web apps for you including databases, user accounts, email etc. I think self hosting is an option with Anvil by now, in which case you may be able to remove the branding.

Re: Ask HN: Why did Visual Basic die?

#477
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.

C# and VB.net are semantically 100% identical. Only difference is surface syntax, like begin end instead of curly braces. It scales exactly as well as C#.

Re: Ask HN: Why did Visual Basic die?

#478
post #339

Earlier quoted context omitted.

> The issue is that a lot of times businesses outgrow their bespoke Access app or whatever... > Of course if that never happens it’s great.. It could also be argued that outgrowing your initial business app is good thing. Lots of business don't outgrow it, because they don't grow :) Indeed, it might be reasonable not to invest too much upfront, before you have scale and can afford to build stuff you won't outgrow.

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.

Re: Ask HN: Why did Visual Basic die?

#479

Earlier quoted context omitted.

Exactly! The little Visual Basic I saw was always and entangled, manually tested, spaghetti code mess. Devs were productive only at the start of the project and slowed down to a crawl as things got more complex.

My favorite VB6 moment was as an intern. I opened a project that lived on a shared drive that wasn't in source control. Visual Studio popped up a dialog warning that I didn't have the proper license on my PC for the parts of the app that interfaced with Excel. Then it cheerfully deleted the offending project files and sections of code and saved it. On the shared drive.

Big oof right there. Thankfully, I've never had that happen on the job. The lack of meaningful version control in most VB projects is dangerous. It's like trying to operate a chainsaw without a handle. Whenever I get a new VB project to rewrite I always have to stop and remember "don't touch _anything!_". Then I sneak around like Indiana Jones in a lost temple filled with traps.

Re: Ask HN: Why did Visual Basic die?

#480

Does VBA for Excel count? Because if it does then VBA for Excel has reached the"nuclear resistant cockroach" level in finance. You wouldn't believe what sort of processes in very big banks/financial institutions are built using 10 year old VBA macros. In fact, VBA consulting for finance is a very juicy cottage industry at least in Europe to this very day.

I keep saying this to all the depressed new and old programmers who believe you cannot make money anymore and it’s all over; there are billions of lines of legacy shite running the biggest companies in the world. Not only Cobol and Fortran, but excel/vba, access, fox pro, and, indeed, old php. Companies have to choose, every year, to rewrite or maintain. I do many projects focusing on maintain; example; my last client had a quite to rewrite his systems in some modern crap (next/react) for a little over 8 million usd (that’s the estimate; not a fixed price and of course no guarantees by the consultancy corp quoting it) or, we will keep their ancient php and Java running for 25-50k/mo (few hours work per year to do that with Docker). I have a very low tolerance for rewrites so we go in hard against companies offering them: we make far far more profit than any of them; we run well over 50% with far less risk. Once I discovered containers (chroots in the late 90s and now docker etc), I knew rewriting things is never needed.
Post reply on HN