Cómo Microsoft perdió la guerra de las API

From The Joel on Software Translation Project

Jump to: navigation, search

Contents

Cómo Microsoft Perdió la Guerra de las API

Por Joel Spolsky

Domingo, 13 de Junio de 2004

He aquí una teoría que se oye mucho en estos días: "Microsoft está acabado. En cuanto Linux haga su entrada al escritorio y las aplicaciones web reemplacen a las aplicaciones de escritorio, el poderoso imperio se derrumbará."

Aunque hay algo de verdad en el hecho de que Linux es una enorme amenaza para Microsoft, las predicciones de la desaparición de la compañía de Redmond son, como mínimo, prematuras. Microsoft tiene una cantidad increíble de dinero en el banco y todavía es increíblemente rentable. Le falta mucho antes de caer. Podría hacer todo mal por una década antes de empezar a estar remotamente en peligro, y uno nunca sabe... podrían reinventarse en el último minuto como una compañía de raspados de hielo. Así que no te apresures a despedirte de ellos. A comienzos de los 90' todo el mundo pensaba que IBM estaba completamente acabado: ¡Los mainframes eran historia! En ese entonces, Robert X. Cringley predijo que la era del mainframe terminaría el 1º de enero del 2000, cuando todas las aplicaciones escritas en COBOL serían abandonadas, y en lugar de mejorar esas aplicaciones, para las cuales además, el código fuente haría mucho que se habría perdido, todo el mundo reescribiría esas aplicaciones para plataformas cliente-servidor.

Bueno, adivinen. Los mainframes todavía están entre nosotros, nada pasó el 1º de enero del 2000, e IBM se reinventó a sí mismo como una compañía consultora de tecnología que además fabrica teléfonos baratos de plástico. Así que extrapolar a partir de unos pocos apuntes de información hasta la teoría de que Microsoft está terminado es realmente una exageración.

Aún así, existe un fenómeno menos comprendido que pasa generalmente sin ser notado: la joya de la corona estratégica de Microsoft, la API de Windows, se ha perdido. La piedra basal del poder monopólico de Microsoft y de las increíblemente redituables franquicias Windows y Office, que representan virtualmente todo el ingreso y cubre un enorme conjunto de no-rentables o marginalmente rentables líneas de productos; la API de Windows, ya casi no interesa a los desarrolladores. La gallina que pone huevos de oro no está todavía muerta, pero tiene una enfermedad terminal, una que nadie ha notado aún.

Ahora que lo he dicho, permítanme disculparme por la grandilocuencia y pomposidad del párrafo precedente. Creo que comienzo a sonar como esos escritores de editoriales de revistas que se explayan largamente acerca de la mejor posesión estratégica de Microsoft, la API de Windows. Me va a tomar unas cuantas páginas, aquí, explicar de qué estoy hablando realmente y justificar mis argumentos. Por favor, no salten a conclusiones hasta que haya explicado de qué estoy hablando. Este será un largo artículo. Necesito explicar qué es la API de Windows; necesito demostrar por qué es la posesión estratégica más importante de Microsoft; necesito explicar cómo se perdió y cuáles son las implicaciones de ello a largo plazo. Y debido a que estoy hablando de grandes tendencias, necesito exagerar y generalizar.

Desarrolladores, Desarrolladores, Desarrolladores, Desarrolladores

¿Recuerdan la definición de un sistema operativo? Es la cosa que gestiona los recursos de una computadora para que los programas puedan ejecutarse. A la gente en realidad no les importa mucho los sistemas operativos; les importa esas aplicaciones que el sistema operativo hace posible. Procesadores de texto. Mensajería instantánea. Email. Pago de cuentas. Sitios web con fotografías de Paris Hilton. En sí mismo, un sistema operativo no es muy útil. La gente compra sistemas operativos debido a las útiles aplicaciones que pueden ejecutarse en él. Por tanto el sistema operativo más útil será aquel que tenga las aplicaciones más útiles.

La conclusión lógica de esto es que si estás tratando de vender sistemas operativos, lo más importante de lograr es hacer que los desarrolladores de software quieran desarrollar software para tu sistema operativo. Es por eso que Steve Ballmer saltaba por todo el escenario gritando "Desarrolladores, desarrolladores, desarrolladores, desarrolladores." Es tan importante para Microsoft, que la única razón por la que no regalan simplemente herramientas de desarrollo para Windows es porque no quieren inadvertidamente cortar el oxígeno competitivo de los otros fabricantes de herramientas de desarrollo (bueno, aquello que quedan); porque tener una gran variedad de herramientas de desarrollo disponibles para su plataforma los hace más atractivos para los desarrolladores. Pero realmente quieren regalar herramientas de desarrollo. A través de su programa Empower ISV se puede conseguir cinco conjuntos completos de MSDN Universal (también conocido como "básicamente cada producto Microsoft excepto Flight Simulator") por unos $375. Compiladores de línea de comandos para lenguajes .NET son incluídos con el runtime gratuito .NET... también gratis. El compilador C++ es ahora gratuito. Cualquier cosa con tal de alentar a los desarrolladores a producir para la plataforma .NET, y manteniéndose muy cerca de barrer con compañías como Borland.

¿Por qué Apple y Sun No Pueden Vender Computadoras?

Bueno, por supuesto, eso es un poco tonto: por supuesto que Apple y Sun pueden vender computadoras, pero no para los dos mercados más lucrativos de las computadoras, el escritorio corporativo y la computadora hogareña. Apple está aún allí en los muy bajos porcentajes de un dígito de participación de mercado y las únicas personas con Suns en sus escritorios están en Sun. (Comprende por favor que estoy hablando de tendencias mayoritarias aquí, por lo tanto, cuando digo cosas como "nadie" en realidad quiero decir "menos de 10.000.000 personas," y así por el estilol)

¿Por qué? Porque las computadoras de Apple y Sun no ejecutan programas Windows; o, si lo hacen, es en algún tipo de costoso modo de emulación que no funciona demasiado bien. Recuerden, la gente compra computadoras para las aplicaciones que utiliza, y hay tantos más programas de escritorio disponible para Windows que para Mac que es muy difícil ser usuario de Mac.

¿Qué es esa cosa "API"?
Cuando estás escribiendo un programa, digamos, un procesador de textos, y quieres mostrar un menú, o escribir en un fichero, tienes que pedirle al sistema operativo que lo haga por tí, usando un conjunto muy específico de llamadas a función que son diferentes en cada sistema operativo. Estas llamadas a función son llamadas la API: es la interfaz que un sistema operativo, como Windows, provee a los desarrolladores de aplicaciones, como los programadoes haciendo procesadores de textos y hojas de cálculo y qué no. Es un conjunto de miles y miles de detalladas e intrincadas funciones y subrutinas que los programadores pueden usar, que hacen que el sistema operativo pueda hacer cosas interesantes como mostrar un menú, leer y escribir archivos, y cosas más esotéricas como averigüar cómo se escribe una fecha en Serbio, o cosas extremadamente más complejas como exhibir una página web en una ventana. Si tu programa usa las llamadas a la API de Windows, no va a funcionar en Linux, que tiene diferentes llamadas a API. A veces hacen aproximadamente la misma cosa. Esa es una importante razón por la que el software Windows no se ejecuta en Linux. Si quieres que un programa Windows se ejecute en Linux, tendrás que reimplementar la API de Windows por entero, la cual consiste en miles de complicadas funciones: esto es casi tanto trabajo como implementar Windows mismo, algo que le llevó a Microsoft miles de años-persona. Y si cometes un pequeño error o ignoras una función que una aplicación necesita, ésa aplicación se bloqueará.

Y es por eso que la API de Windows es una posesión tan importante para Microsoft.

(Ya sé, ya sé, en este momento el 2.3% del mundo que usa Macintoshes están calentando sus programas de email para enviarme una cáustica misiva acerca de cuánto aman sus Macs. Nuevamente, estoy hablando en grandes escalas y generalizando, no pierdas tu tiempo. Sé que amas tu Mac. Sé que ejecuta todo lo que necesitas. Te amo, eres un primor, pero eres sólo el 2.3% del mundo, así que este artículo no es sobre tí.)

Las Dos Fuerzas en Microsoft

Hay dos fuerzas opuestas dentro de Microsoft, a las cuales voy a referirme, un poco irónicamente, como El bando de Raymond Chen y El bando de MSDN Magazine.

Raymond Chen es un desarrollador en el equipo Windows de Microsoft. Ha estado allí desde 1992, y su weblog The Old New Thing está repleto de detalladas anécdotas técnicas acerca de por qué ciertas cosas son como son en Windows, incluso cosas tontas, que resultan tener muy buenas razones.

Las cosas más impresionantes de leer en el weblog de Raymond son las historias de los increíbles esfuerzos que el equipo Windows ha hecho a lo largo de los años para soportar retro-compatibilidad:

Vean el escenario desde el punto de vista del cliente. Compraste los programas X, Y, y Z. Luego se actualizaste a Windows XP. Ahora tu computadora se bloquea aleatoriamente, y el programa Z no funciona en absoluto. Vas a ir y decirle a tus amigos, "No se actualicen a Windows XP. Se bloquea aleatoriamente, y no es compatible con el programa Z." ¿Vas a depurar tu sistema para determinar que el programa X está causando los bloqueos, y que el programa Z no funciona porque está usando mensajes de ventana no documentados? Por supuesto que no. Vas a regresar Windows XP y pedir un reembolso. (Compraste los programas X, Y y Z hace algunos meses. La póliza de reembolso de 30 días ya no es válida para ellos. Lo único que puedes regresar es Windows XP.)

