VELOCIDAD DE ESCAPE

2004-06-28

---

UN PASO ATRÁS

Lo confieso. He vuelto a programar en ASP "clasico".
Miles de euros gastados en cursos y libros sobre la maravillosa plataforma NET, cientos de horas dedicados al estudio y a pruebas y en cuanto me dejan solo vuelvo a mis vicios inconfesables.
En cuanto la presión de los plazos de entrega se hace agobiante y es preciso sacar la aplicación a la intranet lo más rápido posible he cerrado el Visual Studio NET, y con mi bloc de notas favorito echando humo (Homesite) he levantado la aplicación en dos semanas.

¿qué está pasando?

En primera instancia he pensado que lo que ocurre es que todavía no me siento cómodo desarrollando ASP NET. Todavía no tengo la soltura que me hace levantar al menos el esqueleto de la aplicación en un corto periodo de tiempo. Todavía tengo que pelear con pijaditas del framework que me hacen ir más lento. Y digo yo que a estas alturas después de un año con la nueva plataforma la cosa debería ir como la seda. Pues no. La cosa se está implantando muy lentamente. Sintomático de esto es que no tenemos ningún servidor con Windows 2003, que si bien no es necesario para implementar las aplicaciones hechas con C#, sin embargo sí que se supone que ofrece más opciones a la hora de manejarlo con el NET Framework que un Windows 2000.

Esto me ha hecho reflexionar y preguntarme porqué no estamos plenamente incorporados al desarrollo con la nueva plataforma. Y me he dado cuenta que no somos los únicos. Y no sólo eso sino que lo que está ocurriendo es que los planes de Microsoft al respecto de la adopción del nuevo entorno se han ido al traste. Ocurre que no solamente no somos los únicos sino que somos mayoría.

Por un lado. En el entorno Web el servidor Apache ha barrido totalmente. PHP ya no es la alternativa al ASP en cuanto a páginas dinámicas, sino que es el lenguaje dominante. Y para muestra un botón: el ciberpaís del jueves pasado hacía un análisis de los Sitios web de los ayuntamientos en la radiografía anual de Webs municipales y se contabiliza el salto espectacular que Linux ha tenido en el campo de los servidores. Aunque sabido es que gran parte de este salto se produce a expensas de UNIX, no por ello es menos cierto que su cuota aumenta por encima de los servidores Windows.

Sigo dándole vueltas a la cosa y me doy cuenta que hay ciertos detalles que impiden la migración masiva que se produjo por ejemplo en el caso del paso de Visual Basic 4-5 al Visual Basic 6. El cambio de plataforma es total. No hay compatibilidad hacia atrás. O sea que las aplicaciones antiguas no se van a renovar. No hay forma de migrarlas a menos que se reescriban de nuevo. Esto me ha pasado en un par de ellas. Tuve que reescribirlas desde cero. Con el agravante de encontrarme al terminar con que su lentitud, en comparación con la anterior versión, era exasperante.

Otro dato contra la migración. Tampoco habrá compatibilidad hacia adelante. Es decir, la anunciada nueva generacion de sistemas operativos de Microsoft, con Avalon, XAML, y su nueva arquitectura enteramente basada en NET, mas la edición del nuevo Visual Studio 2005 (Whidbey) hacen que no me meta de lleno en la nueva programación porque sé que es muy posible que lo que haga este año no me valga para el año que viene. Y desde luego no estoy dispuesto a perder el tiempo.
Confieso que en algún caso he pensado en elegir PHP para las aplicaciones más sencillas, pero consideré estúpido hacerlo con toda nuestra estructura basada en Windows y SQL Server. O todo o nada, me dije. No voy a andar con paños calientes.
Y claro, si no damos abasto con lo que ya tenemos y el personal que somos, como para andar planteando la migración de servidores y lenguajes. Baste decir que la migración desde el MS Office al OpenOffice está paralizada porque el Departamento informático no dispone de tiempo ni personal suficiente como para preparar un sencillo curso de formación a los usuarios.
Solución: como ahora las licencias de Office 2003 están a 300 Euros, pues licencias de Office 2003 al canto.
Las filosofías y las actitudes ideológicas a hacer puñetas en cuanto no hay forma material ni humana de afrontar el cambio.

Pero mucho me temo que eso no es todo. Buscando opiniones acerca del retraso en la adopción de la nueva plataforma me encuentro con un excelente artículo de Joel Spolsky, que como siempre, da en el clavo.

Microsoft está muriendo de éxito, esa es mi opinión. Joel es más drastico y dice "Microsoft lost the API war".
En mi humilde opinión, no es solo la guerra de las APIs lo que está en juego. Hay mucho más por la sencilla razón de que quien domina el escritorio domina la industria. Y eso tiene todas las trazas de cambiar.
Este vendría a ser el resumen de su artículo, el cual os recomiendo vivamente a poco que leais en inglés. Aquí solo sintetizaré las cuatro ideas fundamentales que articulan la tesis defendida por Joel (y que asumo como mía), por lo que os remito a su artículo para ampliar la información.

Muchos piensan que a poco que Linux cope el escritorio los dias de vino y rosas de Microsoft estarán contados. Yo lo creo.
Personalmente ya solo uso Windows por motivos laborales. Para uso personal estoy encantado con Debian. Aunque no lo domine, y en muchas ocasiones lo maldiga, cubre todas mis necesidades. Y hay familiares y amigos mios que pueden dar fe de lo mismo. A muchos de ellos les instalé Mandrake o Knoppix y de momento no he recibido ni una sola queja. Al contrario, se maravillan de poder hacer lo mismo (e incluso más que con Windows) sin tener que preocuparse de Virus, de instalar programas de terceros y demás historias.

El poder de un sistema operativo se mide por lo que se puede hacer con él. Por eso el futuro de Linux está muy ligado (indisolublemente ligado) a las aplicaciones que corren sobre él. Seamos francos. Usamos el sistema operativo cuyas aplicaciones nos permiten alcanzar nuestros objetivos, no por razones ideológicas. Cualquier otra consideración es falsa. Son las aplicaciones las que dan la victoria a un sistema operativo, no el s.o. en sí mismo. Y esa es la baza que jugó Microsoft para alcanzar el éxito. Entregó la API a los desarrolladores y estos devolvieron un sinfin de aplicaciones para Windows.
Es por eso que compiladores y herramientas de desarrollo (SDK) son gratuitas. Pero el núcleo central de la estrategia de Microsoft (el API de Windows), ha saltado por los aires. No desapareció todavía, pero tiene los dias contados.

En este punto Joel distingue dos facciones o fuerzas dentro de Microsoft, y las denomina "grupo Raymond Chen" y "grupo MSDN Magazine".
Raymond Chen es un desarrollador del equipo Windows desde 1992, y tiene una bitácora llamada "The Old New Thing" donde cuenta siempre interesantes detalles técnicos de porqué en Windows las cosas son como son. Incluso las más incomprensibles.
Lo más importante para el "Grupo Raymond Chen" es la compatibilidad binaria, es decir, una aplicación que funciona en una versión de windows debe de poder funcionar en todas. Esto, como podéis imaginar, supone un esfuerzo brutal en pruebas de todo tipo de programas imaginables.
La fuerza de esta opción se ve en el hecho de que por ejemplo, cuando los "testers" de Microsoft descubren que SimCity, por su particular uso de la memoria, no funciona con Windows, se descompila el juego y con la información obtenida se modifica el código de Windows para que detecte cuando SimCity se esté ejecutando y gestione la memoria de manera diferente.
Y esto no es un caso aislado.

Raymond Chen llega a decir: "I get particularly furious when people accuse Microsoft of maliciously breaking applications during OS upgrades. If any application failed to run on Windows 95, I took it as a personal failure. I spent many sleepless nights fixing bugs in third-party programs just so they could keep running on Windows 95."

La otra "facción",el MSDN Magazine, es aquella que siempre trata de que uses toda nueva y compleja tecnología que Microsoft proponga. ¡ Aunque no la use ni Dios !
COM+, MSMQ, MSDE, Microsoft Office, Internet Explorer y sus componentes, MSXML, DirectX, Windows Media Player,Sharepoint, y todo lo que se les ocurra inventar por raro e inutil que sea.
Es aquel grupo de personas que son felices enfrentándose al infierno de las librerías (DLL Hell).
Su frase más común vendría a ser: "en mi equipo funciona".

El primer grupo trabaja en el convencimiento de que las cosas se les ponen fáciles a los desarrolladores cuando programan una vez y lo hacen funcionar donde quieran (sobre Windows, claro). "Write Once, Run Everywhere".
El segundo piensa que lo mejor es proveer al desarrollador de montones de código y ayudas externas siempre que estén dispuestos a pagar el precio de increibles problemas de implementación y una dura curva de aprendizaje

