Re: [escepticos] El código abierto

[Pepe Arlandis]

El 17 de octubre de 2009 11:13, Adria Comos <AdriaComos en dorna.com> escribió:

> 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
>
>
> _______________________________________________
> Escepticos mailing list
> Escepticos en dis.ulpgc.es
> http://correo.dis.ulpgc.es/mailman/listinfo/escepticos
>
La verdad no entiendo que tiene que ver lo que dices sobre si el código es
conocimiento o no.
Simplemente añadiría que por una parte el código de un programa normalmente
es la resolución de un problema, (si está bien hecho) y como resolución de
un problema es un conocimiento. Otra cosa es como se transmite ese
conocimiento, y si no tienes alguna solución mejor o igual que la del código
o si quieres encontrar una solucion mejor que tienes tienes varias
opciones:
               a) Estudiarte la documentación de ese código si existe y si
no existe, te estudias el código a pelo, y sobre lo que aprendas introduces
posibles mejoras.
              b) Intentas encontrar desde cero una solución mejor que la que
tienes, con el riesgo de descubrír el Mediterráneo, o reinventar la rueda.

Pero no has dado ninguna razón que demuestre que el código no es
conocimiento, pero incluso en el caso de que no fuera conocimiento, ¿qué
tiene que ver eso con la bondad o maldad del codigo abierto?
Para definir código libre (lo prefiero a código abierto, al menos en
castellano donde "libre" y "gratis" no son sinónimos) hasta ahora nadie ha
puesto impedimentos a las tres condiciones que debe cumprir, es una
definición indirecta o axiomática que quizá por deformación profesional me
gusta: