Las reglas de programación de Rob Pike (1989)

• Un artículo sobre las 5 reglas de programación de Rob Pike de 1989
• Regla 1: no asumas dónde pasará la mayor parte del tiempo un programa; los cuellos de botella pueden aparecer de forma inesperada. Evita los hacks de velocidad hasta que se demuestre que existe un cuello de botella.
• Regla 2: siempre mide antes de ajustar por velocidad. Optimiza solo cuando una parte del código tenga un impacto significativo en el resto.
• Regla 3: los algoritmos complejos son lentos cuando n es pequeño. Ese es el caso la mayoría de las veces. Usa algoritmos complejos solo cuando n sea grande con frecuencia, y aun así aplica primero la regla 2.
• Regla 4: los algoritmos simples y las estructuras de datos simples son deseables. Son menos propensos a errores y más fáciles de implementar que las cosas complejas.
• Regla 5: la estructura de datos correcta es decisiva en la programación. Si los datos están bien organizados, el algoritmo se volverá evidente.
• Las reglas 1 y 2 de Pike reflejan el aforismo de Tony Hoare: "la optimización prematura es la raíz de todos los males".
• Ken Thompson reformuló las reglas 3 y 4 de Pike como: "cuando tengas dudas, usa la fuerza bruta".
• Las reglas 3 y 4 encarnan la filosofía de diseño KISS (Keep It Simple, Stupid).
• La regla 5 coincide con una afirmación de Fred Brooks en 'The Mythical Man-Month', a menudo abreviada como: "escribe código tonto que use objetos inteligentes".

[GN⁺]

Opiniones en Hacker News

• Artículo sobre las reglas de programación de Rob Pike de 1989
• Los comentaristas coinciden en que la esencia de la programación son las estructuras de datos, no los algoritmos
• Críticas a que las entrevistas de LeetCode no se enfoquen en estructuras de datos más que en algoritmos
• Se argumenta que los algoritmos complejos son lentos cuando n es pequeño, y que en la mayoría de los casos n es pequeño
• Los comentaristas enfatizan la importancia de elegir estructuras de datos adecuadas y de mantener todo bien organizado
• Debate sobre el mal uso de las bases de datos y el impacto negativo de los esquemas de BD generados por ORM
• Las directrices parecen una estrategia para evitar la sobreingeniería y la optimización prematura
• Algunos comentaristas sostienen que pequeños desperdicios de rendimiento pueden acumularse y volver lento un programa
• Debate sobre la cita "la optimización prematura es la raíz de todos los males" y su contexto
• Algunos comentaristas afirman que los buenos programadores pueden prever qué se volverá lento y hacer apuestas instructivas por adelantado
• Contraargumento de que algoritmos complejos para datos simples pueden traer grandes mejoras de rendimiento e incluso simplificar las cosas
• El artículo sigue influyendo en la manera en que algunos lectores abordan el diseño y la complejidad
• Debate sobre la interpretación de la regla 5, con cierto desacuerdo sobre la frase "escribe código tonto que use objetos inteligentes"