[woodylondon]

I started in Visual Basic 3 and then moved to Delphi. My first job at 18 was working for one of the large ActiveX component libraries, providing technical support to many developers when I wasn't one myself yet!

On my first day, I found a book on my desk—"Learn Visual Basic 3 in 21 Days"—along with a brand new 486DX250 and a 14" monitor. I learned a lot quickly! We answered support queries by fax back then.

I never fully understood why this programming paradigm died off. Building business apps beyond Access or Excel was so straightforward. It was great to get an .EXE that you could package up with InstallShield or Wise Solutions and send to anyone.

I guess the web came soon after, and trying to do WYSIWYG for HTML and CSS has never gone well—even today.

FrontPage came out but died soon after, and mixing desktop apps with web apps was never great.

Today, I feel .NET is overly complex and much harder for beginners compared to the old days.

Sometimes, I think there are only so many ways to control the appearance of business apps. I'd constrain visuals but provide the most straightforward visual builder possible.

The No-Code world is fascinating, and the best I've seen in this space is https://retool.com/, but it's expensive and locks you into their ecosystem.

Even today, small businesses need to build out simple apps that were simple to do back in the Visual Basic days—a stock control system, a basic support system, sales tools, etc. Today, it's a minefield of options that can quickly get expensive.

I'd love to have a visual builder that creates code you can host yourself — something like retool.com but with open source and self-hosting, or maybe I'm just too old for this now! :)

[rty32]

> I never fully understood why this programming paradigm died off

My two cents --

A few reasons (briefly, I could have talked a lot more)

* Shift in platform: Windows is no longer the sole platform people want to build their apps for. Not a bad strategy by itself, and lots of companies still only develop for Windows (e.g. specialized software for instrument control etc), but people increasingly want their stuff to work on iPad, Chromebook etc and maybe even phones

* Shift in screen size: It used to be that everyone runs Windows on a 800x600 screen. That changed, and then changed quickly. Many different resolutions and screen sizes. The drag and drop thing just doesn't work well for that. The web model, where you write "responsive CSS" and the browser handles the rest for you, works better.

* Software and their UI got a lot more complex and require more expertise. On the other hand commercial software becomes easily available and accessible for those purposes. For the examples you mentioned -- stock control system, sales tool, they may be fine with VB6 for a prototype but can quickly get complex. And there is likely a commercial software you can buy and download within a few minutes at an affordable price.

* Shift to online/cloud: vast majority of "small VB6 applications" were used locally, and they never connect to the Internet. That's different now.

* Shift in language: BASIC/VB was often used for teaching, and it is indeed great as a first language to learn. Although Python already existed at that time, it became very popular, and I think many people would agree Python is a much better language than BASIC, in many ways. As a result, BASIC along with VB went out of fashion.

[werdnapk]

I've always found the use of anchors on UI controls to be light years ahead of what HTML/CSS have been doing. I always used to create UI forms with resizing and different screen sizes in mind. If you were coding for a hard coded 800x600 screen then that was just laziness.

[lukan]

Does that solve the problem between vertical/horizontal layout?

On a mobile the default is vertical, on a desktop horizontal. That matters more than different screen size and is the hard part.

[troupo]

It's a bit ironic how in the same breath you go from "it's impossible to build apps for multiple resolutions with drag'n'drop hence web" to "software and their UI has become more complex".

While the absolute vast majority of web-based software cannot hold a candle to UIs you could trivially build in VB (or Delphi and other RADs). Most web-based software is either trivial forms or a few screens of text and images they struggle to display with any acceptable performance.

As for "many different resolutions and screens", have you ever, I don't know, resized a desktop window? Desktop apps work at the number of crazy sizes the web would die at.

[stavros]

I think you left off the biggest reasons, commercial:

* No piracy. Can't crack code you aren't running.

* Immediate installs/updates. No need to tell people to ever update stuff, or to install your program in the first place.

* You can charge subscriptions. It's much easier to justify a subscription when you pay for server costs, even though the customer would be happier just running your application locally.

* Easier deployment. You can handle complex integrations on the server, without the customer having to open ports or whatever.

[rty32]

Good points. I was more focused on the technical side.

