Thread

1. rufugee · 1790120188 · focus · HN ↗

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

   1. sm-silversight · 1790122007 · focus · HN ↗

      Would you trust foxscript? I'm curious if this is just a wide-net data exfil attempt.

      1. rufugee · 1790122847 · focus · HN ↗

         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.

      2. boredjohnny · 1790128262 · focus · HN ↗

         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
   2. boredjohnny · 1790128171 · focus · HN ↗

      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.

      1. rufugee · 1790169159 · focus · HN ↗

         Do you do consulting in this space? I'd be interested in having some discussions...

         1. boredjohnny · 1790197236 · focus · HN ↗

            I run a small consulting shop with a family member. We are a little bit tight on time but I'm willing to help with whatever you guys are facing rn.

            1. rufugee · 1790283628 · focus · HN ↗

               Would love to have a conversation. Drop me an email at rufugee@proton.me. Looking forward to it.
   3. briHass · 1790132926 · focus · HN ↗

      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. rufugee · 1790283529 · focus · HN ↗

         The issue we face is CDX. We have >100 dbfs, and >600 clients hitting them at all times.

Unofficial Hacker News client; not affiliated with Y Combinator.