Cita de Torvalds sobre buen programador [cerrado]

238

Accidentalmente me topé con la siguiente cita de Linus Torvalds:

"Los malos programadores se preocupan por el código. Los buenos programadores se preocupan por las estructuras de datos y sus relaciones".

Lo he pensado durante los últimos días y todavía estoy confundido (lo que probablemente no sea una buena señal), por lo tanto, quería discutir lo siguiente:

  • ¿Qué interpretación de esto es posible / tiene sentido?
  • ¿Qué se puede aplicar / aprender de él?
beyeran
fuente
18
Creo que esta pregunta probablemente tiene múltiples respuestas que son igualmente válidas. Pero es una buena pregunta de todos modos. Me encanta esa cita Expresa por qué no entiendo a los programadores que se preocupan por cambiar de idioma. Raramente es el lenguaje lo que importa en un programa, son las estructuras de datos y cómo se relacionan.
Ryan Kinal
55
¿Quizás si se toma el tiempo de hacer que las estructuras de datos sean "elegantes", entonces el código no tiene que ser complicado para lidiar con estas estructuras de datos? Probablemente soy demasiado tonto para saber realmente el significado de la cita de Torvalds. :}
programador
3
@RyanKinal Pero, por supuesto, el lenguaje sí importa , porque hace que sea mucho más fácil tratar y pensar en ciertas estructuras de datos. Piense en todos los idiomas que se especializan en LISt Parsing, por ejemplo, o en los idiomas que tienen soporte nativo para estructuras de datos que deben ser pirateadas en otros idiomas (se me ocurren conjuntos y matrices dispersas).
kojiro
83
Torvalds no está solo en esto, por cierto: "Muéstrame tu diagrama de flujo y oculta tus tablas, y seguiré desconcertado. Muéstrame tus tablas, y generalmente no necesitaré tu diagrama de flujo; será obvio. " - Fred Brooks, El mes mítico del hombre. "Muéstrame tu código y oculta tus estructuras de datos, y seguiré desconcertado. Muéstrame tus estructuras de datos, y generalmente no necesitaré tu código; será obvio". y "Las estructuras de datos inteligentes y el código tonto funcionan mucho mejor que al revés". - Eric S. Raymond, La Catedral y El Bazar.
Jörg W Mittag
44
Esto explica por qué el kernel de Linux es un desastre :)
l1x

Respuestas:

326

Podría ser útil considerar lo que dijo Torvalds justo antes de eso:

git en realidad tiene un diseño simple, con estructuras de datos estables y razonablemente bien documentadas. De hecho, soy un gran defensor del diseño de su código en torno a los datos, en lugar de al revés, y creo que es una de las razones por las que git ha tenido bastante éxito [...]. De hecho, afirmaré que la diferencia entre un mal programador y uno bueno es si considera que su código o sus estructuras de datos son más importantes.

Lo que está diciendo es que las buenas estructuras de datos hacen que el código sea muy fácil de diseñar y mantener, mientras que el mejor código no puede compensar las estructuras de datos deficientes.

Si se está preguntando sobre el ejemplo de git, muchos sistemas de control de versiones cambian su formato de datos con relativa regularidad para admitir nuevas funciones. Cuando actualiza para obtener la nueva función, a menudo también tiene que ejecutar algún tipo de herramienta para convertir la base de datos.

Por ejemplo, cuando DVCS se hizo popular por primera vez, mucha gente no podía entender qué pasaba con el modelo distribuido, las fusiones eran mucho más limpias que el control de versiones centralizado. La respuesta es absolutamente nada, excepto que las estructuras de datos distribuidos tenían que ser mucho mejores para tener la esperanza de funcionar. Creo que los algoritmos de fusión centralizados se han puesto al día desde entonces, pero tomó bastante tiempo porque sus viejas estructuras de datos limitaban los tipos de algoritmos que podían usar, y las nuevas estructuras de datos rompieron una gran cantidad de código existente.

Por el contrario, a pesar de una explosión de características en git, sus estructuras de datos subyacentes apenas han cambiado. Preocúpese primero por las estructuras de datos, y su código será naturalmente más limpio.

