natxo escribiste:En mi curro llevo meses intentando meter ActivePerl en los servidores Windows porque me permitiría realizar muchas más tareas de modo automático. Al final, lo que hago es usar tinyperl y crear pequeños ejecutables y distribuirlos con la dll y un zip. Si se ejecuta el exe desde la misma carpeta en que están los otros dos archivos, va bien y no hay que 'instalar' nada (muchos administradores Windows se ponen de los nervios si propones instalar algo, y más si lo haces en el disco C: ). En fin.
¿Ponen alguna pega cuando se trata de instalar o actualizar el motor .Net o el Java? Pues Perl también es un motor de máquina virtual.
natxo escribiste:El problema que se me plantea a mí (con relación a este tema) es que nadie quiere aprender nada. Como administrador de redes/sistemas hoy día es casi imposible encontrar a alguien con interés por aprender algún lenguaje de
script (el que sea).
Todos quieren soluciones mascaditas con programas
clik clik clik y ya está. Y si no funciona, quieren poder señalar con el dedo al programador y decir: 'es culpa de este software'. Es la gran diferencia entre Windows y Linux en general. La gente que usa Windows está acostumbrada a aflojar la bolsa para hacer cosas. En el mundo del software libre estamos acostumbrados a remangarnos la camisa y currar
;
El trabajo es muy parecido, pero el lenguaje es distinto. Mientras que ellos prefieren pinchar y arrastrar componentes en pantalla, nosotros preferimos escribir en un editor de textos un map() detrás de un foreach().
Desde luego, la cantidad de información que pueden manejar usando componentes prefabricados es enorme, pero también se les puede indicar que Perl puede manejar enormes cantidades de información usando recursos mínimos... por ejemplo, podrías editar programas Perl en el ordenador de tu empresa, usando una conexión SSH, usando tu teléfono móvil en el taxi que te lleva hasta la empresa del cliente.
Y componentes prefabricados para Perl, hay
miles.
natxo escribiste:Los argumentos que mis compañeros me dan para no usar Perl es que ninguno de ellos lo sabe usar. Mi argumento es que tampoco saben usar
wsh o
jscript, ni siquiera
batch , así que si hiciera mis programillas en esos lenguajes interpretados tampoco sabrían cómo solucionar (hipotéticos) problemas con ellos si a mí me atropellara el autobús.
Pues si esa empresa tiene esos problemas tienes que hacer esto:
1.- Todo desarrollo que hagas, documéntalo hasta el final, como si de hecho te fueran a atropellar al día siguiente y otro administrador tuviera que encargarse de tus desarrollos. De hecho, => TU MISMO <= serás esa persona pasados unos meses.
2.- Busca otra empresa. En los países Bajos hay unas cuantas que buscan perleros.
Actualización: quizás la opción de buscar una empresa nueva sea demasiado exagerada: dices que eres el Administrador de redes, así que deberías ser tu el responsable de indicar qué es lo que quieres instalar en las máquinas para facilitarte tu trabajo diario.
No eres responsable del poco interés que muestren el resto de trabajadores. Sí que te afecta porque la suma total de incompetencia será determinante para el futuro de la empresa, y tu estás en ella. Por eso confiarás más en una empresa en la que los trabajadores se preocupen de su formación.
A mí me pasó algo parecido: solo realizaba
scripts pequeñitos que se dedicaban a mover ficheros de un lado a otro, tipo
backup. Un día me preguntaron si les podía echar una mano para hacer algo más complicado. Les dije que sí. Como no estaban interesados más que en el resultado del programa, no me impusieron el cómo hacerlo. Al poco, llené de mis programas Perl toda la empresa. Dos años más tarde, el "gran jefe" se sorprendió de que los programas más vitales funcionaban en un lenguaje "desconocido" cuando "aquí, de toda la vida, todo lo hacemos en C". Respuesta: Perl se utiliza en esta empresa desde el principio, incluso de antes de que yo llegara (que era cierto: había algunos cgi por ahí). Como un "gran jefe" está más a gestionar que a entender cómo funcionan las cosas, no volvió a insistir, así que yo seguí con mis programas. Cinco años más tarde, Perl se usaba como pieza vital de los principales desarrollos, ya que se había
demostrado a lo largo del tiempo su:
- Versatilidad, frente al C, que se usaba solo para procesamiento puro y duro, mientras que Perl servía para absolutamente todo lo demás. Esto incluye la existencia de librerías en CPAN que resolvían los problemas más extraños.
- Adaptación: se podía trabajar en Linux o Windows, el mismo programa.
- Rapidez de desarrollo: en un lugar donde hay poca mano de obra es vital tener la herramienta que te resuelva problemas lo más rápidamente posible, dejando como secundario que los programas sean los más rápidos posibles.
- Homeostasis (resistencia a los cambios) muy alta: cuando se producían variaciones imprevistas en las condiciones de funcionamiento de los programas, es muy rápido readaptar los programas Perl. E incluso en la mayor parte de los casos, no era necesario cambiar ni una línea de programa.
- Soporte: obtener respuesta de la comunidad en pocos minutos. Poder dialogar con los autores de las librerías... eso tiene un precio altísimo... por nada.