Supe esto por primera vez de uno de los desarrolladores del juego SimCity, quien me dijo que había un bug crítico en su aplicación: utilizaba memoria justo después de liberarla, un no-no mayúsculo que incidentalmente funcionaba muy bien en DOS pero no funcionaría en Windows donde la memoria que es liberada probablemente será de inmediato ocupada por otra aplicación ejecutándose. Los testers del equipo Windows pasaron por varias aplicaciones populares, probándolas para asegurarse de que funcionaban bien, pero SimCity seguía bloqueándose. Lo reportaron a los desarrolladores de Windows, quienes desensamblaron SimCity, lo pasaron por un depurador, encontraron el bug, y agregaron un código especial que comprobaba si SimCity estaba ejecutándose, y si lo hacía, ejecutaba la reserva de memoria en un modo especial en el que aún se podía usar memoria luego de liberarla.

Éste no era un caso poco frecuente. El equipo de pruebas de Windows es inmenso y una de sus responsabilidades más importantes es garantizar que todo el mundo pueda actualizar con seguridad sus sistemas operativos, sin importar qué aplicaciones tienen instaladas, y ésas aplicaciones continuarán funcionando, incluso si esas aplicaciones hacen cosas malas o utilizan funciones sin documentar o se basan en comportamiento erróneo que sucede ser erróneo en Windows n pero ya no es erróneo en Windows n+1. De hecho, si curioseas en la sección AppCompatibility de tu registro, verás una lista completa de las aplicaciones que Windows trata de manera especial, emulando muchos viejos bugs y comportamiento anómalos para que continúen funcionando. Raymond Chen escribe, "Me pone especialmente furioso cuando la gente acusa a Microsoft de bloquear maliciosamente aplicaciones durante actualizaciones de SO. Si cualquier aplicación fallaba en ejecutarse en Windows 95, lo tomaba como un fracaso personal. Pasé muchas noches sin dormir arreglando bugs en programas de terceros sólo para que puedan funcionar en Windows 95."

Muchos desarrolladores e ingenieron no están de acuerdo con esta manera de trabajar. Si la aplicación hizo algo malo, o se basaba en algún comportamiento sin documentar, ellos piensan, debería ser bloqueada cuando el SO se actualiza. Los desarrolladores del SO de Macintosh en Apple siempre han pertenecido a este bando. Es por eso que tan pocas aplicaciones de los primeros días de Macintosh todavía funcionan. Por ejemplo, muchos desarrolladores solían tratar de hacer que sus aplicaciones Macintosh se ejecuten más rápido copiando punteros de la tabla de saltos y llamándolos directamente en lugar de usar la propiedad interrupt del procesador como se suponía que hicieran. Incluso cuando en algún lugar de Inside Macintosh, la Biblia oficial de Apple para programación de Macintosh, había una nota técnica diciendo "no puedes hacer esto," ellos lo hacían, y funcionaba, y sus programas se ejecutaban más rápido... hasta que la siguiente versión del SO salió y ya no se ejecutaron en absoluto. Si la compañía que hizo la aplicación quedaba fuera del negocio (y la mayoría de ellas lo hicieron); bueno, mala suerte amigo.

En contraste, yo tengo aplicaciones DOS que escribí en 1983 para el muy original PC de IBM que todavía se ejecutan sin fallos, gracias al bando de Raymond Chen en Microsoft. Ya sé, no es sólo Raymond, por supuesto: es todo el modus operandi del equipo de la API Windows. Pero es Raymond quien mayormente lo ha hecho público a través de su excelente website The Old New Thing así que le daré su nombre.

Ése es un bando. El otro bando es el que voy a llamar el bando de MSDN Magazine, el cual bautizaré como la revista para desarrolladores llena de emocionantes artículos acerca de las diferentes maneras en que puedes pegarte un tiro en el pie usando esotéricas combinaciones de productos Microsoft en tu propio software. El bando de MSDN Magazine siempre está tratando de convencerte de que uses nuevas y complicadas tecnologías externas como COM+, MSMQ, MSDEW, Microsoft Office, Internet Explorer y sus componentes, MSXXL, DirectX (la más reciente versión, por favor), Windows Media Player, y Sharepoint... ¡Sharepoint! el cual nadie tiene; una verdadera panoplia de dependencias externas cada una de las cuales va a ser un enorme dolor de cabeza cuando envíes tu aplicación a un cliente y no funcione bien. El nombre técnico para esto es Infierno DLL. Funciona aquí: ¿por qué no funciona allá?

El Bando de Raymond Chen cree en hacer las cosas fáciles para los desarrolladores haciéndo fácil escribir una vez y ejecutar en cualquier parte (bueno, en cualquier máquina Windows). El bando de MSDN Magazine cree en hacer las cosas fáciles para los desarrolladores dándoles porciones realmente poderosas de código que ellos podrán reutilizar, si están dispuestos a pagar el precio de implementaciones increíblemente complicadas y jaquecas de instalación, sin mencionar la empinada curva de aprendizaje. El bando de Raymond Chen apunta a la consolidación. Por favor, no hagan peores las cosas, nada más sigamos haciendo que las cosas que tenemos aún funcionen. El bando de MSDN Magazine necesita seguir produciendo en serie gigantescas piezas de tecnología que nadie puede dominar.

He aquí por qué esto importa.

Microsoft Perdió la Religión de la Retrocompatibilidad

Dentro de Microsoft, el bando de MSDN Magazine ganó la batalla.

Su primera gran victoria fue hacer Visual Basic.NET no retro-compatible con VB 6.0. Ésta fue literalmente la primera vez en la memoria viviente en que cuando compraste una actualización para un producto Microsoft, tus antiguos datos (p. ej. el código que habías escrito en VB6) no podía ser importado perfecta y silenciosamente. Era la primera vez en que una actualización de Microsoft no respetaba el trabajo que los usuarios realizaron usando versiones anteriores de un producto.

Y el cielo no parecía estar cayéndose, no dentro de Microsoft. Los desarrolladores de VB6 estaban molestos, pero ya estaban desapareciendo de todas formas, debido a que la mayoría de ellos eran desarrolladores de corporaciones que estaban migrando al desarrollo web de todas formas. El verdadero daño a largo plazo estaba oculto.

Con esta victoria mayúscula en su cinturón, el bando de MSDN Magazine se impuso. De repente era correcto cambiar cosas. IIS 6.0 salió con un modelo diferente de threading que anuló algunas viejas aplicaciones. Yo estaba conmocionado al descubrir que nuestros clientes con Windows Server 2003 estaban teniendo problemas para ejecutar Fogbugz. Entonces .NET 1.1 no era perfectamente retro-compatible con 1.0. Y ahora que el gato estaba fuera de la bolsa, el equipo del SO atacó a fondo y decidió que en lugar de agregar características a la API Windows, iban a reemplazarla por completo. En lugar de Win32, se nos dijo, debemos empezar a prepararnos para WinFX la siguiente generación de la API Windows. Completamente diferente. Basada en .NET con código gestionado. XAML. Avalon. Sí, vastamente superior a Win32, lo admito. Pero no una actualización: una ruptura con el pasado.

Los desarrolladores externos, quienes nunca estuvieron particularmente felices con la complejidad del desarrollo para Windows, han abandonado la plataforma Microsoft en-masse y ahora están desarrollando para la web. Paul Graham, quien creó Yahoo! Stores en los primeros días del boom puntocom, lo resumió elocuentemente: "Hay muchas más razones para que quienes recién comienzan escriban software basado en la web ahora, porque escribir software para escritorio se ha vuelto mucho menos divertido. Si quieres escribir software para escritorio ahora, lo haces en los términos de Microsoft, llamando a sus APIs y tratando de dar rodeos a los bugs de su SO. Y si consigues escribir algo que despega, podrías descubrir que simplemente estabas haciendo investigación de mercado para Microsoft."

Microsoft se hizo suficientemente grande, con demasiados desarrolladores, y se han vuelto tan adictos a la renta de las actualizaciones, que repentinamente decidieron que reinventar todo era un proyecto no demasiado grande. Diablos, podemos hacerlo dos veces. El viejo Microsoft, el Microsoft de Raymond Chen, podría haber implementado cosas como Avalon, el nuevo sistema gráfico, como una serie de DLLs que podían ejecutarse en cualquier versión de Windows y que podían ser incluídas con las aplicaciones que las necesitaban. No hay razones técnicas para no hacer esto. Pero Microsoft necesita darte una razón para comprar Longhorn, y lo que están tratando de hacer es un cambio geológico, similar al cambio geológico que ocurrió cuando Windows reemplazó a DOS. El problema es que Longhorn no es un gran avance con respecto a Windows XP; ni siquiera cercanamente tan grande a Windows con respecto a DOS. Probablmente no será lo bastante atractivo como para hacer que la gente compre nuevas computadoras y aplicaciones como lo hicieron para Windows. Bueno, quizás lo sea, Microsoft ciertamente necesita que lo sea, pero lo que he visto hasta ahora no es muy convincente. Muchas de las apuestas de Microsoft son las equivocadas. Por ejemplo, WinFS, publicitado como una manera de hacer búsquedas haciendo que el sistema de archivos sea una base de datos relacional; ignora el hecho de que la manera real de hacer búsquedas es haciendo una búsqueda. No me obliguen a escribir metadatos para todos mis archivos donde puedo hacer búsquedas usando un lenguaje query. Nada más háganme un favor y busquen en el maldito disco duro, rápido, la cadena de texto que he escrito, usando índices de puro texto y otras tecnologías que ya eran aburridas en 1973.

La Transmisión Automática Gana el Día

No me malinterpreten... Pienso que .NET es un gran entorno de desarrollo y Avalon con XAML es un tremendo avance con respecto a la manera antigua de escribir aplicaciones con interfaz de usuario para Windows. El avance más grande de .NET es el hecho de que tiene gestión automática de memoria.

