13 ms·

Microsoft's FoxPro 2.5 Is Fast and Easy to Use (1993)

155 points by donohoe 6y ago

themodelplumber 6y ago
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)
- bdcravens 6y ago
  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.
Zardoz84 6y ago
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.
williesleg 6y ago
Microsoft was evil back then and killed off foxpro
downrightmike 6y ago
Knew a guy who published a technical book, bigger than a phone book, and he wrote it all in FoxPro and that was 2010.
- themodelplumber 6y ago
  Epic! There's really something about knowing even an old tool inside out, and being able to do amazing things with it.
- deleted 6y ago
  [deleted]
- Pamar 6y ago
  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?
  - rm445 6y ago
    Think of web content in a CMS. All the assets are in a database and they get spat out through a pipeline giving a formatted end result. I've never written a book in a DBMS(!) but it seems plausible.
    - Pamar 6y ago
      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.
  - Terretta 6y ago
    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": https://www.inkdrop.app 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 https://en.wikipedia.org/wiki/WinFS ) and JAMStack is a thing.
meepmorp 6y ago
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.
- int_19h 6y ago
  Also excellent built-in documentation, complete with samples and F1 context help. I pretty much learned FoxPro from scratch entirely from it.
  - marcodave 6y ago
    how did we go from excellent software, with excellent documentation, that made regular people implement solutions, to the current situation?
    - badsectoracula 6y ago
      Things got complicated. But there was a ton of bad software back then, it is just that few remember it.
    - mhd 6y ago
      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.
legulere 6y ago
There’s still software out there today that uses FoxPro for data storage.
- altun 6y ago
  It ranks 33rd on the tiobe list, where Rust is 30th.
- deleted 6y ago
  [deleted]
tmilard 6y ago
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.
- oblio 6y ago
  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.
- selimthegrim 6y ago
  I hope you didn’t fall out with him over a bad sandwich
- spaetzleesser 6y ago
  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.
codeulike 6y ago
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.
- andylynch 6y ago
  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. The matching engine was written in FoxPro for DOS! --- the source code is here-> http://josh.com/notes/island-ecn-10th-birthday/ http://josh.com/notes/island-ecn-10th-birthday/
  - tluyben2 6y ago
    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.
- janci 6y ago
  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)
- altun 6y ago
scott_w 6y ago
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
carlesfe 6y ago
For those curious about Foxpro, I found this link which contains a tutorial with screenshots on how to use it. Worth it just for the very nostalgic Windows 3.1 controls. http://www.dfpug.de/loseblattsammlung%5Cmigration%5Cwhitepapers/vfp_rg.htm http://www.dfpug.de/loseblattsammlung%5Cmigration%5Cwhitepap...
- fredsted 6y ago
  Looks like awesome technology, looks like it's easy to build simple CRUD apps without the need for the overhead of webapps
  - 7steps2much 6y ago
    Thats exactly what it was all about! You basically made a database, attached a frontend with some forms etc. and you were good to go!
- int_19h 6y ago
  TUI in FoxPro for DOS is more nostalgic still: https://twitter.com/dosnostalgic/status/826566061793345536 https://twitter.com/dosnostalgic/status/826566061793345536 It even had a visual GUI editor, and a visual report editor: https://imgur.com/a/174ZAww 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).
- mattl 6y ago
  Looks like NeXT Interface Builder.
lame-robot-hoax 6y ago
When I worked in a college bookstore in 2014, we used FoxPro to record customer information when they bought a laptop. Never thought I’d see it mentioned on Hacker News.
jasim 6y ago
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.
- jasim 6y ago
  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."
yread 6y ago
I've learnt to program (well, draw things with table drawing chars, but that counts, right?) watching my mom work in foxpro. It had the easiest Hello world: ? Hello world
chx 6y ago
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
dmix 6y ago
Great 80s video teaching an office worker to use DBASE 3 https://youtu.be/j0ng2Tp01Hc https://youtu.be/j0ng2Tp01Hc 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).
- bobochan 6y ago
  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.
  - dmix 6y ago
    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).
mhd 6y ago
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.
- teh_klev 6y ago
  > Bad acquisitions were another one, with Borland buying dBase and Microsoft buying FoxBase Amen. Add also Nantucket (Clipper) being acquired by CA (Computer Associates) which pretty much killed Clipper.
  - jasim 6y ago
    Quick shoutout to xHarbour and Harbour - the open-source, commercially-supported versions of Clipper. https://github.com/harbour/core 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.
postit 6y ago
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.
- marcodave 6y ago
  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
