Not to mention that USB drives tend to ignore read only tab and Windows writes the "System Volume Information" folder to the drive.

R:BASE is still around

I loved visual fox pro as a kid (~10). I made little UIs to open my favorite sites and files.

modi comm taekwando

I didn't do Erlang at the Tae Kwan Do studio, that was the FoxPro and ColdFusion (and ActionScript/Flex).

I have just had a lot of very odd jobs which has taken me in a bunch of directions.

I'm wondering if it's the same guy. Without doxxing yourself too much, you didn't happen to be in the central Florida area did you?

it sucks when one of these systems outgrows the capabilities of the underlying platform.

It did, but does it still with AI? Back in the 90's it was crazy painful. I'm not in the same situations as I was back then, but I'm optimistic about the future being better because we have better tools today than we did back then.

The only Citrix Metaframe (and later Windows Terminal Server) machines I ever deployed in Real Life were because of shared-file database-based applications.

MECHANIC

HOURLY RATE

$100/HR ==== STANDARD

$150/HR ==== IF YOU WATCH

$175/HR ==== IF YOU HELP

$200/HR ==== IF YOU WORKED ON IT FIRST

$250/HR ==== IF YOU TELL ME HOW TO DO MY JOB

Why stop there? What the world truly needs is a vibe-coded Lotus Notes!

Without fail, these vibe coded project websites all make themselves look way more ambitious and established than they actually are. A software project could be hours old and it will have a website that, just a handful of years ago, only projects that had been around for a while and with a revenue model would have had. To me, it comes off as so overly persuasive that the only thing I can think nowadays is "what sort of half-baked junk are they trying to sell me?" Today, a primitive website or a mere handwritten README.md is, ironically, a more reliable signal of whether an application is worth considering. At least to me, anyway.

We need https://xkcd.com/1742/ but maybe with a different scale category.

Unlike most other people here, I wouldn't really say I've developed a radar for "the vibecoded webpage design"; I thankfully don't dabble as much with FE nowadays so if you told me this is default Bootstrap 4 or something, I'd have believed you. But as I scrolled through the claims, my AI-generated text radar pinged hard and I was caught in a moment of dissonance between the sleek design and the AI-cadenced copy.

Suddenly, I would've had more confidence if this was a black default font text on a white webpage, served from a .edu domain.

The nightly is rebuilt from every push to main and published as a pre-release on GitHub. Unsigned, so the first launch asks you to confirm.

But with only two commits within the hour this really reads more like a concept of a release plan than an actual regimented/automated release process.

My problem with vibecoded projects was never whether if it was going to work but whether if the failure modes are known. And you can only know the failure modes if you check your work. Hence why, I realized that a history of alpha and beta releases for an opensource project is a signal of quality.

Fuck you. Put the bare minimum of effort or thought into something you claim to have made before spamming it online like it's an achievement. You didn't make this or do real work. You're functionally indistinguishable from a spambot and couldn't even write your own comments.

Apple still sells Filemaker.

https://www.claris.com/filemaker/

A company I worked for has run VFP up until the last few years. I cut my teeth professionally with it on ETL processes. It moved data around like nobodies business!

My first real job was 2006, turning a Visual FoxPro application into a Web Application using ASP.Net 1.1 Web Forms and VB.Net.

With that said, I've never actually used FoxPro. I only had a database as the contract for what my web app was supposed to do.

bigger tables (2 GB cap) and no source code changes.

Probably because *nix programmers in general are the black coffee long beard RTFM type.

There have been shitloads of open source RADs. They do not generate much interest.

For RAD, Delphi was filling a pretty big niche in its day, and it's still used in some companies local to me. I remember being told during an interview that it performs really well and it's kept up well enough with the changing times. I knew someone from University about 10 years ago that got her first Software job writing Delphi!

I ran into all of this with the first few years of my career. Even after years, MAUI has struggled to gain traction and Avalonia has grown and is far more the de-facto choice for .NET cross-platform GUI. Both work collegues and myself have ran into XAML/WPF Styling horrors where it's all one giant aggregation/inheritance nightmare generated by Blend (and done by someone that didn't quite know what they were doing)

Well, (F)OSS projects have never been known for great UI/UX (with some exceptions like Blender), so it doesn't surprise me much