I want to add a bit more to "easier deployment" -- traditional model is that you push updates at some interval (regular interval like semi annually/annually or non regular intervals), and you need to manage multiple versions and potentially patch multiple versions for severe bugs or security issues. Lots of software still works that way. But with office 365, jira etc you only have one version to worry about. Of course it means different risk levels, SLAs etc, but that's a different topic.

[alxlaz]

> Shift in screen size: It used to be that everyone runs Windows on a 800x600 screen. That changed, and then changed quickly. Many different resolutions and screen sizes. The drag and drop thing just doesn't work well for that. The web model, where you write "responsive CSS" and the browser handles the rest for you, works better.

This... really doesn't match my experience at all. I may be thinking of later UI development tools from the .NET era (I no longer recall if VB6 had proper support for linear layouts and the like, that was forever ago) but GUI builders with responsive controls were absolutely a thing, and they ran circles around any "responsive" CSS we have today, if only because they had instant feedback. I don't miss most aspects of programming from that age, but this is one that I do miss tremendously.

Edit: I certainly agree on the other points. I think this one was less of a technical limitation and more due to the humans in the loop; lots of people just didn't know better, information dissemination was far more limited (lots of us learned these things offline, from books and the like), and the platform didn't force you to do the right thing, either.

[specialist]

Yes and:

> Shift to online/cloud ... they never connect to the Internet.

The fall of VB6 style RAD (for CRUD) started earlier with shift from "workgroups" (shared files on LANs) to client/server. This severed the direct link (ADO api) between apps and their persistence.

Tragically, the ODBC (then JDBC) API interface didn't quite fully bridge the gap. Meaning some necessary metadata was no longer front and center (for both compile and runtime, like ADO had always had). Yielding mitigation attempts like DAO/DTO, ActiveRecord, ORMs, LINQ, templates, etc.

That sad state of affairs is described in Ted Neward's famous "ORMs are the Vietnam of computer science" essay. https://web.archive.org/web/20060813030731/http://blogs.tedn...

Of course, client/server had to happen. But the innovators (and critics like Neward) didn't fully understood what they were replacing, what parts were missing. (Lather, rinse, repeat.)

--

It took noob me a LONG time to figure this out. (All I ever wanted was to recover the special magick of VBA + ADO.) And then even longer to attempt mitigation (cuz am noob).

Maybe if we had the new "internet's hourglass shape" analytical framework from the beginning (vs say OSI's layer model), someone(s) could have prevented the oversight. https://cacm.acm.org/research/on-the-hourglass-model/

[anonzzzies]

> Software and their UI got a lot more complex and require more expertise.

In the B2C space sometimes sure. We do business with many companies all over the world and if you can see the 100s of 1000s of apps they are using; you could've done all of them with Delphi/VB without any tricks. Except now some incapable but suave talking Nextjs fanboi walked in and pushed all that overly complex nonsense while it's not needed for almost anything we see used in companies. Spending fortunes on stuff you should just click together in a few minutes and hook up a db. But yeah, we make nice money because of it for both of my main businesses; 1) fixing completely broken stuff because the person who introduced the tech left quickly after introducing the misery 2) creating LoB/ERP custom applications. Both are goldmines and both are goldmines because of the tech losers (resume driven 'workers' almost always) around the world who preach to always use the 'best tool for the job' and then completely do the opposite, introducing tools that really have no place there, ever.

And then the joke of course that they are not even really good at them, which is the worst pet peeve of mine; ONLY yesterday, I was virtually (via Teamviewer) fixing a new LoB app made by 2 freelancers who came (apparently) highly recommended; it was made in Next 15 with React 18 and shadcn (that's not fully compatible yet... but that's normal in that ecosystem; nothing is). So I checked the Linkedin / github's of these freelancers and had a short call with them if they could help (no, they had no time; new clients!); they were Django/Bootstrap guys before, but that sells less well than Nextjs/shadcn/tailwind, so they switched recently. What a joke. Why is this not liable really... But again, we make very good money, so please carry on!

[TeMPOraL]

I'd add another reason:

* Idiot developers like myself. Okay, I was a teenager back when I got infected by this idea, but it did persist for some time into my start of my career too - the idea that RAD tools are inferior, they are not "true programming", just some lazy no-code clicking to save monkeys from understanding the program they're building as a whole, etc.