Muchos de nosotros pensamos en los noventas que la gran batalla sería entre la programación procedural y la orientada a objetos, y pensamos que la programación orientada a objetos daría un enorme impulso a la productividad del programador. Yo creí eso, también. Algunos todavía piensan eso. Resultó ser incorrecto. La programación orientada a objetos es práctica, pero no es realmente el impulsor de productividad que fue prometido. El verdadero avance de productividad significativo que tuvimos en la programación ha provenido de los lenguajes que gestionan la memoria por uno de manera automática. Puede ser con conteo de referencias o recolección de basura; puede ser Java, Lisp, Visual Basic (incluso 1.0), Smalltalk, o cualquiera de los lenguajes de script. Si tu lenguaje de programación te permite tomar un pedazo de memoria sin pararte a pensar si va a ser liberada cuando termines con ella, estás usando un lenguaje con memoria gestionada, y vas a ser mucho más eficiente que alguien usando un lenguaje en el que tienes que gestionar memoria explícitamente. Cuandoquiera que oigas a alguien ufanándose acerca de lo productivo que su lenguaje es, probablemente está obteniendo la mayor parte de esa productividad de la gestión automática de memoria, incluso si la atribuyen incorrectamente.

¿Por qué la gestión automática de memoria te hace mucho más productivo?
1) Porque puedes escribir f(g(x)) sin preocuparte acerca de cómo liberar el valor de retorno de g, lo que significa que puedes usar funciones que retornen interesantes tipos de datos complejos y funciones que transformen interesantes tipos de datos complejos, a la vez que te permite trabajar a un nivel más alto de abstracción.
2) Porque no tienes que pasar tiempo escribiendo código para liberar memoria o rastreando fugas de memoria.
3) Porque no tienes que coordinar cuidadosamente los puntos de salida de tus funciones para asegurarse de que las cosas se limpian apropiadamente.

Los aficionados a carreras de autos probablemente me enviarán correo furiosos por esto, pero en mi experiencia hay solamente un caso, en la conducción normal, donde una buena transmisión automática es inferior a la transmisión manual. Similarmente en el desarrollo de software: en casi todos los casos, la gestión automática de memoria es superior a la gestión manual de memoria y resulta en mucha mayor productividad de programación.

Si estabas desarrollando aplicaciones para escritorio en los primeron años de Windows, Microsoft te ofrecía dos maneras de hacerlo: escribiendo código C que llama a la API Windows directamente y gestiona su propia memoria, o usando Visual Basic y teniendo tu memoria gestionada por tí. Estos eran los dos entornos de desarrollo que más he usado, personalmente, por los últimos 13 años o algo así, y los conozco por dentro y fuera, y mi experiencia dice que Visual Basic es significativamente más productivo. A menudo he escrito el mismo código, una vez en C++ llamando a la API Windows y una vez en Visual Basic, y C++ siempre toma tres o cuatro veces más tiempo. ¿Por qué? Gestión de memoria. La manera más fácil de ver por qué es mirar en la documentación de cualquier función de la API Windows que necesitan devolver una cadena de texto. Miren de cerca cuánto se discute alrededor del concepto de quién reserva la memoria para la cadena, y cómo negocias cuánta memoria será necesaria. Típicamente, tienes que llamar a la función dos veces - en la primera llamada, le dices que estás reservando cero bytes, falla con un mensaje "insuficiente memoria reservada" y convenientemente también te dice cuánta memoria necesitas reservar. Eso si eres tan afortunado como para no llamar una función que retorna una lista de cadenas o toda una estructura de variables. En cualquier caso, operaciones simples como abrir un fichero, escribirle una cadena y cerrarlo usando la API Windows en crudo puede tomar una página de código. En Visual Basic operaciones similares ocupan tres líneas.

Entonces, tenemos estos dos mundos de programación. Todo el mundo más o menos ha entendido que el mundo del código gestionado es con mucho superior al mundo del código no gestionado. Visual Basic era (y probablemente sigue siendo) el número uno de los lenguajes más vendidos de todos los tiempos y los desarrolladores lo prefirieron sobre C o C++ para el desarrollo en Windows, aunque el hecho de que "Basic" estaba en el nombre del producto hizo que los programadores "duros" lo menospreciaran aunque fuere un lenguaje moderno con un puñado de características orientadas a objeto y muy pequeño *gunk residual (números de línea y la sentencia LET hace tiempo que siguieron los pasos del Hula Hoop). El otro problema con VB es que la distribución requería incluír un runtime VB, lo cual era un gran problema para el shareware distribuído por módem, y, peor, dejaba a otros saber que tu aplicación fue desarrollada en (¡vergüenza!) Visual Basic.

Un runtime para Gobernarlos a Todos

