Live data from Hacker News

Ask HN: Why did Visual Basic die?

news.ycombinator.com

461–470 of 535 posts

Re: Ask HN: Why did Visual Basic die?

#461
post #356

Earlier quoted context omitted.

And it's often the best tool for the job

Other than the known calculation bugs in excel that MS refused to fix for at least a decade and probably still 20 years later. http://www.pages.drexel.edu/~bdm25/gnumeric.pdf http://www.phusewiki.org/docs/2009%20PAPERS/SP06.pdf http://www.tandfonline.com/doi/abs/10.1198/tas.2011.09076

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.

Re: Ask HN: Why did Visual Basic die?

#462

The productivity wasn't really that good. Rose tinted glasses. All the VB apps I've seen (and still get paid to maintain/rewrite to this day in the finance world) are an order of magnitude simpler than even a simple modern website. They often only have a few users, no devops automation, no deployment automation, terrible logging, terrible instrumentation, no tests, unacceptable access control, tons of failure edge ca…

Most of those were built by non programmers for "free" (no extra pay).

Re: Ask HN: Why did Visual Basic die?

#463
post #415

Earlier quoted context omitted.

As someone who loved coding in VB6: (I actually dreamt about it the other night, thought I woke up some 20 yrs ago!) - very cool that you got to interview the VB team, your article is high on my reading list :) - to OP’s point, I recently started doing some things in Swift with XCode and found sim having just as much fun. I’m using SwiftUI. So maybe not the same experience for everyone but I wanted to share here.

I did a shitload of programming in VBA, specifically Word macros. Word 6 was the peak of that product. I wrote entire text-processing applications in it, with dialog boxes and everything. Started my career at a Big-6 firm with one, actually. Now I’m learning SwiftUI as well, and like it so far. I’m an experienced iOS dev, but SwiftUI is new to me. But I like it (and QML in Qt) more than I expected. Good luck!

Thanks! Good luck to you too!

I don’t have experience with iOS - I am actually doing a bit of macOS development with that SwiftUI because, well, desktop apps kind of take me to my teen years building VB programmes (no one called them apps, at least I didn’t).

Re: Ask HN: Why did Visual Basic die?

#464
post #423

Earlier quoted context omitted.

This doesn't match my experience, if anything the other way around. CSS back then was a lot harder than it is now. There's still memes around this, but even something as common as centering an item with CSS was not trivial at all. Now we have flex and it's easy, but back then it was very much not. VB didn't work on the same paradigm - it was a more WYSIWYG environment. You drew a button on the form, set some properti…

Having worked for 10 years on both Delphi and VS, I understand the experience you are talking about. Having the ability to draw UI is amazing, and super productive. For business applications, it is amazing. However, I still remember at around 2002 that we where asked to build specific custom user experiences, I think it was around reports, and using VB or Delphi was a lot of programming using draw commands... while u…

These tools were built for GUIs, not typography where they were very weak. They outsourced document production to other tools like Crystal.

Re: Ask HN: Why did Visual Basic die?

#465

I think for a lot of purposes, the internet kind of took over. VB was great if you needed to do something limited to a single machine. These days, we want data to be available across machines which requires using a network, and the default network is the internet. If I'm going to be using the internet anyway, I can knock up something in HTML + JS + firebase/whatever data store, and have an application that works on a…

None of the VBA apps I ever saw needed the internet. They were mostly internal apps that connected to a corporate database over the internal LAN for stuff like "keeping a register of who has checked out which van".

Re: Ask HN: Why did Visual Basic die?

#466

Earlier quoted context omitted.

It was all about the difficulty of actually installing software on all those desktops. The web eliminated all of that. And it was so easy for ODBC and other configs to get trampled on by users and installers running amok over existing settings. Everyone was root on their PC in those days. The opportunity for users to screw things up accidentally was everywhere.

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 procedures you can implement whatever logic is needed for maintaining your data.

Re: Ask HN: Why did Visual Basic die?

#467
post #371

Earlier quoted context omitted.

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