Nerds have vested interests (exposure/influence/status based on exclusivity of skill) to oppose letting ”the wrong people” create software, versus a company like Microsoft is the other way around because they get paid and get to further-entrench their platforms (but I repeat myself).

And/or too many people have internalized a feeling of “I am Very Smart because I know better than to ever try anything unique”, as exemplified by that awful xkcd ‘Standards’ learned-helplessness comic somebody will always rush to post in a discussion of any New Thing, and thus would never even dream of creating RAD tools whose entire premise is the creation of bespoke software.

I'm shocked in general at the lack of open source Rapid Application Development software.

They exist:

- In particular in the 90s and 00s, Tcl/Tk was really magic for creating user interfaces for small applications under GNU/Linux.

- Lazarus attempts to be an open-source analogue to Delphi

- LibreOffice Base attempts to fill the same niche as Microsoft Access

- Historically, in the time of Gtk+ 1.x and 2.x Glade [1] was an editor for clicking together user interfaces. Well, development ceased, and under GNU/Linux there is no attitude of retaining backwards compatibility with applications/libraries that are not maintained anymore (but which might be business-critical).

- ...

But of course Rapid Application Development is much more popular in the business world which is (at least in many European countries) a rather Microsoft-centric environment. Additionally, the typical developer that uses Rapid Application Development is often a subject-matter expert in some department who also knows a little bit about programming (i.e. is not in deep love with programming), and not a programming expert who also knows about some other specialized topics that are important for the business.

On the other hand, the open source environment typically rather attracts people who really like programming.

---

[1] https://en.wikipedia.org/wiki/Glade_Interface_Designer

There was[0] Dabo, an attempt at a modern Visual Foxpro in Python https://dabo.leafe.com/

0: sort-of "is" rather than "was": https://blog.leafe.com/creativity-and-ai-models/

Qt Quick and Qt Creator isn't RAD per se but I feel like it gets you close.

Gambas was neat. I think we also looked at Kivy at the time, and I think there were a couple of other Python RAD systems that aimed to be similar to VFP in spirit, although not even slightly compatible.

Have you seen "Weekend at Bernie's"?

As long as it has a significant number of users Microsoft will keep shipping it. But it is not getting significant new investment. If you are building a new application you're better off using Power Apps, Dataverse, SharePoint, Power Automate, etc.

All true and yeah, I did discuss with my employer at the time about how they needed to think long term about migrating to SQL Server or MySQL/PostgreSQL with a web front-end. However, the giant IT contractor they were stuck with would only allow SQL Server and charge a fortune, and they didn't have the time/money/know-how to go anywhere with that. They were stuck with Access!

It includes SQLite

In the mid-2000's, I built a lot of applications replacing Access. I always met with the actual users of the system, and made sure they understood that once I took over development, they weren't going to be able to build out their own forms anymore. A few clients were turned away, but most could live with paying for myself to make any future edits, so that they could concentrate on the business objective rather than coding in Access. I never really had the same success with replacing Excel, except for a few systems where it needed to be true multi-user.

I looked at FileMaker a few years ago because it would’ve been a nice setup for a semi-technical acquaintance. And then I saw its pricing, and we went in a different direction.

The father of a girl I dated in college (circa 2000s) built an entire student tracking system using FileMaker to use at the High School he was the Principal of.

We didn't date for long, but I'd be curious to know how long that system ran.

There's Gambas: https://gambaswiki.org/website/en/main.html

Lazarus/FreePascal: https://www.lazarus-ide.org/

Kivy: https://kivy.org/

Grails: https://grails.apache.org/

And any number of combinations using the web. I think they've just fallen off in popularity due to all the web interfaces, honestly.

Technically, MS Power Apps is the successor to MS Access. Power Apps is a web application so that solves the cross platform problem.

Having played with it, it’s not as turn key as either MS Access or something like Airtable. It can be overly complicated and it’s infected with the paradox of choice.

Spec one.

Start one.

Has someone written on or otherwise worked on this?

Our high school taught FOXBASE and I immediately fell for it. I didn’t make anything real with it, though, but it was my first official language and I dreamed big back then.

That’s great! Nice work thanks for sharing. I’ve never heard of FoxPro but I’ve seen how businesses need some app for 30+ years. Cool to see this happen.

