One of the original Fox developers wrote a great behind-the-scenes book about the software and the company culture, uptil their acquisition by Microsoft.
It is one of the more niche, under-appreciated technology books out there: "FoxTales: Behind the Scenes at Fox Software" by Kerry Nietz
FoxPro was originally FoxBase, a clone of dBase III, and in some respects better than dBase - IIRC, it could handle larger files, and worked better on a Novell Netware. FoxBase was however a console application - no windowing and no mouse.
Then in the beginning of 1989, they started working on "FireFox" - that's where the classic FoxPro GUI came to life. It was a big departure from dBase, and the name went thru multiple iterations before it became FoxPro. It was a runaway success. dBase never caught up - dBase IV tried catching up with FoxPro's GUI, but it was buggy, slow, and its lunch was being eaten by Nantucket's Clipper compiler.
It was fun times, but sadly the xBase dialect wars were superseded by the rise of Windows, and by the time people retooled into Delphi and Visual Basic, that went away and the web became the dominant application platform.
correction: dBase IV came out before FoxPro. From the book:
"By the beginning of summer ‘89, FoxPro was turning into an impressive product. As an outgrowth of the new language added to emulate dBase IV, and our new window-based interface, many items present in earlier Fox products were substantially transformed."
Kerry continues:
"By the beginning of summer ‘89, FoxPro was turning into an impressive product. As an outgrowth of the new language added to emulate dBase IV, and our new window-based interface, many items present in earlier Fox products were substantially transformed.
One of these was our text editor. Two commands in the language would present this to a user, MODIFY FILE and MODIFY COMMAND. In FoxBASE+, the editor was simplistic. It just filled the screen with whatever file was being edited. Only one file could be edited at a time, and there was a rigid limit to how big that file could be. It was functional for developing dBase programs, but most hardcore users would buy an additional editing program to do real text editing work.
As coded by Eric, though, the new FoxPro editor was an animal of a different color (no pun intended). It resided in a window and users could have as many text files open concurrently as they liked. They could easily copy and paste text between different files. There was no limit to the size of the file. (No attainable limit, anyway; the actual limit for a text file was larger than most modern disk drives.) It was also blindingly fast. It could open hundreds of files in seconds and scroll text faster than it could be read."
They were bought by Microsoft when they released a version of FoxPro with "rushmore", that made it many times faster than the competion. I still remember the adds.
Foxpro is top notch. And I have never used it. Here is why:
- My former best friend has created a software in 1995 that manages 30% of all vendor machine ( coffee, candy bars, sandwich) in Europe.
The software uses Foxpro.
1) He tried twice to migrate to other dev tools. Never succeed.
2) His software is so good his company was in average 40% more profitable then competitors.
3) His CEO has bought 10 competitors of the same size in 20 years. Each time my friends software would replace the former. Than the financial margin would go up.
In the 90s I knew several similar cases where significant companies were run on FoxPro or Access. I don't think there are any web based tools on the market now where you could achieve the same thing with the same level of effort.
I wonder if Microsoft could just open source it now. I can't imagine they're making money from it in 2021 and this would definitely add to the community goodwill towards them, which they definitely lack.
The whole xBase universe is quite fascinating. It might not have been as revolutionary as spreadsheets, but having databases on your homecomputer/PC covers a lot of use cases for regular people and small businesses. Heck, a lot of what we make way too much money with is basically "just" polishing that. (Or trying to sell you pills while you use that, but let's not digress)
And dBase and its variants/rivals had that pretty much covered, from CP/M to Ataris to DOS and later Windows. Also begat a wide spectrum of programming it, from simple end-user customization to pretty large multi-person applications.
But now? The whole xBase/Clipper-verse almost seems like a unique dead end, in an industry that keeps pretty much every other technology afloat. And it doesn't even seem that that is purely for technical reasons. Sure, client/server and more powerful machiens meant that "proper" RDBMS were getting common, and with environments like Visual Basic or Delphi you could create some pretty neat frontends.
But that was only part of it. Bad acquisitions were another one, with Borland buying dBase and Microsoft buying FoxBase. Not before the dBase makers were a bit too litigious, which doesn't really help trust in the market and individual products.
Right now, the most prominent products still somewhat in line with that would be Access and FileMaker, and they seem slightly different beasts. Or maybe even cloud-based data buckets like Firebase, but they don't quite seem as "egalitarian". And while NoSQL database might claim some relationship, their usage patterns are quite different.
> Heck, a lot of what we make way too much money with is basically "just" polishing that.
No one wants to admit it, but 80% of "Enterprise IT" revolves around "CRUD app on top of a database". The other 20% mainly revolves around either running reports off the data in that database or interfacing it with some other system. Been this way for decades.
Maybe it is is "CRUD" in practice, but often it shouldn't. There ist way too much business software with ugly hacks like misused data fields, endless data repetition, manual steps and the like. That might be "good enough" in many cases, but it comes with risk and high costs. Software supporting actual business processes using "domain objects" would be way better.
And of course many editions of MS Office include Microsoft Access, which undoubtedly had a role to play in killing dBase, Borland’s Paradox, and Lotus’s Approach.
Access’s not quite as pervasive as Excel but I'm sure a bunch of VBA die-hards in various industries still use it, at least for prototyping.
FileMaker's quiet, sustained success over the years makes you wonder why Microsoft didn't spin off FoxPro in the same way that Apple spun off Claris. Perhaps they were worried it would be too competitive with their own core products?
> why Microsoft didn't spin off FoxPro in the same way
They have Microsoft Access, which is the sort of spiritual heir to FoxPro, and is bundled with higher tiers of Microsoft Office. Access has lots of users across industries.
Access is bundled with 'Pro' editions of Office and [Office] 365 Business Standard.
Wikipedia has an interesting account of how post-acquisition FoxPro and Access were developed in parallel. Looking at both[1], it seems that the critical point was when Office 2007 was being developed, when Access got a new file format (presumably making it future-ready). FoxPro's demise was announced shortly after Office 2007 was released, although it was supported till Jan 2015.
absolutely, I'm a die hard Linux/Unix fan, but the one tool I miss from Microsoft land is Access.
The code is horrible, scale is a dead end, its expensive, clunky ugly and inflexible. But you can go from db schema and data, to forms and reports with unparalleled speed.
That use case is so common.
I haven't built an app on Access for years soley because M$ decided it should not be a part of the office bundle. But I have never found a replacement.
For my own data I use flat files and better bash. but I can't hand that over to Mum and Pop as a solution.
I've kind of gone to django with the built-in admin for this use-case.
It's not as quick as access to get up and running - but you get the benefit of it being a very well known and supported platform - any bells and whistles you want can be pulled in, you can deploy it online or on a raspberry pi easily enough...
True. Years ago, some FoxPro developers tried to translate their experience in building apps with FoxPro to python. Check the Dabo project. It appears to be dead, though. https://github.com/dabodev/dabo
Yes. Access is a fantastic database modeling and prototyping tool. It just doesn't pay, and there just isn't the tooling for moving Access databases to the web that you'd expect.
Agreed I always thort it wierd that M$ don't have a tool to webify Access and scale it on sqlserver with no dev effort.
You could charge what you like for that: if the data got big, the company got big.
Great for lock-in.
I'm glad, but always surprised, they didn't do it.
If they had, appifying Access data would have been an earner a few years later too IMHO.
Too late now: cool kids are app natives.
As others are pointing out, they have such a thing now in Power Apps (including "appifying") and the extended Power family.
But it's also not like Microsoft stopped trying to build such tools, they've had many fits and starts as priorities shifted and fads arrived and then faded away.
InfoPath tried to be it for the XML world (and preferably the XML world hosted by SharePoint).
SharePoint itself has always dabbled in trying to be a company's low dev solution for a lot information management/database stuff. The low dev stuff some companies have done in SharePoint Lists, for example, is wild. (A lot of the reason developers fear/hate SharePoint is the exact same "things I've seen" feeling from Access, with the added fun of upgrade issues of any modern CMS like WordPress. For most of its life Access maintained a lot of compatibility between versions until it stopped and changed file formats three times in a couple versions.)
Quick shoutout to xHarbour and Harbour - the open-source, commercially-supported versions of Clipper. https://github.com/harbour/core
The projects are still going strong and many years ago I had ported a huge Clipper project into Harbour and had it working well across a 20 node network with both Clipper and Harbour binaries working simultaneously on the same database.
These days every time I make another web application I wish for the simplicity of xBase. But there is some core truth about application development hidden there that is lost to me now.
Thanks for posting. I was a Clipper app developer in the 80's and early 90's, and seeing my old friends TBColumn() and TBrowse() just gave me a rush of nostalgia :)
My parents' small business had all kinds of reporting views (one would print envelopes) from their Lotus Approach database. It's been quite the downgrade to migrate to Excel from this. (Access, wherever it exists, it's just not as simple as GUI desktop DBs).
Wow...this brought back some memories of supporting FoxPro and dBASE users back in the day!
I always wondered, back then...if these people were really so strangely amazing with their DB front-ends, why not get a CS degree? Or study IT like us pros who were helping troubleshoot? (They were educated, but in strange-to-us areas like accounting)
Now I look back and wish I had spent more time listening to their stories and hearing about favorite experiences in putting their own tools together, and less time blaming their software for weird stuff. ;-) We had an office full of cards. From OS/2 guys to proprietary database people, from hardcore WordPerfect fans (Corel what...!?) to the Mac folks one building over, and their interesting networking issues...on top of our Novell network...oh and by the way, there's a cash register attached to a computer in building such-and-such, that makes it our job to fix, right? (Fixed register drawer with an excess amount of grease I found in an old toolbox; call boss with questions)
I do think there's a lost appreciation for those who aren't "pure technologists". My father-in-law was a draftsman, who was tasked with eventually getting up to speed with CAD. His knack for it led to him having responsibility for installing and teaching others, and eventually led to him working in general IT at places like Schlumberger.
Foxpro had an embedded db engine and so SQL commands could be used directly in the language for fetching data, which made it fantastic for CRUD database apps, which is what nearly all applications were back in those days. The 'tables' we're just dos files that could sit on a network drive to make the application multi-user. I think there was some limitation with the SQL, e.g. no outer joins, but it was still very handy.
MS continued to support foxpro somewhat into the .net era but then it fell to the wayside. When Linq arrived for c# it made me smile because it harks back to FoxPros embedded SQL, although of course Linq represents a _lot_ more than just embedded queries.
It was flexible too - my all-time favourite application of FoxPro is Island ECN, one of the first big Alternative Trading Systems and a direct ancestor to NASDAQs current INET platform.
Nice! Reading that code brings back memories... 1990 (around) I did a lot of work in dBase & Clipper & fox pro; it was easy to work with and, because in the Netherlands it was not that popular, I could get excellent job as 16-17 year old for the summer, working on admin systems for factories that used dbase & clipper.
I remember porting some of those systems to Java half a decade later and asking myself if this was a good direction; Java looked so... crude at the time compared to these technologies.
At least two major doctor/hospital softwares in my country still use FoxPro. But new features piled on top of decades old code base make it pain in the ass to use. (i.e. online communication with health insurance company halts the main program and launches a communication program every now and then)
C # creator Anders Hejlsberg made a statement a few years after the .net platform came into being, recognizing that data was very important and admitting that they were developing linq.
It would be interesting to get that statement, because .NET original plan was to be what WinRT is.
A improvement over the COM runtime with better tooling, but then they pivoted the idea with J++, and had to reboot it with .NET for the reasons we all know.
It was relatively rare to see SQL in idiomatic FoxPro of old, and more typical to work directly with indices, or use SCAN .. ENDSCAN. That was partly what made it so fast.
2.0 was the first version that changed it, to some extent, because it included the Rushmore query optimizer, which was actually pretty good. But veteran developers didn't trust it much even so.
What's especially interesting is that UI code was actually compatible between DOS and Windows versions, so long as you didn't use any platform-specific features (which were mostly Windows-specific, so most DOS apps could be ported very easily).
By orders of magnitude, my most popular open source release was a project to help people migrate from FoxPro to PostgreSQL: https://github.com/kstrauser/pgdbf
FoxPro was cool for desktop apps, but couldn’t make the leap to networked clients, where “networked” was more than “has access to the file share where the database files live”.
In the early 2000s I was hired to write a website that published reports from data stored in a Visual FoxPro database. A not-so-fun fact I learned: the VFP database libraries are single-threaded at the OS level. That is, you couldn’t run more than one query on the same machine at the same time, even in different processes. One would block until another finished. In a fit a panic and madness, I ended up writing an XMLRPC service (“which was the style at the time”) in Python, deploying it to multiple old Windows XP desktops we had laying around, and writing a database adapter for the web server that would send queries to those servers round-robin. Need more parallelism? Add another Windows XP box running my janky little service. It was awful, but it let us ship the project.
Later I wrote pgdbf so that we could run a cron job that would copy all our data out of FoxPro into PostgreSQL so that I could code against a real multi-user database that was vastly better in every way. By accident, I released it at a time when the world was wondering how they were going to migrate from FoxPro to something else. Turns out VFP was wildly popular in South America, and pgdbf turned out to be wildly popular there too, which let to me getting lots of email in Spanish and Portuguese and offers to come talk at user groups. I turned those down because what was I gonna say, “yeah, it was painful for me, too. Anyway, here you go and good luck!”?
VFP was crippled, like intentionally, by MS. Fox was absolutely superior to Access and SQL Server at the time (ie: as for build productive apps).
But the engine have so many quirks that affect their reliability (I still remember any fox app have the "rebuild indexes" and "fix corruption" in the menu of the app!)
This was purely a ploy, I think. Then Fox was killed and now millions of hours are wasted doing what fox allow in minutes.
FoxPro 2.x was fast and easy to use, this made it enormously popular back in the days. In mid to late 90' it was the first choice for most apps, even in small to medium companies. The success was coming from performance and ease of use.
In the 90' Turbo Pascal and FoxPro were languages that anyone could understand and use quickly without a lot of training. It made it accessible for learners with or without CS background, so I had many colleagues that knew and wrote a bit of FoxPro 2.6 for their needs - from small task automation to entire apps covering what the company IT was not able to do because it was not a priority.
Fast forward 30 years, the situation is not better, even if one would expect progress. We have hundreds of languages, the language landscape is way too fragmented. Do you want to write some code? Jim will do X, Joe will do Y and Jane will do Z and they will use different languages and everything will not be compatible and they will not understand each other's code. For data we have SQL and we have ANSI SQL which makes it partially compatible, that is great, but for general coding... no. And if you want to write a small data app you cannot just fire up FoxPro, you need to install a SQL server of sort, configure it (and that can be a small dark art in cases), get something like VS Code and write in a language that will not be SQL, but will interact also with SQL. Too complex, too complicated, too easy to give up. And if you want to explain to a non-IT person OOP and why a single line of WriteLine('Hello World') needs a class and a method and what is OO using the old story 'imagine you have animals, and some animals are mammals and mammals can inherit properties from the animals class' just to write Hello World on the screen, then we have a problem of accessibility: 'Man, I just want to write 2 words on that bloody screen!'.
So this is why FoxPro was easy to use: just fire it up and write some code, there is not much to prepare and nothing much you can break. And no dependency management, no unsafe downloads from all over the Internet, you can learn everything in a week and forget it in a year.
I worked on Visual FoxPro 6 and then on Visual FoxPro 9 at my first part-time job while I was in college (2006-07). It was a pleasure to work with. My boss at time had a strong expertise in FoxPro for windows and FoxPro for DOS.
Honestly, Visual FoxPro with embedded database was quite powerful and productive. It was super easy to compile exe files and ship them directly to customers without breaking a sweat. I miss those times.
I wrote an auto-updater using VFP and PHP on the server side. It used compared local .exe version with the remote .exe version stored in a txt file and if there was an upgrade available it downloaded & replaced the local exe. I ended up getting a promotion for this :)
A lot of information handled by Hungarian family doctors were handled by FoxPro at the time. I should know, I ghostwrote the app. I couldn't legally write it because I was a minor when I started on it :D
So much of the early computer world was getting data in databases and spreadsheets. Covers a significant percentage of usecases (and still does with stuff like SharePoint or even SAP).
Wow! That was a nostalgia moment. My first professional gig was in 1988 when I took over writing dBase code for an NSF sponsored evaluation project. That taught me enough to work internationally for USAID writing dbBase code for all kinds of projects around the world, and still make it back to the US in time to catch the beginning of the dotCom boom, Linux, and all of the other great stuff over the past 30+ years.
It was an awesome time. Folks laugh at all of the tech now, but QuickBasic 4.5, Turbo C++, and dBase were amazing tools for building stuff that was very cool at the time.
Makes you think there is always that niche of usecases between newbies and a full blown developer. And we've somewhat lost that today, you have to be a coder with knowledge of an esoteric language (hire one) or nothing.
Businesses have managed to fill this with some (sometimes crazy and fragile) uses of excel, the larger with over complicated ERP and entprise systems, and what not but the late 80s and early 90s were the hayday for the best tooling for this sort of thing. The Golden Era for the hacker sort, building a quick and effective system without anything fancy or boilerplate or requiring the equivalent to a CS degree.
The software that makes software without having to fully know programming has always been the pipe dream product I guess. Many have failed down this route.
The sort of incentive where every simple CRUD app eventually turns into a CMS. Or how B2B software just becoming data managling pipelines (like Zapier), each slightly customized for every industry and plugging into their wider system. There's probably a few small set of archetypes all software fits into, these being two I've come across most often in my career.
There's always plenty of overlap at a high abstraction like that with all of these apps, but the devil (and money) is often in the details (ie, making it accessible and relevant to their business use case with proper sales, documentation, and design).
Still using VFP9 to this day. Our application originated in ~1986 in dBase II, then we switched to FoxBase, then the various version of FoxPro. Currently in VFP 9. But, we still have to invoke Foxpro for DOS 2.5 (in DosBox) to edit some report layouts, because they were created in the DOS version in the 90s, and the automatic tool to 'transport' them to new versions crashes hard for reasons we were never able to figure out.
FoxPro 2.x was absolutely amazing. Incredibly fast, easy to develop with once you understood how it worked. And portable - 2.5 had a version that ran on SCO Unix.
There's still some excellent documentation out there. But basically what happened is the immediate response cycle of the Internet.
You don't know what to do? Well, google it, look up Stack Overflow, open an issue or write the company/developers. You just couldn't do that when the applications were mostly offline and you didn't exactly have a full set of international call agents well versed in the software.
I also believe that more companies had tech writers, which is one of the worst fatalities that the "full stack" mindset inflicted on us. Of course, the open source part doesn't really have the option here.
And once you have this, there's a certain peer pressure. IBM delivers a whole shelf of docs for one product? Welp, need to do that, too.
There's also a definite movement towards video material, although that's not a total excuse. As others in this thread pointed out, dBase had video tutorials too (If I ever make it big enough with a "boxed" product, I'll hire some guy with werewolf hair or a woman named Cheryl to do that with a VHS aesthethic).
Videos and reference documentation doesn't go together.
I've also encountered more "code clearly and you don't need docs" than previously in recent years, maybe Uncle Bob or some other "thought leader" is preaching that again.
I wouldn't say that FoxPro was the kind of tool that "made regular people implement solutions". It was still a fairly complicated PL and framework - in some respects, more so than low-level languages, actually. It was just particularly well-suited to the kind of CRUD-but-complex apps that are especially common when automating business workflows.
I have a bit of experience with older verdions of DBase and Clipper and I find this extremely odd.
Can you give us a bit more details? I am genuinely curious: maybe Foxpro had some fancy reporting capabilities that made it more feasible but the only type of "book" I could imagine writing with such a tool is some sort of catalog.
I.e. each product has a page (maybe with part number, pictures and price, description, maybe standardized product templates with weight, color etc.) ... then each page is a record or collection of records... and then you somehow spit out a massive pdf to send to the printers?
It does seem odd, and yet, engineers still think it's a fantastic idea. This may depend on whether you think of a file system and a table both as just a form of key/value store.
For a hyper-modern example, here's a current and popular Electron-based Markdown editor, "Inkdrop":
From the FAQ, keeping in mind this is a Markdown notes editor:
Q: Can I sync my data with DropBox, GoogleDrive, etc?
A: No. You can only sync your data with a server compatible with CouchDB. Read the documentation to learn how to set up your own sync server.
And then from the docs:
Inkdrop lets you store your notes in your own database compatible with CouchDB API instead of Inkdrop's own service. CouchDB is just another open-source NoSQL database so you can deploy it on your environment for free. See CouchDB's installation guide for more informations. Using DBaaS instead of operating database by yourself is good choice. For instance, Cloudant is one of fully-managed DBaaS providers.
Also:
You can back up all your data to your local filesystem and restore it at anytime. Inkdrop stores them as JSON files continuously while you use it. ... Since the backup data is in JSON format, it is not useful in some cases. You can export all note data in Markdown format from the application menu File -> Export -> All Notes...
To be clear, I think storing markdown notes in CouchDB is fundamentally missing the point.
I honestly doubt that "a DBMS" (especially from the Foxbase era) is really a good choice because formatting, even very basic markdown (titles, bold...) would require custom code or extensive postprocessing.
I still use Visual FoxPro almost daily for a number of things. It really does have charm in it's simplicity and some very robust out of the box support in it's GUI and DB engines.
One thing that maybe a more technical person can explain is how exactly FoxPro accesses it's (free) tables over a network share. Given that there's no central server component, I have the impression that the whole table is loaded over the wire when it's first opened.
My first dev job was working for a company that specialized in xBase apps. We had apps in dbIII, CA Clipper and FoxPro. We were working to move some of them to Visual FoxPro 2.6. One of our Clipper apps was my first experience with porting an app to Delphi. I learned how to pump data from dBase dbf files into InterBase (and then FirebirdSQL). Those systems were so interesting because they were such a far divergence from what I thought software development would be. In college C and C++ taught me about how computers work. I never was able to make the jump to actually building applications. As the years went on, that company tried to make the jump into web via Perl:DBI, then PHP/MySQL. But they never had the success. I hear they tried to use Harbor Project (a popular Clipper clone-like thing for the web). What a great time to be in the industry.
I think is time to revive the spirit of this family of languages.
I'm working solo towards it.
Today things get more complicated because is necessary to cover all major 6 platforms (web, windows, linux, osx, ios, android) to keep the "small bussiness/solo freelancer" friendly usage.
I work in a language that is inspired by fox and by other ideas at https://tablam.org. I will make my first attempt at UI building this year, with the full intention of work across all platform with native controls (plan to render <button..> tags in each, not creating a new UI kit!).
Then have sqlite as the default db, then connectors for others.
I used FoxPro 2.6 back in the day. We used to ship machines to our clients, preloaded with our FoxPro application.
As computers got faster, passing the 300MHz mark, our application suddenly started crashing on startup. Apparently FoxPro tries to figure out how fast it can perform certain operations at startup time, and there's a divide-by-zero error on higher-powered machines. The machines literally got too fast!
Never worked with Clipper but my first job was building a replacement bookkeeping system to sell to schools. The original was built up over 20 years and the only real reason it needed to be replaced was the market was moving to online payments. Connecting to these systems from inside a school environment was a logistical nightmare.
I still recall being reminded about the raw performance that customers got out the original that couldn’t be replicated in a web environment. My standard reply was the reduction in data fix support calls in my version. Swings and roundabouts ;-p
Ahhh... My father make some software on Clipper and later on FoxPro to manage a small shop of a friend, and to manage the TV/Electronics repair shop where he was working.
Hey all -- A friend mentioned this discussion, so I thought I'd drop in to say "Hi" and "Thanks" to those of you who've purchased my book, Foxtales. That was an interesting time to be alive. Now decades later, I still occasionally have dreams (nightmares?) where I'm back coding for Fox again. Hope you enjoy my experience.
Kerry Nietz
In the late 80s my side-project college consulting company was almost 100% FoxPro. I still have the 5 1/4" floppies laying about. They also had a version that ran on the Mac so I ended up getting my first "real" job writing FoxPro sales management apps for the original Apple stores. Also they gave me a sweet Mac II to code on :)
Software definitely lost something when we gained the ability to ship it as separate components over the internet. If you "just" configure components A, B, C, and D, you too can have the equivalent of what FoxPro had in 1993! It may not be The Unix Way(TM), but having an all-in-one solution is very appealing even today.
Is there anything in the The Unix Way(TM) that prevents a the success of project which bundles up components and makes them accessible under a single interface?
EDIT: Adding this bit.
Seems to me that compartmentalizing functionality isn't the problem. The problem is just that good interface design is hard. Arguments about interfaces have fragmented many communities in the Linux world, resulting in a lot of relatively under-baked projects.
Yes, because it isn't just the UI (from your comment about Linux i guess you mean UI with "interface") but about how everything is designed with the rest in mind with no seams in-between.
The "unix way" is to have reusable independent pieces that focus only on one thing that you connect together to create your application (often while accepting any limitations due to those connections - e.g. communication being in text format only). This is in complete antithesis to the monolithic all-in-one design that tools like dBase, FoxPro, classic Visual Basic (to some extent), etc provided.
It is important to keep in mind that these tools aren't just the sum of their parts, you can't take each part in isolation - it is the entire thing as a whole.
Now, you can grab these individual components and throw a blanket over them that pretends to be one unified whole, but AFAIK that has never worked in practice and you always get "leaks" - which will certainly happen with something that people will try to program against.
I really miss tools like FoxPro or MS Access where you could whip up some pretty powerful solutions quickly. Back then I knew several small to medium sized businesses where the owner over time had created pretty intricate systems they ran their businesses on. I bet they would have had to pay six or seven figure amounts of money if they had let "professionals" do this for them.
I don't think there is anything comparable out there that allows you to do the same with "modern" tech.
I wrote a couple of Clipper applications back then, started with Summer '87, enjoyed the OOP improvements on 5, but then they blew it with Visual Objects on Windows, leaving FoxPro as the only xBase clone around for a while.
I think there's still some space for something like fox pro and even access nowadays. Sometimes you just need to solve a problem and that doesn't need to be fancy, specially on the back office.
I remember years ago a Python project called Dabo, which was inspired by the FoxPro architecture or approach of building software. I could create desktop and web apps from the same code base, if I recall.
Code still available on Github. https://github.com/dabodev/dabo
I feel the huge discriminator here is the need of paying up upfront for the license, compared to a free tool/library, regardless whether or not the free stuff is up to the task
If someone wants to build something similar and open sourced for modern interfaces, count me in. I built ui-editor that can generate code for reactjs and I want to work on something big.
It is one of the more niche, under-appreciated technology books out there: "FoxTales: Behind the Scenes at Fox Software" by Kerry Nietz
FoxPro was originally FoxBase, a clone of dBase III, and in some respects better than dBase - IIRC, it could handle larger files, and worked better on a Novell Netware. FoxBase was however a console application - no windowing and no mouse.
Then in the beginning of 1989, they started working on "FireFox" - that's where the classic FoxPro GUI came to life. It was a big departure from dBase, and the name went thru multiple iterations before it became FoxPro. It was a runaway success. dBase never caught up - dBase IV tried catching up with FoxPro's GUI, but it was buggy, slow, and its lunch was being eaten by Nantucket's Clipper compiler.
It was fun times, but sadly the xBase dialect wars were superseded by the rise of Windows, and by the time people retooled into Delphi and Visual Basic, that went away and the web became the dominant application platform.