RE: [escepticos] El código abierto

Jue Oct 15 15:32:38 WEST 2009

[Jose]
Discrepo. El software de gestión de mi compañía no goza de posición mopolística (ni de coña) y el hecho de que sea cerrado nos está provocando problemas gravísimos, que serán una nimiedad al lado de los que tenemos si la empresa que actualmente lo mantiene termina por desaparecer.

[Adrià]
Lo que dices tú es otro tema, que formaría parte de los casos de "emergencia" que decía, cuando el fabricante hace oídos sordos a tus cambios.  Lo que vendría a decir es que esos remiendos que haría tu empresa, en general, tenderán a ser menos eficientes que si los hace el creador.  Pero que sí, en este caso, el código abierto sería una salida (la única quizás) como ya dije.  O quizás demandar al fabricante, no se... :P

Hablando de casos particulares, mi caso: mi empresa tiene el código de una empresa anterior que no existe, y como vosotros querríais, hemos ido modificando el programa.  Te aseguro que el programa funciona, pero créeme: el código dista muchísimo de ser óptimo, es una montaña de parches, ocupa 5 veces más de lo necesario y va 10 veces más lento.  No hay quien entienda ciertas partes de remendadas que están, y el diseño y estructura a estas alturas es practicamente inexistente.  Ah...y si bien no somos genios, tampoco hay malos técnicos.

[Jose]
El conocimiento es información. Y lo que se codifica en un lenguaje de programación (desde Java hasta una máquina de Turing, también lo es).

[Adrià]
Bueno... Repito: considero que el código es información de la que se puede extraer conocimiento (el etic que señalaba anteriormente)...Pero no todo el conocimiento que sería deseable, ni siquiera el mejor conocimiento.

[Jose]
Es mucho más que eso. El simple hecho de que una condición de salida de un bucle esté mal comprobada, ya es una información que necesitamos saber para solucionar un programa que no funciona (y por ende para poderlo arreglar).
Tú estás reduciendo el concepto "conocimiento" sólo a la información tratada conceptualmente (o quizás formalmente). Sin embargo, la implementación también es información en sí misma.

[Adrià]
Si.  Por conocimiento aquí considero el conocimiento conceptual detrás del código.  Evidentemente, la implementación es información en sí misma.  Estamos hablando de cosas diferentes: que una condición de salida de un bucle esté mal comprobada te dará información para solucionar un problema del bucle mal comprobado ...y yastá.  Eso está claro.  

[Jose]
No. Son importantes ambas cosas. El conocimiento previo anterior al código es necesario para poderse aplicar en más casos y para ser utilizado en otros supuestos. El código (como implementación) también es necesario ya que de éste depende que el programa funcione, que no funcione, o cómo funcione. También de la implementación dependen factores como la escalabilidad, la modularidad o la interconexión (3 conceptos que en el caso particular de mi compañía, nos están causando sufrimiento infinito por no tener acceso al código).

[Adrià]
Tu hablas de que el código te da información de cómo arreglarlo o modificarlo.  Nunca he dicho que no sea así, pero recuerda que dije que esa información es, en primera instancia, simplemente "etic" (o sea, que sólo te sirve para remiendos.  Que son útiles...pero son remiendos y nunca la solución perfecta).  Evidentemente, desde un punto de vista pragmático es solución, y a falta de pan...pero eso ya dije que estoy deacuerdo.

[Jose]
>pequeños cambios (los dichos de "sin entrar a fondo").  Pero estos 
>cambios son los típicos "parches" o "remiendos" puntuales que sirven 
>para salir del paso, pero que a la larga hacen que un código se 
>desmorone.  Para resolver un error de forma efectiva,

O, si los publicas, sirven para que el código evolucione y mejore.

[Adrià]
Ahí si que no estoy deacuerdo.  Muchas manos (cerebros debería decir) empeoran un código, no lo mejoran.  Una cosa es el código funcione mejor (falle menos), otra que sea mejor código, y otra muy diferente que sirva de ejemplo para otros.  Lo dicho: los remiendos remiendos son.  Eso sí, con el tiempo y esfuerzo puedes llegar a dominar un código lo suficiente para hacer buenos remiendos y seguir una línea mas o menos coherente.  Pero normalmente (aquí hablo por experiencia personal sin más pruebas) el tiempo suele ser igual o más del que hubieses tardado en hacer tú tu propio programa.

