Microsoft killed FoxPro in 2007. Anyway, here's FoxPro revived
Thread
Unofficial Hacker News client; not affiliated with Y Combinator.
Microsoft killed FoxPro in 2007. Anyway, here's FoxPro revived
Unofficial Hacker News client; not affiliated with Y Combinator.
ksec · · focus · HN ↗
Niche but no small business, commodity with over $400M USD annual revenue, the industry together that is easily $2B+.
If it is not broke, don't fix it. And there are industry that is extremely conservative in anything software, they will just keep it running for as long as they could.
I used to be sad that we don't have something better to replace these antique software. Now I have come to appreciate it, mostly because newer software haven't show they have manage to add value in the slightest. And most of the time they simply don't work as well.
Delphi, 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. Instead everything went more technical, more complex, enterprisy and non-user friendly.
And to the Author of the project. Thank You for making it.
jasode · · focus · HN ↗
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] <a href="https://www.scribd.com/document/384159949/Ms-Foxpro-Developers-Guide-Lck" rel="nofollow">https://www.scribd.com/document/384159949/Ms-Foxpro-Develope...
jjkaczor · · focus · HN ↗
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...)