- silvershell 6y ago
  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 https://github.com/dabodev/dabo
- mamcx 6y ago
  I think the same, I slowly working towards it. I made a POC of a language here: https://tablam.org https://tablam.org. My idea is add UI building to native controls with Rust and as database sqlite as the default + connectors to others.
antb123 6y ago
Approach was another SF startup (1991) that was interesting until IBM basically killed it. Another one that would be a cool open source project. https://en.wikipedia.org/wiki/IBM_Lotus_Approach https://en.wikipedia.org/wiki/IBM_Lotus_Approach
watersb 6y ago
I really enjoyed using FoxBase on Macintosh back in 1991.
bennyp101 6y ago
Oh wow, my first job out of school (~2000) was writing FoxPro to extend Pegasus Opera accounting software - certainly brings back some memories!
imvetri 6y ago
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. Here is my project https://github.com/imvetri/ui-editor https://github.com/imvetri/ui-editor
pjmlp 6y ago
Ah, the xBase days. 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.
deleted 6y ago
[deleted]
fortyrod 6y ago
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 :)
deleted 6y ago
[deleted]
rurdaneta 6y ago
for more information on cybersecurity and how to keep your company safe, log on to demyo inc, you will find a wealth of valuable information. https://demyo.com/ https://demyo.com/
phendrenad2 6y ago
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.
- spaetzleesser 6y ago
  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.
  - csmcgcsmcg 6y ago
    Check out Servoy. It is the closest thing that I have seen to FoxPro in terms of productivity and development ecosystem for web stuff.
- CivBase 6y ago
  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.
  - badsectoracula 6y ago
    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.
lakkal 6y ago
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.
BilalBudhani 6y ago
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 :)
nobleach 6y ago
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.
AdrianB1 6y ago
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.
lninyo 6y ago
I've written thousands of lines of FoxPro code at a logistics company. It was a 200 million a year operation and a good 30-40% of the codebase was foxpro. It was so long ago I don't even remember half that stuff anymore but it was a pleasure to work with.
kstrauser 6y ago
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 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!”?
- mamcx 6y ago
  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.
mamcx 6y ago
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 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!
ericcholis 6y ago
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.
mpicker0 6y ago
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! An old discussion thread: http://computer-programming-forum.com/2-vfp/e6d3528c90cc45d2.htm http://computer-programming-forum.com/2-vfp/e6d3528c90cc45d2...
KerryNietz 6y ago
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

155 points by donohoe 6y ago

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)

bdcravens 6y ago
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.

Zardoz84 6y ago

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.

williesleg 6y ago

Microsoft was evil back then and killed off foxpro

downrightmike 6y ago

Knew a guy who published a technical book, bigger than a phone book, and he wrote it all in FoxPro and that was 2010.

themodelplumber 6y ago
Epic! There's really something about knowing even an old tool inside out, and being able to do amazing things with it.
deleted 6y ago
[deleted]
Pamar 6y ago
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?
- rm445 6y ago
  Think of web content in a CMS. All the assets are in a database and they get spat out through a pipeline giving a formatted end result. I've never written a book in a DBMS(!) but it seems plausible.
  - Pamar 6y ago
    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.
- Terretta 6y ago
  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": https://www.inkdrop.app 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 https://en.wikipedia.org/wiki/WinFS ) and JAMStack is a thing.

meepmorp 6y ago

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.

int_19h 6y ago
Also excellent built-in documentation, complete with samples and F1 context help. I pretty much learned FoxPro from scratch entirely from it.
- marcodave 6y ago
  how did we go from excellent software, with excellent documentation, that made regular people implement solutions, to the current situation?
  - badsectoracula 6y ago
    Things got complicated. But there was a ton of bad software back then, it is just that few remember it.
  - mhd 6y ago
    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.

legulere 6y ago

There’s still software out there today that uses FoxPro for data storage.

altun 6y ago
It ranks 33rd on the tiobe list, where Rust is 30th.
deleted 6y ago
[deleted]

tmilard 6y ago

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.

oblio 6y ago
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.
selimthegrim 6y ago
I hope you didn’t fall out with him over a bad sandwich
spaetzleesser 6y ago
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.

codeulike 6y ago

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.

andylynch 6y ago
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. The matching engine was written in FoxPro for DOS! --- the source code is here-> http://josh.com/notes/island-ecn-10th-birthday/ http://josh.com/notes/island-ecn-10th-birthday/
- tluyben2 6y ago
  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.
janci 6y ago
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)
altun 6y ago

scott_w 6y ago

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

carlesfe 6y ago

