La venganza de los nerds (8 de 11)

¿Qué tan problemático es cada uno de ellos? La importancia del primero varía dependiendo de si tienes control sobre todo el sistema. Si estás escribiendo software que tiene que correr en una máquina remota del usuario, encima de un sistema operativo lleno de errores y cerrado (no menciono nombres), podría haber ventajas en escribir tu aplicación en el mismo lenguaje que el SO. Pero si controlas todo el sistema y tienes el código fuente de todas las partes, como probablemente le hace ITA, puedes usar el lenguaje que quieras. Si cualquier incompatibilidad surge, puedes repararla tú mismo.

En aplicaciones basadas en servidor puedes conseguir usar las tecnologías más avanzadas, y creo que esta es la principal causa de lo que Jonathan Erickson llama el "renacimiento de los lenguajes de programación". Esto es motivo de que incluso oigamos acerca de nuevos lenguajes como Perl y Python. No estamos oyendo sobre estos lenguajes porque las personas estén usándolos para escribir aplicaciones de Windows, sino porque los están usando en servidores. Y mientras el software se desliza de los escritorios a los servidores (un futuro con el que incluso Microsoft parece resignado), habrá menos y menos presión para usar tecnologías a-mitad-de-camino.

En cuanto a las bibliotecas, su importancia también depende de la aplicación. Para problemas menos exigentes, la disponibilidad de bibliotecas puede pesar más que la potencia intrínseca del lenguaje. ¿Donde está el punto de equilibrio? Es difícil decirlo con exactitud, pero donde sea que esté, se queda corto de cualquier cosa que pudieras llamar una aplicación. Si en una compañía se consideran en el negocio del software, y están escribiendo una aplicación que será uno de sus productos, entonces probablemente involucrarán a varios hackers y se tomarán al menos seis meses para escribirlas. En un proyecto de ese tamaño, los lenguajes potentes probablemente empiecen a tener más peso que la conveniencia de bibliotecas pre-existentes.

La tercer preocupación del jefe con-cabello-puntiagudo, la dificultad para contratar programadores, creo que es una conclusión irrelevante. después de todo ¿Cuantos hackers necesitas contratar? Seguramente que para estos tiempos todos sabemos que el software se desarrolla mejor por equipos de menos de 10 personas. Y no deberías tener problemas contratando hackers en esa escala para cualquier lenguaje del que cualquiera haya oído. Si no puedes encontrar 10 hackers de Lisp, entonces tu compañía probablemente está basada en la ciudad incorrecta para desarrollar software.

De hecho, elegir un lenguaje más potente probablemente reduzca el tamaño del equipo que necesitas, porque (a) si usas un lenguaje más potente probablemente no necesites a tantos hackers, y (b) los hackers que trabajan en lenguajes más avanzados sean posiblemente más listos.

No estoy diciendo que no recibirás mucha presión para usar las que son consideradas como tecnologías "estandar". En Viaweb (ahora Yahoo Store), hicimos que entre socios y compradores potenciales se levantaran algunas cejas por usar Lisp. Pero también lo hicimos por usar cajas Intel genéricas como servidores en lugar de servidores con "fuerza industrial" como Sun, por usar una variante de Unix entonces oscura y de código abierto llamada FreeBSD en lugar de un SO comercial real como Windows NT, por ignorar un supuesto estandar de e-comerce llamado SET que ahora nadie siquiera recuerda, y así sucesivamente.

[1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11]