RE: [escepticos] El código abierto

Sab Oct 17 10:13:26 WEST 2009

Saludos! Ayer estuve desconectado y hoy de milagro.

Simplemente para aclarar, las frases "el código es conocimiento" o "el código no es conocimiento" condensan en 4 y 5 palabras muchas cosas, y luego se obtienen muchas interpretaciones.

Cuando digo que "el código no es conocimiento", no quiero decir tanto que contiene "0" conocimiento, sino que no es la forma idónea de obtenerlo (como creo que más o menos todos estamos de acuerdo).

Decir que evidentemente estoy hablando de código INDOCUMENTADO.  Separo código de documentación. Hablar de código documentado es en el fondo imposible, ya que no se puede evaluar "el código documentado" en genérico y decir algo de él, sino sólo de "éste código documentado" o "aquel código documentado".  Evidentemente, hay conjuntos código - documentación completísimos y que sin duda lo considero transmisor adecuado de conocimiento.  

En cambio, sí que pienso que, en este contexto, se puede hablar del código en genérico: por bueno que sea, siempre será una solución parcial.

Tampoco hablo de los códigos de ejemplo en libros.  No deja de ser código ultra documentado ;) 

Mi "filosofada" va más bien en dirección al código en sí.  Código puro y duro, quizás levemente comentado, pero que pretendamos sacar la información directamente de las instrucciones.  Una especie de "reduccionismo" en el código.  Para nosotros, los programadores, creo que es bastante evidente que si bien se puede alegar "es conocimiento porque algo hay", es una forma tan poco óptima de transmitirlo que (al menos yo) no lo considero.  Pero... para la gente que no es programadora o lo vive perifericamente, ¿es tan evidente?. ¿Cómo interpretan gente no técnica, o chavales que ahora empiezan, o jefes que hace demasiado tiempo que dejaron de programar o programaron demasiado poco la "exaltación" del código?.

Cuando gente periférica o ajena totalmente al mundo del software oye cosas como "el código es conocimiento" llega a ciertas interpretaciones que a mí al menos me han hecho pasar momentos jodidos (también de risas).  Por ello, la "exaltación" del código habría que matizarla para que sobre todo la gente no programadora tomara conciencia (que a veces es quien nos manda).  Unos ejemplos totalmente reales:

- En una entrevista de trabajo, cuando pregunté de qué forma documentaban el código, me respondieron "no lo hacemos: el buen código se documenta a sí mismo".  

- En otro, tenía que hacer una versión para Windows de una aplicación de otro sistema antiguo en Unix.  Una persona me explicó amablemente en un par de horas la aplicación (que era bastante grande) para situarme, me dejaron el código (totalmente indocumentado) delante y se fué.  Cuando me levanté por tercera vez a preguntar cosas específicas de la aplicación ya me miraban mal ("mírate el código, ahí está").  Al final hice lo que me dió la gana y me fuí.

- En otro más pasó similar: teníamos que hacer una aplicación de diseño de interiores.  Me pasaron sólo el código (indocumentado también, pa qué si en el código "está el conocimiento").  Cuando les preguntaba cosas de su stock de azulejos, de materiales y de las particularidades de su negocio me dijeron "¿coño, pero tu no eras programador? ¿ahí tienes el código, no?"

- Esta es consecuencia de creerse a pies juntillas el efecto que, siguiendo el ejemplo de Blender, sería "aprendes del Blender -> el Blender va de gráficos -> ahí tienes todo lo necesario para saber de gráficos".  En un trabajo presionaron a mi jefe para que tuviera un sistema gráfico nuevo para una fecha muy cercana.  Ni corto ni perezoso compraron por un pastón una librería gráfica desconocida y específica.  Una vez comprada, me la enchufó porque "como yo ya sabía de DirectX, etc... sabría de esa librería".  Cuando después de días y días de pringar por su idiotez, le expliqué que "saber de tal o cual librería no implica saber de las otras, y que se necesita de un tiempo de aprendizaje" me dijo "eso del tiempo para aprender era un lujo que no siempre tendría".

Hay más, pero van en la línea

Es decir: seguro que aquí todos estaremos de acuerdo en la utilidad práctica de tener código.  El código libre (acompañado de documentación) va muy bien, pero le exaltación más allá de un punto del código hace que personas (generalmente no técnicas) se les vaya la olla.  Es mi experiencia.  Por ello, por los dolores de cabeza que he tenido, por las consideraciones anteriores, prefiero condensar todo esto en la, también imperfecta frase "el código no es conocimiento".  

Aparte, estaría el tema de hasta que punto está bien documentado, de si he entendido realmente la documentación, de si la documentación está perfectamente estructurada, de si hay un método único de estructurar la información que sirva para todo o de si el que la ha escrito ha transmitido exáctamente lo que quería transmitir... Pero eso ya me imagino que no es problema exclusivo del código y del software... :)

Total: que ante un comercial de aluminios, el resultado es "que si quieres que sepa los tipos de marcos de ventana que hay..., mejor me los explicas y no esperes que lo deduzca (tarde y seguramente mal) de un código indocumentado"

Por ahi van mis ideas... :)

________________________________

De: escepticos-bounces en dis.ulpgc.es en nombre de José Á. Morente
Enviado el: jue 15/10/2009 20:11
Para: Lista Escépticos
Asunto: Re: [escepticos] El código abierto

2009/10/15 Adria Comos <AdriaComos en dorna.com>:
> Contesto y me voy ya, que vaya tela! :)
>
> Una cosa es reinventar la rueda...y otra intentar mejorarla!  Evidentemente, cuando hay prisa hay prisa, pero como práctica general no creo que sea tan bueno.
>
> Por otro lado, si quiero entender como funciona un renderizador, sin duda, "Computer Graphics: Principles and Practice" del Foley y van Dam o similares.  El motor del Blender seguro está muy bien y es genial, pero creo que es mucho más inteligible y, sobre todo, genérico, el primero ;)

Nadie lo ha planteado como una opción a elegir entre esas dos. La
primera sigue siendo necesaria incluso aunque te decantases por la
segunda. Para poder entender el render engine de otro tipo, primero
tienes que haber estudiado los libros necesarios. Nadie (insisto) está
planteando usar el código fuente como sustituto del libro de texto.

Y, paradojicamente, si el libro hila tan fino que te explica al
detalle cómo implementar un engine... pues al final habrías acabado
leyendo "open source", eso sí, en un libro específico de motores de
renderizado :-D

:-)

--
http://misshapenreality.blogspot.com/
_______________________________________________
Escepticos mailing list
Escepticos en dis.ulpgc.es
http://correo.dis.ulpgc.es/mailman/listinfo/escepticos