For those curious about Foxpro, I found this link which contains a tutorial with screenshots on how to use it. Worth it just for the very nostalgic Windows 3.1 controls. http://www.dfpug.de/loseblattsammlung%5Cmigration%5Cwhitepapers/vfp_rg.htm http://www.dfpug.de/loseblattsammlung%5Cmigration%5Cwhitepap...

fredsted 6y ago
Looks like awesome technology, looks like it's easy to build simple CRUD apps without the need for the overhead of webapps
- 7steps2much 6y ago
  Thats exactly what it was all about! You basically made a database, attached a frontend with some forms etc. and you were good to go!
int_19h 6y ago
TUI in FoxPro for DOS is more nostalgic still: https://twitter.com/dosnostalgic/status/826566061793345536 https://twitter.com/dosnostalgic/status/826566061793345536 It even had a visual GUI editor, and a visual report editor: https://imgur.com/a/174ZAww 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).
mattl 6y ago
Looks like NeXT Interface Builder.

lame-robot-hoax 6y ago

When I worked in a college bookstore in 2014, we used FoxPro to record customer information when they bought a laptop. Never thought I’d see it mentioned on Hacker News.

jasim 6y ago

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.

jasim 6y ago
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."

yread 6y ago

I've learnt to program (well, draw things with table drawing chars, but that counts, right?) watching my mom work in foxpro. It had the easiest Hello world: ? Hello world

chx 6y ago

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

dmix 6y ago

Great 80s video teaching an office worker to use DBASE 3 https://youtu.be/j0ng2Tp01Hc https://youtu.be/j0ng2Tp01Hc 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).

bobochan 6y ago
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.
- dmix 6y ago
  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).

mhd 6y ago

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.

teh_klev 6y ago
> Bad acquisitions were another one, with Borland buying dBase and Microsoft buying FoxBase Amen. Add also Nantucket (Clipper) being acquired by CA (Computer Associates) which pretty much killed Clipper.
- jasim 6y ago
  Quick shoutout to xHarbour and Harbour - the open-source, commercially-supported versions of Clipper. https://github.com/harbour/core 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.

postit 6y ago

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.

marcodave 6y ago
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
silvershell 6y ago
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 https://github.com/dabodev/dabo
mamcx 6y ago
I think the same, I slowly working towards it. I made a POC of a language here: https://tablam.org https://tablam.org. My idea is add UI building to native controls with Rust and as database sqlite as the default + connectors to others.

antb123 6y ago

Approach was another SF startup (1991) that was interesting until IBM basically killed it. Another one that would be a cool open source project. https://en.wikipedia.org/wiki/IBM_Lotus_Approach https://en.wikipedia.org/wiki/IBM_Lotus_Approach

watersb 6y ago

I really enjoyed using FoxBase on Macintosh back in 1991.

bennyp101 6y ago

Oh wow, my first job out of school (~2000) was writing FoxPro to extend Pegasus Opera accounting software - certainly brings back some memories!

imvetri 6y ago

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. Here is my project https://github.com/imvetri/ui-editor https://github.com/imvetri/ui-editor

pjmlp 6y ago

Ah, the xBase days. 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.

deleted 6y ago

[deleted]

fortyrod 6y ago

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

deleted 6y ago

[deleted]

rurdaneta 6y ago

for more information on cybersecurity and how to keep your company safe, log on to demyo inc, you will find a wealth of valuable information. https://demyo.com/ https://demyo.com/

phendrenad2 6y ago

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.

spaetzleesser 6y ago
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.
- csmcgcsmcg 6y ago
  Check out Servoy. It is the closest thing that I have seen to FoxPro in terms of productivity and development ecosystem for web stuff.
CivBase 6y ago
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.
- badsectoracula 6y ago
  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.

lakkal 6y ago

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.

BilalBudhani 6y ago

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

nobleach 6y ago

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.

AdrianB1 6y ago

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.

lninyo 6y ago

I've written thousands of lines of FoxPro code at a logistics company. It was a 200 million a year operation and a good 30-40% of the codebase was foxpro. It was so long ago I don't even remember half that stuff anymore but it was a pleasure to work with.

kstrauser 6y ago

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 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!”?

mamcx 6y ago
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.

mamcx 6y ago

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 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!

ericcholis 6y ago

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.

mpicker0 6y ago

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! An old discussion thread: http://computer-programming-forum.com/2-vfp/e6d3528c90cc45d2.htm http://computer-programming-forum.com/2-vfp/e6d3528c90cc45d2...

KerryNietz 6y ago

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