LSP: el último gran avance del autocompletado antes de la IA

Hasta 2016, cada editor tenía que implementar el soporte de cada lenguaje a mano. Visual Studio sabía hacerlo bien para C# porque era de Microsoft. Pero si querías un Python decente en otro IDE, alguien tenía que escribir el soporte específico para ese editor. Multiplicabas editores por lenguajes y entendías por qué el autocompletado en Vim o en editores menores estaba años por detrás.

Ese año Microsoft soltó el Language Server Protocol junto con la primera versión de Visual Studio Code. La idea era romper esa multiplicación. Un solo servidor por lenguaje, un protocolo JSON estándar y cualquier editor compatible podía consumirlo. El editor preguntaba, el servidor respondía. Daba igual si el editor era VS Code, Vim, Emacs, Neovim o Sublime.

La industria lo adoptó. Pronto aparecieron servidores serios para todo lo que se movía. rust-analyzer para Rust. gopls para Go. pyright para Python. typescript-language-server para TypeScript. De repente, escribir Python en Vim era equivalente a escribirlo en un IDE pesado.

Por cierto, JetBrains nunca adoptó LSP en sus IDEs principales. Desde IntelliJ IDEA 1.0 (2001) construyeron su propio sistema interno, llamado PSI (Program Structure Interface), mucho más profundo que lo que LSP estandariza. Por eso el refactoring de IntelliJ y compañía sigue siendo el referente hoy. LSP democratizó el autocompletado decente para todos los editores. PSI siguió a otro nivel.

Era el último gran avance del autocompletado clásico antes de que los modelos estadísticos salieran de la academia.

---

Este post forma parte de la serie Evolución de la IA para programar.