Y así llegó .NET. Éste fue un gran proyecto, el super-duper proyecto unificante para limpiar todo el desorden de una vez por todas. Tendría gestión de memoria, por supuesto. Aún tendría Visual Basic, pero ganaría un nuevo lenguaje, uno que es en escencia virtualmente el mismo que Visual Basic pero con una sintaxis tipo C con paréntesis curvos y puntos y comas. Y lo mejor de todo, el nuevo híbrido Visual Basic/C sería llamado Visual C#, así que no tendrías que decirle a nadie que eras un programador de "Basic" nunca más. Todas esas horribles funciones Windows con sus colas y cuernos y bugs de retro-compatibilidad y semántica de retorno de cadena imposibles-de-entender serían eliminadas, reemplazadas por una sola, limpia interfaz orientada a objetos que sólo tiene un tipo de cadena. Un runtime para gobernarlos a todos. Era hermoso. Y lo lograron, técnicamente. .NET es un gran entorno de programación que gestiona tu memoria y tiene una rica, completa y consistente interfaz para el sistema operativo y una rica, súper completa y elegante librería de objetos para operaciones básicas.

Y aún así, la gente no está realmente usando mucho .NET.

Oh seguro, algunos de ellos lo hacen.

Pero la idea de unificar el desorden de Visual Basic y la programación de la API Windows creando un entorno de programación completamente nuevo, desde la base con no uno, no dos sino tres lenguajes (¿O hay cuatro?) es como la idea de hacer que dos niños encaprichados dejen de discutir gritando "¡Cállense!" más fuerte que ellos. Sólo funciona en TV. En la vida real, cuando gritas "¡Cállense!" a dos personas discutiendo a gritos sólo creas una discusión a tres bandos más ruidosa.

(A propósito, para aquellos que siguen el arcano pero políticamente comprometido mundo de los formatos de blog syndication feed, pueden ver la misma cosa allí. RSS se fragmentó con varias versiones diferentes, especificaciones imprecisas y muchos desacuerdos políticos, y el intento de limpiar todo creando otro formato más llamado Atom ha resultado en muchas diferentes versiones de RSS más una versión de Atom, especificaciones imprecisas y muchos desacuerdos políticos. Cuando tratas de unificar dos fuerzas opuestas creando una tercer alternativa, sólo terminas con tres fuerzas opuestas. No has unificado nada y no has arreglado nada realmente.)

Así que .NET en lugar de unificar y simplificar, tenemos un gran desorden de 6 bandos, con todo el mundo tratando de entender qué estrategia de desarrollo usar y saber si pueden permitirse el costo de portar sus aplicaciones existentes a .NET.

No importa cuán consistente Microsoft sea en su mensaje de mercadeo ("Sólo use .NET - ¡Confíe en nosotros!"), la mayor parte de sus clientes todavía están usando C, C++, Visual Basic 6.0, y el ASP clásico, sin mencionar todas las otras herramientas de desarrollo de otras compañías. Y quienes están usando .NET están usando ASP.NET para desarrollar aplicaciones web, que se ejecutan en un servidor Windows pero no requieren clientes Windows, lo cual es un punto clave sobre el cual hablaré más cuando me refiera a la web.

Oh, Espera, ¡Hay Más en Camino!

Ahora Microsoft tiene tantos desarrolladores en loca actividad que no es suficiente con reinventar la API Windows por entero: tienen que reinventarla dos veces. En la PDC* del año pasado preanunciaron la siguiente versión mayor de su sistema operativo, de nombre clave Longhorn, que contendrá, entre otras cosas, una API de interfaz de usuario completamente nueva, de nombre clave Avalon, reconstruída desde la raíz para aprovechar las ventajas de los veloces adaptadores gráficos de las computadoras modernas. y el renderizado 3D en tiempo real. Si estás desarrollando una aplicación con interfaz de usuario para Windows hoy utilizando el último-y-más-grandioso entorno de programación "oficial" de Microsoft para Windows, Winforms, vas a tener que empezar todo de nuevo en dos años para dar soporte a Longhorn y Avalon. Lo cual explica por qué WinForms ha muerto antes de nacer. Espero que no hayas invertido mucho en él. Jon Udel encontró una presentación de Microsoft titulada "¿Cómo Elijo Entre Windows Forms y Avalon?" y se pregunta, "¿Por qué tengo que elegir entre Windows Forms y Avalon?" Una buena pregunta, una para la cual no ha encontrado una gran respuesta.

Así que tenías la API Windows, tenías VB, y ahora recibes .NET, en varios sabores de lenguaje, y no te apegues demasiado a nada de eso, porque estamos haciendo Avalon; sabes, que sólo se ejecutará en el más reciente sistema operativo de Microsoft, el cual nadie tendrá por un laaaaargo tiempo. Y personalmente yo todavía no he tenido tiempo de aprender .NET muy profundamente, y no hemos portado las dos aplicaciones de Fog Creek del ASP clásico y Visual Basic a .NET porque no hay recuperación de la inversión para nosotros. Ninguna. Es sólo Humo y Movimiento en lo que a mí respecta: a Microsoft le encantaría que yo dejara de agregar nuevas características a nuestro software de rastreo de bugs y software de gestión de contenido y en lugar de eso, desperdiciar unos meses portándolos a otro entorno de programación, algo que no beneficiará ni a un sólo cliente y por lo tanto no nos hará ganar ni una sola venta adicional, y por lo tanto sería una completa pérdida de varios meses; lo cual es genial para Microsoft, porque ellos tienen software de gestión de contenido y software de rastreo de bugs también, así que nada les gustaría más que verme perder el tiempo andando en círculos actualizándome al sabor du jour, y luego perder otro año o dos haciendo una versión Avalon también, mientras ellos agregan nuevas características a su propio software competitivo. Claaaaaro.

