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.
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?
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.
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.
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.
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.
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.
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.
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.
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.
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
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).
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.
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).
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.
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 :)
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.
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.)
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...
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.
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).
> 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.
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 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
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
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.
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.
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 :)
107 comments
[ 2.7 ms ] story [ 156 ms ] threadI 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)
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?
I've never written a book in a DBMS(!) but it seems plausible.
For a hyper-modern example, here's a current and popular Electron-based Markdown editor, "Inkdrop":
https://www.inkdrop.app
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.
But I still want WinFS ( https://en.wikipedia.org/wiki/WinFS ) and JAMStack is a thing.
But there was a ton of bad software back then, it is just that few remember it.
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.
- 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.
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.
The matching engine was written in FoxPro for DOS! --- the source code is here-> http://josh.com/notes/island-ecn-10th-birthday/
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.
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.
https://msdnshared.blob.core.windows.net/media/MSDNBlogsFS/p...
https://visualstudiomagazine.com/blogs/desmond-file/2007/03/...
"Confessions of a Used Programming Language SalesmanGetting the Masses Hooked on Haskell"
https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.72...
"It's my hope that in five to 10 years, programming languages simply will have queries as a concept"
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.
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
Worth it just for the very nostalgic Windows 3.1 controls.
http://www.dfpug.de/loseblattsammlung%5Cmigration%5Cwhitepap...
https://twitter.com/dosnostalgic/status/826566061793345536
It even had a visual GUI editor, and a visual report editor:
https://imgur.com/a/174ZAww
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).
Never thought I’d see it mentioned on Hacker News.
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.
"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."
http://www.foxprohistory.org/rushmore.htm
It had the easiest Hello world:
? Hello world
A great starting point for a young developer.
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).
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.
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).
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.
Amen. Add also Nantucket (Clipper) being acquired by CA (Computer Associates) which pretty much killed Clipper.
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.
Interestingly Claris's FileMaker is still in business: https://www.claris.com/filemaker/pro/
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.
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.)
https://support.microsoft.com/en-us/office/build-and-publish...
Also you can use Access as a frontend to any ODBC database such as Postgres.
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.
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...
You can build impressive applications with it, and frankly it took web-first development era to do anything to it.
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.
[1] https://en.wikipedia.org/wiki/Microsoft_Access ; https://en.wikipedia.org/wiki/Visual_FoxPro
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.
My idea is add UI building to native controls with Rust and as database sqlite as the default + connectors to others.
Another one that would be a cool open source project.
https://en.wikipedia.org/wiki/IBM_Lotus_Approach
Here is my project https://github.com/imvetri/ui-editor
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.