Una guía de trabajo con Plex

George Jeffcock, en su sitio relacionado con sus Stella Tools, dedica algunos párrafos a recomendar buenas prácticas en el uso de Plex. Coincidiendo con las guías de enseñanza usuales en Plex, George recomienda:

STOP Coding - Start Architecting
Plex development is essentially a three-step process involving Data Modeling, Pattern Matching and Customization. There are no shortcuts, each step must be adhered to achieve the goals. Missing a step may seemingly achieve a short term solution but in the medium and long term the solution will surely decay far quicker than it should have. The mindset required to use plex effectively is one of:

• Object oriented approach to application design to eliminate the need to code repeatable elements of applications
• Working at a level of abstraction rather than at the ‘nuts and bolts’ level, probably just saying the first point again but this can’t be over stressed the importance to think this way instead of coding procedural code line after line
• Model-based and pattern-based approach to increased application quality and flexibility
• Multiple inheritance is a key part of the way applications are developed in CA Plex therefore leveraging the full value of a site’s existing patterns
• Encapsulation so that function interfaces contain only the attributes pertinent to the use of the function
• An application should be separated into separate layers/tiers, Functionality should be strictly separated into data access, business logic and presentation logic, as this promotes the consistency of the application as well as the possibilities to reuse functionality.

La primera regla que un nuevo desarrollador en Plex debe asumir, es que debe escribir la menor cantidad de código posible: olvidarse de escribir líneas de código, y pensar, pensar el modelo de datos y relaciones, luego estudiar cómo abstraer y explotar patrones existentes, y sólo luego escribir código, sólo lo que es estrictamente necesario. "Whenever there is a hard job to be done I assign it to a lazy man; he is sure to find an easy way of doing it"

Diez reglas para recordar (y seguir...)

Firmado por Javin Paul, un artículo que recuerda diez reglas importantes de orientación a objetos en el diseño con Java (10 Object Oriented Design Principles Java Programmer should know), que podríamos extender fácilmente a otros campos (y estoy pensando en Plex). Un pequeño decálogo, tan escueto que podríamos pegarlo en una pizarra frente a nuestros ojos, y que deberíamos repasar todos los días.

 DRY (Don't repeat yourself)
Our first object oriented design principle is DRY, as name suggest DRY (don't repeat yourself) means don't write duplicate code, instead use Abstraction to abstract common things in one place. If you have block of code in more than two place consider making it a separate method, or if you use a hard-coded value more than one time make them public final constant. Benefit of this Object oriented design principle is in maintenance. It's important  not to abuse it, duplication is not for code, but for functionality . It means, if you used common code to validate OrderID and SSN it doesn’t mean they are same or they will remain same in future. By using common code for two different functionality or thing you closely couple them forever and when your OrderID changes its format , your SSN validation code will break. So beware of such coupling and just don’t combine anything which uses similar code but are not related.

Encapsulate What Changes
Only one thing is constant in software field and that is "Change", So encapsulate the code you expect or suspect to be changed in future. Benefit of this OOPS Design principle is that Its easy to test and maintain proper encapsulated code. If you are coding in Java then follow principle of making variable and methods private by default and increasing access step by step e.g. from private to protected and not public. Several of design pattern in Java uses Encapsulation, Factory design pattern is one example of Encapsulation which encapsulate object creation code and provides flexibility to introduce new product later with no impact on existing code.

Open Closed Design Principle
Classes, methods or functions should be Open for extension (new functionality) and Closed for modification. This is another beautiful SOLID design principle, which prevents some-one from changing already tried and tested code. Ideally if you are adding new functionality only than your code should be tested and that's the goal of Open Closed Design principle. By the way, Open Closed principle is "O" from SOLID acronym.

Single Responsibility Principle (SRP)
Single Responsibility Principle is another SOLID design principle, and represent  "S" on SOLID acronym. As per SRP, there should not be more than one reason for a class to change, or a class should always handle single functionality. If you put more than one functionality in one Class in Java  it introduce coupling between two functionality and even if you change one functionality there is chance you broke coupled functionality,  which require another round of testing to avoid any surprise on production environment.

Dependency Injection or Inversion principle
Don't ask for dependency it will be provided to you by framework. This has been very well implemented in Spring framework, beauty of this design principle is that any class which is injected by DI framework is easy to test with mock object and easier to maintain because object creation code is centralized in framework and client code is not littered with that.There are multiple ways to  implemented Dependency injection like using  byte code instrumentation which some AOP (Aspect Oriented programming) framework like AspectJ does or by using proxies just like used in Spring. See this example of IOC and DI design pattern to learn more about this SOLID design principle. It represent "D" on SOLID acronym.

Favor Composition over Inheritance
Always favor composition over inheritance ,if possible. Some of you may argue this, but I found that Composition is lot more flexible than Inheritance. Composition allows to change behavior of a class at runtime by setting property during runtime and by using Interfaces to compose a class we use polymorphism which provides flexibility of to replace with better implementation any time. Even Effective Java advise to favor composition over inheritance.

Liskov Substitution Principle (LSP)
According to Liskov Substitution Principle, Subtypes must be substitutable for super type i.e. methods or functions which uses super class type must be able to work with object of sub class without any issue". LSP is closely related to Single responsibility principle and Interface Segregation Principle. If a class has more functionality than subclass might not support some of the functionality ,and does violated LSP. In order to follow LSP SOLID design principle, derived class or sub class must enhance functionality, but not reduce them. LSP represent  "L" on SOLID acronym.

Interface Segregation principle (ISP)
Interface Segregation Principle stats that, a client should not implement an interface, if it doesn't use that. This happens mostly when one interface contains more than one functionality, and client only need one functionality and not other.Interface design is tricky job because once you release your interface you can not change it without breaking all implementation. Another benefit of this design principle in Java is, interface has disadvantage to implement all method before any class can use it so having single functionality means less method to implement.

Programming for Interface not implementation
Always program for interface and not for implementation this will lead to flexible code which can work with any new implementation of interface. So use interface type on variables, return types of method or argument type of methods in Java. This has been advised by many Java programmer including in Effective Java and head first design pattern book.

Delegation principle
Don't do all stuff  by yourself,  delegate it to respective class. Classical example of delegation design principle is equals() and hashCode() method in Java. In order to compare two object for equality we ask class itself to do comparison instead of Client class doing that check. Benefit of this design principle is no duplication of code and pretty easy to modify behavior.

Y volviendo sobre la idea de su aplicabilidad en Plex, sin duda lo es. En algunos casos fácilmente entendible, (Favor Composition over Inheritance, Encapsulate What Changes, DRY,  Favor Composition over Inheritance) y en otros casos, después de luchar contra la vía fácil de hacer las cosas (Programming for Interface not implementation). Solo veo difícil implementar Dependency Injection. Y cuando me refiero a aplicabilidad, lo hago a nivel del modelo, no a nivel del código generado, donde su aplicabilidad está asegurada.
Plex, como otros productos, admite distintas interpretaciones, distintas formas de desarrollar. Aplicar principios de OOD permite explotarlo en forma más productiva, potenciando sus características. Luchar por no usar una hoja de ruta rutinaria favorece resultados consistentes y duraderos.

Críticas a OOP

James Hague, programador funcional (o por lo menos por un tiempo), interesado en Python y Erlang, hablando del primero, hace una referencia a la programación orientada a objetos, puntualizando lo que lo aparta de oop:

 (Don't Distract New Programmers with OOP) 
[...] The shift from procedural to OO brings with it a shift from thinking about problems and solutions to thinking about architecture. That's easy to see just by comparing a procedural Python program with an object-oriented one. The latter is almost always longer, full of extra interface and indentation and annotations. The temptation is to start moving trivial bits of code into classes and adding all these little methods and anticipating methods that aren't needed yet but might be someday.

When you're trying to help someone learn how to go from a problem statement to working code, the last thing you want is to get them sidetracked by faux-engineering busywork. Some people are going to run with those scraps of OO knowledge and build crazy class hierarchies and end up not as focused on on what they should be learning. Other people are going to lose interest because there's a layer of extra nonsense that makes programming even more cumbersome.

At some point, yes, you'll need to discuss how to create objects in Python, but resist for as long as you can. 

Esta nota de Hague es de marzo de este año. Por casualidad o no, ese mes otro entusiasta de la programación funcional desacredita totalmente oop. Y nada menos que en un curso introductorio de Carnegie Mellon.
Sería muy interesante conocer un balance del curso terminado.

Diseño dirigido por modelos, en tránsito

Jean-Jacques Dubray publica en InfoQ hace ya algunos días, algunas reflexiones sobre el desarrollo basado en modelos, indagando sobre su estado actual, y sus posibilidades de ganar terreno, o de sus dificultades para hacerlo. Su nota fue seguida por un buen número de comentarios, que dan también una idea aproximada del estado de su uso:

Ulrik Eklund published a summary of the keynote speech from Jon Whittle at the SPLC 2010 conference. In his talk, he presented some findings on experiences from using model-based development in industry from the EA-MDE project. The project is interested in understanding the factors that lead to success or failure with model-driven engineering (MDE) to help design the next generation of MDE tools. This question is not new, two years ago, Sven Efftinge, Peter Friese and Jan Köhnlein published an article "MDD best practices and Johan Den Haan, CTO of Mendix, published an article on the how an MDD initiative could fail. Adopting an MDE approach can be quite daunting. Then, Johan concluded his article by:

It’s not my goal to discourage you from starting with model-driven software development. I just wanted to show you the complexity of it and wanted to share some thoughts hopefully pointing you at directions helping you to overcome the complexity of MDE.

Two weeks ago he also published an article on his blog detailing the lessons he learned while building a Model Driven Software Factory and he reiterated the same skepticism:

I see Model Driven Software Development as an important part of the future of software development. However, I also see a lot of people struggle with actually using Model-Driven techniques and applying them in their daily business. It isn't trivial to build a successful Model-Driven Software factory (MDSF).

The question is actually quite popular. Last week, Marco Bramballi and Stefano Butti also published a presentation on the same topic while applying BPM and MDD to a Large Scale banking scenario with BPMN, WebML and WebRation.
In his talk, Jon provided some key success factors of a successful MDE approach, as he identified as part of his research:

1. Keep the domains (modelled, I assume) tight and narrow.
2. Target well known domains.
3. Put MDD on the critical path (he means that pilot projects never get sufficient attention and resources).
4. MDD works best form the ground up.
5. Be careful of gains that are offset elsewhere.
6. Don't obsess about code generation.
7. Not everyone can think abstractly.
8. Most projects fail at scale-up
9. Match tolls and processes to the way people think, not the other way around

In their articles, Swen, Peter and Jan also warned:

Our most important recommendation for the reader is: be pragmatic. DSLs and code generators can, when used appropriately, be an immensely useful tool. But the focus should always be the problem to be solved. In many cases, it makes sense to describe certain, but not all, aspects using DSLs.

Even though MDE is still evolving quite rapidly, Jon reports that 83% of the EA-MDE survey respondents "consider MDE a good thing".
After over a decade of Model Driven Architecture, Development and Engineering and which itself followed some rich Model Driven Development environments like NeXTStep that emerged in the early late 80s, models are everywhere, yet, in such a small quantity that our industry seems to still be looking for the path that will make Model-Driven approaches mainstream. Are we really in the position of defining "lessons learned" or "best practices" with so few successes reported? What is hampering us? Is it the focus and precisions of the model? Is it lack of tools? standards? Is is the level of abstraction that make it difficult for most people to create a viable software factory? What's your take on it?

A esta invitación final de Jean-Jacques a discutir le siguieron muchas e interesantes respuestas. Siguen algunas de ellas:
Rui Curado, autor de su propia herramienta, destaca algo que comparto:

Existing model-driven approaches were conceived by "top-notch" developers/mathematicians. This lead to the assumption that those who would use such approaches are "top-notch" developers too. And this is precisely what is happening: Current MDD practitioners belong to the "top 1%".
Most of the world's developer population (myself included) are what I call the "average developer mortal": developers who are good at their job without actually being "geniuses". People who do things the right way, but pragmatically. We are the "everyday programmer". MDD approaches and tools fail to address us

Sobre el enfoque orientado a objetos de las actuales herramientas orientadas a MDD, dice Dean Wampler:

[...] all the MDD approaches that I know of are based on objects. Unfortunately, objects have proven to be poor at defining reusable component standards. That's a controversial statement, but to prove it, ask yourself why the world's most successful "component" standards, like TCP/IP, HTTP, busses in digital electronics, etc. are not object oriented, while OO-based component standards, like CORBA, proved to be too complex to survive the test of time and to achieve ubiquitous, permanent adoption. (Still not convinced? "Design Rules, Vol. 1: The Power of Modularity" discusses the characteristics of successful modularity standards. Very few OO APIs meet those criteria.)

Dice Steven Kelly, sobre las condiciones para elaborar un modelo satisfactorio:

The key issues are:
1) use a language that is highly targeted, efficient and precise at describing the systems you want to build (and thus useless for most other systems)
2) generate production quality code that you don't need to look at or touch
3) use a toolset that makes creating the language, generators and models efficient, scalable and maintainable.