I mean, sure, you could do a lot in RAD tools really quickly, and do it well - but that was cheating. Too good results for too small an effort. It wouldn't impress any of your IRC friends.

(Curiously, those few I know from my "generation" who wrote software for e.g. their parents' business, would happily use VBA or Delphi. Wonder why...)

This was all adjacent to and connected to other ideas that became influential with our cohort of developers, like "Windows suxx, Linux rulez", "plaintext is best", "CLI is best", "code generation is evil", etc. Those ideas are still deeply rooted in FLOSS, too.

VBA - was not C-like, you couldn't exactly put the whole project in SVN and diff nicely, it's tied to a specific platform (that sucked), a specific vendor (at a time when we all hated the evil M$ because it was the Right Thing to Do), and to a specific software suite (which was not vim). It's tricky for a technology to survive after a significant part of the fresh workforce tried to steer clear of it as a matter of principle.

[woodylondon]

https://www.flutterflow.io/ is an interesting option for cross-platform web-based low-code.

My main issue with these is using the the cloud dev tools has a cost, normally usage-based - so if you use Firebase, if you're not careful, you can end up with a large bill.

[sirjaz]

Funny thing is that there are more Windows devices out there than all iOS,MacOS, and chromebooks combined.

[dannymi]

There are 1.46 billion iphones, 3.3 billion Android phones and tablets, 1.5 billion Windows computers in the world. About 100 million people use MacOS.

I'd say with the (few 100 million) Chromebooks it's an equal number of Windows devices to the sum of the other ones you listed.

P.S. What happened to Android in your list? That is like leaving out the 500 pound gorilla :)

[ptman]

are you certain? At least mobile phones (android+ios+maybe some other with somewhat modern web browser) outnumber desktops/laptops.

[mrweasel]

I don't think the platform mattered much, this happened before macOS became popular, and remember that at that time mac developers would still use Interface Builder and Objective-C. There was a certain level of pride in making Mac apps look very much like Mac apps. Very rarely did developers target both Windows and Mac.

My take is: A lot of developers didn't feel like cluing components together in Visual Basic 6 or later Visual Studio, dragging and dropping UI elements, was "real development". VB-developers where looked down on as second rate programmers. If you used VB.NET and WinForms/WebForms who where not a real developer. You had to use C# and XAML, which was absolutely terrible, but "real programming".

Same with Delphi, not something you built "real" applications in, no you use Java if you're a real developer.

Shit like that was all to common, and yet WinForms are still around and working, but XAML is dead (Edit: Apparently it's not dead).

[DeathArrow]

>The No-Code world is fascinating, and the best I've seen in this space is https://retool.com/, but it's expensive and locks you into their ecosystem.

>Even today, small businesses need to build out simple apps that were simple to do back in the Visual Basic days—a stock control system, a basic support system, sales tools, etc. Today, it's a minefield of options that can quickly get expensive.

A RAD tool like Visual Basic, Borland C++ Builder, Borland Delhi, QT Designer doesn't mean no code. Rapid application design helps the developer quickly build the UI using already made components and using some predefined behaviors like gluing a database table to an UI component. But the developer has still to provide the application logic and to write whatever else is not covered by the RAD tool. It helps you build faster, write less code, but it isn't no code.

[mmerlin]

VB6 fans looking for a modern approach should try twinBasic which after many years is about to release v1.0 https://twinbasic.com/

[woodylondon]

Never seen this before - thanks. Looks interesting.

[wongarsu]

Delphi is still around and filling a niche for boring business apps where usability, accessibility and quick UI development is more important than following design trends. You won't get any VC money for Windows XP styled apps, but if you make industrial hardware and need control and maintenance software Delphi is a reasonable and somewhat popular choice.

They even cleaned up their licensing a bit, offering a free version for hobby use: https://www.embarcadero.com/products/delphi/starter

[jamalaramala]

> I never fully understood why this programming paradigm died off.

First and foremost -- the world wide web.

Suddenly, we had a much more flexible way to deliver applications.

If I remember it correctly, Visual Basic couldn't write to STDOUT -- so it couldn't be used as a scripting language for the web.

Microsoft tried to push VBScript as an alternative, but it was linked to their expensive ecosystem, while LAMP (Linux Apache, MySQL Perl and PHP) was free.

[rattray]

> I'd love to have a visual builder that creates code you can host yourself — something like retool.com but with open source and self-hosting

I believe this is the promise of AppSmith: https://www.appsmith.com/

I haven't tried it myself, curious for others' experiences

[pieter_mj]

Developing visually with VB(A) RAD-like dev tools to build websites without wallgardening and cleanly generated html, css, js, server side code & whatever, is a huge niche to be filled. Incredible that it doesn't exist yet. Maybe I'll do it myself.

[xtracto]

We've been using ToolJet (the open source version) at my company with good results. It is self hosted, open source and you can export created apps in some JSON format.

I've successfully setup a dev-stage-prod flow where we export from one env and import into another pretty seamlessly.

The coolest thing about that is that I was able to hire a very Jr. Frontend dev to immediately start working building internal dashboards.

I've used retool in another company but found problematic not having the source code for the lack of control.

[jasode]

>Today, I feel .NET is overly complex and much harder for beginners compared to the old days.

I often see similar statements like that but that's not what I experienced. I did IBM DOS BASIC, MS GWBASIC and worked on VB3 to VB6 at a corporate jobs.

The C#/NET workflow feels much the same rapid-development simplicity as classic VB6: Drag some GUI components like text boxes and buttons onto a form, code the controls' event handlers, build the exe.

In contrast, the examples of GUI dev kits that had more complex language syntax and build steps than VB6 were original Apple iOS Objective-C, C++ Qt, Java AWT.

Sure, C# is a bigger language than Visual Basic in VB6 but C# also does a lot more. E.g. in VB6, it didn't even have a built-in way to check the existence of a file. Instead, you had to declare a "win32" API monstrosity such as :

  VB6:  
  Private Declare Function OpenFile Lib "kernel32" ByVal lpFileName As String, lpReOpenBuff As OFSTRUCT, ByVal wStyle As Long) As Long
  Function FileExists(FileName As String) As Integer
  Dim RetCode As Integer
  Dim OpenFileStructure As OFSTRUCT
  Const OF_EXIST = &H4000
  Const FILE_NOT_FOUND = 2
  RetCode = OpenFile(FileName$, OpenFileStructure, OF_EXIST)
  FileExists = (not OpenFileStructure.nErrCode = FILE_NOT_FOUND)

  C#:  
  File.Exists()

In many ways, VB6 being "simple" means it created a ton of extra complexity for the programmer to do basic tasks. Another example is that VB6 didn't include a datagrid. You had to buy 3rd-party VBX/OCX controls for that. C# WinForms includes a datagrid.

EDIT reply to: >most definitely open files in VB, and therefore the "File.Exists()" function would at worse be comprised of a exception handler (on error ...) and a open call,

From my memory the "pure" VB6 way checking existence of a file by opening a file with error handler had issues (other processes using exclusive access and/or other issues) causing false-negatives or false-positives. Therefore, the recommended way back in 1990s was the win32 api declaration using OF_EXIST flag. It looks convoluted but it was more reliable.

[AshamedCaptain]

You chose a very poor example, since you can most definitely open files in VB, and therefore the "File.Exists()" function would at worse be comprised of a exception handler (on error ...) and a open call, as in many other languages. No need to import OpenFile for sure.

[coliveira]

I believe some people used that monster version because VB had simple libraries that didn't allow many options. Anything more complex required you to go down the Win32 rabbit hole. And that was the main weakness of VB, it was such a simple language that you didn't have many options to do something more complex than going straight to Win32.

[AshamedCaptain]

It is a very different thing to claim "the language doesn't allow simple things such as checking for a file's existence" (which is false, the language allows many ways to do so) than to claim "the language doesn't have many options, but allows you to interop with the entire win32 API if you need to". The first is a valid if only false complain; the second reads to me not as a complain, but as a feature.

[jasode]