Según Joel (y estoy de acuerdo con él), dentro de Microsoft, ha ganado la batalla el "grupo MSDN Magazine".

Esto explica porqué la plataforma NET no tiene compatibilidad hacia atrás con VB 6, por ejemplo.
Es la primera vez en la historia en la que cuando compras un producto Microsoft, todo lo anterior no vale. En un primer momento los desarrolladores pusieron el grito en el cielo, pero su paulatina migración al desarrollo Web acalló las críticas, aunque el daño ya estaba hecho.

Con este cambio de estrategia, las cosas ya vinieron rodadas. IIS 6.0 (equivalente a Apache en sistemas Windows) usa un modelo diferente de manejo de hilos que hace que antiguas aplicaciones no funcionen. El NET Framework 1.1 no es compatible con el 1.0., y al final, hasta el propio sistema operativo sucumbe a esta forma de hacer las cosas. Adiós al API de Windows. Ya no hay más Win32, ahora es WinFX. Código gestionado, seguro, XAML, Avalon...una total ruptura con el pasado.

En este punto, gran parte de los desarrolladores externos habían abandonado en masa la compleja programación para escritorio Windows y se habían pasado a la web. En los 90 se pensaba que la batalla entre lenguajes procedurales y orientados a objetos sería ganada por la POO. Luego se descubrió que esa batalla no era la guerra. La guerra la ganaron los lenguajes que libraban al programador de tener que manejar la memoria, lo que aumentaba la productividad. Ganó la recolección de basura. Ganó el código gestionado (Managed Code). Visual Basic ganó a C++.

Y así llegamos a NET. Un sistema maravilloso, con gestión de memoria, un framework multilenguaje, nuevas opciones completamente orientadas a objetos y....bueno...casi nadie lo usa.

Ha pasado un poco como con los formatos RSS. Se fragmentó rápidamente en varias versiones y para tratar de arreglarlo se crea Atom, otra nueva especificación que añade aún más fragmentación. Cuando tratas de unificar dos alternativas creando una tercera...tienes tres alternativas.

No importa lo fuerte que sea la inversión de Microsoft en Marketing para que usemos NET. La mayoría seguimos usando ASP 3, VB 6, C, C++. Al menos en mi caso tengo claro que cuando hay prisa y hay que solucionar un problema lo mejor es no meterse en el jardín del NET Framework.
Incluso aquellos que usamos NET lo usamos porque programamos ASP NET, lo que no requiere clientes Windows. En mi caso, intranets corporativas y aplicaciones accesibles mediante redes privadas virtuales (VPN).
Entre otras cosas, porque de aquí a dos años, con Avalon y Longhorn, todo el que haya desarrollado aplicaciones de cliente windows Forms, se encontrará con que no le sirven para nada. WinForms ha nacido muerto. A mí no se me ha ocurrido ni tocarlo.
A ver cómo capeamos las modificaciones y "mejoras" introducidas en la nueva versión de C#, que han prometido para el 2005. ¡¿pero a quién se le ocurre que necesitamos diferentes versiones de un lenguaje?!
Así que tenemos dos opciones: programar pensando que en dos o tres años nada de lo que se haga para el escritorio valdrá, o bien programar para Avalon teniendo en cuenta que pasará mucho tiempo antes de que alguien tenga ese nuevo sistema operativo instalado.

No es como en los 90, cuando el crecimiento en las ventas de PCs fué tan brutal que cada año había más ordenadores vendidos que la base total de máquinas instaladas. En esa tesitura, aquel que entregara su sistema operativo con cada PC vendido, tendría el mercado dominado. Eso hizo Microsoft. Mientras el mercado de Pcs creciera como el fuego, no habría problema. Ahora que todos tienen ordenador y les funciona razonablemente bien..¿para qué van a cambiar su copia de windows 95-98?. Con este problema se dieron de morros los de MicroSoft cuando decidieron no dar soporte a Windows 98. Han tenido que ceder unos años más en vista de que la gente no iba a cambiar de sistema operativo sólo porque ellos lo dijeran.
Con este panorama, incluso si longhorn sale al mercado en el año 2006 (ni de coña cree eso nadie), tomará un par de años que la gente siquiera tenga en cuenta la posibilidad de actualizarse. Un par de años que Linux tiene que aprovechar muy bien si quiere tener éxito. Y me refiero a crear un buen entorno para programar. Atraer programadores en torno a un estándar (tanto en herramientas de desarrollo como API) independiente de la distribución es el empuje que necesita Linux.

