Educación y tecnología ¿por dónde empezar?

Hace algún tiempo, a propósito de un comentario de un dirigente de empresa chileno, me preguntaba acerca del real valor de los planes de soporte tecnológico en Argentina, Chile, Uruguay, y muchos otros sitios. Bien, esta semana tengo una respuesta sobre su valor en Argentina..."La netbook casi no se usa en el aula"...
Dice Franco Varise, en La Nación:

Las computadoras todavía no pueden competir con la tiza blanca, el pizarrón, el cuaderno, la lapicera y el eterno lápiz negro. Por ahora, las netbooks de los programas Conectar Igualdad y S@armientoBA, de los gobiernos nacional y porteño, respectivamente, no encuentran su lugar en las aulas argentinas.
Según un estudio del Observatorio de la Educación Básica de la Argentina, los dos millones de computadoras personales entregadas a alumnos de los niveles primario y secundario se utilizan poco y nada en las aulas. El relevamiento fue hecho para indagar sobre las deficiencias del sistema y poder corregirlas.
Estas no son buenas noticias para quienes creían que los maestros y los profesores iban a reemplazar los instrumentos tradicionales de enseñanza por las nuevas tecnologías como forma de complementar o enriquecer los contenidos educativos. El diagnóstico muestra que los docentes, y en consecuencia los chicos, usan las netbooks casi exclusivamente en sus casas. El estudio del Observatorio, integrado por la Fundación del Centro de Estudios en Políticas Públicas, la Universidad de Buenos Aires (UBA) y el Banco Santander, y que cuenta con el apoyo del Ministerio de Educación de la Nación, le puso datos a lo que había comenzado a notarse en el aula desde que comenzaron a entregarse las netbooks.
"Si bien el 90% de los profesores usan computadoras, no lo hacen en el aula", explicó el experto en educación, Gustavo Iaies, durante la presentación de los resultados del relevamiento y, agregó que, estos dispositivos tecnológicos, no encontraron aún un lugar curricular.

La falta de una currícula específica que incluya a la netbook dentro del aula es una de las explicaciones sobre la falta de resultados educativos de estos programas. Porque, si bien todos tienen la computadora, nadie sabe para qué usarla todavía.

Mientras se piense que con "fierros" y sin metas educativas se resuelve todo, la educación seguirá igual, y los únicos que prosperarán serán quienes ganen licitaciones de aprovisionamiento de recursos.

Windows Metro y sus clientes corporativos

Acabo de ver una presentación sobre la evolución del mercado de aplicaciones móviles, que muestra una tendencia abrumadoramente inclinada hacia el crecimiento de la venta de recursos móviles (tablets y teléfonos) en perjuicio de un mercado estancado de computadores de escritorio. Ninguna novedad, así como tampoco lo es que el contenido de las aplicaciones varía radicalmente del que poblaba los PCs de escritorio. Se trata de una verdadera explosión del alcance de las aplicaciones, que escalan al uso diario de cientos o miles de millones de personas. El hecho es que la computación corporativa o de negocios pasa a ser una fracción relativamente estable del mercado total, y, comparativamente, con un crecimiento mucho menor que el resto. Esta es, a mi juicio, la razón que explica el estilo del nuevo Windows 8: salir a luchar por una porción dominante en el mercado de móviles. ¿Estará a tiempo todavía, o estará condenado a compartir una porción dividida con la competencia ya suficientemente establecida? ¿Podría haber sido más adecuado, a partir de un núcleo común, desarrollar dos líneas de producto que respetaran las diferencias de estos dos mundos?
El problema está en el universo corporativo: ¿contempla Windows 8 genuinamente este mercado? Por ahora, por lo que veo, no: Fundamentalmente, lo único que se ha destinado a este mundo es Win32, al que se ha declarado obsoleto. Todas las herramientas y lenguajes disponibles apuntan a soportar lo nuevo, básicamente pensado para dispositivos móviles, poco aptos para el trabajo de escritorio. Ni siquiera, al menos por ahora, es posible arrancar una estación Win 8 en modo "tradicional": usted debe iniciar en Metro, y luego cambiar manualmente de modo: se avecina una pesadilla para todos los administradores de servicios de escritorio que tengan scripts de inicio de sistema...Microsoft desprecia las grandes diferencias que existen entre una estación de trabajo y un aparato de comunicación móvil.
¿Será esta la versión final corporativa? Creo que todavía habrá importantes cambios, y, quizá veamos todavía, en "el Service Pack 2", algo más próximo a lo que este mercado requiere. Entretanto, haga sus cálculos financieros para solventar el cambio, o estaciónese en Windows 7.
Mary-Jo Foley comentaba hace poco lo incómodo del nuevo panorama:

While many love the tiled Metro start screen and are looking forward to using it on touch tablets and PCs, many others aren’t keen on it — especially business users who are convinced that Metro will be nothing but a nuisance, especially on non-touch-enabled hardware, and that they’ll do most of their work in the Desktop app on Windows 8.
Paul Thurrott of Windows SuperSite told me a while back that he believed Microsoft would allow users to get around Metro using a group-policy setting, but when I ran that past my contacts at Microsoft, I was told this would likely not be the case. So in the end, it looks like So who knows at this point whether business users who don’t want Metro may get their wish, after all.
(...)
The other big looming question that many business users want more information about is what they will and won’t be able to do when it comes to managing their Windows 8 on ARM (WOA) tablets and PCs.
Microsoft posted a document for download on February 29 (not sure if intentionally or not) that outlined Consumer Preview features for business users. In that document, Microsoft corroborated word that WOA tablets won’t be able to join an Active Directory domain. Some sites have reported that the document also said that Microsoft wouldn’t allow WOA tablets to be managed at all using Microsoft’s own management tools.
(...)
Charles Fitzgerald, a former Microsoft exec now working at VMWare, noted that the domain join limitation means Microsoft won’t be able to one-up the iPad on this front. (And lack of manageability was one of the themes that Microsoft has advised its salesforce to use in selling agains the iPad in businesses.) From Fitzgerald’s March 1 post:

Lack of domain join “means Windows 8 ARM tablets are going to be consumer devices that don’t integrate with the Microsoft enterprise infrastructure any better than the iPad, so Microsoft loses what should have been a major selling point. You will have to sacrifice battery life and go with x86 to get enterprise features and manageability. This is a big blow to Microsoft’s tablet proposition for the enterprise and WOA may be DOA as a result.

Foley todavía dejaba lugar en su comentario a las novedades que la participación de Microsoft en CeBIT pudiera tener para mejorar este panorama. Hasta donde se puede ver, no ha habido cambios notables.

Plex 7.0 disponible

Desde hace unos pocos días está disponible la versión 7.0 de Plex, con buenas novedades especialmente para la variante .NET, soporte de Azure, servicios web, java/JEE (pensado para java 7), y el uso incrementado del API de Plex. Un aspecto que especialmente valoro es que su aparición mantiene un ciclo relativamente corto de actualizaciones.
La persistencia en el trabajo sobre el API del modelo facilita además la labor de partners, que pueden crear extensiones con mayor control sobre el modelo. Podemos decir que Plex sumado a las extensiones que explotan el API abierto, permiten cubrir ampliamente las plataformas existentes y las emergentes. En particular, estoy esperando en algunos días ver el primer ensayo sobre Windows 8 Metro, la ejecución de una aplicación construída con WebClient (Plex generando Java, HTML5, JavaScript, y CSS3). Considerando la evolución de Windows 8, creo que tenemos garantizada una nueva actualización de Plex en un ciclo más corto que el anterior.
Un documento de presentación está disponible en el sitio de CA.

Java y Metro/WinRT

Windows 8, en su versión orientada a futuro, es Metro/WinRT. Francamente, no sé si Metro será un nuevo Vista, condenado a ser cambiado a una nueva versión tras ser descartado masivamente; sin embargo, creo que está claro que este será el nuevo sistema operativo de Microsoft, con mayores o menores parches o variaciones, después de un mayor o menor paso de tiempo. Y también está claro que el API de Win32 tiene sus años contados, que será considerado "legacy", y que no se deben esperar mejoras futuras sobre él. En estas condiciones, que creo que son irreversibles desde el punto de vista de Microsoft, WinRT debe ser considerado como el futuro del mercado Windows dependiente.
Si esta premisa es cierta, la pregunta siguiente es acerca del universo de productos, lenguajes o herramientas construídas sobre y para esta plataforma: seguramente, algunas que ya hoy han quedado obsoletas, o cambiarán radicalmente, o deberán repensar una tecnología que las suplante, como sería el caso de Flash. Otras, las más, enfrentan un camino complicado. Particularmente, en este momento pienso en Java; no sé si tendrá sentido crear una máquina virtual pensando en Metro como interfaz de usuario (tiles, pantalla táctil), que pudiera quedar a futuro como algo más asociado al usuario final, a tablets, a dispositivos móviles en general. Pero seguramente sí debe comprobarse que una máquina virtual puede ejecutarse sobre WinRT. No he visto todavía ningún pronunciamiento de Oracle ni de otros responsables del estándar, y probablemente pase algún tiempo antes de que haya alguno; habrá problemas de políticas (qué excelente momento para cerrar Windows a la competencia...), antes de resolver cómo enlazar la máquina virtual. por ahora, solo es posible encontrar algunos sencillos intentos de ejecutar java, algunos logrados, pero doy por entendido que estos casos lo han hecho sobre el escritorio (Win32). La siguiente es una pequeña lista de  casos en este sentido:
Ejecutando Java en DOS, claramente sobre Win32,
Lo mismo, en una edición temprana.
Un intento de  instalar Eclipse.
Un intento algo inadvertido, quizá sobre Metro, pero que cae hacia Win32.
Un intento con muchos problemas.

Sin embargo, lo más sustancioso está en otros casos tempranos enfocando Metro/WinRt. Particularmente uno en Google Groups (The Java Posse), discutiendo los problemas de arquitectura (aunque para nada hay que despreciar otro argumento discutido allí: "The real reason is Microsoft pathetically trying to exclude competitors and competing technologies, trying to impose HTML5 for everything"):

So it seems that Windows 8's new "Metro" user environment will make IE plugin-free. Any attempt to use plugins like Flash, Java, Silverlight or anything else, will bring the user to the "old-style" (as in  Windows 7) desktop, which will be seen as a severe experience degradation for users who prefer the new environment.

I am not as much plugin-hater as some people; in my Android smartphone, I certainly appreciate the support for Flash, for simple practical purposes - the rare website that uses some Flash and has no mobile-optimized version or native Android app. And yeah, my karma be damned but Flash works well enough  for me (admittedly on a nice hardware - Tegra2, dual-core Droid X2, rooted & debloated, Flash updated to 10.3).

Still, I love the idea of a plugin-free world, if only for the security improvement. (Including avoidance of trash like "security plugins" mandated by online banking sites...) But this is not really fair if we consider modern browsers that run plugins in separate and low-privilege processes, plus enhanced plugin technology like Google's (Pepper and NaCl / PNaCl), plus plugins for runtimes that are managed and have their own sandboxing and security mechanisms and are sufficiently well patched (candidates: Java, Flash, Silverlight - yes none of them are perfect, they all add some to the attack surface, but the ever-growing browser is already a huge attack surface, there's no single week going without new security bugs being found in every major browser so I don't think the "three big" plugins would make things significantly worse).

There's already people betting that Microsoft will have to back away and maybe, put an option to allow plugins in Metro mode even if not active by default. I know for sure, that corporations are writing new apps with things like Flash, by the thousands. Everybody complains that the corporate world is still dragging its feet with old versions of IE, remarkably the much reviled IE6; but if you think that ActiveX code for IE6 is holding back the web, this is nothing compared to how much stuff depends on Flash. A plugin-free IE10+ will be adopted in corporate world by 2020 with some optimism...