An IDE, form designer, language, runtime, and database engine.

People used it to write business applications. Like Microsoft Access, or Visual Basic.

It started as a competitor to dBase II/III called FoxBase, and then Microsoft bought it.

Original - FoxPro: https://en.wikipedia.org/wiki/FoxPro

Successor - Visual FoxPro: https://en.wikipedia.org/wiki/Visual_FoxPro

Yes, they bought it. But they didn’t buy it and stab it in the heart. They developed it for several years.

A primary bit of tech that came out of the purchase was the core DB engine. They reworked this into what became the Jet engine. The Jet engine was the core of Access.

Access was in many ways a next generation of FoxPro. They both went after the same niche of desktop and file server DB applications. But FoxPro carried the legacy of its dBase roots, FoxBase was basically “better dBase”, but had to appeal to and be familiar to dBase developers.

Access had no heritage like that to hold it back, and was a better citizen in the VB/Office/OLE/COM world. It was also more SQL first even though it kept things like DBF files as first class citizens.

It was boxed software that, when going to a computer/office store as a child in the mid-1990s, you wanted your parents to buy because it had a fox on the cover and in the name without actually knowing what it did.

Simply speaking from experience.

A tool and language to write apps where you could write "Select * from customers" in the command window and get results right there in a browse table, beautifully

Not a single language nowadays can do that

Besides being a DB with forms, reports, etc as already mentioned by others - its significance was huge as it was the peak of an era where small/single developers could deliver business solutions by knowing a single tool, and people with domain knowledge could write their own solutions.

Since then everything became much more complex - networking, security, GUIs, web development, deployment, etc.

Is it less performance if you compare the hardware it was probably running on vs today?

Funny enough the customer is one of my dads friends that has been running the same shop for 20 years, wanted bigger tables and keep milking that for the foreseable future. I wanted something simple, no jit stuff, no gc complexity. Just a stack based interpreter. Yes it was LLM assisted like most stuff nowadays.

Hi! thank you for the candid response.

Hahahah this is too funny 8)

I wished almost it was terminal based

Hey, I got to mention this recently! One of my bizarre claims to fame was writing this little tool[0] a few employers back to convert Visual FoxPro database files to PostgreSQL as part of a migration. For a while we had to run it as a cron job so that people could to data entry in an old VFP app but others could run fast reports on our web app with a postgres backend. It wasn't pretty, but it worked great and helped us get off that ancient stack.

[0]https://github.com/kstrauser/pgdbf

One benchmark would be: would someone with a legacy FoxPro LOB app be entrusting their data to this? Or is it just a nice "wow, that's a cool project"?

Yeah, you're right. The models have just gotten better at design.

"Every picture is a real session."

Dead giveaway.

There's a continuum between vibe coded and directed LLM, I guess we'll see which it is.

Robots (by default).

Take the time to ask for anything else.

The post comment here is 100% packed with LLMisms, so yes.

The runtime didn’t contain the debugger or other dev tools, only the dev version/IDE did. It did contain the report writer, though.

Wow, I’ve had the opposite experience. I’ve needed to talk Claude down from Redis clusters for hobby projects to avoid concurrency edge cases.

Although to your point, it struggles to do anything with SQLite beyond a single user even when its architecturally not a problem

It wasn’t that hard to make it multiuser back on the day, either. But as OP discovered, FoxPro also made it very easy to write shit multiuser code. Pessimistic/optimistic locking, etc.? It was in there, but you had to use it.

Low code solution have a fairly steep learning curve, and when someone got into it in anger, the complex electrical diagrams that result are even more impenetrable than spaghetti code.

In a large enterprise environment I have seen business users getting burned by vibe coding already, as they often don't even read the comments and warnings that the LLM gives them. But I think it is inevitable and should enable software to automate the millions of manual processes that are too bespoke to pay an IT team to automate.

For a solo entrepreneur, it should enable to get so much done before having to hire the first employee. Hence less risk to go bust, easier to take risks, pure value added.

Same, but not a Mac.

The lecturer had a side business building FoxPro apps for local businesses, and really pushed us with real-world style SQL puzzles.

Built an app to track my MtG cards at the time. (this was pre-Web)