>to claim "the language doesn't allow simple things such as checking for a file's existence" (which is false,

That's not what I wrote. I said there's no _built-in_ way to check existence of the file. A reasonable interpretation of "built-in" is for an obvious named function such as "File.exists()" _without_ cobbling together extra workarounds and hacks -- whether those workarounds include re-purposing other VB built-in functions with On Error ... or using Win32 interop.

> in VB, [...] would at worse be comprised of a exception handler (on error ...)

That's an example of what I meant of not being built-in to VB. I should have been more clear. We were using different meanings of "builtin".

In any case, the following "pure" VB code to check for file existence is not found on Google or Bing search but I still have it from my 1995 archives and copied it here. It has many lines of code (instead of a simple "one-liner") because it tries to cover all the edge cases. And yet with all that defensive code, there's still a hidden timebomb of a bug in it. Can anyone spot it? The code is unmodified from Visual Basic Programmer's Journal. In contrast, the alternative using Win32 interop with OF_EXISTS doesn't have the bug.

  Dim strTestFilename As String
  strFilename = Trim(strFilename)

  ' To avoid problem with known bug, don't pass root directory to
  ' the Name function
    Select Case Right$(strFilename, 1)
        Case "\": strExistsFilename = "Root": Exit Function
        Case "\.": strExistsFilename = "Root": Exit Function
        Case "\..": strExistsFilename = "Root": Exit Function
    End Select

    On Local Error Resume Next      ' Enable error trapping for Name function
    Name strFilename As strFilename ' A trick to see if filename/path is good

  ' Now check the resulting err code of the Name function
    Select Case Err
        Case 5  ' Illegal function call
        Case 53 ' File not found
        Case 58         ' File exists (maybe)
            strTestFilename = Dir$(strFilename)
            If Len(strTestFilename) Then
                strExistsFilename = ""      ' It's a file
            Exit Function
            Else
                strExistsFilename = "Dir"   ' It's a directory
                Exit Function
            End If
        Case 64 ' Bad filename
        Case 68 ' Device unavailable
        Case 71 ' Disk not ready
        Case 75 ' Access denied
        Case 76 ' Path not found
    End Select

My point was that C# builtin File.Exists() is a lot simpler than that.

[AshamedCaptain]

So, what is so wrong about simply calling FileLen() to check if the file exists, or if you also want to distinguish between Files/Directories using GetAttr to check the directory bit ? Why do you have to go all the way to this monster of code which even hardcodes lists of errors (why do you care which error it is?) ?

Your code sample renames the file, then globs anyway (when dir$ by itself can also be used to check existence). It looks too convoluted, and I cannot imagine why it needs to be so.

What is exactly the corner case that you want to avoid -- and if such case really exists, why are you so sure the File.Exists() implementation would not fall into the same pit trap, considering it also simply uses the metadata?

Disclaimer: I'm only familiar with VBA, not VB itself. But these file metadata functions definitely already exist in 95's VB5. (EDIT: Actually 97's. Maybe the problem is these functions did not exist in earlier VBs? But I would find it hard to imagine you could not check a file's size).

The sample code smells even in the trivial-case checks. E.g. Right$(_, 1) will only return a 1-char string at most, yet it tries to compare it with 2, 3 len strings. I didn't check any further than that.

[Brian_K_White]

But then you may have actually opened the file.

[AshamedCaptain]

But if you rely on these subtleties this is hardly a "basic feature" that the language is lacking. In fact, I imagine File.Exists()/OF_EXISTS also opens the file (then immediately closes it).

[Brian_K_White]

It better not!

If you actually open a file, you update it's access time, and you interfere with the process that should actually open the file. Those both break perfectly simple business logic.

[AshamedCaptain]

The documentation for OF_EXISTS literally says it will open then close it. I leave to your imagination whether this updates the (very poorly defined) access time or not, but for sure you "interfere" with other processes...

If you want to get the access time, why don't you just query the access time? Which is likely the only thing almost universally guaranteed not to change it... And I'm sure VB6 has an API for that, considering that VBA had a global API for it (FileDateTime).

(Which is, btw, yet another way to one-line check if a file exists).

[ahoka]

But then the only way to make sure that you can open a file is to actually open it.

[Brian_K_White]

You don't use exists and then open a file. If you actually want to open a file, you open it or fail. You don't check if it's ok and then do it, you do it and then check if it failed.

exists followed by open is a pointless exists because anything can happen in between.

Conversely, if you are neither the producer nor consumer of the file at this time, you don't want to actually open it just as a way to stat it, because actually opening it updates it's access time and interferes with the actual consumer(s). Even read-only non-exclusive.

[gus_massa]

You can use it as an improvised lock.

[personalityson]

    Public Function Fso() As Object
        Static s_oFso As Object
    
        If s_oFso Is Nothing Then
            Set s_oFso = CreateObject("Scripting.FileSystemObject")
        End If
        Set Fso = s_oFso
    End Function
    
    Fso.FileExists("path")

[jasode]

>CreateObject("Scripting.FileSystemObject")

That's not included by default in Windows 95. (A lot of classic VB6 apps of that era ran on Win95.) In contrast, "kernel32.dll" is always included.

Even for the later Windows 98, using "Scripting.FileSystemObject" as a dependency was fragile and could fail:

https://www.tek-tips.com/threads/forms-do-not-open-in-window...

https://www.vbforums.com/showthread.php?135362-running-vbs-f...

[Brian_K_White]

The sub thread this created of people not recognizing this as a problem is pretty interesting.

It's probably one of many ingredients that went into how so many of these apps are so half baked and buggy.

Not just the obvious that the language was aimed at and used by junior programmers and so of course much of the code is not robust in general.

But here is an example of the toolbox missing a tool. You can't really fault people for doing whatever seems natural using the tools they are given.

Not being experienced developers otherwise, they didn't know that something necessessary was missing, and made things that only mostly worked without it.

To be clear they would have often mis-used the tool if it existed too. In this thread people have thought the way you would use exists is to check before doing some actual operation. The inexperienced coder aspect is also true, seperately.

But the combination of a missing tool combined with a language explicitly aimed at users who don't come with their own experience and don't know anything but what the language provides, seems a little extra nasty.

[AshamedCaptain]

Are you literally calling every commenter of this subthread an inexperienced developer? Seriously?

First, the subthread starts by claiming you cannot check for the existence of a file, which is simply false. You can try to open it, you can try to read metadata from it, you can glob it, etc. all of it using language builtins.

But then you claim that you need to check for a file's existence without actually opening it. If anything, as we people are constantly pointing to you, any code which does it is a code smell at the very least, and very likely wrong. There's a reason TOCTOU is a thing, and why these exist/access APIs usually have huge disclaimers right in the documentation.

But let's entertain the idea. Maybe you really have a crappy IPC handshaking mechanism implemented with temporary files (sorry!). Maybe you want to avoid side-effects of trying to open file (virus scan overhead? network traffic?) . It cannot be that you want to preserve the atime, because that would also be a code smell, seing how undefined the atime is on win32. On win9x, for example, reading metadata updates atime - likely the AV scan, but nonetheless; also, the granularity is only 1 day (welcome to FAT).

The WA offered by GP actually very likely opens the file anyway, so clearly he didn't have this requirement. But anyway, this scenario is no longer a "simple" feature whatsoever, and therefore the original complain loses all weight.

And to top it all, you _still_ can check the existence of a file w/o opening it by just trying to read the metadata, using any of the myriad functions at your disposal, in around two lines of code; no need to interop with Win32 at all. In fact, (trying to) get the file's metadata is exactly how .NET's File.Exist does it.

If you find yourself in a situation where everyone thinks you are trying to do a senseless thing, it is more likely you are, rather than everyone else being junior and inexperienced.

[Brian_K_White]

I am calling inexperienced developers inexperienced. Are you literally suggesting that there are no inexperienced developers?

I am also saying that this thread is interesting and that inexperienced developers don't see the problem.

"very likely opens the file anyway" is not an argument.

"code smell" and "very likely wrong" are not arguments.

The reasons you need to stat a file without opening it, or do any other low level operation, are open ended and infinite. It's backwards to try to think up some specific invalid contrived example use case, and then say how you didn't need to do that specific thing that specific way, and so therefor you never needed that facility.

These are all quite bad reasoning and "inexperienced developer smell". If you are experienced and still reasoning like this, that's unfortunate.

[wink]

I know this is a bit of a first-world problem but back in those days[tm] you just slapped 2-3 DLLs into the exe directory and it worked. Yes, I know there were also different versions for different runtimes, but overall it was a couple of DLLs and fine. Since .net you really need to install the distributable by MS, and every new .net upgrade it's the same. Just 2 days ago I apparently needed the .net 8 runtime and even after installing it the app in question didn't work (without a reboot maybe, I will find out later today).

Overall, strictly as a consumer, C# and .net apps have been mostly great, except the practice (is it a best practice?) that some of them end up somewhere in my home dir's Local dir and not in c:\program files.

[nurettin]

This is the worst example you could give. Just add filesystem dll or whatnot from the .net framework as a reference to your project and you can use File.exists from VB.

[jasode]

>Just add filesystem dll or whatnot from the .net framework as a reference to your project

To clarify, "Visual Basic 6" in this thread's title that everybody in this discussion has abbreviated to "VB6" is the "classic VB" from 1998.

There was no publicly released .NET in 1998. That came 4 years later in 2002. Maybe you're thinking of the newer VB.NET.

[nurettin]

yes, I misread thanks

[hasbot]

PowerBuilder too. I worked for an S&P 500 corporation from 2000 to 2006 trying to replace several business critical PowerBuilder apps in Java using a bloated commercial framework called Windchill. The original apps were written by a handful of developers over the years. The new team was fifty developers that struggled to replicate the old app functionality. We did manage to reimplement a couple of the old apps but they took a lot longer than anticipated and were incredibly slow.

The corporation chose Java/Windchill for the rewrite instead of PowerBuilder because Java was trendy. Both the original and replacement apps were desktop applications. During development of the new apps, browser based applications became trendy and some of the developers really wanted to switch to browser-based. Fortunately, that shipped had sailed. Can you imagine writing business critical apps for the browser in 2002?!

[scarface_74]

Because for the most part, you don’t need desktop applications in 2024. They are harder to maintain when used across multiple computers and you can’t access them from anywhere like web apps.

And most companies that need to build the things you mentioned can use a SaaS.

Also, those “simple apps” end up being an unmaintainable mess after a couple of years. In 2024, to a first approximation, no company should be writing software that is not core to their business.

Most problems are not special snowflakes. Someone has already solved their problem and created a customizable SaaS around it.

Yes I’m old enough to have used VB6 professionally from 2001-2008 (when it was way past its prime). But my first programming was on an Apple //e in BASIC and assembly and programming professionally in C and C++ from 1996-2008

[woodylondon]

In some context, I think desktop apps are far better than the web, and it's now super simple to roll out desktop apps using tools like Intune.

However, I'm talking about general business apps here.

The likes of Zoho, Salesforce, and, to some extent, Dynamics are covering some of this space—but again, they're expensive.

The main point of my post was that if I were 18 today and starting my first job, it'd be much harder to acquire the skills needed to grow. With VB or Delphi and a book, you could become pretty productive within a year or so, and the cost of entry was very low. The skills you learned opened the door to a whole new world for little cost. Especially, as others have mentioned, finding "DVDs lying around" :) which, of course, doesn't work for web tools in 2024! I was lucky my company provided, but i know friends who learned from the other approach.

These web based NoCode companies should provide people starting out with free, fully functional accounts—but then restrict live users to about 5. Atlassian/JIRA was always good at this with their $10 entry point. While it's not a programming tool, this approach is why it's found everywhere. It allowed someone wanting to experiment and learn to pay just $10 for access to the complete platform.

You might say there is plenty of open source out there, and this is correct, but again, in companies, this is not always used. They want the known companies.

What the generation do have today which we never did is access to high quality training beyond books - and now AI! Wish I was 18 again!

[scarface_74]

How do I roll out that Windows software on Macs? On mobile? And all computer management software especially on Windows ends up being corporate installed malware.

Besides, if you think that installing desktop software is ever easy - especially if something goes wrong - take a look at what happened with CrowdStrike.

As far as learning how to code, everyone has a web browser and can download VSCode or even Visual Studio for free. All languages are free and you can download free versions of every popular database for hobby level work.

Heck these days you can stay in the free tier of AWS forever if you stay serverless.

And software developers aren’t expensive as is maintaining software?

I was hired as a lead developer back in 2016 by a then new director. He had four mid level developers working there. After he interviewed me, he asked two of the developers to interview me while he was in the room.

They said they wanted to do address validation and they were trying to think through all of the corner cases - this was a real world issue not a coding challenge.

They asked me did I have any suggestions. I said sure, there are third party CASS solutions that are USPS approved and they shouldn’t be building that in house.

I was initially hired to modernize their homegrown Electronic Medical Records system built on PowerBuilder in 1999 using Sql server 2001 (this was 2016). It had been maintained by two other “developers” who had been at the company for 10 and 20 years respectively. I walked him through my proposed strategy if I were hired.

It didn’t take long to realize that this company had no business writing software. They were a low margin company that sent nurses to homes of special needs kids and made most of their money from Medicaid reimbursements.

I started leading the effort to do data migrations and being part of negotiations with SaaS companies as the company I worked for started buying up other companies in their vertical.

The company ended up laying off the developers who interviewed me and turning the other two into report writers and doing data analytics.

A year and half later, I had a frank discussion with the director. I told him we both know you don’t need me. I found another job three weeks later. I literally “put myself out of a job”

[DeathArrow]

>I never fully understood why this programming paradigm died off. Building business apps beyond Access or Excel was so straightforward.

Because every business app needs to be written in a Javascript framework to be considered serious. Nevermind speed, resources, speed of development.

[giancarlostoro]

> providing technical support to many developers when I wasn't one myself yet!

This reminds me of my days as a Lab Tutor at the programming lab at my college. I was only one or two semesters in helping people with Advanced Java homework while taking basic Java.

[DeathArrow]

>I guess the web came soon after, and trying to do WYSIWYG for HTML and CSS has never gone well—even today.

>FrontPage came out but died soon after, and mixing desktop apps with web apps was never great.

I remember using Macromedia Dreamweaver and Microsoft WebMatrix for WYSIWYG.

[jarsin]

I think we would still be using all macromedia products if adobe didn't buy them. I miss flash :(

[InsideOutSanta]

I think one aspect is that business requirements for many of these apps became more complex, which is why we now often use process management or case management tools instead of smaller local programs.

[woodylondon]

Agreed, a fair point - companies are a lot more aware of what is possible beyond a spreadsheet! :)

