Una ventana a la historia de Plex

Ramon Chen, Director de Producto de la ya desaparecida Synon, ha recreado en su sitio el original Lava Lounge, el volcánico salón de reunión de los desarrolladores interesados en Obsydian, el primitivo nombre de Plex. El corte está hecho a junio de 1998, en el momento en que se anuncia la compra de Obsydian por Sterling Software. Ramon construyó una cronología comenzando en septiembre del 96, hasta la fecha del corte.

Finalmente, Oracle toma Sun

Seguramente la compra de Sun tendrá impacto profundo en el negocio informático, y lo veremos progresivamente. Dos comentarios hoy destacan el carácter de oferta vertical que ahora podría presentar Oracle. Ashlee Vance, en The New York Times ("Cash in Hand, Technology Giants Go Shopping"), y Tom Steinert-Threlkeld, en ZDNet ("A complete industry in a box"). Vance dice:

Most consumers do not want to get a PC by purchasing microprocessors, hard drives and operating system software from different suppliers and assembling them all into a working computer. They prefer to buy a complete, customized machine from one supplier.

Corporate customers increasingly want the same thing: a one-stop shop for hardware, software and services. And the largest technology companies are deploying their huge cash hoards to make acquisitions to bolster their ability to be that single provider.

That trend drove Oracle, a leader in business software, to announce Monday that it was spending $7.4 billion to buy an ailing Sun Microsystems and get into the computer hardware business. Oracle beat out rival I.B.M., which considered buying Sun to enhance its own software offerings but ended serious acquisition talks about two weeks ago.

“Oracle will be the only company that can engineer an integrated system — applications to disk — where all the pieces fit and work together so customers do not have to do it themselves,” Oracle’s chief executive, Lawrence J. Ellison, said Monday.

Vance no piensa en lo que le pase a MySql, ni el cambio de manos de Java, sino en la consolidación de agentes con control completo del negocio. Quizá sea su punto de vista el más acertado en todo lo que comienza a debatirse tras la compra. ¿Habrá cometido IBM un error histórico?

Indice TIOBE de popularidad de lenguajes: reaparece RPG

Ya mencionado antes aquí, mensualmente Tiobe publica un ranking de popularidad de los lenguajes de programación, que es interesante para observar tendencias. Lo puede leer estimando el futuro tecnológico, profesional, de negocios, y más, ya que los cuadros de análisis son variados a partir de la masa de datos obtenida:

The TIOBE Programming Community index gives an indication of the popularity of programming languages. The index is updated once a month. The ratings are based on the number of skilled engineers world-wide, courses and third party vendors. The popular search engines Google, MSN, Yahoo!, and YouTube are used to calculate the ratings. Observe that the TIOBE index is not about the bestmost lines of code have been written. programming language or the language in which

The index can be used to check whether your programming skills are still up to date or to make a strategic decision about what programming language should be adopted when starting to build a new software system.

La lista comparativa de abril muestra una situación estable o muy levemente descendente para los lenguajes más populares, incluyendo Java, C, C++, PHP, C# y Visual Basic, una pequeña subida para Python y Javascript, para los primeros diez puestos. Notablemente, RPG sube y se coloca en el puesto 18, creciendo fuertemente durante 2009. Mas notable todavía que la subida de ABAP en el mismo período, ya que RPG está fundamentalmente ligado al OS/400 y el ISeries (AKA AS/400). ¿Recupera posiciones el uso del AS/400?. Considerado en sí, el actual RPG tiene ya poco que ver con sus versiones iniciales, y se ha potenciado tanto como lo ha hecho el ISeries.
El ranking completo para los primeros veinte puestos:

Position Apr 2009	Position Apr 2008	Delta in Position	Programming Language	Ratings Apr 2009	Delta Apr 2008	Status
1	1		Java	19.341%	-1.55%	A
2	2		C	15.472%	-0.04%	A
3	3		C++	10.741%	-0.06%	A
4	4		PHP	9.888%	-0.32%	A
5	5		(Visual) Basic	9.097%	-0.69%	A
6	7		Python	6.080%	+1.18%	A
7	8		C#	4.059%	+0.00%	A
8	9		JavaScript	3.678%	+0.75%	A
9	6		Perl	3.462%	-2.09%	A
10	10		Ruby	2.569%	-0.07%	A
11	11		Delphi	2.272%	+0.25%	A
12	14		PL/SQL	1.086%	+0.33%	A
13	12		D	1.076%	-0.37%	A
14	13		SAS	0.792%	-0.13%	A
15	15		Pascal	0.717%	+0.12%	A-
16	21		Logo	0.707%	+0.37%	A
17	27		ABAP	0.658%	+0.42%	B
18	26		RPG (OS/400)	0.646%	+0.40%	B
19	19		Lua	0.491%	+0.12%	B
20	23		MATLAB	0.482%	+0.22%	B

El análisis completo se puede encontrar en la página de Tiobe. Se puede suscribir al informe mensual.
Otro aspecto de interés acerca del análisis es el análisis por categorías, con indicación de un 40% de persistencia de lenguajes procedurales:

Category	Ratings April 2009	Delta April 2008
Object-Oriented Languages	55.6%	+0.0%
Procedural Languages	40.3%	-1.1%
Functional Languages	3.0%	+0.8%
Logical Languages	1.2%	+0.2%

El método de cálculo del índice es este.
Sobre Tiobe:

TIOBE is specialized in assessing and tracking the quality of software. We measure the quality of a software system by applying widely accepted coding standards and quality metrics to it.

We provide quality systems that monitor your software real-time. Software managers and architects are offered a top down view, whereas engineers get a plug-in for their programming environment to measure the quality at file level.

Un poco de criticismo sobre MS Oslo, II

Continúa la discusión entre Jean-Jacques Dubray y Douglas Purdy, con la introducción de algunas acotaciones de Charles Young. Una discusión farragosa, en la medida que se habla de algo que es un proyecto, sobre una base que a su vez se mueve. Creo que es válida la observación de Dubray, al menos aplicándola a la dirección de las investigaciones de Microsoft de los últimos años:

I am personally a bit sick of that, it seems that Oslo is taking the same path as WCF/WF and it will take years to undo quick "pragmatic" decisions made in the early days of the project. Considering that WCF was announced in 2003, shipped 2007 and being rewritten (one more time...) in 2009 for a release in 2010-2011, it looks like we should expect Oslo to do anything useful in 2014-2015 timeframe. I wish a lot more people would have the luxury to work with these kinds of time frames.

¿Será Oslo solo aplicable para la plataforma Windows? Tan pronto se desenvuelve cualquier discusión sobre el tema, éste se encauza por ese camino. En ese caso, el valor que se discute sobre la capa superior (meta-metamodelo) tendría escaso alcance.
Dubray puntualiza lo que Charles Young piensa al respecto. Todo lo dicho por Young es de mucho interés, pero particularmente sobre los objetivos de Oslo:

In this thought exercise, we are capturing models which are specific to a given technology. We need to be able to specify the metamodel very precisely in order to ensure that our models are valid and well-formed in respect to BizTalk Server. However, we will probably be less interested, in this scenario, in ensuring that our metamodels conform to some meta-metamodel. One reason for this is that we probably won’t have a compelling need to exchange BizTalk-specific metadata with other systems and applications. This could change over time, however. For example, as BizTalk Server evolves further, future versions may exhibit much closer integration with platform-level technologies such as WCF and WF, or standards such as BPEL4WS and BPMN. They may be more deeply integrated into platform-level host environments (this is already the case with regard to IIS-based ‘isolated’ hosts in BizTlk Server). In this case, the ability to exchange and transform metadata on the basis of some meta-metamodel could become an important consideration. Even here, though, we might wish to our meta-metamodelling to address a specific technology platform.

A major theme in Oslo is the reduction of the bar that ISVs and development teams face when seeking to support rich modelling approaches to software development and runtime configuration. Oslo is agnostic with regards to the number of metalayers that are required in any given scenario and makes no assumptions with regard to how platform/technology-specific or independent a particular model needs to be. It avoids forcing conformance to any abstract M3 specification and provides a general-purpose metamodelling language that minimises the learning curve for developers. To all this, Microsoft adds pre-defined mappings to T-SQL and is building additional tooling for generalised visualisation of models and parser generation tools for creating domain-specific modelling languages. They also provide many pre-defined models (e.g., for WF workflows) out of the box.

In our BizTalk Server example, the bar is now set very low. MSchema is a natural choice for defining model specifications whose conformance to the models in the BizTalk management database can be verified, but which can reduce the amount of detail to an appropriate level. The Oslo tooling can be used to create tables in the repository which correspond directly to the tables in the Management database. Access to models in the repository can be via any appropriate and familiar data access technology that can connect to SQL Server. There is no need for developers to engage in a steep learning curve in respect to meta-metamodelling, no need to conform to unfamiliar APIs and no need to inject an unnecessary level of platform independence in the way models are specified.

Charles Young historia las relaciones entre Microsoft y la OMG (UML, metamodels, MOF and MDA), hasta desembocar en las Software Factories y Oslo. Pero eso podría verse por separado. Curiosamente, esta historia de interrelaciones es prácticamente inhallable hoy.

Un poco de criticismo sobre MS Oslo

Jean-Jacques Dubray escribe en su blog acerca de Oslo (Where is Oslo going?), reflejando un poco de descreimiento en el curso definitivo que el proyecto tome. Pero además, Jean-Jacques hace algunas agudas observaciones sobre arquitectura y el futuro del modelado.
En primer lugar, sus observaciones sobre Oslo:

What is clear is that now Oslo is only about "modeling", SOA and Composite Applications are simply areas where Oslo can be applied. That's a bit different from the original announcement on the project in the fall of 2007 and pieces like "Dublin" seem to have fallen off Oslo which is now only 3 elements: a metadata repository, quadrant and the M language.