My daughter loves foxes. When I made a desktop shortcut to allow her to easily hibernate her school laptop I knew right where to go to get an icon she'd like.

moricons.dll holds a very special place in my heart.

https://devblogs.microsoft.com/oldnewthing/20250505-00/?p=11...

https://retrocomputing.stackexchange.com/questions/6705/what...

I love the detail in these things... icons today don't take advantage of the incredibly high resolution of modern screens, they're just wishy washy corporate logos

Exactly, or an access database. This is to enable end users who live in a fully locked down environment (enterprise setup) and can't install anything to use database like features without having to wait 6 months for IT to lift a finger.

But if it starts being a system of records / authoritative system, there needs to be a plan to decommission it.

seen this exact pattern in small business FoxPro setups too, DBFs on a share are one dropped SMB connection away from a corrupted index. if you're stuck maintaining something like this the least bad move is nightly copies of the whole folder to a second box, and actually opening that copy in the app now and then instead of just checking that the file sizes match.

Sounds like it works as designed.

Feel free to quote me, contact info in profile if needed.

EDIT: sorry, I originally just skimmed your comment. I was unclear in my original comment: the files can be accessed and “hacked” from the file system with a text editor. (And a bunch of deleted stuff because I misread your comment.)

Well, on a different note, if you have a scripted language application, you typically can edit files and bypass whatever you want on the application. In fact, I'd bet most modern software isn't signed; and even if it is, sometimes the libraries that get compiled in into that signed binary... aren't.

I can change the behaviour of many/most applications by just having read/write access to files; Can you give me examples of mainstream applications that are resistant to filesystem tampering when eg.you have install access? Maybe I'm missing something.

But the filesystem access to read/write the db files creates a path to bypass half of that application.

Is there any local/native application for which this is not true?

Further along those lines, it was a different world when the code was created.

Trust was a thing back then. Spam was something that came out of a tin and was made of dead animal. And passwords were limited to eight ASCII characters.

And as such, bolting security onto something that was designed inherently to be security agnostic is going to be a recipe for failure.

A massive footgun? :)

And that would be relevant if someone use sqlite as the default database backend for multiuser applications with stored procedures.

That's the problem here: Systems built on sharing the database over a networked filesystem, where one user can not just modify all the data, but can also execute code on all users machines.

True. When someone on the internet sends me a vfp file... i just open it in my IE6.0 no cares given.

I have memories of supporting a Netware network with a custom Foxpro app used by a bunch of telemarketers in the mid 90's.

When there was application error the source code would pop up in dialog maybe a some sort of debugger and the end users would just type a bunch of crap in trying to get out of it and hit enter and save the changes and corrupt the app for everyone and it would have to be restored from backup.

Pretty sure it was Foxpro or maybe dbase, definitely wasn't MS Access as it was still a dos based client.

Very different idea about app security back then, was really nice to developed the db, GUI front end and printable reports all in single runtime though.

Here’s my problem with reviving FoxPro in any form

And then it moves to the orthogonal problem:

SQL DB

(that in fact means: An app made for end users that are not trusted by default but really are somehow that is a improper implementation of the relational model and more improper developer platform, more like wordpress, and because is mostly deployed "networked" suddenly need to worry about remote access, that is totally not the main point of old Fox/dbase apps!)

And the funny things: SQL injection is not a problem with a Fox app (use of a stringy api is a MAJOR issue that lack of a permission model)

---

As one that have long experience with FoxPro and try to revive the style, lets go to the core of the problem:

Imagine you say to a C developer:

"You can't use `fopen` and other filesystem APIs, because well you have access to to the whole filesystem"

Or even better, the user!:

"You should not own your own filesystem!"

The DB is like the filesystem, but not that dumb!

The permissions model is orthogonal. Maybe you (normal) filesystem is running on a networked deployment with access by spies with and other personal that should have top-notch security.

Or is just a embedded device.

WHAT DECIDE THE SECURITY MODEl?

The kind of storage?

Nope!

Is the deployment and use case.

Similarly, what decide the security of a database?, the fact is a "database"?

No!, that is ridiculous. If you need to layer some kind of access control or whatever, is outside of the kind of storage you choses.