Hay una segunda decisión que hacer cuando uno se pone a programar una aplicación: ¿programo para la lenta y poco flexible Web o programo un rico cliente que permite mucha interacción con el usuario?. Las diferencias están claras. Las aplicaciones ligeras (web) son fáciles de implementar, mientras que las aplicaciones pesadas (cliente) ofrecen una rápida respuesta y un entorno interactivo más rico para el usuario. La aplicacion web es tan sencilla de instalar como teclear una URL en el navegador y no presenta ni de lejos la minima parte de problemas de compatibilidad con el software instalado que presentan las aplicaciones pesadas. Además siempre tendremos disponible la última versión para todos los usuarios.
Esto, claro, tiene limitaciones en el tipo de aplicaciones que se pueden implementar. En general, aquellas que requieran cortos tiempos de respuesta o alta carga gráfica o mínimo uso del ratón (¿alguien ha intentado navegar sin él?) son inviables en la web. Joel opina que el tema del ratón se soluciona con Javascript pero yo en este caso no estoy de acuerdo con él. Pese a que el explorer se ha convertido en el navegador dominante, nunca puedes dejar de lado la programación "cross browser", lo que en muchos casos implica programar la misma aplicación dos veces como mínimo. Y como máximo, una vez por cada navegador presente en el mercado. ASP NET cubre muy bien ese frente haciendo que nos olvidemos del navegador del cliente dado que genera el código en función del navegador que lo solicita, aunque de momento no se ha llegado a la perfección en esta estrategia. En mi caso tengo suerte, para las intranets controlo el navegador utilizado y programo para él. Lo que no me quita de problemas ante los parches y actualizaciones que en algunos casos hacen que falle la aplicación. Me he encontrado curiosas combinaciones de "packs de seguridad" que tras instalarse y detectar una versión del Explorer muy concreta inhabilitaba totalmente cualquier aplicación que llevase javascript en los menús.

En suma. No me preocupa la API. Me preocupa el navegador. Me preocupa que cumpla los estándares. Me preocupa que sea seguro. Y personalmente voto por FireFox. Aunque en este caso tengo problemas para implementar las aplicaciones. No he logrado que los botones y los formularios funcionen todos perfectamente, supongo que es cuestión de dedicarle más tiempo. La última vulnerabilidad descubierta con explorer hace que sea aún más urgente no usar este navegador. Eso siempre es mejor que dejar de usar el ordenador cada vez que se descubre un agujero, como dijo aquel incompetente asesor de "seguridad".

Sin embargo, va Microsoft, agarra, coge y paraliza totalmente cualquier nuevo desarrollo relativo al navegador. DHTML y HTA fueron cortados de raiz. Por una sencilla razón."Microsoft is betting the company on the rich client.", es decir, Microsoft arriesga la empresa apostando por las aplicaciones pesadas o "rich clients". Avalon, Longhorn, y demás parafernalia son desarrollos que vienen a potenciar aún más el escritorio. No les interesa la web y por eso no hay nueva versión del navegador desde hace tiempo.

Joel dice: "Es demasiado tarde", y estoy de acuerdo con él. Si me dieran a elegir, siempre elegiría desarrollar mis aplicaciones en entorno intranet y manejarlas via navegador. El tiempo de desarrollo es menor, la implementación es más sencilla, y el mantenimiento también. Si tuvieramos que dar el mismo soporte que damos a nuestros clientes con aplicaciones de escritorio nuestro departamento de informática debería ser al menos tres veces más grande.

Esto tiene un problema: como programador de intranets corporativas siempre ganaré menos dinero que como desarrollador de aplicaciones de escritorio. Por la sencilla razón de que cualquiera programa una aplicación web (con ciertas salvedades) mientras que muy pocos conocen win32. Joel lo describe muy gráficamente, en Nueva York un programador C++ y COM gana 130 mil dólares al año mientras que un programador web (Java, PHP, Perl, o ASP.NET) gana 80 mil dolares al año. La diferencia es clara. Y la razón también: no hay programadores que quieran pelearse con la API y sus extrañas llamadas. Y lo que es peor, no hay quien sepa. Y los que saben, ya son jefes de proyecto o directores de departamento, a los cuales hay que pagarles una millonada para forzarles a pelearse de nuevo con las malditas librerías.

La nueva API es el HTML, y Microsoft no se ha dado cuenta de ello.

Programación | jomaweb | 11 Comentarios | Enlace