[...] Failing to reach (or even aim for) those 3 targets is what consigns most MDD attempts to mediocrity or failure. Using a tool or language because it's a "standard" or already in use is hardly likely to result in major productivity increases compared to normal. As Einstein said, insanity is doing the same things as before and expecting different results.

Steven, respondiendo a una pregunta de Dubray, dice, respecto a su afirmación de generación completa de código:

100% code generation is definitely the goal, and the norm is to achieve it. Here, 100% means 100% of the code that is specific to this model. There is of course hand-written code below the generated code: what we call the domain framework, i.e. code specifically written to complement this modeling language and generators, and which doesn't change per model.

In some cases a particular model may need an addition to the domain framework; in others models may contain snippets of code or refer to per-model functions that are hand-coded separately.

If by "custom models" you mean "custom modeling languages", then yes, at least that has been my experience. I'm not sure it's "inherently" true, but I think there are good reasons for it. Have you ever seen a tricky or laborious problem can be turned into something an order of magnitude faster and easier by applying the correct language? If so, you probably understand what I'm talking about. Obviously, in general development those situations were rare, because the right language didn't yet exist. DSM lets you create that "right language" for your needs.

Una vez más, un punto cuestionado es el uso de UML, que es confrontado con DSL (Domain Specific Languages). Por supuesto, Steven Kelly, uno de los gestores de Metaedit, es quien especialmente pone el acento en DSM (Domain Specific Modelling). Dice Kelly:

As Dean Wampler said, "Give me a language and APIs that let me express what I need to do very succinctly!" That of course is the whole idea of DSM, and why it is so different from (say) UML-based MDA. It's just a shame that working "code generation" often gets tarred with the same brush as approaches that have failed.

Of course, we're all constrained by what we have experienced personally, e.g. Dean saying that all MDD he has seen has been based on object-oriented languages (I guess referring to UML?). It's just a fact that by nature humans trust personal experience far more than even statistically significant research.

Dean said "Nothing beats a Turing-complete, textual programming language for expressivity and productivity." That may be true if you have to pick one language to use for every single task for your whole life. But for any given problem space, it's simply not true. Expressivity is the ability to say everything you want, precisely and concisely - which is as good a definition of a Domain-Specific Modeling language as you're likely to get. The consistent measured increase in productivity by a factor of 5-10 with DSM is a proven fact. And when you've actually seen DSM in practice, as opposed to code generation with UML or IDE wizards, it's obvious why it is so much faster throughout.

Jean-Jacques complementa la valoración de UML:

With respect to UML, I think the problem the industry doesn't see is that the OO metamodel is all but arbitrary. The structure of a class has nothing absolute. As such is has become a hindrance as more and more complex solutions cannot be efficiently described/implemented with a one size fits all concept. Of course all the ingredients I think are there in OO (object, property, method), but it is how they are combined that is inflexible. The tragedy with UML is to think that (abstracted) OO concepts are the foundation of modeling. They built the whole thing on the wrong foundation (MOF). As a result, people are using UML as an M3 layer, because MOF (or Ecore) is simply impractical to use.