Ningún desarrollador con un trabajo diurno tiene tiempo de mantenerse al tanto con todas las nuevas herramientas de desarrollo que salen de Redmond, aunque más no sea porque hay ¡demasiados malditos empleados en Microsoft haciendo herramientas de desarrollo!

No Estamos en 1990

Microsoft creció durante los ochentas y noventas, cuando el crecimiento en las computadoras personales era tan dramático que cada año había más computadoras nuevas vendidas que todas las instaladas. Eso significaba que si hacías un producto que sólo funcionaba en computadoras nuevas, en el lapso de un año o dos podía conquistar el mundo incluso si nadie se cambiaba a tu producto. Esa fue una de las razones por las que Word y Excel desplazaron a WordPerfect y Lotus tan rigurosamente: Microsoft sólo esperó a la siguiente ola de actualizaciones de hardware y vendió Windows, Word y Excel a las corporaciones comprando así la siguiente ronda de computadoras de escritorio (en algunos casos su primera ronda). Así que en muchos sentidos Microsoft nunca necesitó aprender cómo hacer que una base instalada se cambiara del producto N al producto N+1. Cuando la gente pedía una computadora nueva, era feliz de obtener las últimas cosas de Microsoft en la nueva computadora, pero es mucho menos probable que la actualizen. Eso no importaba cuando la industria del PC estaba creciendo como incendio forestal, pero ahora que el mundo está saturado de PCs y la mayor parte de ellas funcionan Bastante Bien, Muchas Gracias, Microsoft se está dando cuenta que toma mucho más tiempo a las novedades en salir. Cuando intentaron el "Fin de la Vida" de Windows 98, resultó que aún había demasiada gente usándolo y tuvieron que prometer que le darían soporte a la abuela por unos años más.

Desafortunadamente, estas Felices Estrategias*, cosas como .NET y Longhorn y Avalon, tratando de crear una nueva API en la cual retener a la gente, no funciona muy bien si todo el mundo está usando todavía sus suficientemente-buenas computadoras de 1998. Incluso si Longhorn sale a la venta cuando se supone que lo haga, en 2006, lo cual no creo ni por un minuto, aún tardará un par de años antes de que suficiente gente lo tenga como para que siquiera valga la pena considerarla una plataforma de desarrollo. Desarrolladores, desarrolladores, desarrolladores, desarrolladores, y desarrolladores no se están tragando esas sugerencias con desórdenes de personalidades múltiples de Microsoft acerca de cómo deberíamos desarrollar software.

Llega la Web

No estoy seguro cómo pude llegar tan lejos sin mencionar la Web. Cada desarrollador tiene una decisión qué tomar cuando planea una nueva aplicación de software: pueden construírla para la web o pueden construír una aplicación "cliente enriquecido" que se ejecute en PCs. Los pros y contras básicos son simples: las aplicaciones web son más fáciles de implementar, mientras que los clientes enriquecidos ofrecen tiempos de respuesta más rápida, permitiendo muchas más interesantes interfaces de usuario.

Las aplicaciones web son más fáciles de implementar porque no hay instalación involucrada. Instalar una aplicación web significa escribir una URL en la barra de locaciones. Hoy instalé la nueva aplicación de email de Google escribiendo ALT+D, gmail, CTRL+ENTER. Hay muchos menos problemas de compatibilidad y problemas de coexistencia con otro software. Cada usuario de tu producto está usando la misma versión así que nunca tienes que dar soporte a una mezcla de versiones anteriores. Puedes usar cualquier entorno de programación que quieras porque sólo tienes que hacerlo funcionar en tu propio servidor. Tus aplicaciones están automáticamente disponibles en virtualmente cualquier computadora considerable del planeta. Los datos de tus clientes, también, está automáticamente disponible en virtualmente cada computadora considerable del planeta.

Pero hay un precio que pagar en la suavidad de la interfaz de usuario. He aquí un par de ejemplos de cosas que realmente no se pueden hacer bien en una aplicación web:

  • Crear un programa rápido de dibujo
  • Construír una revisión ortográfica en tiempo real, con subrayado rojo ondulado
  • Advertir a los usuarios que van a perder su trabajo si presionan el botón de cerrar de su navegador
  • Actualizar una pequeña parte de la pantalla de acuerdo a un cambio que el usuario haga sin un viaje ida y vuelta hasta el servidor
  • Crear una rápida interfaz de teclado que no requiera el mouse
  • Permitir que la gente continúe trabajando cuando no están conectados a Internet

