Qué ha funcionado en Ciencias de la Computación: 1999 vs. 2015 (2015)

Lenguajes heredados y específicos de la industria

• Muchos sistemas críticos dependen de tecnología “vieja” o de nicho: Erlang (telecomunicaciones), COBOL (banca), MATLAB/FORTRAN (científico), MUMPS (salud).
• La discusión pregunta qué se puede aprender de por qué esos lenguajes tienen éxito y siguen arraigados.
• Una visión: la adopción y evolución de los lenguajes se parece a la de las lenguas habladas: impulsada más por fuerzas sociales e históricas que por el mérito técnico.

Sistemas de tipos sofisticados y TypeScript

• Se elogia TypeScript por haber “realizado” la tipificación fuerte para la mayoría de la programación web, especialmente para quienes no tienen formación formal en CS.
• Otros sostienen que sistemas de tipos similares o más fuertes ya existían décadas antes; el principal logro de TS es llevarlos a la mayor base de practicantes.
• Debate sobre cuán “sofisticado” es realmente TS comparado con Java/C#/Checker Framework:
  • A favor: tipos estructurales, uniones, tipos mapeados, inferencia rica, bibliotecas potentes (p. ej., SQL a nivel de tipos).
  • En contra: toma mucho prestado de Java/C#, carece de una especificación formal y puede comportarse de formas sorprendentes.

Tipado estático en lenguajes dinámicos

• Python y JavaScript están ganando tipado opcional; herramientas y guías de estilo lo están volviendo semimandatorio en los equipos.
• Algunos temen que el tipado obligatorio traicionaría el propósito de Python, y predicen un fork o un nuevo lenguaje sin tipado.
• Otros dicen que “obligatorio” en la práctica sigue permitiendo salidas (Any, casts), lo que lo hace menos doloroso que los lenguajes totalmente estáticos.
• Se valoran los tipos por el soporte del editor, la incorporación a bases de código grandes y la coordinación del equipo, pese a la fricción adicional.

RISC, CISC y conjuntos de instrucciones

• Fuerte hilo que retoma el “RISC = No” del artículo:
  • Muchos ven ahora el dominio móvil de ARM y los M-series de Apple como evidencia de que RISC es un “Sí” o al menos un “Quizá”.
  • Contraargumento: la verdadera división es x86 frente a no‑x86; ARM y x86 modernos dependen mucho de micro‑operaciones y difuminan las líneas RISC/CISC.
• Algunos enfatizan que las instrucciones de ancho fijo de ARM permiten una decodificación muy ancha y eficiente, lo que contribuye a su alto rendimiento por vatio.
• Otros sostienen que RISC importaba originalmente cuando los presupuestos de transistores eran ajustados; hoy podemos permitirnos ISAs complejas y tuberías profundas.
• RISC‑V se cita como un éxito principalmente por su apertura y no por su “RISC‑ness” en sí, aunque los núcleos RISC‑V pequeños ni siquiera usan micro‑operaciones.
• La discusión se adentra en comparaciones históricas (R2000 vs 80386), tuberías vs velocidad de reloj, nodos de proceso y microcódigo, sin un consenso único.

Capacidades y seguridad

• Se aclara que “capacidades” significa seguridad basada en capacidades (tokens no falsificables que conceden derechos específicos, por ejemplo, descriptores de archivo).
• Los diálogos de permisos en apps móviles están vagamente relacionados, pero en su mayoría implementan permisos semiestáticos basados en identidad, no sistemas de capacidades completos.
• Las capacidades se consideran elegantes, pero rara vez se usan como única base de la seguridad del mundo real; aparecen sobre todo dentro de sandboxes y código de bajo nivel del SO.

Programación funcional vs “estilo funcional”

• Muchos ven la “FP pura” como un “No” práctico, pero las ideas FP (lambdas, pattern matching, sum types, APIs de orden superior) como cada vez más comunes.
• Punto de vista 1: los lenguajes híbridos (Java/C#/JS con características FP) ofrecen la mayoría de los beneficios de FP manteniéndose imperativos/OO.
• Punto de vista 2: esos híbridos son subóptimos; la FP verdadera necesita más que lambdas: por ejemplo, orientación a expresiones, inmutabilidad por defecto, estructuras de datos persistentes y gestión explícita de efectos.
• Debate en curso sobre qué define la FP:
  • Algunos dicen que las funciones de primera clase bastan.
  • Otros insisten en condiciones más fuertes como transparencia referencial y manejo estructurado de efectos (mónadas o sistemas de efectos alternativos).
• Aclaración de que los “records” en sí no son inherentemente funcionales; preceden a la POO y existen en muchos paradigmas.
• Deriva aparte sobre qué hace que algo sea “orientado a objetos”, sin acuerdo; algunos ven los records en Java como anti‑OO porque minimizan el estado y comportamiento ocultos.

Paralelismo, GPUs y Rust

• Se pregunta si las GPUs/TPUs “cuentan” como paralelismo para la clasificación del artículo.
  • Una postura: implementan el modelo de “el mago en una caja”: kernels paralelos escritos por expertos, no programación paralela de propósito general.
  • Otra: casi todas las apps GUI/web usan paralelismo de GPU de forma implícita, y además map-reduce y SIMD son donde realmente funciona el paralelismo.
• Se propone Rust como algo que podría cambiar el panorama del paralelismo, con su sistema de propiedad/borrow aportando fuertes garantías de seguridad en hilos además de seguridad de memoria.

Redes neuronales y cambios en las evaluaciones

• Algunos sugieren que el estado de las NN sería “Sí” para 2024, señalando los grandes trabajos de deep learning alrededor de 2014–2015.
• Otros subrayan que las redes neuronales han tenido varias fases de auge desde los años 60; 2015 fue un resurgimiento construido sobre décadas de trabajo previo.

Meta: actualizar “What’s Worked” para 2024

• Varios comentaristas quieren una tabla actualizada:
  • RISC pasó de “No” (2015) a al menos “Quizá”.
  • Los sistemas de tipos sofisticados son más prominentes (Rust, TS avanzado), y podrían haber pasado de “No” a “Quizá/Sí”.
  • Las ideas funcionales ahora son características “esperadas” en muchos lenguajes principales.
• Existe cautela general de que cualquier clasificación sí/quizá/no envejece rápidamente y no debe tratarse como verdad intemporal.