Dubray parte de una premisa con la cual juzga Oslo:Metamodel Oriented Programming (MOP):

MOP is an approach which seeks to create a programming model independent of architecture such that architects can architect and developers can build the solution in an architecture independent way. This is in line with projects like Microsoft Volta which talked about "Architecture Refactoring" concepts. Incidentally Volta has disappeared from the face of the earth, what a shame. MOP is not about creating a single programming model, but again, rather an approach to separate architecture(s) from programming model(s). I, of course, focus on SOA and Composite Apps, but as a good software engineer, I believe that anything I do is so general MOP can be applied to anything...

Dubray, basado en las conjeturas que permite extraer la todavía difusa información sobre Oslo, sostiene que el proyecto no logra establecer una separación clara entre el nivel de abstracción de modelado y la programación:

If you build something like Oslo you start with a programming model like .Net RIA Services or anything you want that tries to do the same thing and then you build Oslo to make it easy(ier) to build something like .Net RIA Services. In case you have not noticed MOP has already happened, all the annotations in Java or C# is MOP layered on top of OO. But MOP layered on top of OO does not provide a clean separation between Architecture and Programming Models. This is the mission that Oslo should set itself up with. So starting with an "app" is, of course, a traditional Microsoft approach. But this is the wrong level. This is actually catastrophic to start at this level, it ensures they will never deliver something at the MOP level. What our industry needs today is not a better way to write code snippets or string templates, it needs a way to express business logic in a sustainable way, i.e. outside a given architecture.

Sobre M:

"M lets developers build out domain-specific languages (DSLs) relatively easily" is no longer the problem, Microsoft has DSL tools for that, the question that the Oslo team should ask itself is does M stands for Model or Metamodel?

Douglas Purdy, mencionado por Dubray, acaba de contestarle. En todo caso, postula M como una herramienta para trabajar a nivel de metamodelos y meta-metamodelos. Diferenciando M de las DSL tools de VS:

The current DSL tools (the DSL Toolkit) are for visual DSLs, not for textual DSLs. We want an architecture that supports both both textual and visual DSLs operating over the same model. Speaking of model, M is for model and metamodel and metametamodel. Since my Smalltalk days, I have grown tired of using the meta prefix, as it often confuses more than helps the conversation with developers.

También en su contestación está implícito el rumbo zigzagueante de Oslo desde su inicio al contestar aceerca de la relación entre Oslo y FTA.

Está abierta una discusión...Más allá del punto de vista sobre Oslo, otras aristas del pensamiento de Dubray merecen ser seguidas. En otro momento.

Un tercer aspecto de la (posible) venta de Sun

Eugene Ciurana, en un post en The Sever Side, agrega un factor más a las razones de la compra de Sun, ahora apuntando a su (eventual) estrategia futura para Java. Según especulaciones de Stephen Colebourne, Sun perseguiría retornar Java a un desarrollo propietario:

Stephen Colebourne argues that there will be no Java 7 because of the ongoing disagreements between the Apache Software Foundation, Sun, and the JCP regarding Apache Harmony, the independent, open source, compatible Java SDK.

Stephen argues that Harmony's success motivated Sun to return to a proprietary Java development model and is blocking Harmony from getting the JDK compatibility kits it needs for validating that its Java implementation is up to snuff.

[Según Stephen Colebourne] Apache's implementation of the Java SE 5 JSR specification is Apache Harmony. However, when Apache came to obtain the testing kit for the specification a whole political game started. Instead of Sun offering the testing kit as normal for each of the other 25 JSRs, they offered a testing kit where the results of the tested code would not be Open Source

Obviously, Apache couldn't accept this limitation, which is against the legal agreement signed between Sun and Apache. Apache complained 2 years ago, but has yet to receive an acceptable response. And no, there is no way a charity not-for-profit like Apache is going to sue a multi-national corporation - who do you think would get the better lawyers?

The key point is that Sun's tactics here were quite deliberate. They knew exactly what they were doing by offering a testing kit with a restrictive license. They wanted to ensure that Apache Harmony couldn't be certified as complete. Sun was going out of its way to ensure that there was no competition to its own JDK.

In the meantime, Sun played the OpenJDK card. It announced the release of the JDK under the GPL license [...] I think this shows a gross lack of perspective - the code may now be GPL open source, but the specification is now no longer open. Which is more important?

Thus, the next release will be JDK 7, not Java 7.

This means that there won't be an open Java 7 specification. This would mean that what makes it into Java is what Sun choses to release in OpenJDK, not what's agreed in the JSRs. This returns control of Java back to Sun and prevents its standardization.

Stephen made a second posting where he documents the ongoing discussions between the Apache Harmony and Sun regarding the Java 7 specifications, using the JCP Executive Committee meeting minutes to support his argument.
An interesting read, to say the least, and a potential threat to having an open Java specification.

¿Qué peso puede tener esta hipótesis? En este caso es simple: el tiempo le dará su lugar en pocos meses.