Mi impresión: Sigue siendo un hecho que MDD es un concepto en construcción y evolución. Tras años de acento en UML como herramienta básica de elaboración de modelos, la no obtención de resultados robustos ha llevado a un punto en que se exploran otras alternativas. Probablemente, esa robustez llegará, y las variantes actuales serán sólo una parte de las herramientas que sobrevivan. Lo que no sucederá, es que el desarrollo vuelva atrás a herramientas que no impliquen generación de código y un grado alto de abstracción.

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

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.

(Thinking in Objects)

Henry Story, en su blog The Sun BabelFish, plantea un problema que mide los límites de la programación orientada a objetos, y la contrapone a las herramientas usuales en la Web Semantica. Con un ejemplo basado en el mundo del autismo, Story presenta un mundo de vistas personales, no de objetos reales. Probablemente el ejemplo usado no fue muy afortunado, particularmente en cómo implementarlo en OOP y en su contrapartida con RDF. Henry fue muy criticado, y en general con acierto, tanto en su expresión del problema en OOP como en la correlación parcial entre ambos ejemplos. Sin embargo, la presentación del problema es estimulante para medir OOP y sus límites:

In order to be able to have a mental theory one needs to be able to understand that other people may have a different view of the world. On a narrow three dimensional understanding of 'view', this reveals itself in that people at different locations in a room will see different things. One person may be able to see a cat behind a tree that will be hidden to another. In some sense though these two views can easily be merged into a coherent description. They are not contradictory. But we can do the same in higher dimensions. We can think of people as believing themselves to be in one of a number of possible worlds. Sally believes she is in a world where the ball is in the basket, whereas Ann believes she is in a world where the ball is in the box. Here the worlds are contradictory. They cannot both be true of the actual world.

To be able to make this type of statement one has to be able to do at least the following things:

• Speak of ways the world could be
• Refer to objects across these worlds
• Compare these worlds

Henry propone un ejemplo (imperfecto y criticado por varios de sus lectores):

Let us illustrate this with a simple example. Let us see how one could naively program the puppet play in Java. Let us first create the objects we will need:

Person sally = new Person("Sally");
Person ann = new Person("Ann");
Container basket = new Container("Basket");
Container box = new Container("Box");
Ball ball = new Ball("b1");
Container room = new Container("Room");

So far so good. We have all the objects. We can easily imagine code like the following to add the ball into the basket, and the basket into the room.

basket.add(ball);
room.add(basket);

Perhaps we have methods whereby the objects can ask what their container is. This would be useful for writing code to make sure that a thing could not be in two different places at once - in the basket and in the box, unless the basket was in the box.

Container c = ball.getImmediateContainer();
Assert.true(c == basket);
try {
     box.add(ball)
     Assert.fail();
} catch (InTwoPlacesException e) {
}

All that is going to be tedious coding, full of complicated issues of their own, but it's the usual stuff. Now what about the beliefs of Sally and Ann? How do we specify those? Perhaps we can think of sally and ann as being small databases of objects they are conscious of. Then one could just add them like this:

sally.consciousOf(basket,box,ball);
ann.consciousOf(basket,box,ball);

But the problem should be obvious now. If we move the ball from the basket to the box, the state of the objects in sally and ann's database will be exactly the same! After all they are the same objects!

basket.remove(ball);
box.add(ball);
Ball sb = sally.get(Ball.class,"b1");
Assert.true(box.contains(sb));
//that is because
Ball ab = ann.get(Ball.class,"b1");
Assert.true(ab==sb);

There is really no way to change the state of the ball for one person and not for the other,... unless perhaps we give both people different objects. This means that for each person we would have to make a copy of all the objects that they could think of. But then we would have a completely different problem: namely deciding when these two objects were the same. For it is usually understood that the equality of two objects depends on their state. So one usually would not think that an physical object could be the same if it was in two different physical places. Certainly if we had a ball b1 in a box, and another ball b2 in a basket, then what on earth would allow us to say we were speaking of the same ball? Perhaps their name, if it we could guarantee that we had unique names for things. But we would still have some pretty odd things going on then, we would have objects that would somehow be equal, but would be in completely different states! And this is just the beginning of our problems. Just think of the dangers involved here in taking an object from ann's belief database, and how easy it would be to by mistake allow it to be added to sally's belief store.

