Microsoft 在 2007 年扼杀了 FoxPro。无论如何，这里是 FoxPro 的复活

原文 ↗ Hacker News 讨论 ↗

一个新项目试图复活微软早已消亡的 FoxPro/Visual FoxPro 生态，引发了曾在其上构建整个业务的开发者的怀旧情绪，也引来了对依赖 AI 生成的“vibe coded”工具的质疑。评论者在讨论：是尽量少改动地继续运行旧 FoxPro 应用更安全，还是迁移到现代技术栈，或者把这类工具当作过渡桥梁，同时也担忧多用户可靠性、DBF/DBC 文件设计中的安全漏洞，以及长期维护问题。讨论进一步扩展到现代平台和低代码工具为何始终未能完全替代 FoxPro、Access、Delphi 和 VB 这类经典 RAD 环境，尤其是在小型定制业务应用场景中。

怀旧与历史背景

  • 许多评论者都是在 FoxPro/dBASE/FoxBase 中学会编程，或者在其中完成了自己的第一份有偿工作，时间通常是在 80 年代到 2000 年代之间。
  • 它被广泛用于小型企业应用（医疗办公室、电话营销、房地产、保险、图书馆、武术馆等）。
  • 人们回忆起自己能多快构建 CRUD 应用、UI、报表，以及这对非技术型企业带来的变革性影响。
  • 有几位将 FoxPro 时代的工具与 HyperCard 或经典 VB 相比，认为它们同样易上手且能赋能用户。

为什么 FoxPro 及类似工具很重要

  • FoxPro 将数据库引擎、SQL、语言、IDE、窗体设计器和报表编写器整合在一个包中。
  • 它非常适合基于文件、单用户或局域网的业务应用，入门门槛极低，生产力很高。
  • 一个反复出现的主题是：只要一个人具备领域知识和适度的编码技能，就能构建关键任务系统。

当前 FoxPro 的使用现状与迁移痛点

  • 一些组织仍在运行大型 FoxPro 代码库（数十万行），支撑着可观的收入。
  • 基于 DBF、通过网络共享运行的系统仍在生产环境中使用；人们提到损坏、锁定问题以及扩展限制。
  • 重写通常被视为高风险且昂贵；有些人正在使用 AI 辅助将其重写到现代技术栈。

Foxscript 项目与技术选择

  • 这个新项目被定位为一个 64 位、兼容 Visual FoxPro 的运行时，使用 Rust 和 WASM，并用 Electron 作为 IDE。
  • 目标包括移除 2GB 表/备忘录限制，在无需更改源代码的情况下保留现有 FoxPro 应用，以及在桌面和测试之间共享同一个 VM。
  • 作者指出，性能不如 I/O 和 UI 重要；原版 VFP 也只是解释器。

安全、架构以及 DBF/DBC 问题

  • 一个主要担忧是 FoxPro 的架构模型：数据库文件本质上只是共享文件，并没有真正的权限模型。
  • DBC 存储过程是纯文本，并且可以执行任意 FoxPro/Win32 代码；任何有文件写入权限的人都可以改变行为，绕过应用逻辑。
  • 有些人认为这是一种根本性的单层、客户端侧设计选择，而不是“bug”；但另一些人仍将其称为“不安全设计”或严重的危险陷阱。
  • 建议包括迁移到真正的客户端/服务器数据库（SQL Server、Postgres），或在新的运行时中加入完整性检查。

关于 AI “vibe-coded” 项目的争论

  • 许多人觉得该项目网站和一些评论“听起来像 AI 生成的”，并认为这种风格令人反感或过度炒作。
  • 他们担心的问题包括：对于非常年轻的项目却采用精致的营销包装、失败模式不明确，以及对关键数据的可信度。
  • 也有人反驳说，AI 辅助并不一定会否定代码本身，但同意审计、历史记录和测试很重要。

RAD 工具与现代替代品

  • 讨论大量延伸到桌面 RAD（FoxPro、VB6、Delphi、Access）的衰落，以及今天的 Web 技术栈和低代码工具。
  • 一些人感叹，至今仍没有真正面向非开发者、可跨平台替代 Access/FoxPro 的工具，尽管提到了 FileMaker、Lazarus、Gambas、Kivy、Power Apps 等替代品。
  • 讨论凸显了简单、单人开发工具与现代期望之间的张力：CI/CD、版本控制、安全性、多用户 Web 访问，以及跨平台 GUI。