Karl Bielefeldt
fuente
25
el mejor código no puede compensar las estructuras de datos pobres y la buena salsa es así
Conrad Frix
55
Está hablando desde el punto de vista de los programadores que hacen cambios para git. El punto de vista del usuario final es completamente ortogonal a esta discusión, aparte del código fácil de mantener que genera menos errores y adiciones de funciones más rápidas.
Karl Bielefeldt
2
@James: Está diciendo que el software es mejor (por lo tanto, más fácil de usar y utilizado por más personas) porque las estructuras de datos son mejores. Por supuesto, no necesita saber sobre las estructuras de datos del software que usa, pero sí se preocupa por ellas, indirectamente, incluso si no se da cuenta, porque las estructuras de datos son las que impulsan las cosas que sí comprende. preocuparse.
ruakh
1
+1. Esta respuesta pone el contexto en una declaración que de otro modo podría interpretarse como algo muy diferente. Cualquiera que haya leído una monstruosidad de 5000 líneas de un archivo sabe exactamente lo que quiero decir.
Riwalk
20
"Preocúpese primero por las estructuras de datos, y su código será naturalmente más limpio": El estadista romano Cato ( en.wikipedia.org/wiki/Cato_the_Elder ) solía decir "Rem tene, verba sequentur" = "Tenga claro el argumento en tu mente, las palabras seguirán naturalmente ". Lo mismo con la programación: entienda las estructuras de datos y el diseño primero, el código real seguirá solo.
Giorgio
60

Algoritmos + Estructuras de datos = Programas

El código es solo la forma de expresar los algoritmos y las estructuras de datos.

revs zxcdw
fuente
Última edición ethoberon.ethz.ch/WirthPubl/AD.pdf
dchest el
Esto es cierto para la programación de procedimientos; en OOP es un poco diferente.
m3th0dman
3
No es fundamentalmente ningún diferente. Tienes datos y haces un conjunto de operaciones sobre ellos. Miembros variables y métodos. Exactamente lo mismo. Toda la esencia de la informática desde los años 50 se ha construido sobre esa regla muy simple de que los programas consisten en algoritmos que modifican las estructuras de datos, y se mantiene vigente 60 años después. También podría considerar los programas como funciones . Toman entrada en la que operan para producir salida . Exactamente como lo hacen las funciones matemáticas.
zxcdw
31

Esta cita es muy familiar para una de las reglas en "The Art of Unix Programming", que es el fuerte de Torvalds para ser el creador de Linux. El libro se encuentra en línea aquí.

Del libro está la siguiente cita que expone lo que dice Torvalds.

Regla de representación: Doble el conocimiento en datos para que la lógica del programa pueda ser estúpida y sólida.

Incluso la lógica de procedimiento más simple es difícil de verificar para los humanos, pero las estructuras de datos bastante complejas son bastante fáciles de modelar y razonar. Para ver esto, compare la expresividad y el poder explicativo de un diagrama de (digamos) un árbol de puntero de cincuenta nodos con un diagrama de flujo de un programa de cincuenta líneas. O compare un inicializador de matriz que exprese una tabla de conversión con una instrucción de cambio equivalente. La diferencia en transparencia y claridad es dramática. Ver la Regla 5 de Rob Pike.

Los datos son más manejables que la lógica del programa. De esto se deduce que cuando vea una opción entre la complejidad en las estructuras de datos y la complejidad en el código, elija el primero. Más: al desarrollar un diseño, debe buscar activamente formas de cambiar la complejidad del código a los datos.

La comunidad de Unix no originó esta idea, pero una gran cantidad de código de Unix muestra su influencia. La facilidad del lenguaje C para manipular punteros, en particular, ha alentado el uso de estructuras de referencia modificadas dinámicamente en todos los niveles de codificación desde el núcleo hacia arriba. Las persecuciones de puntero simples en tales estructuras con frecuencia cumplen funciones que las implementaciones en otros idiomas tendrían que incorporar en procedimientos más elaborados.

Jay Atkinson
fuente
¡También me acordé de esto!
Jesvin Jose
1
OTOH, mira cualquier pregunta sobre StackOverflow int**. Eso debería convencerlo de que los datos de hecho NO son obvios; solo se vuelve así al atribuir significado a los datos. Y ese significado está en el código.
MSalters
29

El código es fácil, la lógica detrás del código es compleja.

Si está preocupado por el código, eso significa que aún no comprende los conceptos básicos y es probable que se pierda en el complejo (es decir, las estructuras de datos y sus relaciones).

imbéciles
fuente
17
Je, me pregunto si la próxima generación de programadores preguntará: "Una vez que los imbéciles dijeron Code is easy, it's the logic behind the code that is complex, ¿qué quiso decir?"
Yannis
36
@YannisRizos Eso será especialmente confuso cuando la gente no esté segura de si fue dicho por personas que eran imbéciles o una sola persona con el nombre de imbéciles.
KChaloux
14

Para ampliar un poco la respuesta de Morons , la idea es que comprender los detalles del código (sintaxis y, en menor medida, estructura / diseño) es lo suficientemente fácil como para construir herramientas que puedan hacerlo. Los compiladores pueden comprender todo lo que se necesita saber sobre el código para convertirlo en un programa / biblioteca en funcionamiento. Pero un compilador en realidad no puede resolver los problemas que hacen los programadores.

Podría llevar el argumento un paso más allá y decir "pero tenemos programas que generan código", pero el código que genera se basa en algún tipo de entrada que casi siempre se construye a mano.

