alt Hacker News>, 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...
Replies
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?
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.