[Jose]
>motivos (incluso experiencias personales propias que tú nunca tendrás) 
>P.e: un programa que utilice Fourier no te explicará la >transformada 
>de Fourier ni fundamentos sobre tratamiento de señales, y mucho menos 
>si alguien ha utilizado la transformada en

No, pero si te puede enseñar cómo implementarla más eficientemente (o más eficientemente para un supuesto específico, por ejemplo).  Y también te servirá para que puedas programar otra aplicación de tratamiento de señales sin tener que reescribir de nuevo algo que ya han hecho otras personas, en definitiva, no reinventar la rueda.

[Adrià]
Bueno...no necesariamente.  Simplemente insisto en que, para mí, lo que realmente es importante para implementar eficientemente algo es, de largo, el conocimiento conceptual detrás del código (que yo no digo que lo hayas perdido de vista).  El código es secundario e incluso puede llegar a ser irrelevante.  Si quiero implementar un renderizador 3D, bajarme el Blender me sirve de nada y menos.  Primero, un buen libro de geometría y teoría de gráficos.  E incluso cuando ya domino, el Blender, con sus tropecientos códigos fuentes, tampoco es que sea de gran utilidad y hay formas mejores y más rápidas de conseguir información.

[Jose]
> Con (1), tenemos que para transmitir el conocimiento lo mejor es un 
> libro de texto de toda la vida que hable del tema.  Con (2)

Nadie ha pretendido sustituir los libros por los programas de código abierto. Al menos no creo haber leído en ningún sitio esa proposición.

[Adrià]
Bueno...por si alguien lo pretendía.. ;)  

[Jose]
>que el código es como mucho "conocimiento ensuciado por las 
>circunstancias".  Y aparte, con (3) que tampoco podrás

¿Y por qué no "enriquecido" por las circunstancias? ¿No puede ser que se den ambas situaciones?

[Adrià]
Uy no. Las circunstancias raramente se repiten, y por ello no son aprovechables.  Sólo es el ruido que enmascara la solución (o al menos yo lo veo así).  No obstante, te puedo dar la razón en que hay casos en que por sus características, las circunstancias estén limitadas a poca variación y no "den por saco".  Pero hay otros que no...y cuando más complejo sea el problema, menos.

[Jose]
>transmisión de "conocimiento sucio" y de forma más costosa que por métodos tradicionales.  Aparte, si se tomase como norma >general su utilización indiscriminada sin control, tendería a generar código menos óptimo y mal parcheado.

¿Indiscriminadamente y sin control? Sí... por eso plataformas como MySQL o servidores como Apache están tan descontrolados y funcionan tan mal que nadie los usa en el mundo...

[Adria]
Ojo: MySQL o Apache no estan descontrolados ni he dicho que lo estén.  Yo no he dicho que el "codigo abierto" sea imposible que funcione: simplemente, que acaba necesitando de tanto control que pierden sentido muchas de las cualidades que se defienden por el hecho de que todos podamos acceder.  Al final, en todos esos proyectos acaban siendo un grupo de gente más o menos contínua la que lo mantiene, por mucho que el código esté disponible.  E incluso así se modulariza para que cada persona toque módulos concretos (con lo que daría casi igual disponer el código o que sencillamente te dijeran el interface que necesitan).

[Jose]
> Total: lo mejor si encuentras un error, envía un mail al equipo que ha 
> creado el software (sea empresa o grupo de amigotes).  Y

¿A Microsoft?

[Adrià]
Pues sí, a nivel teórico sí.  Sería el procedimiento ideal.  O no?? :D

[Jose]
>como sea".  Ahí el código abierto sí es una ventaja: como  solución de emergencia ante eventualidades de ese estilo.  Pero >como filosofía general, el código abierto pienso es irrelevante e incluso perjudicial depende de cómo se tome.

Pues la tendencia general es precisamente lo contrario a lo que tú propones. Incluso los gigantes de la informática (exceptuando MS) están arrimándose al opensource (si te parecen irrelevantes compañías como Apple, Oracle, Sun, IBM o Novell, pues... entonces me retiro de la conversación).

[Adrià]
Me gustaría saber, si despareciera MS, cuántas de ellas tardarían en poner precio a su código.  Los motivos por lo que lo hacen creo sinceramente que están mucho más allá de la discusión filosófica del opensource...o sea que esa "tendencia general" no creo que sea prueba de nada...digo yo! 

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