Entonces, sea cual sea la ruta que tome para llegar al código: ya sea a través de algún tipo de configuración u otra entrada que luego produce código a través de una herramienta o si lo está escribiendo desde cero, no es el código lo que importa. Lo que importa es el pensamiento crítico de todas las piezas que se requieren para llegar a ese código. En el mundo de Linus, eso es en gran medida estructuras y relaciones de datos, aunque en otros dominios puede ser otras piezas. Pero en este contexto, Linus solo dice "No me importa si puedes escribir código, me importa que puedas entender las cosas que resolverán los problemas con los que estoy lidiando".

Daniel DiPaolo
fuente
Todo programador usa programas que generan código. A menudo se les llama "compiladores", a veces en combinación con "vinculadores". Toman una entrada (relativamente) legible y escribible por humanos, que generalmente se proporciona (pero no siempre) en algún tipo de formato de texto, y la convierten en datos que la computadora puede entender como instrucciones y ejecutar.
un CVn
13

Linus significa esto:

Muéstrame tus diagramas de flujo [código], y oculta tus tablas [esquema], y seguiré desconcertado; muéstrame tus tablas [esquema] y generalmente no necesitaré tus diagramas de flujo [código]: serán obvios.

- Fred Brooks, "El mes del hombre mítico", cap. 9.

Daniel Shawcross Wilkerson
fuente
12

Creo que está diciendo que el diseño general de alto nivel (estructuras de datos y sus relaciones) es mucho más importante que los detalles de implementación (código). Creo que valora a los programadores que pueden diseñar un sistema sobre aquellos que solo pueden centrarse en los detalles de un sistema.

Ambos son importantes, pero estaría de acuerdo en que, en general, es mucho mejor obtener una visión general y tener problemas con los detalles que al revés. Esto está estrechamente relacionado con lo que estaba tratando de expresar acerca de dividir las funciones grandes en pequeñas .

GlenPeterson
fuente
+1: Estoy de acuerdo contigo. Otro aspecto es que a menudo los programadores están más preocupados por la característica de lenguaje genial que van a usar, en lugar de centrarse en sus estructuras de datos y algoritmos y en cómo escribirlos de una manera simple y clara.
Giorgio
Yo tambien estoy de acuerdo. El hecho es que es fácil cambiar piezas de código aisladas, pero es más difícil cambiar las estructuras de datos o las interfaces entre piezas de código (ya que estos tipos de cambios pueden afectar muchas cosas en lugar de una sola).
Brendan
5

Bueno, no puedo estar completamente de acuerdo, porque tienes que preocuparte por todo. Y para el caso, una de las cosas que me encantan de la programación son los cambios a través de diferentes niveles de abstracción y tamaño que saltan rápidamente de pensar en nanosegundos a pensar en meses, y viceversa.

Sin embargo, las cosas superiores son más importantes.

Si tengo una falla en un par de líneas de problemas que causa un comportamiento incorrecto, probablemente no sea demasiado difícil de solucionar. Si está causando un bajo rendimiento, probablemente ni siquiera importe.

Si tengo una falla en la elección de la estructura de datos en un subsistema, que causa un comportamiento incorrecto, es un problema mucho más grande y más difícil de solucionar. Si está causando un bajo rendimiento, podría ser bastante grave o soportable, aún apreciablemente menos bueno que un enfoque rival.

Si tengo una falla en la relación entre las estructuras de datos más importantes en una aplicación, que causa un comportamiento incorrecto, tengo un rediseño masivo frente a mí. Si está causando un bajo rendimiento, podría ser tan malo que casi sería mejor si se comportara mal.

Y será lo que dificulte la búsqueda de esos problemas de nivel inferior (solucionar errores de bajo nivel normalmente es fácil, encontrarlos puede ser difícil).

Las cosas de bajo nivel son importantes, y su importancia restante a menudo se subestima seriamente, pero palidece en comparación con las cosas grandes.

Jon Hanna
fuente
2

Alguien que conoce el código ve los "árboles". Pero alguien que entiende las estructuras de datos ve el "bosque". Por lo tanto, un buen programador se centrará más en las estructuras de datos que en el código.

Tom Au
fuente
2
Pero centrarse en el bosque o en los árboles con exclusión del otro puede ser perjudicial, por lo que no creo que esta analogía encaje.
kojiro
1
@kojiro: en la expresión no puede ver el bosque por los árboles , se supone que alguien que puede ver el bosque también verá los árboles (ver en.wiktionary.org/wiki/see_the_forest_for_the_trees ). Por lo tanto, creo que es una buena analogía aquí.
Treb
2

Saber cómo fluirán los datos es muy importante. Conocer el flujo requiere que diseñe buenas estructuras de datos.

