Hola, hay que ver dónde acaba uno posteando a base de botar de un lado a otro de la red buscando documentación sobre hibernate/nhibernate.
Porque habeis leido bien, buscaba de los 2 a la vez. Pero empecemos por el principio...
En todos los años que llevo en este mundillo de la programación, los sistemas de datos empresariales, en resumen en el mundo de las IT (soy ingeniero de telecomunicaciones por la universidad de Vigo, España, y trabajo como consultor/jefe de producción en una empresa de ingeniería que trabaja con operadoras de telefonía y cable gallegas como R y Comunitel), todas mis experiencias me han llevado a hacer que me distance un tanto de las implementaciones en sí de un mismo concepto. Esto que suena un poco así, se resume en que "cada cosa para lo que es", una máxima que me da muy buen resultado en mi vida laboral y personal. Ahí coincido con fox.
Cuando apareció java, yo como mucha gente, ya llevábamos programando muchos añitos en cosas como C++, delphi o pq no, VB. Antes de nada, resaltar que bueno, de aquella donde estaba yo personalmente más potente era en vb, lo cual es normal si te planteas hacer aplicaciones windows de ventanas sin volverte loco interceptando mensajes de la api...:P Sólo es por poneros en contexto.
Bueno, apareció java. Y como cuando aparece algo nuevo, aparecen fanáticos. Recuerdo mis agrias discusiones con un compañero de carrera (que mirad por donde, acabamos trabajando codo con codo, y con una gran admiración mútua, que sigue creciendo a día de hoy, un saludillo para Rui) sobre java, puesto que yo defendía la eficiencia de los lenguajes compilados sobre los interpretados. Todo el mundo había hecho máquinas virtuales inventadas en alguna práctica de la carrera, y sabíamos que claro, el rendimiento no se podía comparar a un código directamente hecho en C y compilado con el gcc, por el simple motivo de que por cada bytecode, se tenían que ejecutar varias instrucciones de código máquina.
Rui por supuesto, me vendía las bondades multiplataforma y de lenguaje estructurado de java, el famoso "Code and compile once, run anywhere", pero en los laboratorios de aquella, veíamos que eso de degradaba por culpa de las enrevesadas implementaciones del momento de AWT (si, AWT no swing, el dolor hecho código de GUI :P)
De aquellos tiempo de extremos ya han pasado bastantes añitos, y bueno, he hecho proyectos en ambas plataformas. Desde en embedded java en un dispositivo TINI (para los que no los conozcais, ahí está lo de las lavadoras, y es realmente cómodo programar hardware en alto nivel, aún tengo hecho cosas en micros Motorolla y pics en ensamblador a pelo), hasta implementaciones de CRM y ERP en ambos sistemas. Y os estoy hablando de programitas grandes, si no conoceis las siglas anteriores :P programitas que se sustentan sobre varias bases de datos empresariales (oracle, informix, sql-server) con varios cientos de tablas en total.
En todo este tiempo de trabajo, he aprendido de asociar al factor rendimiento intrínseco de una pltaforma, sistema operativo etc, el factor coste. Y la labor de un ingeniero es la de optimizar la relación calidad/coste. Para que veais ejemplos más radicales de mundo real, sale mejor a un cliente pagar por hacer un programa empresarial en un entorno de máquina virtual, con lenguajes de muy alto nivel, que sea escalable, y que necesite 3 servidores (y hablo de servidores, no pcs haciendo la función de servidor), que realizar ese mismo programa en un entorno compilado nativo y optimizado a nivel máximo.
Le sale mejor por el simple motivo que es mucho más trabajoso y se necesitan más recursos por hora, utilizar lenguajes y herramientas no RAD, sólo por no tener capas de overhead de procesamiento. Otro ejemplo: ¿qué es mejor para un cliente? ¿Hacer un refactoring completo de una aplicación, tuneando tooodas y cada una de los miles de sentencias sql de una base de datos, y tuneando la base de datos en sí (denormalizándola normalemente para acelerar las búsquedas a costa de la aparición de redundancia), o simplemente comprar más potencia de cálculo en paralelo? Mi respuesta es la segunda, ya que la primera implicaría cientos de horas de personal cualificado, cuyos costes sobrepasarían con creces a comprar otro nuevo servidor, además de que si la aplicación crece, las optimizaciones se pueden convertir en un nudo al cuello que no te deje evolucionar el sistema.
Si existen todos estor frameworks de desarrollo, ya sea con java, .NET, hibernate,nhibernate.. es pq hay que darse cuenta de una cosa... vale más en un mercado competitivo como el nuestro un producto regular-bueno producido en 3 meses y el gran producto del universo producido en 1 año. Y no es que esto sea triste, sino que es la técnica del ladrillo, ir poco a poco, fase a fase, y cobrar antes aunque menos, que hay que comer a finde mes.
Java y .NET nacen con esa filosofía de desarrollo rápido, aunque desde dos enfoques distintos (no me voy a meter con quien copió a quien, pq lo que realmente me importa es que ambas me den de comer a fin de mes y paguen mi hipoteca :P).
Java lo hace desde la óptica de la homogeneidad: si tienes siempre el mismo lenguaje para todos los entornos de producción, te puedes especializar muchísimo, lo cual implica una gran productividad.
.NET lo hace desde el enfoque opuesto: si los programadores ya se han formado a lo largo de su vida en una familia de un lenguaje en concreto, no vamos a cambiarsela por algo totalmente nuevo, para que su productividad no decrezca con una curba de aprendizaje previa de unos añitos.
Cada cosa para lo que es: el objetivo de ambas plataformas es el aumento de la productividad, más que la eficiencia en sí del programa. Lo cual es lógico, pq si nos fueramos al otro extremo, seguríamos haciendo todo en ensamblador. Pero lo que manda es la pela, no los ciclos de CPU.
Por lo tanto, yo opino que en lugar de pelearse por defender tal y cual plataforma, habría que conocer las ventajas y desventajas de cada una, y como un doctor, elegir la herramienta más adecuada para cada desarrollo, teniendo en cuenta las casuísticas económicas y de rendimiento de cada proyecto.
He visto a gurús de unix en mi oficina perder 5 horas de trabajo (aprox 600 euros en total calculando en pasta el tiempo perdido) intentando configurar bien un linux que no se dejaba, mientras yo callaba, sonría y seguía trabajando en una excel del cálculo de riesgos de un proyecto.
He visto a esos mismos gurús cagándose a gusto cuando al ISS6 se le da por colgarse en uno de nuestros servidores de aplicaciones, y ahí me toca callar a mí.
Las cosas son como son: no existe una solución única en este complicado mundo de las IT. Si existiera, sólo habría esa y todo el mundo la utilizaría bien a gusto. Suele pasar la gran mayoría de las veces que defendemos lo que más nos gusta, y que además, le dedicamos más horas de formación pq nos gusta más, lo que hace que la otra opción se vea desmerecida porque no estamos tan puestos en ella.
Tenemos a nuestra disposición como ingenieros, programadores, etc, una gran variedad de herramientas en las que gente muy preparada, más que nosotros seguro, ha invertido una gran cantidad de trabajo. Respetemos todas las alternativas, y como el doctor, elijamos la herramienta más adecuada a cada corte. En la misma operación, se usa el bisturí y la sierra.. imaginaros al doctor que sólo utilizara únicamente una de ellas, pq la otra no le gusta...
En resumen... es mejor centrarse en cómo programar mejor (buenos patrones de diseño, diseño de arquitecturas escalables, etc) que en especializarse absolutamente en programar en una única plataforma de desarrollo. Pensad que siempre hay gente que va a programar mejor que uno, y que es más productivo un gran diseño hecho por gente que sabe mucho de diseño de aplicaciones y no tanto de la implementación, y que la implementación la realicen los fieras de la plataforma elegida. Para eso están los fanáticos, para ser los mejores en lo suyo, ¿no? ;)
A otro nivel, esta vez con personas, se vuelve a cumplir lo de "Cada cosa para lo que es..." o "Zapatero, a tus zapatos". Porque sean cuales sean, siguen siendo zapatos.
Jur despues de este troncho, si aún queda alguien despierto, me doy por satisfecho :P
Un saludillo a todos. Ya me contareis qué os parece mi forma de ver las cosas.
|