Here’s my problem with reviving FoxPro in any form: there’s a huge security hole in the Database Container (DBC) design. For DBCs to be useful, they must be read/write to all users (there is no permissions scheme). DBCs have stored procedures that can run any FoxPro code, including Win32 calls made from the FoxPro runtime. The stored procedures are stored as plain text in a “memo” field. Do you see where this is going? With a little technical knowledge, one can modify that INSERT trigger to whatever you like. EDIT: as the DB is just files in the file system, modifications can be made using a text editor, bypassing any checks in the FoxPro runtime. FoxPro just executes what it finds in there.
My recommendation is to get rid of the DBF/DBC files and move to a SQL DB of some flavor ASAP. If you have the source code, use ODBC or OLE DB to point to a server.
Source: filed that bug over 20 years ago when I worked on the Fox team. No, it wasn’t going to get fixed without rewriting large parts of how the DB engine worked.
Exactly. It's not a security hole. It's just the architecture of the program.
It seems like many people have a hard time understanding this, including developers.
Any attempt to add any kind of permissions, security, etc, without addressing the nature of the architecture (that the database engine runs in the same address space / security context as the UI) misses the point.
Well, I had to call it something. File system DBs were a problem long before FoxPro’s DBCs, yes. Yes, it’s an architectural decision. Sharp cookies would just modify the files directly. But that would just trash data (or bump my hourly rate in the HR DB). Most of the time, “full access to data” doesn’t necessarily mean “run arbitrary code”. In this case, it does, which I don’t think folks expect, hence “hole”.
One of the Ohio Secretary of State's "certified" (wrong terminology, but you get the idea) voter registration databases used by various county Boards of Elections is written in VFP. The software maintains the list of voters, their addresses, and scans of signatures.
Recently it had TOTP 'MFA' added to comply with a Secretary of State mandate.
Anyone who uses the software can just open the database files directly. They're just DBF files in a shared folder on a file server. All the users have to have read/write access to the files or the application won't work.
If it isn't client / server architecture there's no privilege separation using SQLite either. The storage format isn't the concern. Rather, the concern is it all runs in the same OS security context.
Thanks, this is the most useful comment here. FoxDev reads the DBC the same way VFP does, so today it inherits the hole exactly. The runtime is actually the one place it can be fixed. I would put in a hash of the stored procedure text into the built executable and refuse to run a container whose procs don't match. Adding it to the list. Would you mind if I quoted your comment in the issue?
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. Runtime checks won’t save you. A hash check, or what have you, simply turns it from super-easy to “hmm, I might have to spend an hour or two on this”.
I worked with a physician's office in 2006, and the lead physician had cobbled together a system for patient tracking using Visual FoxPro. It was a monstrosity, and using it over a network drive gave all sorts of file locks and issues with multiple people changing the same record (usually the physician and front of house staff when checking the patient out).
I finally got the physician to switch to a proper client/server architecture using .NET WinForms and ASP.NET RPC calls. All issues went away, and I was even able to allow staff members to edit the interface to set what mattered to them most at the top of the application, by building the lab testing form in XML so they could move the X/Y coordinates to where they wanted them. It wasn't even a feature I had thought of, just a physician looking through the technology and figuring out how it worked (luckily the business and security logic were on the server, so a bad actor could only have destroyed their own local copy of the app).
When networked PCs and rapid application development platforms became popular there was a "Cambrian explosion" of custom electronic health record and practice management applications built by doctor hackers who knew exactly what they wanted, and had just barely enough technical skill to sort of make it partially work. Those have gradually died off because commercial products kept improving, and the cost of complying with security and interoperability requirements kept escalating. But I predict that the cycle will now repeat because the combination of AI coding tools plus headless EHR platforms (built in security, storage, and APIs) has made it easier to build a custom EHR that actually works.
Yes, I am seeing exactly this at my own workplace. Two things have happened close together: low code and LLMs. I don't personally like using low code solutions (such as PowerBI and Power Automate), but for many knowledge workers this is all they have. Now you can just ask your favorite LLM how to do stuff and it can help you. It's not exactly vibe coding because these people really understand what they have and what they want, they just don't know the syntax to get there.
DBase/Fox Pro were born when local networks weren't common, it excelled as a single-user batteries-included IDE. Now that you mention this, I understand why it couldn't work these days as it is.
I also think it won't be that hard to make it multiuser, that's a long-ago solved problem these days.
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.
One fear I saw manifest in a job was before AI, and an associate was doing a screen for a request in dot net and it let the user read the record, edit the record and write the record. Last person to write the record won of course.
At this tier of small time company IT, I am hoping that AI will actually improve the quality of code, because people who write racey nolock code that occasionally "drops a few records" are probably hopefully not posting their code to forums or alternatively getting roasted to pieces if they do so its my hope they are only represented in training data as "what not to do."
Just antidotal but I don't know how many times I've had to help developers fix their vibe coded code to account for concurrency problems. LLMs don't seem to be very good at picking up on this today unless you call it out.
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.
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. :) )
The low barrier to entry, high developer productivity, and
bespoke and "highly conforming to proprietary business processes" nature of resulting applications are all really cool, but man, it sucks when one of these systems outgrows the capabilities of the underlying platform.
I shudder at the though of businesses trying to access DBF files on "network drives" across the variety of shitty overlay network technologies that are the norm today. Seamless remote access to applications is the exact recipe Visual FoxPro apps fail at.
It looks cool but I wouldn't want actually work around apps built in it. It would be cool if a client/server database could be transparently shoehorned in to it.
Oh boy, do I have some stories. I've worked with many companies that actually still do this today. You'd be amazed at what someone can do with VFP and Citrix - or maybe horrified.
The only Citrix Metaframe (and later Windows Terminal Server) machines I ever deployed in Real Life were because of shared-file database-based applications.
> 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.
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.
Microsoft might have killed FoxPro but even in windows 11 they still have the icon for it in moricons.dll where it will live presumably forever in every version of windows Microsoft ever releases.
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.
> Visual FoxPro is a 32-bit program, and that decides more than it appears to.
Has anyone studied what in the models causes this sentence structure? Is it some consequence of the architecture that leads it to blurt out a fact and then only later the significance of that fact?
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
My father built several projects in FoxPro. I was too young in the ’90s to remember much of it, but I’m sure he’ll be super happy to check this out. The kicker is that we’ll probably need to buy a floppy disk drive and dust off some old boxes to find them.
All these years later, Microsoft Access is still alive and kicking, and just three years ago, the 32bit version got Large Address Aware (LAA) support! Technically my very first software job was writing VBA in Microsoft Access for a few weeks and they're probably still running it (there's no drop in replacement for it or cheap way to migrate away)
Access is so good. I can't believe there's no universal equivalent for Linux and Mac. There are dozens of times when I've used a spreadsheet when a file-based database would have been better.
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.
Someone will no doubt correct my hazy memory, but I wonder how much to blame was the fact that default QT apps were so ugly around the time that was the height of RAD, and QT was the only(?) well-supported cross-platform cross-DE gui framework at that time.
On windows you could RAD your way to a good looking windows application that looked and behaved like everything else. On linux, default behaviour was either ugly, or not very compatible, or heavily customised anyway, and that didn't change until much later with improvements to GTK.
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 think Microsoft coming out with XAML/WPF created too much complexity for most of the developers that were working with WinForms. Although the code had better separation from the interface, it also took quite a bit more effort to get an application up and running quickly. They took the "R" out of RAD, and then kind of put both WinForms and WPF on life support, while continuing to tout cross-platform on .NET Core without a first-party GUI platform. Now it just looks like Azure was always going to be the solution, to tie users into a platform they don't fully control.
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)
> 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.
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.
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've looked into these before and they're often a monthly/annual SaaS that are either by a one-person company, or worse, something like AirTable that gets crazy price hikes out of nowhere (or shut down) that's a disaster for a small company. Place I worked already had Microsoft Office paid for so why move away from Access.
If it works for you then there is no need to switch. But Access is a desktop app, and in 2026 it is pretty unusual to use a desktop app for business applications. Also, Microsoft is no longer developing Access.
In 2026, Microsoft Access is still fully supported and bundled into Microsoft 365 Enterprise subscriptions. Back in 2014, I'd said to my employer that it's not going anywhere for at least a decade (and that they can fully ignore a report they'd received from the NDPB that oversaw their work that suggested Access might be at risk of disappearing)
>In 2026, Microsoft Access is still fully supported and bundled into Microsoft 365 Enterprise subscriptions.
Having a subscription is only a small part of the total cost. Access works best when combined with a bunch of VBS/macro scripts, which IT departments globally are trying very hard to stamp out completely. Access also needs its own set of permissions and manager of permissions since it can't inherit permissions from anywhere of the other usual Microslop security stores - at least, not without having its own developer/maintainer/champion on tap.
Not to mention the agreed wisdom that while Access is fantastic for rapid-prototyping applications/warehouses/ETL processes, any "permanent" DB/DBMS/solution worth doing in Access is worth doing in a 'proper' database with a proper front-end.
> Access works best when combined with a bunch of VBS/macro scripts...
You're thinking of Visual Basic for Applications (VBA), which is interpreted inside of Access. The standalone Visual Basic Scripting (VBScript) is a completely different thing, and eliminating VBScript doesn't have any ramifications for Access.
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!
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.
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.
Access is a whole package with form designers, widgets, scripting, etc. so that you can build an entire distributable app from it. SQLite's a brilliant little DB but it only covers a tiny portion of what Access does.
I kinda loathe access for any number of reasons, but appreciate the dev tools it put into the hands of non-developers. A great many people who'd be passive users on most systems were able to build apps to meet their business and requirements, and although Access was janky as hell, that's very, very cool. I think it's most spiritually similar to HyperCard on Mac: you wouldn't want to write a whole large app in it, and if you're an experienced developer there are any number of tools you'd rather write programs with. But if you weren't a traditional developer (e.g. an office worker or a student or a home computer enthusiast, etc.) it gave you a pleasant hand-holding process for making your ideas come to life. I respect that.
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.
We run 500 KLOC of FoxPro at my company, daily. It is the engine that fuels a $500M business.
I hate that it's the hand I'm dealt, but aside from AI rewrites (underway), there's no good answer. It's complicated by our reliance on DBFs.
I welcome efforts like foxscript and anything else in this space. There are still a significant number of FoxPro apps out there and no one has a good answer. If you are struggling in this space, leave a comment here. I'll reach out to you. Strength in numbers...
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.
I might literally be the only person on earth that can honestly say I have been paid to write FoxPro, Erlang, F#, and ColdFusion.
My first software job was at a Tae Kwan Do studio who ran their own billing department, and the entire billing half was some weird custom thing written with FoxPro. Not Visual FoxPro, I've never actually used that, but the old school DOS stuff.
I absolutely hated every time I had to touch it and I had hoped that it would die in a fire. I hope Visual FoxPro sucks less.
The main kick is that there is not a way to "rewrite" a foxpro app without tons of stuff along the way!
(Example: You can ship an app that internally run `CREATE REPORT` and the report builder show up. You can invoke the debugger (that as I remember is the best I used a zero alternatives as good existed)) and so on
This is awesome! Having had to deal with ancient file formats knowing that there are renewed tooling that's not binding to legacy OSes that you can't no longer find viably is great.
Now, who's open sourcing and reviving FileMaker that Apple killed?
What issues were your customer running into that made a 64-bit FoxPro necessary? What makes you more confident in rewriting the entire runtime the app runs inside of than rewriting the app itself? That seems just as risky if not more.
Great job! 32-to-64-bit conversions are always fun :) One question though. If this is intended for desktop, why bother with WASM at all? Do you gain anything other than less performance?
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.
Because the same module runs in three places: inside the Electron IDE, in the shipped app, and in the test suite under jsdom, with no native build per platform. The other reason is the boundary itself: wasm exports can't re-enter, which forced the design where every side effect is yielded to the host and the VM is never on the stack while a dialog is up. That's what makes MESSAGEBOX not freeze the window. Perf isn't where these apps hurt, they're I/O and UI bound, and VFP itself was a p-code interpreter. The crate is plain Rust, the CLI runner is native, so a native build is a cargo flag away if it ever matters
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.
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!
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.
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.
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
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.
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.
So hard to take these vibe coded projects seriously. I can feel the LLM selling it to me. I don't want to suggest the code is bad or it doesn't work or doesn't have awesome features... but ai built landers are just so smelly.
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.
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.
Probably. The website does look too good though, none of the design cruft ("eyebrows") that LLMs like. But the last design I let it do was from opus 4.7 or gpt 5.3.
Obviously they used AI at some point in the project, the question to you is what is your definition of vibe coding and how does it discredit the effort they did put into it?
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"?
The website is obviously and gratingly LLM-voiced. I don't know how people aren't tired of paragraphs like this yet:
"Visual FoxPro is a 32-bit program, and that decides more than it appears to. It is why a table stops at two gigabytes, why a memo file stops at two gigabytes, and why a big report runs out of memory on a machine with plenty to spare. The limits are signed 32-bit numbers buried in the file handling, not a licensing decision anybody made."
and
"The editor checks what you type through that very compiler, so what it underlines and what the runtime refuses cannot drift apart."
My recommendation is to get rid of the DBF/DBC files and move to a SQL DB of some flavor ASAP. If you have the source code, use ODBC or OLE DB to point to a server.
Source: filed that bug over 20 years ago when I worked on the Fox team. No, it wasn’t going to get fixed without rewriting large parts of how the DB engine worked.
I don't know if dBASE variants support bind variables. That isolation is really required to avoid the "Bobby Tables" effect.
https://bobby-tables.com/
I'd prefer to see the dBASE language adapted to run on SQLite files, as they are a far more profound standard.
If you already have full access by design, then there's no "huge security hole" either.
It seems like many people have a hard time understanding this, including developers.
Any attempt to add any kind of permissions, security, etc, without addressing the nature of the architecture (that the database engine runs in the same address space / security context as the UI) misses the point.
Recently it had TOTP 'MFA' added to comply with a Secretary of State mandate.
Anyone who uses the software can just open the database files directly. They're just DBF files in a shared folder on a file server. All the users have to have read/write access to the files or the application won't work.
I hang my head.
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. Runtime checks won’t save you. A hash check, or what have you, simply turns it from super-easy to “hmm, I might have to spend an hour or two on this”.
I finally got the physician to switch to a proper client/server architecture using .NET WinForms and ASP.NET RPC calls. All issues went away, and I was even able to allow staff members to edit the interface to set what mattered to them most at the top of the application, by building the lab testing form in XML so they could move the X/Y coordinates to where they wanted them. It wasn't even a feature I had thought of, just a physician looking through the technology and figuring out how it worked (luckily the business and security logic were on the server, so a bad actor could only have destroyed their own local copy of the app).
I also think it won't be that hard to make it multiuser, that's a long-ago solved problem these days.
At this tier of small time company IT, I am hoping that AI will actually improve the quality of code, because people who write racey nolock code that occasionally "drops a few records" are probably hopefully not posting their code to forums or alternatively getting roasted to pieces if they do so its my hope they are only represented in training data as "what not to do."
Although to your point, it struggles to do anything with SQLite beyond a single user even when its architecturally not a problem
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.
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. :) )
I shudder at the though of businesses trying to access DBF files on "network drives" across the variety of shitty overlay network technologies that are the norm today. Seamless remote access to applications is the exact recipe Visual FoxPro apps fail at.
It looks cool but I wouldn't want actually work around apps built in it. It would be cool if a client/server database could be transparently shoehorned in to it.
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.
[0]https://github.com/kstrauser/pgdbf
Has anyone studied what in the models causes this sentence structure? Is it some consequence of the architecture that leads it to blurt out a fact and then only later the significance of that fact?
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
If they do, immediately copy the data over. They tend to crumble and fall apart (and contaminate the drive head, which will need cleaning)
On the Mac, it's FileMaker,[1] which was released in 1985. Claris is a subsidiary of Apple.
[1]: https://www.claris.com/blog/2026/claris-filemaker-2026-is-no...
We didn't date for long, but I'd be curious to know how long that system ran.
Start one.
Has someone written on or otherwise worked on this?
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.
On windows you could RAD your way to a good looking windows application that looked and behaved like everything else. On linux, default behaviour was either ugly, or not very compatible, or heavily customised anyway, and that didn't change until much later with improvements to GTK.
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
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.
Here you go: https://visualdb.com There are many modern alternatives, in fact.
Having a subscription is only a small part of the total cost. Access works best when combined with a bunch of VBS/macro scripts, which IT departments globally are trying very hard to stamp out completely. Access also needs its own set of permissions and manager of permissions since it can't inherit permissions from anywhere of the other usual Microslop security stores - at least, not without having its own developer/maintainer/champion on tap.
Not to mention the agreed wisdom that while Access is fantastic for rapid-prototyping applications/warehouses/ETL processes, any "permanent" DB/DBMS/solution worth doing in Access is worth doing in a 'proper' database with a proper front-end.
You're thinking of Visual Basic for Applications (VBA), which is interpreted inside of Access. The standalone Visual Basic Scripting (VBScript) is a completely different thing, and eliminating VBScript doesn't have any ramifications for Access.
I don’t think that’s true.
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.
I kinda loathe access for any number of reasons, but appreciate the dev tools it put into the hands of non-developers. A great many people who'd be passive users on most systems were able to build apps to meet their business and requirements, and although Access was janky as hell, that's very, very cool. I think it's most spiritually similar to HyperCard on Mac: you wouldn't want to write a whole large app in it, and if you're an experienced developer there are any number of tools you'd rather write programs with. But if you weren't a traditional developer (e.g. an office worker or a student or a home computer enthusiast, etc.) it gave you a pleasant hand-holding process for making your ideas come to life. I respect that.
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.
I hate that it's the hand I'm dealt, but aside from AI rewrites (underway), there's no good answer. It's complicated by our reliance on DBFs.
I welcome efforts like foxscript and anything else in this space. There are still a significant number of FoxPro apps out there and no one has a good answer. If you are struggling in this space, leave a comment here. I'll reach out to you. Strength in numbers...
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.
My first software job was at a Tae Kwan Do studio who ran their own billing department, and the entire billing half was some weird custom thing written with FoxPro. Not Visual FoxPro, I've never actually used that, but the old school DOS stuff.
I absolutely hated every time I had to touch it and I had hoped that it would die in a fire. I hope Visual FoxPro sucks less.
Now your customer has two problems instead of just one.
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
>domain registered 7 hours ago
>ghost pusher named Dev
(Example: You can ship an app that internally run `CREATE REPORT` and the report builder show up. You can invoke the debugger (that as I remember is the best I used a zero alternatives as good existed)) and so on
Now, who's open sourcing and reviving FileMaker that Apple killed?
https://www.claris.com/filemaker/
Of course, it's impossible to know for sure what was LLM processed or not, but your comments are getting classified that way.
(The project itself is fine, of course, to submit to HN. We just want text on this site to be entirely human-written.)
Simply speaking from experience.
Not a single language nowadays can do that
Successor - Visual FoxPro: https://en.wikipedia.org/wiki/Visual_FoxPro
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.
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.
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)
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.
I wished almost it was terminal based
Dead giveaway.
"Visual FoxPro is a 32-bit program, and that decides more than it appears to. It is why a table stops at two gigabytes, why a memo file stops at two gigabytes, and why a big report runs out of memory on a machine with plenty to spare. The limits are signed 32-bit numbers buried in the file handling, not a licensing decision anybody made."
and
"The editor checks what you type through that very compiler, so what it underlines and what the runtime refuses cannot drift apart."
Like, what? Who talks like that?