A propósito de la década de Eclipse

Jean Bezivin comparte hoy en Google+ una nota de Ian Skerrett, de la Fundación Eclipse, que puntualiza algunos de sus logros en diez años de existencia. En lo esencial:

As I have written, Eclipse is celebrating 10 years of open source and community during the month of November.   There have been a number of milestones that have shaped the Eclipse community but what have been the major accomplishments?  What has Eclipse done to actually change the software industry?  Here are what I see as some of the key accomplishments for Eclipse.
1.  Dominant Java IDE.  Eclipse started out as being a really great Java IDE and continues today to be the market leader for Java IDEs.  If you think back to the late 1990′s and early 2000′s the Java IDE market was a dog-fight between Borland JBuilder, Visual Cafe, IBM VisualAge for Java.   Eclipse is now the clear leader and has approximately 65% market share in the Java IDE market.
2. De-facto Solution for C/C++ Tools.  If you are building a tooling solution for C/C++ developers there is a very good chance you are using Eclipse CDT as the platform.   In the realtime operating system and embedded development market, Eclipse CDT has become the de-facto standard.  There at least 50 companies that are building their developer tools solution based on CDT.
3. A large and innovative modeling community.  I am not sure how to quantify it but I believe the Eclipse modeling community has grown to become one of the largest and innovative communities at Eclipse.  If you are doing modeling, chances are you are using Eclipse Modeling Framework (EMF).  However, EMF is just the core that has created a really amazing community of innovation and diversity that happens at Eclipse Modeling.   There are over 70 modeling projects at Eclipse and I know a lot more not hosted at Eclipse.   It is a great success.
4. Integrating ALM Tools.  The Mylyn project has grown into becoming the industry hub for integrating tools across the application lifecycle.   There are now over 70 different Mylyn connectors that integrate different projects into the developer desktop.
5. Modular runtimes.  Equinox and the EclipseRT projects demonstrate how modularity can work on a large scale.  Everything at Eclipse is based on Equinox, since it is the OSGi runtime.  However, Equinox and the EclipseRT top-level project has spawned an industry around Eclipse RCP and server-side OSGi.  The range of applications being built on RCP is impressive, including NASA Mars Rover, financial institutions, aircraft design, genome decoding, etc, etc.   On the server side, Equinox is used by most enterprise Java application servers and Virgo is emerging as a new Equinox based platform.
6. Eclipse Release Train.  The Eclipse release trains have demonstrated open source communities can be predictable and scale to large distributed teams.   This is incredibly important as large more conservative companies become involved in open source.  Very few other organizations can claim a track record of predictability and scale that compares to the Eclipse community.
7. Eclipse Ecosystem.  Eclipse has become one of the two major development tools platform in the industry; MS Visual Studio being the other.   No matter what language you are using there is most likely an Eclipse IDE for you.  No matter what developer tool you are using, there is probably an Eclipse plugin.   No other platform has been able to create such a diverse and large ecosystem.  It has actually made building and integrating developer tools a lot easier!

De esto algo conocemos en la comunidad de Plex: al menos dos emprendimientos vinculan extensiones de Plex con las posibilidades de Eclipse: Webclient, creando una variante web ajax a partir de la generación de código Plex java, y el trabajo de Christopher Smith, mejorando el proceso de implementación de un modelo Plex. Dos sugerencias que abren un panorama más que positivo para el futuro.

Una opinión sobre el valor de Java

En el curso de una discusión sobre Dart en Google+, Rafael Chaves da una interesante visión sobre Java:

"Java was not innovative at the time, and did kill many OO languages initiatives"

I am not sure Java killed other initiatives - I feel more like they were dead on arrival, at least from a market suitability PoV.

The non-technical aspects are just as important as technical merits. It does not matter how cool a language is, if it is not going to be supported by multiple vendors/platforms, if it evolves in a way that invalidates previous investments, if it is hard to learn for the average developer, if doesn't have proper support for a wide variety of application styles/domains, if is going to be hard to hire people. Getting that right is as critical as (or even more than) technical benefits.

Java got all those right, and that is why it succeeded. I don't think it is a lot about money. Sun could have poured twice as much money into it, but if they failed to recognize the importance of those aspects, it would have been a flop, or have limited success (see Microsoft .Net). But these days I wouldn't bet against similar success being attainable by an open source foundation with a strong community, without nearly the same level of financial backing, if they aimed for building for the mainstream and the long term like Sun did with Java.

As a developer, I want my investment in learning my next language to pay off for as long and across as many domains and technical architectures as possible. That is much more important than having the perfect feature set.

...y a propósito del valor de Dart, Angel "Java" López ha abierto una línea de discusión e información.

Scott Klement: juego de caracteres en el AS400

Sólo para usuarios de AS400/iSeries: Scott Klement dedica una nota suficiente al juego de caracteres y su uso al intercambiar datos con otros sistemas, y entre distintos lenguajes en el propio sistema. Necesario  de conocer. No lo voy a repetir, excepto el siguiente párrafo:

Things You Should Definitely Know

• It is not OK to create a text string without knowing and identifying which CCSID the data is stored in.
• It's not reasonable to expect the computer to "detect" a CCSID.
• Power Systems (and their predecessors, System i5, iSeries, and AS/400) are not "EBCDIC machines." They can run ASCII, EBCDIC, or Unicode equally well.
• The IBM i operating system (and its predecessors i5/OS and OS/400) do most of their work in EBCDIC, but they also understand both ASCII and Unicode and can run programs based on them (e.g., Java, PHP, PASE, Apache).
• IBM i has knowledge of many CCSIDs (including ASCII, EBCDIC and Unicode) built in and can easily and efficiently translate between them.
• The web is not based on ASCII. It is based on Unicode.

Things to Think About When You Have Problems

If you tell me that you have a character encoding problem, I'll want to know the following:

• How the characters were supposed to be encoded in the original file.
• What the CCSID of the original file was.
• How the characters were supposed to be encoded in the destination file.
• What the CCSID of the destination file was.

Para conservar en la guía fundamental de trabajo.

Estimando el impacto de Windows 8, parte II

Para comenzar, una pequeña disgresión, para hablar de un aspecto reiterado con Microsoft: la campaña anticipada sobre productos que estarán en el mercado en un futuro indeterminado pero medianamente cercano.
Lo hemos visto en tiempos más o menos próximos con Windows Vista, y en un terreno más específico, con el proyecto Oslo y todos sus elementos participantes. Este fenómeno ha producido en el pasado dos movimientos, uno razonable, de cautela y espera de parte del mercado corporativo, que se ve obligado a sopesar en cuánto le impactará una evolución del producto; o cómo deberá modificar sus estrategias, si es un proveedor de productos de Microsoft o su competidor. Y otro, no precisamente razonable, de entusiasmo y apoyo de parte de la comunidad de desarrolladores o de proveedores de servicios o productos basados en Microsoft, que por lo general, ya ante versiones tempranas del producto, aseguran que marcha más que bien, y que cura todos los males del mundo, en los casos más extremos de adhesión a la marca. De tal forma que comienza a producirse una espiral de información y debate sobre algo que está a mitad de desarrollo, cuyas características podrán variar, o incluso podrá ser discontinuado como vía de investigación, con entusiastas que son capaces de describir un algoritmo que seguramente funcionará en el futuro. Los casos de Longhorn (Vista) y Oslo muestran particularmente estas características, y sus consecuencias. Esto produce, a mi juicio, dos efectos negativos importantes: condiciona o aplaza las decisiones y estrategias de quienes están relacionados y dependientes del ecosistema de Microsoft, y produce descrédito en la marca por el largo proceso de maduración del nuevo producto, sujeto a la exposición pública cuando todavía no está acabado. Y mucho mayor descrédito si toda esa "burbuja" de información conduce a un producto discontinuado.
Este comienza a ser el caso de Windows 8: es sorprendente el número de rápidas conclusiones sobre el producto que se pueden encontrar en éstos días. Pronto veremos condicionar muchos proyectos basados en lo que vendrá, que  también pudiera ser lo que vendría. Nuevamente, proliferan las afirmaciones basadas en un kit de demostración que no maneja todas las variables, porque los planes de desarrollo ni siquiera tienen fechas públicas de entrega.
Finalmente, desde el punto de vista del usuario, especialmente del usuario corporativo, que es esencialmente distinto del que compra en el mercado general, existe una pregunta: ¿me hace falta pasar a Metro? ¿necesito en mis cien/quinientos/mil escritorios de mi casa central disponer de terminales táctiles? Sin embargo, cualquiera sea la respuesta, probablemente el resultado final será que seré condicionado a adoptar el nuevo paradigma, y deberé replanear mi arquitectura. Al menos, si Windows es mi terminal cliente.
Lo que me lleva a lo que quería recordar hoy: una pequeña nota sobre la actualización contínua del software que Kevin Kelly escribió en abril:

(...) It's taken me 60 years, but I had an ephipany recently: Everything, without exception, requires additional energy and order to maintain itself. Not just living things, but the most inanimate things we know of: stone gravemarkers, iron columns, copper pipes, gravel roads, a piece of paper. None will last very long without attention and fixing, and the loan of additional order. Life is maintenance.
Most surprising to me has been the amount of sheer maintenance that software requires. Keeping a website or a software program afloat is like keep a yacht afloat. It is a black hole for attention. I can kind of understand why a mechanical device would break down after a while -- moisture rusts metal, or the air oxidizes membranes, or lubricants evaporate -- all of which require repair. But I wasn't thinking that the intangible world of bits would also degrade. What's to break? Apparently everything.
Here is news to the young: Crap accumulates in code. Chips weaken. Programs break. On their own, nothing you did.
And then there is the assault of the changing digital landscape. When everything around you is upgrading, trying new actions, or seeking new loopholes, this puts pressure on the website and necessitates maintenance. You may not want to upgrade, but you have to because everyone else is.
This upgrade arms race spills over into our private lives. It's completely altered my attitude about upgrading. I used to upgrade begrudgingly (why upgrade if it still works?), and at the last possible moment. The trouble is familiar. Upgrade this and suddenly you need to upgrade that, which triggers upgrades everywhere. A "tiny" upgrade of even a minor part can be hugely disruptive. But as our personal technology became more complex, more co-dependent, more like a personal ecosystem, delaying upgrading is even more disruptive. So I now see upgrading as a type of maintenance: you do it to survive. Technological life in the future will be a series of endless upgrades.
Expecting to spend your life upgrading should be a life skill taught in school. Indeed, I'd like to learn how to manage maintaining my digital ecosystem better myself. There must be a zen and art to upgrading.

Estimando el impacto de Windows 8, parte I

Este último mes me he dedicado a recolectar información sobre Windows 8, particularmente después que la conferencia Microsoft Build develara un buen número de características y planes. Inmediatamente se observa que la nueva versión del sistema operativo trae consigo un cambio drástico respecto a los sistemas anteriores. A primera vista el cambio fundamental es el ¿estilo de presentación/técnica de construcción?, que abandona una larga tradición de interacción con las aplicaciones, introduciendo un modo inspirado o destinado al mercado de tabletas táctiles. Sin embargo, yendo un paso adelante, un cambio más importante está por debajo de éste, y es el que posibilita el funcionamiento de su nueva interfaz de usuario (Metro): el nuevo API, WinRT.
Esta nueva API no se comunica con el API Win32, o no al menos muy bien. Dice Tim Anderson (mencionado por Mary-Jo Foley):

Make no mistake: Microsoft has re-invented the Windows API in WinRT. Just to recap, WinRT is the API for Metro-style applications, the touch-centric, app-centric API for tablets and, one presumes, eventually for Windows Phone (though Microsoft has yet to admit it).
WinRT is only useable from Metro applications. You cannot call WinRT from a Win32 application, nor vice versa*. I think it is reasonable to assume that a future version of Windows which runs only WinRT is a possibility; and that Windows 8 on ARM will look a bit like that even though Win32 will still be there, but mainly out of sight; but I am speculating.
Does that mean Win32 is now legacy? In a way, but such a huge legacy that for the moment we should think of Windows 8 as two platforms side by side.

Miguel de Icaza hace una evaluación temprana entusiasta y optimista (WinRT demistified). Sin embargo, de su comentario sobre WinRT y .Net, dejando aparte las ventajas que Miguel elogia, lo que consigue es abrir nuevas áreas de interrogantes acerca de su impacto.
¿Por qué hablo de impacto? Porque Windows 8 no sale en un mercado virgen, sino en uno en el que conviven no menos de dos clases de aplicaciones, las que fueron planeadas pensando en Windows XP y predecesores, y las que fueron, esforzadamente, movidas a Vista/Windows 7, o escritas para este nuevo y, por lo que se ve, fugaz concepto. Ahora podemos decir que no solo cualquier aplicación del nivel XP/anteriores es legacy, sino que también lo serán aquellas creadas para Vista/Windows 7, dado que ambos comparten el API Win32 (Y estoy tratando de evaluar el alcance de los cambios que impacten en .NET...) Sólo por ese hecho, estarán en una categoría inferior, y espero conocer más adelante las consecuencias de performance que puedan acarrear.
Es decir, debemos mirar el movimiento hacia Windows 8 no sólo desde el punto de vista de las novedades y mejoras, sino de todo aquello que condiciona y obliga a replanear. Este es el punto que ahora me interesa fundamentalmente: considerando el patrimonio de aplicaciones en las que trabajo, si me viera obligado a asumir una migración a Windows 8, debería pensar las alternativas: si soportara Metro, lo mínimo que debiera hacer en nuestros patrones sería contemplar una variante que invocara WinRT en lugar de Win32, y asumir el nuevo tipo de eventos que implica Metro. La separación entre la presentación y la lógica "servidora" sería manejable, así como los lenguajes de implementación (Esto vale para cualquier variante de interfaz de usuario). Si no soportara Metro, poco cambiaría o nada, pero los problemas estarían en el ambiente: estaría ejecutando aplicaciones en un ambiente "no preferente".
Finalmente, siempre queda la alternativa simple de desechar la interfaz del sistema cliente, y usar java. ¿cuál se supone que sería la alternativa más rápida y confiable?
¿Cuál supone usted que sería la alternativa que una corporación usaría si tuviera que pensar en la transición de sistema operativo de Microsoft?
Los reclamos de la comunidad de Silverlight pueden ser pálidos reflejos del impacto del cambio generalizado sobre el mundo corporativo. Especialmente si las politicas de actualizaciones de Microsoft comienzan a establecer presión hacia el cambio.