现有编程环境有哪些需要改进的地方？
现有编程环境有哪些需要改进的地方？
事先声明，下面的文字，我没有使用 AI，而是我根据多年编程经验获得的知识。
有些商业上的痛点，大家看不到，不是因为笨，而是因为太聪明，忽略了很多关键问题。一旦一个人太聪明，他往往可以快速入门任何语言，且忽视其他入门者遇到的那些糟糕体验。既然忽略了各种体验，那么要“改进体验”，也就无从谈起。
所以，请保持愚钝。
先说存在的问题：
类型缺失
尽管在某些场合中包含类型信息，但在编译后、嵌入插件接口后，或传输到其他执行环境时，往往会丢失类型。这种丢失，会让很多工作的体验变得糟糕。
非结构化
代码往往是由一个巨大的字符串构成，编辑器经常需要重新解析整个文件，才能重新结构化，然后才能进一步处理。由于语言众多、配置格式众多，解析的难度和出错率也激增。IDEA 每次更新多半都是在解决这种问题，我印象中 Vue3 的完全支持，花了大约一年半时间。而且在代码修改的过程中，这种解析反复进行，非常消耗性能，大项目中尤其如此。
另外，一旦边界符号（比如花括号或者双引号）没有成对，则会出现错误，且往往现有环境不能自动修复这种错误。也就是说，非结构化产生很多报错，且耗费编程人员的大量时间，前端程序员对此应该有印象。
大量的编码和转码
这是由于如上第 2 点中的非结构化导致的，这些转码，不是为了解决用户的需求，而仅仅是浪费时间的技术补丁。
文档在代码视图下难以阅读
这是也由于如上第 2 点中的非结构化导致的，必须转码，而转码使得某些注释文档难以阅读。
边界不清晰
同样的，这也是非结构化带来的衍生问题，使得边界（比如花括号）需要用户自己维护，较为繁琐。
代码被各种配置环境隔离
很多代码被分割在 GitHub 的各种仓库中，这些仓库充斥着类型不完备的配置。而如果不运行这些仓库中的配置，则无法加载和运行我们所要的代码。更糟糕的是，即便能下载这些配置和代码，也不一定能在用户的环境中运行起来，有时候需要碰运气。
端与端的隔离
用户往往需要调用类似 GET 或 POST 等的接口，才能在两个端之间交互，增加了初学者控制多端的难度。而且在端与端之间，类型和逻辑也难以共享。
版本混乱隔离
这里不多做解释，见识过 node_modules 的庞大和不稳定的人，都能理解。尽管目前有一些解决方案，但都不完美。
补丁叠加补丁
现有编程环境的技术债较多，补丁上叠加了更多的补丁，使得维护成本增加，用户入门时所要学习的无用的补丁知识也越多。举个例子，HTML 的补丁是 CSS，而 CSS 的补丁是 LESS。当然，某些高级程序员太聪明，认为这是“专业的解决方案”，没有考虑到整个 Web 发展过程中遗留下来的问题。很多技术通常不是为了解决真正的需求，而仅仅是为了解决上一个补丁引发的问题，比如早期 html 在设计上的不完备，引发了后续的各种子语言的补丁，比如 css，比如 js、ts，这么多的语法迥异的补丁，往往会耗费初学者大量的时间和精力。
如何改进？
很多改进都是现成的，比如 Java 在某些方面做得不错，IDEA 在某些方面做得不错，而虚幻引擎的蓝图在某些方面也做得不错，一些低代码编辑器也做得挺好。但是，没有哪一款产品能把下面所列的措施都做全，所以仍然有很大的改进空间：
统一编程环境
表面上看，环境的统一，或者语言的统一，是不可能实现的。但只要接触过 LLVM IR（这门中间语言），就会知道，我们可以在某个中间层进行统一。尽管这一过程很艰难，但其带来的收益仍非常可观。比如苹果公司，就资助了 LLVM 项目，使得 Objective-C 的性能保持在较高水平，进而让 iPhone 的性能得到提高。长期以来，iPhone 在性能测试中（比如那个经典的测试流畅性的滑屏动作）的表现常常优于 Android，这主要就是苹果对 LLVM 的投资带来的正面效应。因此，既然我们要改进编程环境，那么就要在某个层面进行统一，从而获得广泛的语言兼容性和编译性能。目前看来，LLVM 是一个不错的中间层，可以兼容大量编程语言。
推行结构化
将代码从字符串形式，转变成基于二进制的树状结构或网状结构，这样做会带来一些好处：
a. 提升性能：不用反复解析，也不用全局解析，如果代码变动，仅需局部解析。
b. 提升可读性：结构化之后，可以加入个性化的装饰，这提高了可读性，但不影响代码的结构。
c. 提升可维护性：由于以上 a、b 两点，所以维护起来也更轻松。
d. 边界清晰：减少很多错误的发生。
e. 提升可扩展性：由于以上 a、b、c、d，所以扩展起来更容易。
任何情况下，都尽量保持类型不丢失
编译后的最上层函数体，保留其类型 ID，这样我们可以在任何情况下重新阅读和修改它。
ID 全球唯一，且可访问、可缓存
以前为了性能，往往取 8 位或 32 位的 ID，但长期来看，缺点多于优点。我们应该不限制 ID 的长度（甚至可以长过 IPv6）。当然，为了编译后的性能，可以让系统在编译时去掉非顶层 ID，只保留顶层 ID，就像第 3 点说的那样。
支持多种操作视图
由于用户的习惯有所不同，我们将采用多种编辑视图，用户可以在他习惯的视图之间自由切换，甚至可以定制他自己的视图。这些视图包括但不限于：节点式蓝图、Notion、传统代码视图（C 视图、Python 视图、C# 视图等）。
移除配置文件
配置文件提供的是动态性、灵活性。如果期望某种动态性，这可以由系统根据用户需求，动态编译某些局部。因为类型随时可以获取，所以自动编译是可能的。用户随时可以将新的“配置”以口头的形式告诉系统，由系统去处理剩下的事情，用户无需手动配置。如果非要手动配置，那么代码就是配置，代码本身也可以配置，要改配置，就直接改代码。
磨平端与端的沟壑
普通用户可以在一个屏幕中，远程控制任意端，系统自动维护各个端之间的信息传递。当然，如果是高级程序员，他当然也可以接触到最底层的接口。
其实还有很多边边角角的设计可以列出来，比如：如何整合 AI，但限于篇幅，这里不多讲，后面再找时间来分析。
感谢阅读。