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).
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.