Henry aboga por el uso de RDF (Resource Description Framework) como herramienta capaz de expresar adecuadamente las distintas vistas de un problema, en un universo de vistas en lugar de objetos. Pero sin duda, esto merece otro espacio.
De los comentarios que siguen al artículo, particularmente abre un poco más el que hiciera Ryan, y la respuesta de Henry
Ryan:

I really like your analysis of OOP and it's relation to autism. I have never thought of it in such a way, but it does make a lot of sense (when I am able to remove my preconceptions). However, why is autism bad in this scenario (if you are even implying it)? I can understand that if our perspective is not an omniscient one then this can fail us. Would you please provide a applied example of the problem at hand with relation to your point on Semantic Web? Thanks a lot!

Henry:

Thanks for asking Ryan. Yes there are a lot of examples. The following article "Extending the Representational State Transfer (REST) Architectural Style for Decentralized Systems" which you can find here
http://portal.acm.org/citation.cfm?id=999447
makes the point about how the distance between the source of a message and the recipient of a message makes perfect immediate communication impossible, if you think of it as resources having the same access to an object. But if you think of it as message passing then you can do some interesting things... Ok I read that quickly, but that is what made me decide to write this article out today.

In the AddressBook I am writing, which I describe in an audio slide cast here:
http://blogs.sun.com/bblfish/entry/building_secure_and_distributed_social
I need to get data from distributed places around the web. This can only be done seriously if you accept that there will be spammers, liars, and just simply wrong data out there. So though you may by default merge data, you may want to make it easy to unmerge it too. I wrote about that in more detail here:
http://blogs.sun.com/bblfish/entry/beatnik_change_your_mind

As I said, if you are writing tools, that you can think of as physical, mechanical objects, that don't have to have points of view on the universe, say if you are writing a web browser, a calculator, or some such thing, then this is not important. But as soon as you want to mesh the information on the web, you will need to take the opinion of others into account. We are fast moving to a world where this is going to become more and more important.

In any case it is good to know the limitations of your tools. :-)

En el mismo sentido, apunta Benjamin Damman:

Hmmmm. Parts of your intriguing article made me think of erlang.

"When one fetches information from a remote server one just has to take into account the fact that the server's view of the world may be different and incompatible in some respects with one's own. One cannot in an open world just assume that every body agrees with everything. One is forced to develop languages that enable a theory of mind. A lot of failures in distributed programming can probably be traced down to working with tools that don't."

Erlang was created for coding highly fault-tolerant (and distributed) systems; characteristics stemming this fact might make it an example of a language that 'enables a theory of mind.'

http://erlang.org/white_paper.html

Un papel sugerente de ideas, mas allá de los puntos observados por su crítica.

El duro trabajo de salir del enfoque procedural

Me inicié en la programación aprendiendo de profesores y mentores que a su vez se iniciaron desde el Assembler y el Fortran hasta el Cobol. Como he reconocido, mi primer contacto con Yourdon fue cuando la programación y el diseño estructurado eran la forma correcta de hacer las cosas. Por lo tanto, a diferencia de los nuevos programadores o analistas o diseñadores, siempre tengo que pensar dos veces un problema: primero la vía "natural" procedural, y luego como mundo de objetos. Andando el tiempo, sin embargo, encuentro que en el mundo diario, es mucho más frecuente encontrar el modo de enfocar un problema orientado a los procesos, que el modo basado en objetos. Dos o tres discusiones en comp.object, el grupo Google que me resulte de mayor interés, me muestran sin embargo que los tropiezos no son sólo míos. En el link que titula esta nota se menciona a uno de estos casos, donde Lahman reenfoca desde el punto de vista de objetos un algoritmo presentado como secuencia de procesos.
Pero el más interesante y valioso de los varios casos sobre lo mismo es el llamado "OOP/OOD Philosopy". Invito a seguir la discusión y poner a prueba sus criterios.