The History of FoxPro: Interview with Wayne Ratliff (1986)
foxprohistory.org
foxprohistory.org
Wayne Ratliff, in the late 70s, built a revolutionary piece of tech: a high-level memory-managed language that regular people could use (from early 80s!) to build database-backed user interfaces. That was dBase.
It is the greatest NoCode tool of all times.
The best release of dBase was dBase III Plus. Everything that came after was a trash-fire. dBase was interpreted - you needed the source .PRG to run it. So a couple of folks formed Nantucket and built Clipper Summer 87. It was primarily marketed as a compiler for dBase. But later versions of Clipper became their own language, and remains my most favorite programming language.
In parallel, there was FoxBase, originally a cheaper and then faster version of dBase, which was then turned to FoxPro with its separate command window and output window (thanks to a port to the original Mac GUI which necessitated it). Excellent product, extremely wide adoption for building business applications until FoxPro 2.6 for DOS.
For a detailed history of FoxPro, read FoxTales by Kerry Nietz. Anyone who's used dBase/Clipper/FoxPro would find it deeply enjoyable!
The blog is called The History of FoxPro. The Ratliff interview is just one post of a number in the pre-history of FoxPro detailing the rise of dBase. Many of the others pertain to FoxPro.
http://www.foxprohistory.org/tableofcontents.htm
I agree with you about the FoxTales book. It was a great read.
After Turbo Pascal 5.5, Clipper 5 became my second OOP language actually, a couple of months before I finally got hold of Turbo C++ 1.0.
Also learned DBase III Plus, followed by Summer '87 before Clipper 5.
It was great, I got some money during high school doing Clipper based CRUD applications, super easy.
I still remember how hard it was to get my head around SQL and even Access, given what I thought a DB should look like.
The dBASE language was upwardly compatible with the larger FoxPro command set.
That was a great interview around dbase (EDIT: foxpro does not build on top of dbase I was wrong). I played around a lot with dbase in my early days. It was very cool. I never felt out of my league.
I've seen some of the ugliest yet most functional software done in foxpro. Incredibly easy to build feature rich software that unfortunately looked like dog poop.
Which has let them to either profit enough for a modern rewrite in .net, or disappear.
Most of the shops that moved to .net highly missed how productive they were with tiny teams in foxpro, and how expensive the move to .net had been.
If only foxpro had remained a viable option similar to VB, history might have gone a different way.
You have to respect how productive people were in those time. We really took a dive. Budgets blew up, so did team sizes, and here we are.
Stacks like foxpro and dbase allowed people like my uncle in his basement to start a massive business, or maintain the list of shirts he sent to the dry cleaners.
Can you find any screenshots to illustrate this? I'm curious about how you make the IBM PC 80x25 text screen look like poop. :)
https://winworldpc.com/res/img/screenshots/2x-841fe628c2d754...
vs.
https://docs.microsoft.com/en-us/dotnet/desktop/winforms/adv...
For its day, it actually could produce some of the better looking DOS-based database apps if you actually wrote them as native FoxPro applications and didn't just migrate some old FoxBase or dBase code to it. Microsoft (who purchased the company and its products) deliberately hobbled, and then killed, FoxPro as a product since it didn't fit into their product strategy. I recall reading an interview where it was stated that MSFT believed FoxPro provided too much value vs the licenses (mainly Access or SQL Server) they were trying to sell instead which was part of why they wanted it to disappear.
Ha. After my webmaster internship at the local newspaper ended, I took a gig doing data entry for a guy operating out of his basement on Visual FoxPro apps for things like HVAC equipment selection and other calculation software for area manufacturers. He'd talk about the dozens of developers and millions of dollars that it took to build the in-house solution, and how everyone preferred his application. He must have had a champion in the company, because his software was freely downloadable. He was fond of saying "FoxPro is very robust," and absolutely resisted learning anything else. For various reasons, I ended up going elsewhere... It was 2003, FoxPro was deader than dead.
To me it was, anyway. I just visited his website, which somehow is still around (and still designed for 800x600 monitors), and he's still using and promoting Visual FoxPro as of 2020. Hey, go with what works for you, I guess.
The question was, what, after dBase/FoxPro? In 2000s, there wasn’t a single proper stack. I did an internship in 2003 to migrate a company owner’s awesome dBase system into this awful architecture.
- VB6 was rejected because it didn’t integrate a DB,
- .Net was way-too-hard for the quidams they were.
> Budgets blew up, so did team sizes
Nowadays people can’t have a custom DB. We tell them to use Facebook’s CRM, because they wouldn’t be able to hire a 120k$ engineer, who are billed at this rate because they are n-times more productive than a grandpa with WinFox.
Are we really that productive?
The company I worked for had this full ERP solution that had many modules, Finances being one if them.
I remember we had DBF and NTX files for indexes and you needed to run a reindexing procedure every morning before all the employees would start using the system.
Once we got a support call claiming one of the users of such module was freaking out because the system was falsely accusing her.
Upon asking for more details we found that the system would stop with the very particular message of “corruption detected” :)
The ultimate fix was to ask everybody to logout and run the reindexing procedure, as always. But this funny story always stuck with me.
I think I "yahoo'd" something about how much trouble I was in.
Made me remember when my friend’s father got this spanking new PC XT and I was super excited to play with it, since I only had an MSX computer back home.
I started playing with all sorts of different commands and I remember I found this one called TREE.COM. I ran it and minutes after the computer took a crap.
I was desperate with his father confronting me asking if I had done something bad and after a lot of pressure I confessed I ran TREE.COM and he thought that is what killed the computer.
It was eventually reformatted and got back to operating fine but it took me YEARS to figure out the dreaded TREE.COM command had nothing to do with it :-)
Anyways thanks for sharing!
Here in Michigan there are small niches where people are still selling Clipper programs and making a living from it, mostly one or two person teams.
My pathway right after was Delphi as well.
After it “ended” I contributed a tiny bit to the Harbour project but I think it came a little too late.
Clipper also had a huge array of third party libraries, I fondly remember Nanfor, Grumpfish, and SuperLib.
If you want to see some code, here's a repo of one of my Clipper projects: https://github.com/jasim/EasyAccounts
There is also The Oasis mirrors which have a large cache of Clipper code: https://harbour.github.io/the-oasis/docs/
Sometimes I dive into old programming stuff I used to do, mostly forgotten and then get amazed how I was doing OOP, functional programming, memory safe systems programming, some form of automatic memory management, AOT compiled languages (statically linked) and now it seems everyone is kind of rediscovering what we were doing almost 40 years ago.
FoxPro was nifty in many ways, but nightmarish outside the “single person running the app with the database on their local hard drive” setup. The moment you tried to put the database files on a file share (which is how you used it as a network DB), it was a world of locking pain. And a fun fact: the client libraries were single threaded to the point that you could only run one query at a time per machine. If you had 2 apps running at once, only one of them could be querying at any given time.
It was up to the developer to take care to avoid unnecessary locking. For example, you could open databases in read only mode, avoid locking when browsing via 'browse nomodify', don't lock the database until you actually needed to do your CRUD work etc. If you migrated apps to utilize SQL and other 'modern' (at the time) FoxPro features instead of the legacy FoxBase/dBase syntax much of this was taken care of for you. I had production databases with up to 100 concurrent users before the overhead of the locking mechanism really started to be a problem. (which back in the NetWare days was more than enough for many mid-sized business applications)
Just by way of comparison, I saw lots of 'what the hell were they thinking?' multi-user MS Access deployments starting in the late 90's that were even worse... without the ability to mitigate the way FoxPro apps could.
That said, of course client/server databases still scaled better, farther and easier.
http://www.burtonsys.com/download/dbf2csv.php
Makes sense a format made in the same decade as this programming language would be the best tool for the job for me at the time, and if you're trying to export the data into anything other than postgres if need be.
Sometimes I wonder if people set up adverts on their own site, but use and ad-blocker themselves and have no idea what the advert script now does to their pages.
There are a lot of resemblances of CRUD Web/app programming to 1980s PC database applications. Including things like many people using high-level frameworks/DSLs/painters for forms and reports, and sometimes getting much better results by being able to write code at a lower level.
Pretty much all the coding we do today could be learned by a 12-year-old. (Product/project/politics experience takes longer, and judgment hasn't fully leveled up yet.)
I can't say what the biggest successes were of Foxpro, but for better or mostly worse, I was exposed to a use of Foxpro which brought a few hundred millions of revenue (and 20%ish percent of profits) based on it.
There was a multi-level-marketing company based out of the Dallas-Fort-Worth area of Texas in the mid 1990s which sold 1/10th ounce gold coins in a pyramid-ish scheme that rose to significant fame in the "home business (MLM)" market.
The compensation scheme was legit in that it operated as advertised. And indeed it made some marketing types very wealthy.
The entire backend, as it was in those days, was based on Foxpro running on a Windows PC.
I recall with amusement that the leader of that company invited me to review his binary tree calculion system to try to improve it. Foxpro wasn't actually the problem. The problem was a grossly inefficient linear system which couldn't manage binary structures with hundreds of braches and thousands of leaves.
To be fair, this system was built buy a guy who was a used car salesman with no formal training. What he accomplished was astonishing, but it was also an abomination.
I don't understand why at least new technologies don't imitate it. Seems so logical.
George Tate realized he wasn't a software developer and cut Ratliff and his team wide slack although he'd make suggestions sometimes based on his learnings with customers.
Ed Esber was a bit more arrogant and saw Ratliff and his crew as nothing more than mere employees. Esber famously told Wayne Ratliff that he was no more important to the company than the people loading the trucks! Ratliff quit and started a competitor. It was the beginning of the end for Ashton-Tate.
Ratliff created a new product that competed with dBase. In many ways it was a superior product but he couldn't market his way out of a paper bag. Meanwhile another competitor out of Perrysburg, Ohio had much more success in the dBase market and was later acquired by Microsoft.
Interview with Wayne Ratliff, author of dBASE (1986) - https://news.ycombinator.com/item?id=22382346 - Feb 2020 (16 comments)
During highschool for the computing classes I had a high density floppy (whopping 1.4 MB!) with a custom installation of MS-DOS 3.3, TP, Q editor, TASM and maybe a few other utilities. Basically the minimum for a quick coding session on the computer lab.
Maybe Microsoft's PowerApps are more in line with that target market.
There are still millions of SME relying on Visual FoxPro, which had its last release 14 years ago.
I used the el editor to write it. Learning vi afterwards felt like such an upgrade