In fact, see how Wonderfully could be all if the "filesystem" where an actual database and you can run relational queries on top: Millions of "cli utilities" suddenly are unnecessary, the user (and developers!) have more freedom and control, and your big corp with byzantine rules will be even more happy.

----

P.D: I'm very well aware of the limitations of Fox, is ancient software! but the style of programming? Is like have a taste of start trek

P.D.2: And note that the vector attack described here is a fault of the dumb filesystem, actually!

Could the security hole not be closed up?

Maybe there's a way to run them more securely with a wrapper.

It does make sense to try and move to a sql db of some type, and my immediate thought is if something like Postgres, with a plugin or extension or two couldn't simulate enough of Foxpro.

That, or rewriting large parts of the DB engine seem readily much more possible now with LLM driven development.

Actually you can use foxpro with mssql and ole, you could than even add row level security for even more security

FoxPro just executes what it finds in there.

Perfect. I'm looking for a program that executes everything it reads. You've tracked a 20-year-old security bug for FoxPro? That's gnarly. What if, instead of reviving FoxPro, we summon a new type of DOS with no security model to begin with? FoxPro was always better that way.

Hear me out. So, you have your regular computer on your desk, right? I call that the REAL SECURITY computer for REAL WORK: You know, your typical choice of Windows 11, Apple, or Linux. The biggest names in security. The names we trust. Real work. Real computers. Real security.

Next to it sits FoxPro, running new DOS on a separate computer with no security model at all.

Here's the ergonomics. You press your hands against your desk and push your office chair off like a boat, gliding away from the SECURE COMPUTER in the REAL WORLD toward FoxPro. FoxPro reads everything and executes with religious zeal.

- written from my treadmill. edit: fix typos

Ugh. My first job was rewriting foxpro. Bad memories.

Flashback. When I was an adolescent, the dBase and Fox products were my first paid software development, and they were surprisingly accessible to even kids.

I was only supposed to help assemble computer furniture, and maybe install networked Unix and PC software, but the retired Marine my mom worked for thought I had potential. "Hey, Kid", he would say, we need to modify this dBase vehicle fleet insurance database to support more vehicles; figure it out. Here's the manuals for C database library, and Microsoft C, I'm evaluating; figure it out. We need to migrate between accounting systems; here's a sample .DBF of the target schema, here's how you generate a full dump from the legacy minicomputer, use this editor called Emacs to clean up the dump for import, once you figure out the schema mapping; figure it out. I also bought an older dBase product, and then a Fox product, for home, and figured out how to build a few fancier systems.

(Then I kept working, and there was a period when all employers either wanted me to figure out something, or were favorably surprised when I soon did, thanks to formative influences of figure-it-out mentors. Then a break to get belated formal degrees, then being surprised after that pause, when job interviews were suddenly Leetcode-like, and they didn't seem to want me to figure it out, but wanted a rehearsed ritual performance conforming to a big-corporate sanctioned set of rules, and apparently the Marine hadn't written a book to counterbalance that awful green book. :) )

Why does every AI written project website make it sound like it's going to kill all your enemies for you and get you all "the bitches"? This is true power. Unforseen by human eyes thus far. Your manager will tremble in fear.

I wouldn't trust anything without further review.

I would welcome a community effort. There are many (?) companies still relying on FoxPro. Vibe coding a solution is feasible these days. We've vibe-coded a few from FoxPro to Ruby on Rails with great success. I'm no longer stressed about the future... just the timeline.

Fair concern. MIT licensed, all source code on Github for audit. Only Nodejs + a Rust toolchain is required to compile it. On windows (for the FLL bridge) it needs Visual Studio C++ tools

Hi Neat! you mentioned you guys are already on a rewrite path. That is the proper way forward and I recommend gathering as much information about the product and edge cases as possible. Document every business rule, every product decision. Handwaving aside, audit the Foxscript source code, clone it to a virtual machine or container. Any issue you face, feel free to post an issue on Github as I would love a few edge cases on the wild. As the Foxscript runtime relies on 64 bit offsets for the DBF/Memo, once a DBF (past the 2GB) is opened they can't be migrated back to old VFP9, so I recommend to test this carefully on an airgaped setup with tests DBF.

DBFs tend to be the easy part, in my experience in a similar company (not as much revenue.) The spec is simple enough that one can write a reader/writer in an afternoon, even before AI.

