Hacker News Reader

>, Visual FoxPro, Visual Basic, Flash. I used to think one day we will have something that is not only faster, easier and scalable replacement of those.

A person's perspective on the older dev tools being "superior" to today's newer tools depends on the things they want to build.

I had jobs working on Foxbase/FoxPro for DOS and migrated those apps to FoxPro for Windows, and Visual Basic 3.0 to 6.0 ... and I don't look back at those with the same positive nostalgia.

Classic VB was "simple" but every project at each company had a different hodge podge of 3rd-party VBX/OCX add-on controls to do anything non-trivial. E.g. 3rd-party calendar date picker, report writer, etc. VB didn't have a decent datagrid so everybody bought a 3rd-party one. In contrast, C# WinForms standard controls included a usable datagrid with data binding out of the box.

In a FoxPro for Windows project I was working on, we needed to open .zip files. FoxPro didn't have that functionality so the company paid an extra $300 for the FoxPro Library Construction Kit[1] and I hand-coded a .zip file parser in C Language to be called by FoxPro code. Instead of FoxPro dev work being simple, it's complex! Today's Python or C# can trivially open .zip files with builtin modules and functions so devs don't waste time on writing low-level C code or use 3rd-party libs.

With old 1990s tools, you can't do "simple" tasks such as getting a UTC timestamp, use a regex expression, or retrieve a web page with an http call, etc without calling Win32 API functions or 3rd-party tools.

If one wants to do things beyond the limitations of classic VB/FoxPro, the newer dev tools like Python/C# etc absolutely do make things easier and faster.

[1] https://www.scribd.com/document/384159949/Ms-Foxpro-Develope...

This is only tangentially related but I often wonder about the nature of software and whether we made a mistake "standardizing" as much as we have.

I say this not because you're wrong - I'm sure that using built-in modules for .zip parsing is faster and easier! - but rather because I don't know whether or not it's worth knowing how to do that. In the AI days right now there's argument being had about whether learning any coding at all is valuable. My gut says it is, but I've also spent years learning before AI, so maybe it's a sunk cost fallacy.

Regardless, my feeling is that we haven't found the balance between what's worth making every programmer learn/implement themselves, and what's worth abstracting away. Maybe implementing a .zip parser gives you some kind of secret wisdom that makes your future work better?

I'd hardly consider it secret, or wisdom, but I can think of many problems involving ZIP files I've solved in the past that it wouldn't even have occured to me to pose if I hadn't understood the broad structure of ZIP files as a series of metadata/data pairs followed by an index containing a mostly redundant copy of the metadata.

In other words, solving the right problems, however inefficiently, will always be more useful than solving the wrong problems efficiently.

Oh the VBX > OCX transition nightmare...

At the time I worked for an organization which pretty much had an unlimited budget for development and had therefore purchased just about every VBX bundle. They also had a solution with about 90+ complex forms - and no standards, so each developer of each form would pick whichever VBX control that "pleased their eyes". Which was "fine", until about 50% of those VBX control vendors simply did not offer an OCX upgrade in a timely manner - or in many cases simply folded/stopped entirely...

(The next nightmare was transitioning to what was supposed to be a more loosely-coupled COM type architecture, where each form could be dynamically loaded - except, referenced dependency tree and "breaking-binary-compatibility" during weekly "clean builds" ended-up taking sooooo much time... Thanks to a tool from a MSFT employee via their consulting service called "VBBuilder" (think of essentially "make") finally helped reduce that manual effort from a full day to just minutes...)

I don't recall that I ever did this with a FoxPro app. I used to make part of my money porting or cloning bespoke small business apps to OpenOffice Basic or OpenOffice with its Python integration. Visual Basic, QuickBasic, MS Basic PDS, TurboBasic, MS Access, and Turbo Pascal apps I'd replace with the integrated languages of the office suite.

Some of those originals used DBase III or DBase IV libraries. Some used bdb libraries. An awful lot used fixed-width fields designed into the application itself. Many of them I wouldn't have the source for, so I'd have to reverse engineer the data file format a little and then write a proper schema for a real database.

Sometimes the hardest part was getting the forms to look acceptable to employees at my client who were used to a curses style interface.

