Cita:
Iniciado por chuscazo La verdad que la apicacion 'vieja' al final me la conozco de memoria, el caso es que primero solo se hizo una pequeña aplicacion para suplir alguna deficiencia de la antigua y al final se ha optado por pasarla a PHP. ¿Porque? Supongo que por que es el lenguaje que mas domino y en el que estamos desarrollando otras aplicaciones de la intranet.
La teoría informática sobre las olas de conocimiento en las nuevas generaciones se vuelve a cumplir...
Cita:
Iniciado por chuscazo La verdad que tampoco me habria costado demasiado trabajo actualizar la antigua, pero mi jefe no queria tocar nada en ella y parece que los empleados le han empezado a cojer mania y todo.
Lo que hagan los demás empleados me da igual. Lo que quiero saber es si un día te animarás a aprender Perl.
Cita:
Iniciado por chuscazo Tu pregunta tiene mucho sentido y tienes razon. Pero ya esta casi terminada.
La verdad creo que tambien se esta haciendo en PHP porque sera mas facil de entender para otra persona en el futuro. Creo que es mas conocido este lenguaje. (creo)
Sí, es más conocido.
¿Sabes por qué? Pero lo que no está garantizado es que otra persona lo pueda leer. Perl tiene 18 años y ha fracasado en tu empresa, ya que has tenido que cambiar una aplicación. Y sin hablar de que la nueva versión esté tan bien escrita que se pueda entender (me refiero a que no importa el lenguaje utilizado, se pueden escribir programas de forma tan enrevesada que no sean facilmente
entendibles)
Lo que quiero decir es que, como profesionales de la Informática, cuando nos presentemos en un caso como estos debemos dar una razón tecnológica del porqué es necesario hacer el cambio.
* Que no conozcamos el lenguaje, no es culpa del programa
* Que tengamos manías y que el jefe no quiere que se toque, no es culpa del programa
* Que nosotros dominemos otros lenguajes no es culpa del programa.
En cambio,
* Si el programa empieza a funcionar mal, ahora, en este momento, es quizás porque ha cambiado el entorno de trabajo para el que fue diseñado. Es culpa del programador no haber previsto esas circunstancias (por ejemplo, disco duro lleno), pero no es culpa del programa ni del programador si la máquina donde corre es más lenta con respecto a sus vecinas.
* Si el programa no reconoce nuevas circunstancias que sí estaban previstas en el momento del diseño, entonces suele ser culpa del programador.
* Si el programa empieza a tener un comportamiento extraño por cambios en la API, sistema operativo, hardware o librerías más modernas, entonces sí, hablamos de que el programa es viejo y que hay que mantenerlo o cambiarlo.
Te contaré una cosa.
Yo entré en un departamento donde todo el mundo programa en C desde hace años, por la sencilla razón de que no saben otra cosa (son licenciados más preocupados por los aspectos formales del problema que por la forma de resolverlo, cosa que es trabajo del informático). Yo me encontré que había algunos scripts hechos en Perl, del que no tenía ni idea. Como alguno de ellos ya empezaba a funcionar mal, no por culpa suya si no porque los ficheros que tenía que procesar habían cambiado, aprendí a hacer algunos cambios y los dejé así. En esto que llega el jefe y dice. "¿Qué lenguaje es ese?". "Es Perl", respondo. "¿Y eso que és? No, no, no. Aquí se debe trabajar todos con el mismo lenguaje, porque si no es un follón", me dijo. Mi respuesta: "pues están funcionando en la web del departamento desde hace diez años, y en lugares vitales de todo el sistema". Se quedó muy sorprendido y se dió media vuelta, pensando que, como es natural, un jefe está para mandar y no para decir cómo se tienen que hacer las cosas, sobre todo cuando lo último que hizo de informática era con tarjetas perforadas.
A mí en cambio me picó la curiosidad y me dió por leerme todos los programas y entender un poco porqué se hizo así en su tiempo. Hablé con los dos programadores anteriores y me contaron que fue por cuestión de tiempo, nada más. Y claro, se veía que el código estaba muy mal hecho por culpa de esas prisas. Y ahora viene la pregunta crucial: ¿qué hago? Puedo reescribir esos programas a C o C++, como decía el jefe, o a cualquiera de la media docena de lenguajes que puedo usar -porque los domino, PHP incluído-, o también puedo aprender Perl.
Yo opté por la última... si un lenguaje tiene 18 años de vida, será por algo... Entonces entré en
CPAN y lo entendí.
Empezé a escribir programas más pequeños, de los que los compañeros me pedían (scripts para filtrar nombres de ficheros, hacer ftps, mirros de webs, tareas en el cron y cosas así). Pero poco a poco me dí cuenta de que se podía hacer algo más. Mis compañeros se mostraban extrañados de un lenguaje que por supuesto no sabían, pero que más o menos podían leer. Lo que sí veían es que la velocidad de producción era muy alta -con las expresiones regulares hacía en dos líneas lo que ellos en más de 30-, así que poco a poco me pedían más nivel. Al final, conseguí entrar en el terreno del procesado de ficheros, un terreno que era coto privado del C, pero resulta que el programa en Perl que yo escribí lo hice en la cuarta parte de tiempo, en la trigésima parte de líneas y procesaba el fichero a un 80% del tiempo anterior... y cuando no quedaba más remedio que decir que C era superior a Perl en cuanto a velocidad, tampoco pasaba nada... se puede
meter código C dentro de Perl y así obtienes lo mejor de ambos mundos.
Bueno, esto sólo es una opinión personal. No quiero que pienses que soy un hincha acérrimo. Yo suelo siempre pensar en el mejor lenguaje para resolver un problema antes de empezar. Lo que pasa es que la mayoría de las veces Perl juega con ventaja. Fíjate que ahora mismo estoy con una aplicación 'antigua' en PHP que me está dando tantos problemas que he tenido tentaciones de reescribirla en Perl, pero me digo que no, que hay que seguir con PHP, porque sino se me va a olvidar, como ya me ha pasado con el Java