[opensuse-es] [OT] Buenos lenguajes, malos lenguajes, buen codigo, mal codigo, etc
Me parece que hay un hecho indiscutible: Un buen programa es el que cumple la función para la que fue diseñado. Creo que esta frase es indiscutible...pero ahora empiezan los problemas : Los objetivos son cambiantes en el tiempo. El "estado del arte", la tecnología, también lo es y lo peor la moda también. Cuando empezó este negocio, se programaba directamente en código maquina y mas tarde en ensamblador. Mas tarde aparecieron Algol, Fortran y algunos mas. En aquella época, programar era un arte, véase " El arte programar" de Knuth. Vistos desde hoy, todos los lenguajes de alto nivel de esa época tienen problemas graves de diseño.(Backtracking en compilación, la mayoría) Eran malos? No, evidentemente no. Eran lo mejor que se había podido hacer en una época donde los objetivos eran : 1/ Que el lenguaje se pareciese al de uso común. 2/Que el código ocupase poco espacio( los equipo casi no tenían memoria, y eran ferritas) 3/Que fuese rápido de ejecución( los equipos eran muuuuyyyyyyyyy lentos). Con la aparición de C se abrió otra perspectiva : Era un lenguaje técnico que se apartaba de los lenguajes mas enfocados a problema de usuario. Un buen programador de C sabe casi lo que generara en ensamblador la sentencia que esta escribiendo. Hacia falta escribir poco.( quedaba mas tiempo para cerveza) No te limitaba, casi cualquier cosa se podía escribir en C. En esa época, también andaba por ahí Pascal, pero tenia problemas: Había que escribir mucho. No te dejaba hacer tonterías, sino escribías mucho y aun así algunas eran imposibles. Hasta aquí los programadores eran artistas y bichos raros, cobraban sueldos mas que decentes y no terminaban la mitad de los proyectos. A alguien se le ocurrió que eso era muy caro y que había que reestructurar el negocio. En la parte de gestión se subdividió al personal en : Analistas y Programadores. Los analistas piensan como hay que hacer un programa. Los programadores son escribanos que ejecutan lo que han especificado los analistas. En la parte técnica, esta división no ha funcionado nunca bien, por muchos intentos que se hagan. Tenemos analistas, desarrolladores y programadores. Tenemos formas de especificación UML, etc Pero no acaba de funcionar. Para intentar que funcione esa "ingenierizacion" de la programación, se han desarrollado también lenguajes mas orientados al problema. Es el caso de todos los orientados a objetos, por ejemplo C++ y C# Evidentemente nos encontramos con un cambio de objetivos. Ahora son : Programación orientada al problema. Eliminar errores del programador( tipados fuertes)( se vuelve a escribir mas) Mantenibilidad. Nivel de integridad. Multiplataforma. El tamaño de un programa en general ya no es problema, los tamaños de memoria se han multiplicado por mil. La velocidad de ejecución ha aumentado considerablemente y solo hay que tenerla en cuenta en unos cuantos casos. Hay mucha información sobre lo que HOY entendemos como calidad en la programación, pero no es lo mismo que se entendía ayer. -- Saludos Lluis
O Sábado 11 Abril 2009 23:00:15 lluis escribiu:
Me parece que hay un hecho indiscutible:
Un buen programa es el que cumple la función para la que fue diseñado.
Creo que esta frase es indiscutible...pero ahora empiezan los problemas : En realidad eso es muy discutible. El problema está en el adjetivo "buen". ¿Qué parametros definen lo qué es bueno?
Generalmente algo "bueno" es algo que suele tener en cuenta el coste en recursos y la eficiencia con la que desempeña la función asignada. Por ejemplo, el Concorde no era un buen avión, por el simple hecho de que era demasiado caro viajar en él. Otro aspecto que no debe eludirse es el funcional. ¿Qué es "cumplir con la función"? Las señales de humo cumplen con la función de medio de comunicación, pero es fácil ver que tienen serias limitaciones para esa misma función. Por ejemplo, el emisor tiene que estar en disposición de ver dichas señales. Un buen programa debería ser "aquél que desempeña bien su función", por lo menos. Entonces, la calidad de la definición de la función es lo importante.
Los objetivos son cambiantes en el tiempo. El "estado del arte", la tecnología, también lo es y lo peor la moda también. Los objetivos son los mismos, lo que cambian son cuestiones accesorias. Uno "va a la moda" por los mismos motivos ahora que hace 3000 años. Y uno pinta un cuadro o toca una melodía por idénticos motivos. Cuando empezó este negocio, se programaba directamente en código maquina y mas tarde en ensamblador. Mas tarde aparecieron Algol, Fortran y algunos mas.
En aquella época, programar era un arte, véase " El arte programar" de Knuth. En cierto sentido sigue siéndolo. Si tú tienes una silla y la ves, puedes hacer otra, o tomarla de referencia para hacer una silla distinta. En informática, como en otras ingenierías, no tienes modelos físicos sobre los que trabajar. Si tú haces literatura o música lo llaman arte; si haces ingeniería... Vistos desde hoy, todos los lenguajes de alto nivel de esa época tienen problemas graves de diseño.(Backtracking en compilación, la mayoría)
Eran malos? No, evidentemente no. Eran lo mejor que se había podido hacer en una época donde los objetivos eran : 1/ Que el lenguaje se pareciese al de uso común. 2/Que el código ocupase poco espacio( los equipo casi no tenían memoria, y eran ferritas) 3/Que fuese rápido de ejecución( los equipos eran muuuuyyyyyyyyy lentos). Las señales de humo eran un sistema de comunicación muy malo comparado a la telefonía móvil, el GPS, internet... Que no hubiera muchas más opciones no hace mejor la solución. Puede justificarla, pero no la mejora. Con la aparición de C se abrió otra perspectiva :
Era un lenguaje técnico que se apartaba de los lenguajes mas enfocados a problema de usuario. Un buen programador de C sabe casi lo que generara en ensamblador la sentencia que esta escribiendo. Hacia falta escribir poco.( quedaba mas tiempo para cerveza) No te limitaba, casi cualquier cosa se podía escribir en C.
En esa época, también andaba por ahí Pascal, pero tenia problemas: Había que escribir mucho. No te dejaba hacer tonterías, sino escribías mucho y aun así algunas eran imposibles. Puedes hacer las mismas tonterías. Pascal proporciona herramienas (en su definición estándar) para prevenir errores, como el fuerte tipado y el manejo reducido de punteros. Pero puedes apuntar un dato que no deberías borrar y borrarlo a través del puntero.
Hasta aquí los programadores eran artistas y bichos raros, cobraban sueldos mas que decentes y no terminaban la mitad de los proyectos.
A alguien se le ocurrió que eso era muy caro y que había que reestructurar el negocio.
En la parte de gestión se subdividió al personal en : Analistas y Programadores.
Los analistas piensan como hay que hacer un programa. Los programadores son escribanos que ejecutan lo que han especificado los analistas.
En la parte técnica, esta división no ha funcionado nunca bien, por muchos intentos que se hagan. Tenemos analistas, desarrolladores y programadores. Tenemos formas de especificación UML, etc Pero no acaba de funcionar. Sigue habiendo el mismo problema. Demasiados proyectos paralelos. Además, la reusabilidad del software (pilar tanto del software libre como de las nuevas metodologías de programación) no se utiliza, porque cada uno desarrolla sus
C no comprobaba las cosas, y el compilador no te iba a avisar de lo que se supone que sabes que estás haciendo. Si estás asignando un entero largo a un entero corto, tú sabrás por qué lo haces XDD propias versiones de todo para a) no pagarle a la competencia por usar las suyas, o b) poder registrarlas para así tal vez si cabe algún día cobrarle a otros por usarlas. Además, es cool XD
Para intentar que funcione esa "ingenierizacion" de la programación, se han desarrollado también lenguajes mas orientados al problema. Es el caso de todos los orientados a objetos, por ejemplo C++ y C#
Evidentemente nos encontramos con un cambio de objetivos. Ahora son :
Programación orientada al problema. Eliminar errores del programador( tipados fuertes)( se vuelve a escribir mas) Mantenibilidad. Nivel de integridad. Multiplataforma.
El tamaño de un programa en general ya no es problema, los tamaños de memoria se han multiplicado por mil. Y los requerimentos del sistema aumentaron en la misma forma, de manera que siempre vamos justos XD La velocidad de ejecución ha aumentado considerablemente y solo hay que tenerla en cuenta en unos cuantos casos.
Hay mucha información sobre lo que HOY entendemos como calidad en la programación, pero no es lo mismo que se entendía ayer. Es los mismo.
Salud!! -- O malo da relixión e a súa carenza de imaxinación -- karl -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
On Sunday 12 April 2009 00:07:12 Karl García Gestido wrote:
O Sábado 11 Abril 2009 23:00:15 lluis escribiu:
Me parece que hay un hecho indiscutible:
Un buen programa es el que cumple la función para la que fue diseñado.
Creo que esta frase es indiscutible...pero ahora empiezan los problemas :
En realidad eso es muy discutible. El problema está en el adjetivo "buen". ¿Qué parametros definen lo qué es bueno?
Generalmente algo "bueno" es algo que suele tener en cuenta el coste en recursos y la eficiencia con la que desempeña la función asignada. Por ejemplo, el Concorde no era un buen avión, por el simple hecho de que era demasiado caro viajar en él.
Otro aspecto que no debe eludirse es el funcional. ¿Qué es "cumplir con la función"? Las señales de humo cumplen con la función de medio de comunicación, pero es fácil ver que tienen serias limitaciones para esa misma función. Por ejemplo, el emisor tiene que estar en disposición de ver dichas señales.
Un buen programa debería ser "aquél que desempeña bien su función", por lo menos. Entonces, la calidad de la definición de la función es lo importante.
Entre : Un buen programa es el que cumple la función para la que fue diseñado. Y Un buen programa debería ser "aquél que desempeña bien su función", por lo menos. No estas mareando la perdiz? No me voy a molestar en buscar las diferencias semánticas y hermenéuticas de ambas frases.
Los objetivos son cambiantes en el tiempo. El "estado del arte", la tecnología, también lo es y lo peor la moda también.
Los objetivos son los mismos, lo que cambian son cuestiones accesorias. Uno "va a la moda" por los mismos motivos ahora que hace 3000 años. Y uno pinta un cuadro o toca una melodía por idénticos motivos.
Cuando empezó este negocio, se programaba directamente en código maquina y mas tarde en ensamblador. Mas tarde aparecieron Algol, Fortran y algunos mas.
En aquella época, programar era un arte, véase " El arte programar" de Knuth.
En cierto sentido sigue siéndolo. Si tú tienes una silla y la ves, puedes hacer otra, o tomarla de referencia para hacer una silla distinta. En informática, como en otras ingenierías, no tienes modelos físicos sobre los que trabajar. Si tú haces literatura o música lo llaman arte; si haces ingeniería...
No, ya no lo es. Tienes modelos estructurales.(UML) Es solo la proletarizacion de la programación.
Vistos desde hoy, todos los lenguajes de alto nivel de esa época tienen problemas graves de diseño.(Backtracking en compilación, la mayoría)
Eran malos? No, evidentemente no. Eran lo mejor que se había podido hacer en una época donde los objetivos eran : 1/ Que el lenguaje se pareciese al de uso común. 2/Que el código ocupase poco espacio( los equipo casi no tenían memoria, y eran ferritas) 3/Que fuese rápido de ejecución( los equipos eran muuuuyyyyyyyyy lentos).
Las señales de humo eran un sistema de comunicación muy malo comparado a la telefonía móvil, el GPS, internet... Que no hubiera muchas más opciones no hace mejor la solución. Puede justificarla, pero no la mejora.
Era la mejor en su época, Sin necesidad de justificación posterior.
Con la aparición de C se abrió otra perspectiva :
Era un lenguaje técnico que se apartaba de los lenguajes mas enfocados a problema de usuario. Un buen programador de C sabe casi lo que generara en ensamblador la sentencia que esta escribiendo. Hacia falta escribir poco.( quedaba mas tiempo para cerveza) No te limitaba, casi cualquier cosa se podía escribir en C.
En esa época, también andaba por ahí Pascal, pero tenia problemas: Había que escribir mucho. No te dejaba hacer tonterías, sino escribías mucho y aun así algunas eran imposibles.
Puedes hacer las mismas tonterías. Pascal proporciona herramienas (en su definición estándar) para prevenir errores, como el fuerte tipado y el manejo reducido de punteros. Pero puedes apuntar un dato que no deberías borrar y borrarlo a través del puntero.
Pascal era un lenguaje para enseñanza. Y si puedes hacer barbaridades.
C no comprobaba las cosas, y el compilador no te iba a avisar de lo que se supone que sabes que estás haciendo. Si estás asignando un entero largo a un entero corto, tú sabrás por qué lo haces XDD
Lo que bien manejado es útil, pero requiere un cierto cuidado en como se hace.
Hasta aquí los programadores eran artistas y bichos raros, cobraban sueldos mas que decentes y no terminaban la mitad de los proyectos.
A alguien se le ocurrió que eso era muy caro y que había que reestructurar el negocio.
En la parte de gestión se subdividió al personal en : Analistas y Programadores.
Los analistas piensan como hay que hacer un programa. Los programadores son escribanos que ejecutan lo que han especificado los analistas.
En la parte técnica, esta división no ha funcionado nunca bien, por muchos intentos que se hagan. Tenemos analistas, desarrolladores y programadores. Tenemos formas de especificación UML, etc Pero no acaba de funcionar.
Sigue habiendo el mismo problema. Demasiados proyectos paralelos. Además, la reusabilidad del software (pilar tanto del software libre como de las nuevas metodologías de programación) no se utiliza, porque cada uno desarrolla sus propias versiones de todo para a) no pagarle a la competencia por usar las suyas, o b) poder registrarlas para así tal vez si cabe algún día cobrarle a otros por usarlas. Además, es cool XD
Para intentar que funcione esa "ingenierizacion" de la programación, se han desarrollado también lenguajes mas orientados al problema. Es el caso de todos los orientados a objetos, por ejemplo C++ y C#
Evidentemente nos encontramos con un cambio de objetivos. Ahora son :
Programación orientada al problema. Eliminar errores del programador( tipados fuertes)( se vuelve a escribir mas) Mantenibilidad. Nivel de integridad. Multiplataforma.
El tamaño de un programa en general ya no es problema, los tamaños de memoria se han multiplicado por mil.
Y los requerimentos del sistema aumentaron en la misma forma, de manera que siempre vamos justos XD
La velocidad de ejecución ha aumentado considerablemente y solo hay que tenerla en cuenta en unos cuantos casos.
Hay mucha información sobre lo que HOY entendemos como calidad en la programación, pero no es lo mismo que se entendía ayer.
Es los mismo.
Si??? Menos memoria? Mas velocidad? No creo. Pongamos mas integridad y mas mantenibilidad.
Salud!! -- O malo da programacion e a súa carenza de imaxinación --
-- Saludos Lluis
O Domingo 12 Abril 2009 00:25:09 lluis escribiu:
On Sunday 12 April 2009 00:07:12 Karl García Gestido wrote:
O Sábado 11 Abril 2009 23:00:15 lluis escribiu:
Me parece que hay un hecho indiscutible:
Un buen programa es el que cumple la función para la que fue diseñado.
Creo que esta frase es indiscutible...pero ahora empiezan los problemas :
En realidad eso es muy discutible. El problema está en el adjetivo "buen". ¿Qué parametros definen lo qué es bueno?
Generalmente algo "bueno" es algo que suele tener en cuenta el coste en recursos y la eficiencia con la que desempeña la función asignada. Por ejemplo, el Concorde no era un buen avión, por el simple hecho de que era demasiado caro viajar en él.
Otro aspecto que no debe eludirse es el funcional. ¿Qué es "cumplir con la función"? Las señales de humo cumplen con la función de medio de comunicación, pero es fácil ver que tienen serias limitaciones para esa misma función. Por ejemplo, el emisor tiene que estar en disposición de ver dichas señales.
Un buen programa debería ser "aquél que desempeña bien su función", por lo menos. Entonces, la calidad de la definición de la función es lo importante.
Entre : Un buen programa es el que cumple la función para la que fue diseñado. Y Un buen programa debería ser "aquél que desempeña bien su función", por lo menos.
No estas mareando la perdiz?
No me voy a molestar en buscar las diferencias semánticas y hermenéuticas de ambas frases. Es que es lo importane. Puedes matar moscas a cañonazos, pero nadie diría que es una buena forma. (...)
En cierto sentido sigue siéndolo. Si tú tienes una silla y la ves, puedes hacer otra, o tomarla de referencia para hacer una silla distinta. En informática, como en otras ingenierías, no tienes modelos físicos sobre los que trabajar. Si tú haces literatura o música lo llaman arte; si haces ingeniería...
No, ya no lo es. Tienes modelos estructurales.(UML) Es solo la proletarizacion de la programación. Bueno, todos podemos escribir libros y componer canciones, incluso pintar. Te apuesto que muchos de esta lista podrían mejorar muchas obras de muchos de los grandes museos de arte contemporáneo XD
Vistos desde hoy, todos los lenguajes de alto nivel de esa época tienen problemas graves de diseño.(Backtracking en compilación, la mayoría)
Eran malos? No, evidentemente no. Eran lo mejor que se había podido hacer en una época donde los objetivos eran : 1/ Que el lenguaje se pareciese al de uso común. 2/Que el código ocupase poco espacio( los equipo casi no tenían memoria, y eran ferritas) 3/Que fuese rápido de ejecución( los equipos eran muuuuyyyyyyyyy lentos).
Las señales de humo eran un sistema de comunicación muy malo comparado a la telefonía móvil, el GPS, internet... Que no hubiera muchas más opciones no hace mejor la solución. Puede justificarla, pero no la mejora.
Era la mejor en su época, Sin necesidad de justificación posterior. No es excusa. La medicina de hace cuatrocientos años era mala. Puede ser entendible, pero no por eso es mejor.
C no comprobaba las cosas, y el compilador no te iba a avisar de lo que se supone que sabes que estás haciendo. Si estás asignando un entero largo a un entero corto, tú sabrás por qué lo haces XDD
Lo que bien manejado es útil, pero requiere un cierto cuidado en como se hace. Si requiere "cierto cuidado", bueno bueno no es.
(...) Es los mismo.
Si??? Menos memoria? Mas velocidad?
No creo.
Pongamos mas integridad y mas mantenibilidad.
Salud!! -- O malo da programacion e a súa carenza de imaxinación -- Todos son requisitos de un buen programa. No vale que sea muy rápido si no hay Monesvol que solucione sus fallos.
De forma análoga, no vale de nada que sea fácil de mantener si no hay computador que pueda cargarlo en memoria. Salud!! -- O malo da relixión e a súa carenza de imaxinación -- karl -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-04-12 a las 00:07 +0200, Karl García Gestido escribió:
En la parte técnica, esta división no ha funcionado nunca bien, por muchos intentos que se hagan. Tenemos analistas, desarrolladores y programadores. Tenemos formas de especificación UML, etc Pero no acaba de funcionar. Sigue habiendo el mismo problema. Demasiados proyectos paralelos. Además, la reusabilidad del software (pilar tanto del software libre como de las nuevas metodologías de programación) no se utiliza, porque cada uno desarrolla sus propias versiones de todo para a) no pagarle a la competencia por usar las suyas, o b) poder registrarlas para así tal vez si cabe algún día cobrarle a otros por usarlas. Además, es cool XD
Se utiliza algo, pero poco. Uno de los problemas es la falta de documentación bien hecha, que permita encontrar la librería adecuada para hacer lo que buscas, y a usarla correctamente.
El tamaño de un programa en general ya no es problema, los tamaños de memoria se han multiplicado por mil. Y los requerimentos del sistema aumentaron en la misma forma, de manera que siempre vamos justos XD
Es verdad: yo creo que han aumentado antes el hambre de memoria de los programas que la memoria disponible. A los fabricantes les conviene que nos haga falta más memoria. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAknhHnsACgkQtTMYHG2NR9WHEQCfdft9jv12y71zSKqQXGyV+4eb easAoJKitZa/o+/DmmXR+iKbirDXgaBC =Pjlx -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-04-11 a las 23:00 +0200, lluis escribió:
En esa época, también andaba por ahí Pascal, pero tenia problemas: Había que escribir mucho.
Eso era su ventaja: era a propósito para evitar errores.
No te dejaba hacer tonterías, sino escribías mucho y aun así algunas eran imposibles.
Depende de la implementación, que eran incompletas. Con el turbo pascal podías hacer casi cualquier cosa, incluso acceso a hardware a bajo nivel, insertar código assembler... las limitaciones reales son cosas como cambiar el modelo de binario, para hacer un driver: y eso es una limitación de la implementación del compilador, no del lenguaje en sí. ...
Programación orientada al problema. Eliminar errores del programador( tipados fuertes)( se vuelve a escribir mas)
¿Lo ves? - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAknhHIYACgkQtTMYHG2NR9VnpgCglRfa4zTXFSuKnOJVHjx/g7pc CW8AnA/XbnYLC49bUc0ik21/ewSjUW6G =B66N -----END PGP SIGNATURE-----
On Sunday 12 April 2009 00:41:09 Carlos E. R. wrote:
El 2009-04-11 a las 23:00 +0200, lluis escribió:
En esa época, también andaba por ahí Pascal, pero tenia problemas: Había que escribir mucho.
Eso era su ventaja: era a propósito para evitar errores.
No te dejaba hacer tonterías, sino escribías mucho y aun así algunas eran imposibles.
Depende de la implementación, que eran incompletas. Con el turbo pascal podías hacer casi cualquier cosa, incluso acceso a hardware a bajo nivel, insertar código assembler... las limitaciones reales son cosas como cambiar el modelo de binario, para hacer un driver: y eso es una limitación de la implementación del compilador, no del lenguaje en sí.
Ese compilador era una joya, y además barato, valía la pena comprarlo. -- Saludos Lluis
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-04-12 a las 00:44 +0200, lluis escribió:
Depende de la implementación, que eran incompletas. Con el turbo pascal podías hacer casi cualquier cosa, incluso acceso a hardware a bajo nivel, insertar código assembler... las limitaciones reales son cosas como cambiar el modelo de binario, para hacer un driver: y eso es una limitación de la implementación del compilador, no del lenguaje en sí.
Ese compilador era una joya, y además barato, valía la pena comprarlo.
Y lo hice... La primera vez que lo vi, en la versión 2, me alucinó. Menos de 30 KiB, editor y compilador juntos. Al primer error, te dejaba en la línea del error; tenías las ventajas de velocidad de un código compilado con la facilidad de desarrollo de un código interpretado. El editor al menos lo hicieron en assembler. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAknhILkACgkQtTMYHG2NR9VnGQCfaMxeypSgJUOJYcc+nbfGdkDr KGgAniEap2vpia31Yw9YqZsm+mG9JtTp =tGk3 -----END PGP SIGNATURE-----
El 2009-04-11 a las 23:00 +0200, Lluis Martínez escribió: (...)
Hay mucha información sobre lo que HOY entendemos como calidad en la programación, pero no es lo mismo que se entendía ayer.
Es curisoso... hace poco en la lista inglesa se preguntaban "dónde había quedado el orgullo de los programadores" (debido a un error tonto en un paquete del OBS al que le estaban dando vueltas para corregirlo en Bugzilla). Pero algo de razón tiene quien expresaba así su malestar. Y no se trata sólo de los programadores, es algo generalizado en todos los sectores. Es sólo una cuestión de actitud, pero nos lo intentan vender como si fuera algo que no dependiera de ellos: "Ah, pues habla con los managers" o "Ah, es que bugzilla tiene unos cauces para seguir, que no se pueden saltar..." o "Ah, pues compra una sles/sled". La cuestión es "no hacer nada", para que nunca "pase nada" >:-) Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-04-12 a las 12:21 +0200, Camaleón escribió:
El 2009-04-11 a las 23:00 +0200, Lluis Martínez escribió:
(...)
Hay mucha información sobre lo que HOY entendemos como calidad en la programación, pero no es lo mismo que se entendía ayer.
Es curisoso... hace poco en la lista inglesa se preguntaban "dónde había quedado el orgullo de los programadores" (debido a un error tonto en un paquete del OBS al que le estaban dando vueltas para corregirlo en Bugzilla).
Pero algo de razón tiene quien expresaba así su malestar.
Desde luego. Se cargan "a postas" un paquete del kde3, y no lo quieren arreglar porque el kde3 no se mantiene. ¡Pero es que se lo han cargado! Si hubieran tenido las manos quietas no pasaría nada. Le han metido el kdiff de la 4 a la 3, con calzador.
Y no se trata sólo de los programadores, es algo generalizado en todos los sectores. Es sólo una cuestión de actitud, pero nos lo intentan vender como si fuera algo que no dependiera de ellos: "Ah, pues habla con los managers" o "Ah, es que bugzilla tiene unos cauces para seguir, que no se pueden saltar..." o "Ah, pues compra una sles/sled".
Y lo de comprar una slex pues tampoco, porque de repente te quitan un componente crítico y a buscarse la vida. O te lo bajas por tu cuenta, o te pasas a otro ditribuidor. Al final, pues tienes la sala llena de distintas ditribuiciones según quien tenga el programa adecuado a cada servidor, y llena de parches. Una pesadilla de mantener.
La cuestión es "no hacer nada", para que nunca "pase nada" >:-)
Y tampoco... - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAknh2TwACgkQtTMYHG2NR9V0eACgl+8nvf8LbxsEFmjHSkbHT4zJ dV4AnikUn5ve1++X9Cv8gwRSSaaXL52W =Xesr -----END PGP SIGNATURE-----
El 2009-04-12 a las 14:06 +0200, Carlos E. R. escribió:
El 2009-04-12 a las 12:21 +0200, Camaleón escribió:
Es curisoso... hace poco en la lista inglesa se preguntaban "dónde había quedado el orgullo de los programadores" (debido a un error tonto en un paquete del OBS al que le estaban dando vueltas para corregirlo en Bugzilla).
Pero algo de razón tiene quien expresaba así su malestar.
Desde luego.
Se cargan "a postas" un paquete del kde3, y no lo quieren arreglar porque el kde3 no se mantiene. ¡Pero es que se lo han cargado! Si hubieran tenido las manos quietas no pasaría nada. Le han metido el kdiff de la 4 a la 3, con calzador.
Según Marcus Meissner, sólo se mantienen los paquetes de la distribución y los parches. El OBS queda fuera, y por tanto al libre albedrío de cada mantenedor. Está bien, pero es poco, es caótico y genera un círculo vicioso. a) En primer lugar porque: 1. Nos animan a informar de bugs 2. En bugzilla, nos indican que instalemos el KOTD o paquetes que están en el OBS para ver si resuelven los problemas 3. Al instalar paquetes del OBS se soluciona el problema inicial pero se generan otros. 4. Al informar sobre los otros problemas nos dicen que el OBS no está soportado Pues estamos bien :-/ b) Y en segundo lugar porque el software avanza muy rápido. Hay paquetes "imprescindibles" en un entorno de escritorio (Mozilla, KDE, GNOME, OOo...) o las últimas versiones de Apache o php/perl (para un entorno de servidor) que sólo están en el OBS y para mantenerlos actualizados tenemos que pasar por ahí. Si hay algún problema con esos paquetes, nos quedamos pendientes de sus respectivos mantenedores, que pueden seguir manteniéndolos o no, pueden querer solucionar el problema o no. Por ejemplo, Mozilla Thunderbird. El Thundercito de opensuse no funciona con los plugins de la web de Mozilla: hay que usar los plugins del OBS (porque no hay plugins oficialmente mantenidos por opensuse, o yo no los veo) o instalar Thunderbird desde Mozilla. Por eso los paquetes "oficiales" están bien, pero se quedan claramente "cortos" para cualquier usuario que ve como sus opciones se reducen a: - Buscarse la vida por su cuenta (instalar los paquetes desde las páginas de los productos, desde Mozilla o desde Sun). - Arriesgarse con el OBS y esperar no tener problemas. Por tanto, creo que los paquetes del OBS (los que tengan mayor demanda) deberían ir incorporándose poco a poco en los oficiales o bien deberían pasar a tener un estatus "oficial". O al menos, susceptibles de "arreglo" si algo se "rompe". ¿Que hace falta gente que se haga cargo de los paquetes? Lo sé (ver nota), pero la única opción para mantener una distribución "viva" pasa (entre otras cosas) por propocionar paquetes y mantenerlos, no hay otro misterio. Si la gente tiene que compilarse los programas más básicos (nvidia, mozilla, OOo...) o instalarlos desde fuera, al final terminará por cambiar de distribución porque no verá ninguna ventaja en seguir a caballo entre "lo oficial" (poco pero bueno) y "lo oficioso" (más opciones pero más costosas de mantener). Y Novell despidiendo gente... :-( Nota: Lo de ClamAV es sangrante. No se actualiza hasta pasadas semanas de la salida del parche oficial -y eso que es un paquete oficialmente mantenido- y ya es una tónica habitual -y ahora ya han sacado una nueva versión, a ver lo que tenemos que esperar. Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
participants (4)
-
Camaleón -
Carlos E. R. -
Karl García Gestido -
lluis