Do you have an example screenshots of what you are talking about?

https://imgur.com/T9VnXi8

Why did this stuff happen?

Creating custom controls was difficult and considered to be for advanced programmers only. If you did create one, you'd get little to no help from the OS. You got lines and rectangles basically. You lost all layout support, there was no good typography features, etc. Coordinates would all be computed by hand. A real PITA. So everyone used the pre-made widgets even when they weren't really appropriate.

There were no icon packs and very few icons that were widely recognized by users anyway. So, everything was very text heavy.

There was a strong convention back then that you did not use scrolling to reveal controls. In other words, if you had more controls than fitted on the screen, you were expected to use button-like things to switch between pages of them, not expect the user to scroll down. The UI toolkits didn't support scrolling of widgets all that well as a consequence. This bias goes back very far and is partly due to the lack of compositing and pervasive optimizations for slow redraw speeds - it was more efficient to do a single redraw from old to new set of widgets than the constant rapid redraws required for animation.

All the UI code is being written in relatively bad languages like VB or C that aren't designed with refactoring in mind. The word "refactoring" doesn't even exist in this era, IIRC. Certainly, IDEs that help you do it don't exist.

Layout in this time is mostly absolute, or scaled to font sizes at best. Layout managers barely exist, so windows that aren't resizable are standard. As a consequence if you run out of space in a window, it can be disastrous - adding a new button or feature can become a tedious nightmare of relaying out everything by hand. So once code is written and app architecture is set early on, it's never changed. Features get added but redesigning the UI is so painful people just don't do it, and so if they run out of space you get ever more tabs, dialogs, buttons that open more dialogs that have more tabs, in an endless maze.

Re: Ask HN: Why did Visual Basic die?

#468
"why hasn't someone come out with a solid replacement?"

There are some companies/people keeping the torch burning but they're not as widely known, one such is Mercury which targets a whole host of platforms and is actually quite good - https://www.remobjects.com/elements/mercury/

The problem is it feels a bit of a niche language now because MS basically forced people on to C# by not actively maintaining VB.NET which was the first hop for people coming from VB. Early in my career I did various conversion projects for corps from VB to VB.NET then eventually as that atrophied to C#.

Re: Ask HN: Why did Visual Basic die?

#469
> I would go so far as to say we've gone backwards in a big way.

I would say you probably just don't remember how bad VB was. As a language its extremely simple and misses most of the modern niceties we take for granted, no iterators, no maps, no anonymous functions, no multidimensional arrays, no objects, the list goes on.

I remember when I moved from Basic to VB the single most impressive thing was that it AUTOMATICALLY KNEW THE LINE NUMBERS! YOU DON'T EVEN HAVE TO WRITE THEM ON EVERY LINE! If you made a mistake IT COULD JUST TELL YOU THE ERROR, no more looking up codes on a table in the back of a book.

Basic was never supposed to be good to use it was only ever supposed to be easy to learn.

Re: Ask HN: Why did Visual Basic die?

#470

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…

VB was probably 80%+ line of business CRUD apps. What would you write in VB that needed multi-threading? You're not writing trading systems or games in it.

> VB was probably 80%+ line of business CRUD apps.

That's more a result of it not supporting it I'm sure. It could have been a great general purpose language if it was a bit more powerful.

I used to write apps in it and I often ran into these issues. Mainly small business custom administrative stuff. Like a management system for a chain of hostels. It was still important to have multithreading because things can get updated by other users, or even clients themselves through the internet (in fact I spent a lot of time adding ASP frontends back then). I don't like using locking too much in a multi-user environment because it gives a terrible UX, so I would have to constantly check if nothing had changed.

In this day and age you will also have to deal with a lot of web API calls that can happen asynchronously. Locking the main thread is really not an option. Remember that VB6 even locked the User Interface when it was doing something, even the visuals didn't have their own thread. Making for a very choppy experience.

Like I said peppering DoEvents everywhere helped mitigate this a bit, but sometimes you had to call stuff in external DLLs and while the call was away the whole UI would be hanging.

Post reply on HN