Re: [escepticos] El código abierto

[Pepe Arlandis]

El 17 de octubre de 2009 17:05, Pepe Arlandis <pepe.arlandis en gmail.com>escribió:

>
>
> 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: (continúo que había enviado por error)
>

                  a) Derecho a la libertad de uso del los programas (Una vez
has adquirido un programa gratis o pagando debes de ser libre de usarlo como
quieras se sobreentiende que como toda actividad humana, sometido a las
leyes vigentes).
                  b) Derecho a modificar esos programa para adaptarlos a tus
necesidades (modificarlos tu mismo o pagar a alguien para que los modifique)
                  c) Dereho a publicar las modificaciones de los programas
de forma que se pueda compartir las mejoras que se hayan podido introducir.

Entonces todas las objeciones que puedas poner al código libre se deben
poner a estas condiciones a) b) o c) o proposiciones deducidas de ellas,
pero ninguna de ellas se resiente en lo más mínimo en las objeciones que tu
le has puesto.
saludos pepet