My biggest challenge is the speed at which calculation heavy business logic can operate in FP, even on network shares, as long as they're optimized for IOPs not bandwidth. Trying to adapt similar data access patterns to a networked RDBMS will kill you with round trip and connection overhead. Converting that logic to set-based operations or stored procedures means altering logic and all the risks that entails.

1 commit 2 hours ago

domain registered 7 hours ago

ghost pusher named Dev

Oh nostalgia, dbase, clipper, clarion, foxbase, delphi, I loved VFP so much, not for the language but for the tools, the screen designer, the db browser, the sql queries, all that power and user love was dumped in the trash can for the travesti that was .net at the time

I learned VB.net, C# and even F# to see if they surpassed in any sense my beloved VFP but no, I felt so betrayed I decided to migrate to a galaxy far far away and never look back, 25 years ago (a time where exes and single user apps where the norm for my clients, then came multiuser and external db storage, then the web took over)

This looks promising, I'll give it a try. If I asked AI to fork it, I'd change the language to modernize it a bit (uppercase now looks like cobol written on a punch card)

Edit: On a second thought, I'd fork it in Swift (with the help of AI of course) and use it in MacOS for single user desktop apps. It would serve a single purpose much better than xCode does

Not sure but I'm getting really sad reading anything and seeing this AI speak everywhere.

Goddamn this brought me back to my childhood with FoxPro books on my dad's bookshelf when I was a child. Thanks for that, necromancer.

My goodness, a blast from the past. Such a glorious time to be a programmer... every single business needed a database to do their simple little daily chores, the coding was insanely easy (just a bunch of CRUD process), and the difference it made to the customers was night/day... hence, you could charge thru the roof.

I wrote a simple little CRUD app in FoxPro, for the Canadian real estate appraisal market, which took about a part-time month to create, and first year, sold 300 licenses at $299 a pop.

Ahh, memories of a simpler time.

This is great! Next up: VB6

It's incredibly jarring, and subtly nonsensical...

Perhaps this is a good use case for AI? I'm sure it's trivial to write an AI system that reads AI text and replaces AI-generated text with AI-generated, non-AI-looking text.

AI.

haha, I used this exact example in sales calls to make the case against app modernization. Sometimes, you just need the stuff to keep working, with $20-and-a-roll-of-duct-tape-level budgets.

My proposal was proxy layer sitting in between, running on something like k8s and written mostly by an LLM to provide a safe interface to queries against foxpro, with ratelimiting, query parsing, rest, whatever other business logic you want.

I am appalled at the fact it's still out there, but there is even older, more Archean stuff out there running literally the entire world :)

I miss the VB6 days. Simpler days with worse options than what we have today, but being able to drag a button onto a canvas, double click it, wrote the code behind it, and then build to an executable was lovely. I wish I could do that today with macOS but everything is so complicated these days. AI helping.

Delphi

Delphi is alive. https://www.embarcadero.com/products/delphi

A big software for simulating the economic balance sheets of life insurance companies moved many years ago from using FoxPro under the hood to CSV files and sold it as a huge improvement. I don't think anybody was convinced by that, but vendor lock-in makes companies accept such regressions.

That is the same experience that I had with manufacturing shops, they just keep using the tool if it works.

And to the Author of the project. Thank You for making it. My pleasure

Think Flash (eventually) had most of these. That said, not all software development needs to happen at the same scale and not all software authoring environments benefit from the same tradeoffs vis-a-vis complexity, collaboration, accesibility etc. the success of Flash as a platform for independent game devs shows that different markets are better served by different tradeoffs.

I haven't used Delphi since I was a child.

Microsoft should open-source FoxPro, at least some version of it, because as of 2026, it has no commercial viability (no ability for it to make the company money) compared to say SQL Server, Access and/or Visual Basic with the appropriate back-end database drivers. If Visual FoxPro V9 (2007) is too late because there are unexpired patents or other issues, then Microsoft should open-source an earlier version.

Even open-sourcing FoxPro 2.6a for DOS (the last DOS version, August 1994, > 30 years ago) would be better than open-sourcing no FoxPro version.

Fundamentally, FoxPro, at its core, is 4 things:

1) It's own low-level database engine

2) It's own SQL parser/interpreter/engine sitting on top of #1.

3) Simple (but very data-aware of the underlying data!) scripting language (based on dBase, referred to as "xBase" -- or more specifically the FoxPro dialect of xBase) sitting on top of #1 (except for the SQL commands, SELECT, INSERT, UPDATE, DELETE, etc., which sit on top of #2)

4) Form / GUI / Data-entry and Data-search Form Designers that exist on top of #1, #2 and #3. Basically a primitive (although very functional and elegantly simple) windowed App building environment.

Now, all of those 4 things could be replaced and/or outsourced to other open-source projects...

For example, to read/write/index/seek in FoxPro database files (the low-level database engine):

https://github.com/MPSystemsServices/CodeBase-for-DBF

I'm not sure if CodeBase comes with its own SQL engine/parser -- but if not, SQLite has a pretty good one which could probably be used with some modifications. If not, ANTLR has various SQL grammars for it floating around on the net (here's a quick blog post of someone using ANTLR to create a query language: https://markandrewperry.medium.com/using-antlr-to-create-a-q...)

For the scripting language, any scripting language could potentially work, but special attention should be paid to the way FoxPro variables are aware of data in underlying open tables in the current work area (SCATTER and GATHER commands and how they work, etc.), which is one of the unique features of FoxPro. (Also, for command / line / expression evaluation, you'd probably want to use or at least know about Dijkstra's Shunting Yard Algorithm: https://en.wikipedia.org/wiki/Shunting_yard_algorithm)

For the GUI / Form designers, well, any data-aware form-designing graphical toolkit could work, but of course, FoxPro has/had its own nuanced "flavor" of these.

Generically speaking, FoxPro is/was a database engine, SQL engine, very-data-aware scripting language and form/gui/app designer -- all rolled into one package.

I'd love to see an app where all of these components are open source, where there are clear interfaces between those components (separate compilation options for codebases, depending on which components you want), where the original FoxPro/dBase/xBase scripting language is used (because it was great!) and where any underlying database engine and/or SQL engine could be "swapped out" for any other (i.e., SQLite, Postgres, etc.)

Anyway, FoxDevStudio looks interesting in this space!

Ah yes, yet another reason not to bury the dead.

I haven't used FoxPro but I have had plenty of exposure to tech with a similar 'feel' - Excel and Word documents scripted to the gills with VBA, eventually C#, and mutating into new and kinds of horrors.

It always starts simple - you wanna build just a simple CRUD where the entry is a form that goes into the table.

Then the complexity grows, and your table has to reach out to other services, call APIs etc. etc.

The 'convenient' primitives, that did 90% of the things that need doing can't do the last 10% - so you drop down to VB, which is exactly like regular programs but worse. It also doesn't interact well with the rest of the system, so you have to rewrite adjacent stuff in VB too.

OMG what a blast from the past. We were taught FoxPro in school in 2002 for some reason. Not even Visual FoxPro, the old school DOS version. It taught me a lot about scripting and I remember helping out a medical rep who had built a FoxPro app to manage his business while in college.

Interesting! Yes, I would love to give it a try.

Ah the xBASE languages, I was a big fan of them and Clipper 5 helped a couple of side gigs during school years.

Never got to use FoxPro though, but followed along in magazine articles and such, great to see this kind of tech going on.

I have learnt programming watching my mom code in foxpro (using el editor) in the early 90s. I would sometimes correct her missing parantheses haha. She made all UI out of box drawing characters, unbelievable amount of work compared to today.

Can LLM access FoxPro programmatically, or is the file format easily parsable? Most of FoxPro apps are likely fairly simple CRUD apps. It would be trivial for a modern AI to transcode it to a web based client server solution.

I believe it would be helpful for those who would want to continue development, contribute to the project.

Pro-AI people now argue that the code is ephemeral nowadays, we should not look at it like we don't look at generated assembly (most of the devs). So in this regard, sharing only the "assembly" doesn't make sense, it's like sharing only the binaries and calling that open source (before LLM days).

Very nice one of my favorite revivals ever. Kudos.

Good lord. I remember having to convert Visual FoxPro "programs" to PHP+MySQL way back in 2011. That was actually a lot of fun.

This is fascinating. The author did great work here.