Si retrocede veinte años, este fue uno de los grandes puntos de venta para el enfoque orientado a objetos utilizando SmallTalk, C ++ o Java. El gran argumento, al menos con C ++ porque eso fue lo que aprendí primero, fue diseñar la clase y los métodos, y luego todo lo demás caería en su lugar.

Indudablemente, Linus estaba hablando en términos más amplios, pero las estructuras de datos mal diseñadas a menudo requieren una revisión adicional del código, lo que también puede generar otros problemas.

octopusgrabbus
fuente
2

¿Qué se puede aplicar / aprender de él?

Si puedo, mi experiencia en las últimas semanas. Las discusiones anteriores aclararon la respuesta a mi pregunta: "¿qué aprendí?"

Reescribí un código y reflexioné sobre los resultados que seguía viendo y diciendo "estructura, estructura ..." es la razón por la cual hubo una diferencia tan dramática. Ahora veo que fue la estructura de datos la que marcó la diferencia. Y me refiero a todo .

  • Al probar mi entrega original, el analista de negocios me dijo que no estaba funcionando. Dijimos "agregar 30 días" pero lo que queríamos decir era "agregar un mes" (el día en la fecha resultante no cambia). Agregue años, meses y días discretos; No 540 días durante 18 meses, por ejemplo.

  • La solución: en la estructura de datos, reemplace un entero entero con una clase que contenga múltiples enteros, el cambio a su construcción se limitó a un método. Cambie las declaraciones aritméticas de la fecha real, las 2 de ellas.

La recompensa

  • La nueva implementación tenía más funcionalidad, pero el código del algoritmo era más corto y claramente más simple.

En la fijación del comportamiento del código / resultados:

  • Cambié la estructura de datos, no el algoritmo.
  • NO se tocó la lógica de control en ningún lugar del código.
  • No se cambió la API.
  • La clase de fábrica de estructura de datos no cambió en absoluto.
radarbob
fuente
1

Me gusta imaginar un equipo muy inteligente de bibliotecarios en una biblioteca bellamente hecha con un millón de libros al azar y brillantes, sería una locura.

Tudor Watson
fuente
1

No puedo estar más de acuerdo con Linus. Centrarse en los datos ayuda a destilar en gran medida una solución simple y flexible para un problema dado. Git en sí mismo es un ejemplo de prueba: dado que hay tantas funciones compatibles en los años de desarrollo, la estructura de datos central permanece en gran medida sin cambios. Eso es magia! --2c

mc2
fuente
0

He visto que esto es numerosas áreas.

Piense en el análisis comercial ... Supongamos que está analizando la mejor manera de apoyar el marketing en una empresa de productos de consumo como Colgate. Si comienza con ventanas sofisticadas o la última tecnología, no ayudará a la empresa casi tanto como si piensa primero en las necesidades de datos de la empresa y luego se preocupa por la presentación posterior. El modelo de datos dura más que el software de presentación.

Considera hacer una página web. Es mucho mejor pensar primero en lo que quiere mostrar (el HTML) y preocuparse por el estilo (CSS) y las secuencias de comandos (elija su herramienta) después.

Esto no quiere decir que la codificación no sea importante también. Necesita habilidades de programación para obtener lo que necesita al final. Es que los datos son la base. Un modelo de datos deficiente refleja un modelo de negocio demasiado complejo o poco pensado.

MathAttack
fuente
0

Me encuentro escribiendo nuevas funciones y actualizando las existentes con mucha más frecuencia que tener que agregar nuevas columnas o tablas a mi esquema de base de datos. Esto probablemente sea cierto para todos los sistemas bien diseñados. Si necesita cambiar su esquema cada vez que necesita cambiar su código, es una clara señal de que es un desarrollador muy malo.

Indicador de calidad del código = [cambios en el código] / [cambios en el esquema de la base de datos]

"Muéstrame tus diagramas de flujo y oculta tus tablas, y seguiré desconcertado. Muéstrame tus tablas, y generalmente no necesitaré tus diagramas de flujo; serán obvios". (Fred Brooks)

Joel Jacobson
fuente
-2

Parece que esta idea tiene varias interpretaciones en los distintos tipos de programación. Es cierto para el desarrollo de sistemas y también es cierto para el desarrollo empresarial. Por ejemplo, uno podría argumentar que el cambio brusco en el enfoque hacia el dominio en el diseño impulsado por el dominio es muy similar al enfoque en las estructuras y relaciones de datos.

eulerfx
fuente
-4

Aquí está mi interpretación: usa código para crear estructuras de datos, por lo que el enfoque debe estar en lo último. Es como construir un puente: debe diseñar una estructura sólida en lugar de una que parezca atractiva. Sucede que las estructuras de datos bien escritas y los puentes se ven bien como resultado de sus diseños eficientes.

Mover
fuente