What about the applet tag? This is not part of HTML5 anymore, but it's part of previous versions even if deprecated. This should give Java applets special privileges, at least if Metro-mode-IE will support pre-HTML5 markup (and sure as hell it must, for a long time still). I'm too lazy to install the Win8 beta just to check this, would anybody report if applet [tag] works in Metro/IE? Just curious, I guess it doesn't...

Even in HTML5, there's the [object] tag which is supported and not even deprecated. Will Microsoft break the spec and declare that this feature of HTML5 is not supported in Metro mode? What about Java WebStart, maybe the deployment toolkit can be adapted to detect Metro and not depend on [object], I guess the only fundamental need is the ability to download a JNLP file and launch the associated program? Will Metro restrict such launching too? Both Oracle and Adobe are working on their Plan B for the eventual dominance of HTML5, with new tooling that convert their stuff in plain HTML5. In Oracle's case, there is hope for JavaFX 2.0 if its Web Runtime turns out to be good (it's not yet included in the public beta so I have no idea). There is no similar hope though for old-style, AWT/Swing applets or JAWS apps that will not benefit from a similar Web Runtime.

By the way, the JavaFX Web Runtime (WRT) will be a very interesting test for the claim that Javascript & HTML5 can be fast enough and powerful enough to build any application, competing at least with Java/Silverlight/Flash if not with native apps. Summarizing, the WRT will have a pure-web implementation of the JavaFX frameworks (animation, controls, graphics etc.), I guess using canvas or WebGL and Javascript; and the application code will be (perhaps partially) converted to Javascript code. So, supposing that this WRT is well designed and implemented - and that's a core part of the v2.0 reboot plan so I guess they carefully redesigned the whole thing to make the WRT possible - then if it turns out to be much less efficient than the conventional runtime, this will be strong evidence that the mantra "HTML5/Javascript is fast enough" is bullshit. Let's wait and see.

In another interesting development, Google's technologies like PNaCl and Dart can be powerful enablers for anything that generates Javascript code, from GWT to Adobe's and Oracle's  tools. Dart is supposed to be much more efficient than Javascript, and also, the Java language will probably be much
closer to Dart than it is to Javascript (less sure about AS3...); and I'm sure Oracle and Adobe can write new compilers that emit Dart code instead of Javascript code. Or even, PNaCl code. So if these Google technologies succeed, they can benefit other platforms too. We will still be able to run other browsers in Win8. 

Otra interesante apertura es la expuesta en Iced in code:

The big question now is where does JavaSE fit in all this bold re-imagining? Oracle/Sun have done a great deal of work over the past few years to get Java to work pretty well on Windows and become as natively integrated as possible, but with the re-working of Windows, Java will be confined to the “legacy” application section for the time being, and will not be able to play with the new cool kids in the “Metroverse”. I wonder what steps Oracle  is going to take to make Java still a viable product in the new Windows 8 platform, or will they simple give up and require us all to move to platform specific programming again, like C#?

y alguna acotación de lectores:

First, Oracle should under all circumstances make Java SE compatible with the new platforms like tables, macbooks and metro to keep their concept intact – OR – find a way to easily let Java SE applications run as “apps-likes” under another Java distribution made specificly to these platforms.
Second, Metro is nothing more (or less) than a simple “start-web-page”. Windows 8 is very similar to Windows 7, with program and filesystem seperated – where android and apple are more likely to melt these two things together. Therefore I doesn’t like andorid and apple as their operationsystem are defining the limitations. Some people would call that user-friendliness, I partially agree with that.
I believe that Windows 8 Metro will be an extension to their current desktop on traditional computers, but not a future replacement making the desktop legacy – and we won’t see anything like this within the next 10 years. But Windows 8 Metro will be the beginning of web and computers melting together – and this will eventually make the desktop computer look more like a tablet – and a tablet will look more like a desktop computer – and that will happen!

Uno de los casos que chocaron con WinRT.
Una discusión que refiere a Intel y ARM.

En fin, faltando una respuesta oficial de Oracle, comienza a abrirse el juego. ¿Va usted sopesando el impacto de Windows 8 en sus inversiones en licencias, plataformas, aplicaciones?

Firefox en Windows 8

Firefox anuncia sus planes de desarrollo del soporte para Windows 8. Su plan de trabajo delinea el tipo de dificultades con las que cualquier tercero se encontrará al trabajar para Windows 8 y Metro:

Mozilla’s Brian R. Bondy revealed today that development has begun on Firefox for Metro.

Last month, Mozilla’s Asa Dotzler announced that a Metro version of Firefox was in early planning stages, with a blog post about Mozilla’s goals that in turn linked to a roadmap. Dotzler is listed as the product manager.

Today’s announcement fleshes out some of the key decisions that the Mozilla team has made in the past month.

According to Bondy, Firefox for Metro will mimic Internet Explorer 10’s split personality, as a “Metro style enabled desktop browser”:

Unlike Metro applications, Metro style enabled desktop browsers have the ability to run outside of the Metro sandbox. Meaning not only can we build a browser, but we can build a powerful browser which gives an experience equal to that of a classic Desktop browser.

Metro style enabled desktop browsers have access to most Win32 API and the entire new WinRT API.

Unfortunately a browser can only participate in Metro mode if it is the default browser. So if Firefox is not the default browser on a system, you can’t use it in Metro mode. This is a decision made by Microsoft.

Volveremos sobre la "doble personalidad...

Metro y la herencia de Win32, II

Mientras recopilo información de Windows 8, pensando en el impacto que pudiera tener sobre las aplicaciones existentes (Win32), encuentro estas observaciones de Osvaldo Doederlein, ingeniero en Google:

Microsoft's "squaring of the circle" is by no means perfect: it looks more like an octogon to me. And while I understand and even appreciate the new UI concepts (semantic zoom, layout, typography etc.), its current rendering still looks crude, and (like Peter mentions) the Desktop and Metro look totally alien to each other. Maybe Microsoft can still work on this and make Metro's look more polished, and more similar to the desktop. I like shades, subtle 3D effects, and other decorations that a large display can use (and yeah, OSX uses more elegantly than anyone, though I'm happy enough with Win7). And I'm not visually impaired to need fonts with grotesque sizes everywhere; I'll rather see more data in one screen than need lots of horizontal scrolling (which is really cumbersome on mouse systems). My PC is not a giant Windows Phone!

Now I realize that MS is struggling in the smartphone and tablet markets, and having a single OS and UI that carries over all these platforms will be a big win. Can't really blame Microsoft: Apple is moving in the same direction with Mountain Lion (but not as aggressively as Metro). Even at Google we have Android and ChromeOS, but these platforms are more device-/web-/cloud-centric, and they have no desktop legacy; also, they're not competing on full desktops, to run complex apps like Photoshop (at work, I use Goobuntu for my "macho apps" like Eclipse). The problem is, after years of failure trying to shoehorn the classic Windows into tablets, Microsoft went to the opposite extreme--the total "tabletification" of the PC. Big mistake; there's no reason to believe a device-centric UI will be optimal for a conventional PC, remarkably when running sophisticated applications like IDEs, graghic editors, office suites etc.

Esta es mi especial preocupación. Así como y antes observara respecto a la tecnología de Activex frente al énfasis en .NET, existe un riesgo evidente de que todo el universo de aplicaciones basadas en Win32 y en la interfase visual del Windows [ahora] tradicional, se encuentre ante un futuro de difícil encaminamiento. Por necesidad, volveré sobre esto. Mi cuenta de aplicaciones Win32 a atender es demasiado grande.

Windows 8, WinRT y la herencia de Win32

Este miércoles pasado ha sido un día especial en la pre campaña de lanzamiento de Windows 8: se ha iniciado su "consumer preview", con presentación especial en el Mobile World Congress de Barcelona, y comentarios simultáneos en toda publicación tecnológica que se precie. Sigue resultándome muy curioso que un producto todavía inmaduro, cuyas prestaciones aún no están completas, sea presentado primero a la comunidad de desarrolladores (esto sí es normal) y luego al público en general, tal como está. Sin embargo, puede decirse en este caso en que existe un cambio muy grande en el producto, que puede ser entendible: medir la respuesta, conocer temprano los fallos más gruesos, delinear un mercado de aplicaciones, entusiasmar al cambio. La actividad de difusión entre desarrolladores y socios de negocios ha sido intensa, y sus principales características son bastante conocidas. Desde hace meses se pueden encontrar evaluaciones, comentarios, ensayos, normalmente favorables a Windows 8, y pocas observaciones críticas. ¿No existen reservas críticas sobre los cambios de magnitud que se avecinan?
Sí existen, pero hubiera preferido ver más distanciamiento y criterio en desarrolladores, actores varios de consultoría  y comercializadores, en cuanto al impacto que Windows 8 pueda llegar a tener sobre el mercado actual de usuarios de empresa. Algo que ahora pudiera llamarse un mercado "legacy" o "tradicional", si comparamos lo que hoy usan, y lo que Windows 8 propone.
Partiendo del hecho de que la arquitectura propuesta (WinRT) es diversa y no integrable con la anterior, todo lo que hoy existe está inicialmente confinado al ámbito de Win32, un ámbito sin prioridad de evolución en cuanto a proyectos, y también al momento de ejecutarse. Usted puede construír una nueva aplicación desde cero para ser expuesta en WinRT (y ser aceptada por la AppStore), y se sentirá muy felíz de aprovechar sus ventajas intrísecas y ser de los primeros en el mercado; o tomar su aplicación ahora "legacy" para siempre, analizarla, reescribir todo lo necesario, y portarla a WinRT; o dejarla como está, y confinarla a Win32, es decir, al "escritorio", que ahora es un contenedor subordinado. Lo que está claro es que existe una verdadera ruptura entre las versiones anteriores y la nueva: usted deberá aprender un nuevo API, y deberá replantear cada aplicación, y olvidarse de lo que conocía. Algún comentarista recomienda reconvertir cada actividad diferenciada en un servicio web, para poder ir adelante en la migración. ¿Ha pensado en rever todas y cada una de sus aplicaciones que no sean Office u otros productos nativos de Microsoft?
¿Ha sido la mejor opción definir una arquitectura orientada a recursos móviles como prioridad casi exclusiva? ¿Se ajusta al mercado corporativo? probablemente sí, en el nicho de actividades de movilidad. Pero seguramente no en la mayoría de actividades diarias, atendidas por las llamadas aplicaciones "de escritorio". Este área difícilmente sacaría ventajas del paradigma Metro. Creo que existe una posibilidad de que se repita la situación dada con Windows Vista: una prolongada resistencia a adoptarlo. Tendrá que esforzarse mucho Microsoft para lograr adopcíon en ese área de su mercado.
Presento a continuación algunos análisis, algunos tempranos (último cuarto del año pasado en adelante) y otros muy recientes. Esto es importante porque, como hemos dicho, Windows 8 ES UN PRODUCTO EN CONSTRUCCIÓN, y algunas dudas tempranas se han disipado (y otras han madurado).

Un análisis positivo se puede leer en los comentarios y ejemplos de Harry Pierson (varios). Dos analistas favorables que de todas maneras exponen la magnitud del problema, son Rockford Lhotka y Miguel de Icaza. Lhotka, por octubre de 2011, presentaba una serie de diagramas que mostraban dónde operaban distintas tecnologías, WinRT o Win32. De estos diagramas queda claro que prácticamente todo lo que hoy ejecutamos cae del lado de Win32: Silverlight, WPF, sitios web con plugins (Today’s web sites that use HTML, js, Flash, Silverlight, ActiveX, and other common web technologies all run in the desktop web browser. This is the same as web sites work today in Win7), c++, MFC, ATL, Windows Forms. Y se ejecutan en WinRT casi exclusivamente tecnologías nuevas construídas por Microsoft para Windows 8: WinRT .NET y XAML (I expect this to be the most widely used technology stack for building WinRT applications. The .NET available to WinRT applications is (I think) best thought of as being like .NET on the Windows Phone. It is basically the Silverlight subset of .NET, plus a bunch of WinRT-specific features and capabilities. The differences between Silverlight and WinRT are a bit more dramatic than with WP7, but the analogy remains quite accurate. The XAML is very close to Silverlight and WPF, and the types of code you can write using C# and VB are very comparable to what you can write today using Silverlight); HTML5, WinRT c++. Excepcionalmente, también se pueden ejecutar en WinRT paginas web que consistan sólo de HTML, CSS y JavaScript (If a web site only uses HTML, CSS, and js, then it can run in the WinRT and desktop browsers interchangeably. Microsoft clearly expects this type of web site to become more common over time, though it is interesting that a large number of existing Microsoft web sites are really only useful in the desktop browser)
Resumiendo sus primeras impresiones, Lhotka dice:

Through this series of diagrams, we clearly show how today’s technologies map directly into the Win8 desktop world, still running on the Win32 API. And we show the three technology stacks that enable development of applications on the new WinRT API.
From everything we know today, it seems clear that migrating to WinRT will require effort, regardless of the technology used today, or in the Win8 desktop. Of all existing technologies, Silverlight and then WPF appear to offer the easiest migration. HTML 5, css, and js skills, along with some code assets will also migrate, but there’s a non-trivial architectural difference between web development and smart client development that shouldn’t be overlooked.

por su parte, Miguel de Icaza estudia detalladamente el nuevo modelo enfocado en .NET, y en su detalle podemos dimensionar la dificultad de readecuación a Windows 8 y su API. El API sigue un modelo asincrónico (Microsoft feels that when a developer is given the choice of a synchronous and an asynchronous API, developers will choose the simplicity of a synchronous API. The result usually works fine on the developer system, but is terrible when used in the wild. With WinRT, Microsoft has followed a simple rule: if an API is expected to take more than 50 milliseconds to run, the API is asynchronous); .NET pasa a estar disponible parcialmente en el nuevo modelo (Some developers are confused as to whether .NET is there or not in the first place, as not all of the .NET APIs are present (File I/O, Sockets), many were moved and others were introduced to integrate with WinRT. When you use C# and VB, you are using the full .NET framework. But they have chosen to expose a smaller subset of the API to developers to push the new vision for Windows 8. And this new vision includes safety/sandboxed systems and asynchronous programming. This is why you do not get direct file system access or socket access and why synchronous APIs that you were used to consuming are not exposed)

Invito a seguir sus observaciones, para ir teniendo una idea de cuánto trabajo deberá afrontar en estas condiciones para adecuarse.

Para no abundar, recomiendo la lectura del resumen de dificultades comentada en Techrepublic por Justin James. De las más importantes mencionadas, el modelo asincrónico, la falta de acceso directo a disco, el uso de pantallas táctiles, el énfasis en la nube. Hay más, pero quizá sea preferible que lo lea directamente.

Esto es sólo un pequeño resumen, para que usted piense y estime los tiempos por venir, y vaya calculando decisiones. Una vez más, sería valorable que desarrolladores, implementadores, consultantes, comercializadores, e influyentes en general, se ocuparan del impacto de la adopción del producto, y no sólo del brillo de las novedades. Tras muchos años de hegemonía, también Microsoft tiene un patrimonio "legacy", y alguien debería recordar que eso significa muchas horas de trabajo, y mucho dinero invertido.