[wink]

Not only business. I think it's better in 2024, but as someone who lived through the browser war years as a frontend developer.. We may shit on Windows a lot, but learning the windows bits you need to write software in VB were ridiculously less complex than writing a backend AND a frontend for a webapp circa 1999-2005. Just because of all the tiny undocumented differences to make stuff look ok-ish or even quite the same. VB's layouting stuff was very good in my memory.

[TeMPOraL]

Most of it is negative possibility? :)

Being 100% serious here: half the SaaS webapp products I've ever used, both personally and at work, would be better and much more ergonomic if implemented as an Excel sheet or an Excel plugin instead.

[ransom1538]

Visual basic was the best way to build business apps ever. We just got these features in visual studio. Some we may never get (drag and drop dbs, form builders, etc etc). The closest I have seen was Flash. But if you say Flash or visual basic you are downvoted. I will let people get back to their js frameworks.

[coliveira]

You're completely right, however the market for business desktop apps is over; not just because of the web, which is still inferior to VB in many respects, but because companies restrictions of what can be installed in a corporate desktop. It is much easier to use a web service than having permission to install a desktop app in a corporate computer. The huge Windows vulnerabilities destroyed the desktop as a viable business software platform.

[carlosjobim]

Small businesses don't want to pay for simple apps. They want to pay a percentage of their sales to a large middle man who takes care of sales. It's too much for them to pay a few thousand (or hundred) dollars for a bespoke solution, but they have no problem paying tens of thousands per year to a middle man.

There's a reason small businesses remain small.

[hobs]

Almost none of those reasons are managing what are generally trivial costs for a growing business.

Small businesses remain small because they: cant scale, have a small tam, require direct labor from the founder to get the job done, the market is fairly well established but the founder has some special skills which are difficult to impart, especially in the context of the business.

Market conditions, the ability to get capital, and a lot of luck have way more to do than is your SaaS bill a little too high, you can always just use some google sheets and google docs and get 80% of what you'd need in most SMB situations.

[carlosjobim]

When you deal with enough small businesses, you'll find out that they usually pay a large percentage of their revenue to middle men in order to save a pittance of money or effort which would be required to get rid of the middle man. People don't act rationally. Those who do act rationally regarding their business, generally find ways to grow it beyond being a small business. Assuming they want to. Many are happy being small.

SaaS is not a middle man. They're usually a good solution for a small business.

[coliveira]

Pretty much everything boils down to having capital. Tech startups work because they inject capital into an idea that can be developed using technology. If you don't have capital to hire talent and sustain losses during several years, you have little chance to create a growing business in the modern economy.