Microsoft's FoxPro 2.5 Is Fast and Easy to Use (1993)
latimes.com
latimes.com
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."
- 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.
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.
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)
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.
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:
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).
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!”?
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.
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.
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 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).
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.
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":
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.
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.
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.
Wanna join? Is fun!
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!
An old discussion thread: http://computer-programming-forum.com/2-vfp/e6d3528c90cc45d2...
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
I don't think there is anything comparable out there that allows you to do the same with "modern" tech.
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.
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.
Another one that would be a cool open source project.
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.
My idea is add UI building to native controls with Rust and as database sqlite as the default + connectors to others.
Never thought I’d see it mentioned on Hacker News.
It had the easiest Hello world:
? Hello world
Here is my project https://github.com/imvetri/ui-editor