A big software for simulating the economic balance sheets of life insurance companies moved many years ago from using FoxPro under the hood to CSV files and sold it as a huge improvement. I don't think anybody was convinced by that, but vendor lock-in makes companies accept such regressions.

I was on a project trying to migrate off Oracle and they wanted to just dump all historic data to CSVs.

I pointed out they'd lose a lot of the integrity and audit features built into a database.

I get wanting to be free from Oracle but go to another database.

I wonder how that happened.

Maybe someone proposed Postgres and they said well who is going to support it. And then they'd have to pay some company to show they have postgres support anyway.

CSV has no support.

I once worked on maintaining an accounting package that exported to csv. At one point there was a bug where if the notation for a transaction included a single unmatched quote, the rest of the exported data silently disappeared.

The depressing part wasn’t finding this bug (in a very mature codebase), it was painstakingly explaining what the problem was and how to fix it.

> Delphi

Delphi is alive. https://www.embarcadero.com/products/delphi

Often FreePascal with Lazarus is a suitable alternative, and it's also very much alive.

> Delphi, Visual FoxPro, Visual Basic, Flash

All these tools are nice for a single developer. But they fail to scale for teams where you want a distributed version system, automated tests and CI/CD pipelines. Also you want to reuse code via package management systems. And a single code base for several target systems (cross compilation , electron) is also nice. I believe the mentioned tools offer none of this.

> But they fail to scale for teams where you want a distributed version system, automated tests and CI/CD pipelines.

I don't think this is true? Certainly you could have done those things with Delphi but it pre-dated DVCS and CI/CD being common concerns.

> Also you want to reuse code via package management systems.

Again, these tools pre-dated package management systems being in common use because they pre-date internet access at any sort of bandwidth being a reliable assumption. No reason they couldn't have one. Perl did at the time, which I mainly put down to it being in common use where internet access was a reliable assumption, but very little else did.

> And a single code base for several target systems (cross compilation , electron) is also nice

You can absolutely do this with Lazarus, which picked up where Delphi left off. Flash also counts here.

At least FoxPro stores code in binary files, but I’ve seen scripts to convert them back and forth to a text representation that can be checked in.

Think Flash (eventually) had most of these. That said, not all software development needs to happen at the same scale and not all software authoring environments benefit from the same tradeoffs vis-a-vis complexity, collaboration, accesibility etc. the success of Flash as a platform for independent game devs shows that different markets are better served by different tradeoffs.

> Also you want to reuse code via package management systems.

I thought everyone was on monorepos to "solve" that.

That is the same experience that I had with manufacturing shops, they just keep using the tool if it works.

> And to the Author of the project. Thank You for making it. My pleasure

> And there are industry that is extremely conservative in anything software

Honestly, that's at least 90% of non-tech industry, and there's a good living to be made as a consultant that can support legacy software.

> Niche but no small business, commodity with over $400M USD annual revenue, the industry together that is easily $2B+.

This feels so small in 2026.

It feels small to some people in 2026, depending on the business type and the field. Most businesses are small businesses, though. It actually approaches 100%. This is under the SBA's definition as of not long ago. There are limits on earnings, number of employees, or both for what can even be considered a "small business" that vary by industry. They are as low as $9 million revenue or 100 employees, although some industries have much higher ceilings. https://legacy.sba.gov/sites/default/files/2023-06/Table%20o...

The average annual revenue of a small business in the US in 2026 is around $1.2 million. The average headcount is about 11 people. About 46% of employees in the US are employed by small businesses. In 2024, about 64% of new jobs were created by small businesses. About 61% of new jobs from 1991 to 2025 were created in small businesses.

https://entrepreneurshq.com/small-business-statistics/

https://www.forafinancial.com/blog/small-business/average-sm...

https://www.venasolutions.com/blog/small-business-revenue-st...

As a small business owner, aware of all of this.

That said:

> It feels small to some people in 2026, depending on the business type and the field

$2Bn was stated as the size of an entire industry, which is weird when you work at companies that do more than that a fiscal quarter.

Well, commodities are commodities, and it was said it was a niche market. The company itself seems pretty big to me, relatively. $400m in a market of about $2b means they fill a pretty substantial part of the available market.

I haven't used Delphi since I was a child.