Functional programming en TypeScript: las abstracciones que realmente uso y las que abandoné
Hay un momento específico que reconozco en casi todo developer que llega a TypeScript desde un background de lenguajes tipados: abrís la documentación de fp-ts, ves pipe, Option, TaskEither, ReaderTaskEither y pensás "esto es lo que me faltaba". El type checker te respalda. La API es hermosa. La teoría es sólida.
Tres semanas después, el PR tiene 800 líneas de cambio y un comentario de un compañero que dice: "¿qué hace fold acá?".
Mi tesis es esta: los patrones funcionales tienen valor real en TypeScript, pero la adopción total de fp-ts tiene un costo de onboarding que casi nadie menciona cuando evangeliza la librería. El criterio que terminé usando —después de evaluar la adopción completa y descartarla— es: adoptá los patrones, no la librería, salvo que el equipo entero esté alineado y dispuesto a sostenerlo.
No soy anti-FP. Uso pipe, tengo un Result type casero y pienso en funciones puras cuando puedo. Pero hay una diferencia entre escribir código funcional y adoptar un framework de categorías matemáticas en un proyecto colaborativo.
