主要观点：

• 肯定 LSP 的重要性和成就，如存在广泛、功能较全、工作良好等，但也指出存在诸多问题。
• 重点讨论 LSP 的架构和设计，而非功能特性。
• 强调对 LSP 持批判态度是基于对其发展的期望，而非否定其价值。

关键信息和重要细节：

• 重要成就：

  • 为各种编辑器提供 IDE 工具，降低工具开发成本，改变开源编辑器对编程语言支持不佳的状况。

• 设计特点：

  • 注重呈现而非语义：选择聚焦于编辑器中实际出现的内容，虽存在一些语义元素混入，但总体方向较好。
  • 向后兼容：微软主导的 LSP 一直遵循严格的向后兼容原则，虽偶有处理不当情况，但总体对用户友好。
  • 机器可读的类型规范：有机器可读的 LSP 类型和方法规范，虽格式怪异但对维护库和消除类型 JSON 序列化相关的错误有很大帮助。
  • 动态注册：虽实现较乱，但在支持运行时配置更改和服务器能力动态变化方面有其合理性。

• 存在问题：

  • 非真正开放项目：LSP 规范由微软员工 Dirk Bäumer 主导，外部贡献者参与度低，缺乏开放性讨论和扩展协议的论坛，不利于项目发展。
  • 未考虑并发：规范对并发处理态度消极，未充分考虑并发对协议的影响，如请求取消和进度跟踪等方面。
  • 缺失因果关系：在处理失败和异步处理时，无法确定事件的顺序，导致客户端无法确定获取的结果是否最新，这是一个普遍问题。

  • 状态同步问题：

    • 不同功能的状态同步实现不一致，功能集也不一致，需要多种方法且依赖跟踪不完善。
    • 可以考虑有一个通用的状态同步协议作为 LSP 的一部分，以解决这些问题。

  • 其他问题：

    • 规范庞大，难以理解和实现，且存在类型定义奇怪、不精确和不一致、配置模型混乱、文本编码选择不当、交互模型简单等问题。
    • JSON-RPC 作为传输层存在一些问题，如引发因果性丢失和字段省略等问题。
    • 不认为需要一个大的 LSP 2.0，更希望 LSP 转变为真正开放的模式。

总结：LSP 在提供 IDE 工具方面取得了重大成就，但在架构和设计上存在诸多问题，需要在开放性、并发处理、状态同步等方面进行改进和完善。