Todos estos no son grandes problemas. Algunos de ellos serán resueltos muy pronto por ingeniosos desarrolladores de Javascript. Dos nuevas aplicaciones web, Gmail y Oddpost, ambas aplicaciones de email, hacen realmente un trabajo decente evitando o resolviendo completamente algunos de estos problemas. Y a los usuarios no parece importarles los pequeños lapsos de la interfaz de usuario y la lentitud de las interfaces web. Casi toda la gente normal que conozco está perfectamente feliz con su email basado en web, por alguna razón, no importa cuánto intente convencerlos de que un cliente enriquecido es, em, más rico.

Así que la interfaz de usuario web está casi un 80% aquí, e incluso sin nuevos navegadores web podemos probablemente llegar a un 95%. Esto es suficientemente bueno para la mayoría de la gente y ciertamente es suficientemente bueno para los desarrolladores, quienes votaron por desarrollar casi cada nueva aplicación significativa como una aplicación web.

Lo cual significa que, de repente, la API de Microsoft ya no interesa demasiado. Las aplicaciones web no requieren Windows.

No es que Microsoft no se diera cuenta de que esto estaba sucediendo. Por supuesto que lo hicieron, y cuando las implicaciones se hicieron evidentes, clavaron los frenos. Promesas de nuevas tecnologías como HTAs y DHTML fueron detenidas en la salida. El equipo de Internet Explorer parece haber desaparecido; completamente desaparecido en acción por varios años. No hay manera en que Microsoft vaya a permitir a DHTML ser algo mejor de lo que ya es: simplemente es demasiado peligroso para su negocio central, el cliente enriquecido. El gran meme en Microsoft por estos días es: "Microsoft está apostando la compañía al cliente enriquecido." Verás eso en algún lugar de cada presentación sobre Longhorn. Joe Beda, del equipo Avalon, dice que "Avalon, y Longhorn en general, es la estaca en el suelo de Microsoft, que significa que creemos que el poder en tu escritorio, asentado allí localmente haciendo cosas geniales, llegó para quedarse. Estamos invirtiendo en el escritorio, creemos que es un buen lugar donde estar, y confiamos en que vamos a comenzar una nueva oleada de emociones..."

El problema es: ya es muy tarde.

Yo Mismo, Estoy un Poco Triste por Esto

Realmente estoy un poco triste por esto. Para mí la web es genial pero las aplicaciones basadas en la web con sus lamentables e inconsistentes interfaces de usuario de alta latencia son un enorme paso hacia atrás en el uso diario. Amo mis aplicaciones cliente enriquecidas y enloquecería si tuviese que usar versiones web de las aplicaciones que uso a diario: Visual Studio, CityDesk, Outlook, Corel PhotoPaint, QuickBooks. Pero eso es lo que los desarrolladores van a darnos. Nadie (con lo cual, de nuevo, quiero decir "menos de 10.000.000 de personas") quiere desarrollar para la API Windows nunca más. Los Capitalistas de Riesgo no invertirán en aplicaciones Windows porque tienen miedo de la competencia de Microsoft. Y a la mayoría de los usuarios no parece importarles las interfaces de usuario web tanto como a mí.

Y he aquí el remate: he notado (y confirmado esto con un amigo reclutador) que los programadores para API Windows aquí en New York City que conocen la programación C++ y COM ganan unos $130.000 al año, mientras que los típicos programadores web que usan lenguajes de código gestionado (Java, Perl, PHP, incluso ASP.NET) ganan unos $80.000 al año. Es una enorme diferencia, y cuando hablé con unos amigos de Servicios de Consultoría de Microsoft sobre esto admitieron que Microsoft ha perdido toda una generación de desarrolladores. La razón por la que cuesta $130.000 contratar a alguien con experiencia COM es porque nadie se molestó en aprender programación COM en los últimos ocho años o algo así, así que vas a tener que encontrar alguien realmente mayor, quienes por lo general ya están en puestos directivos, y convencerlos de que tomen un trabajo como programador raso, y vérselas con (Dios me ayude) marshalling y monikers y apartment threading y aggregates y tearoffs y un millón de otras cosas que, básicamente, sólo Don Box alguna vez comprendió, e incluso Don Box no soporta verlas nunca más.

Por mucho que odie decirlo, una enorme porción de desarrolladores hace mucho que se han mudado a la web y se rehúsa a regresar. La mayoría de los desarrolladores .NET son desarrolladores ASP.NET, desarrollando para un servidor web Microsoft. ASP.NET es brillante; he estado trabajando con desarrollo web por diez años y está realmente una generación adelantado de todo lo que existe. Pero es una tecnología para servidores, así que los clientes pueden usar cualquier tipo de escritorio que quieran. Y funciona perfectamente bien en Linux usando Mono.

Nada de esto augura algo bueno para Microsoft y los réditos de los que disfrutó gracias al poder de su API. La nueva API es HTML, y los nuevos ganadores en el mercado de desarrollo de aplicaciones serán las personas que puedan hacer al HTML cantar. 6

Personal tools