Monthly Archives: August 2008

The Six Faces of IT Complexity

I received an email from Roger Sessions, announcing his most recent issue of the ObjectWatch Quarterly Newsletter. ObjectWatch Newsletter is now in its thirteenth year of publication. He has written seven books including Simple Architectures for Complex Enterprises and many articles. In each issue, Sessions comments about one topic. This time, the topic of the Issue #57 (August 2008) is “The Six Faces of IT Complexity”. You can download the PDF version from:

Issue #57 (August 2008)

He has been studying IT complexity for several years now. Sessions has concluded that the vast majority of IT complexity falls into six categories. According him, if you can control these six categories, you can dramatically reduce the complexity that is choking your IT projects and preventing them from delivering business value.

These are the six causes of IT complexity Session enumerates (I take description from his articles and posts):

  1. Decompositional Failures – that is, systems that have not been decomposed into small enough subsets.
  2. Recompositional Failures – that is, systems that have been decomposed into subsets that are too small and have not been recomposed appropriately.
  3. Partitioning Failures – that is, systems in which either data and/or functionality has been divided into subsets that do not represent true partitions.
  4. Synergistic Failures – that is, systems in which functionality and/or data placement does not pass the test for synergy.
  5. Boundary Failures – that is, systems in which the boundaries between subsets are weak.
  6. Removal Failures – occur when there is functionality in a system that is unnecessary.

Read the article to a more detailed discussion, with real examples.

I know Sessions’ work since his book: Software Fortresses (I commented the book in an Spanish post), where Sessions gave us a new way to think about Service-Oriented and Enterprise Architectures.

Sites to visit:

The whitepapers at:

(I have to read one comparing enterprise architecture methodologies, like Zachman Framework)

Newletters index at:

(there are issues dedicated to SOA, complexity, Software as a Service, Enterprise Architecture…)

and Sessions’ new blog:

Simple Architectures for Complex Enterprises

promoting and discussing his new book of the same title:

(at Amazon)

Angel “Java” Lopez

AjBasic: an open source Basic-like interpreter

My code generation project AjGenesis uses a interpreted language to execute tasks and expand templates. The language was named AjBasic. It’s used in all the examples I wrote with AjGenesis (more info at AjGenesis posts). Years ago, I had separated the interpreter code from the mother project. This weekend, I was refactoring the code. The result is now published at:

In my opinion, Google Code is easy to manage. Contrary to SourceForge and CodePlex, they are using Subversion as code repository. I use the Tortoise SVN client to checking the changes. Google people are gentle: I can create many projects, until now: (it’s in good form, I guess) (it’s still in its infancy)

More info in previous posts:

AjLisp- a Lisp interpreter in .NET
AjTalk- a Smalltalk-like interpreter

The Solution

The solution AjBasicWithTests is composed by the projects:

AjBasic: It implements the compiler and tokenizer. The tokenizer separates the incoming text in tokens. The compiler makes abstract trees from such input.

AjInterpreter: A new project, not present in AjGenesis. It contains all the support for the abstract tree, its nodes, the environment for values, and an evaluator of programs. The management of .NET objects, and dynamic objects, are in this project, too. My intention is to continue to use this project to support other interpreted languages.

AjBasic.Console: A simple console to test the interpreter.

AjBasic.GUI: A simple (and ugly) WinForm to test the interpreter.

AjBasic.Test: Some test fixtures, using NUnit (there is another solution AjBasic that not includes the tests)

All the projects are written using Visual Basic .NET. The solution was compiled using Visual Studio 2005. The console and GUI project could be used as a base that explains how to use the interpreter from your own application.

There are many points to discuss about the implementation: they would deserve future posts. By now, let’s explore some of the main features of the project, at its current status. Then, I’ll write down some ideas to explore in future versions.

As I mentioned, the language was born to support code generation inside AjGenesis. I designed it to manage native .NET objects, as dynamic object. But, what is a dynamic object? Its an object that has no class, but that can be expanded with new properties (the nearest example I could think now, are the Javascript objects).

So, you can write code like this:

a.FirstName = Adam a.LastName = Doe a.Age = 800

You don’t have to declare the variable. You can create the object and add the property FirstName in one command (this automatic creation of object is not supported in AjGenesis, yet).

You can test the existence of a property:

if a.LastName then it has a LastName not nothing elseend if

If the variable a has no assigned value, or if it has no LastName property, the above condition is evaluated to false. You can test something like and no exception is raised. The result value would be a nothing, what is evaluated as a false in a condition.

The Tests

The solution was not developed using TDD (Test-driven development). Instead, I wrote the tests after the code, only to be sure the core functionality were well implemented, according to my expectations. I didn’t use descriptive names, but they were useful when I refactored the full solution:

You can try the language from the console AjBasic.Console:

and from the WinForm AjBasic.GUI

None of the above is the “ultimate app”, but they work… 😉

Next Steps

There are many ideas flying near my remaining neuron, and I have to put order on them. Some points, for the record:

– Now the interpreter core is separated from compiler, I could write AjSharp, an interpreter with C# syntax. Then, it could be added to AjGenesis, to write templates in a language more palatable to die-hard C# programmers.

– Add support to dynamic classes and prototypes.

– Refactor the tests

– Write down a minimal manual, explaining the language and its features

– Extend the language to support delayed values and delayed evaluation

– The internal form of this interpreter could be rewritten in Java

– The option to write an AST related to DLR support doesn’t attract me, it could be a lot of work. But it could be interesting to learn more about .NET DLR.

– Use the language as the basis for programming distributed agents (an ambitious point, that deserves more evaluation).

As usual, I had fun written this software.

Angel “Java” Lopez

Top ten code-generation rules

Everyone can recognize me as a die-hard code-generation fan, with a twist: use a model as the starting point. I adopted the idea every week, practicing “dog fooding”, using my own code generation project AjGenesis. This week, I’m reading the now classic book “Code Generation in Action” , by Jack Herrington, edited by Manning. This book is a “must be read” to everyone interested in code generation. It’s a very interesting reading for developers, but also to managers: the author makes the case for use code generation, appealing to increasing quality and productivity, including agile teams.

In the first chapter, Herrington lists top ten rules I want to comment in this blog. The indented paragraphs are textual excerpts from the book (section 1.7), followed by my own comments:

Give the proper respect to hand-coding

You should both respect and loathe handwritten code. You should respect it because there are often special cases integrated into code that are overlooked with a cursory inspection. When replacing code you’ve written by hand, you need to make sure you have the special cases accounted for. You should loathe hand-code because engineering time is extremely valuable, and to waste it on repetitive tasks is nearly criminal. The goal of your generator should always be to optimize the organization’s most valuable assets—the creativity and enthusiasm of the engineering team.

Yes, the basis of code generation is to make easy to delegate the repetive tasks to the machine. We have to use tools that make easier our work: that’s the reason we are using compilers nowadays, instead of switching the bits directly in memory (or setting the relays in the old Eniac). Code generation rationale is not to destroy the handwritten code: its mission is to support it.

Handwrite the code first

You must fully understand your framework before generating code. Ideally, you should handwrite a significantly broad spectrum of code within the framework first and then use that code as the basis of the templates
for the generator.

Absolutely yes. Sometimes, new users of AjGenesis begin to use it directly from the examples. That is good, but it would be better to generate an example using the framework and technology they uses. If you know how to program using Struts/Hibernate, then, you can separate the variations from the essentials. At that point, you can begin to write the code generation artifacts (templates, tasks).

Control the source code

I can’t stress enough the importance of having a robust source-code control system. This is critical to a successful code-generation project. If your generator works directly on implementation files that contain some hand-written code, make sure you have a versioning system running that can protect your work.

Another path: if you generate the code from a model, check in only the model. The rest of the artifacts will come from code generation process. With the current technology, you can’t generate ALL the solution, but you can separate, with care, the generated part from the manual one.

Make a considered decision about the implementation language

The tools you use to build the generator do not have to be the same tools you use to write the application. The problem that the generator is trying to solve is completely different from the problem being solved by the application. For that reason, you should look at the generator as an independent project and pick your tools accordingly.

That is one of the reasons that supports my adoption of a new language (affectionately named AjBasic) for my code generation tool AjGenesis. I wanted a dynamic language under my control, to extend in any direction the code generation process requires. In one of my initial test, I tried PHP, but I prefer to have a dedicated language.

Integrate the generator into the development process

The generator is a tool to be used by engineers; thus, it should fit cleanly within their development process. If it is appropriate, it can integrate with the integrated development environment (IDE), or in the build process or check-in process.

Making the core of AjGenesis as a class library, it could be integrated to other tools. You can use from NAnt, for example. An IDE tool calling AjGenesis is a pending task.

Include warnings

Your generator should always place warnings around code that it generates so that people do not hand-tweak  the code. If they hand-tweak the code and rerun the generator, they will lose their revisions. In addition, your first response to people ignoring the warnings should be to help them and not to berate them. The fact that  they are using your tool is a big step. Learn why they needed to ignore the warnings and improve  the generator or the documentation. You are the emissary of your tool.

In AjGenesis, this issue is the concern of the templates the user writes. You can add any text you like: that’s the power of writting your own templates, you have the ownership of the generated code.

Make it friendly

Just because a generator is a tool for programmers doesn’t mean it gets to be rude. The generator should tell the engineer what it’s doing, and what files it has altered or created, and handle its errors with a reasonable amount of decorum. It may sound silly, but a tool that is difficult to use or that’s flaky will be ignored and your efforts will be wasted.

AjGenesis core is a dll, that can be invoked from any application. Years ago, I wrote tasks to use it from NAnt. Thanks to Jonathan Cisneros, we have now the AjGenesis Studio, since last year. I improved the original code at the beginning of 2008, adding AjGenesis Web Studio. The error handling must be improved, specially for new users of AjBasic.

Include documentation

Good documentation is a selling point for the generator. Your documentation should be thorough but not overwhelming, and should highlight the key points: what the generator does, how it is installed, how it is
run, and what files it affects.

Actually, is a point not very covered by AjGenesis. But in exchange, there are many blog posts explaning the process, ideas, and examples (AjGenesis posts) (AjGenesis posts in Spanish). Users of the tool are beginning to write too (read Carlos Marcelo Santos posts). There is an Spanish email list where the users can discuss the tool (Code Generation group). And in the Codeplex project page, there are examples for Java, .NET, and PHP, many of these using the same model (the litmus test).

Keep in mind that generation is a cultural issue

Educating your colleagues through documentation, seminars, and one-on-one meetings is critical to successfully deploying the generator. People are skeptical of new things, and a good programmer is twice as skeptical as the average person. You need to break through those concerns and doubts and emphasize that you designed the generator for their benefit.

I gave three to four speech by year, only dedicated to explain the tool and its potential. Additionaly, I explain the tool in every course I give (Java, .NET, PHP, or software development in general). But to be adopted in a company or project, a power user must became the champion of the tool. It’s not easy to raise the level of abstraction, write the model and its transformation, in the middle of the day to day work.

Maintain the generator

Unless the generator is just a temporary measure, it will need to be maintained long term. If the generator manages a large portion of code, treat it just as you would an engineer maintaining that same piece of code. Your budget should include dedicated time and money for maintaining and upgrading that resource.

AjGenesis is not the “things” to maintain. They are the templates and tasks you use in your work. If you adopt the tool to generate .NET applications, you have to change and improve the templates when new tech appears (LINQ, ASP.NET MVC….). And when you gain experience, you have to improve the model itself, if you discover new ways to represent the product lines your company are involved.

I could add some points more:

– The generated code generated must be the kind of code you are proud to write by yourself. The tools should not dictate the form and appearance of such code.

– The use of a model raise the level of abstraction. Such strategy separates the wheat from the chaff, put the technicalities in the place they deserve: the importance is in the model

Well, enough for now. As you can notice, code generation is one of the subject that passionate me. It’s not the silver bullet. But it is a bullet I want to have, just in case.

Angel “Java” Lopez

New Smalltalk Site:

These days, this new site dedicated to Smalltalk was launched:

According to the site: is a non-profit organization which congregates Smalltalk programmers and enthusiastics. In 2008, we are going a step forward with this new website.
The big idea behind this website is to provide a source of information about Smalltalk in general.
The Smalltalk community has not good sources of information, or they’re all over the net, and sometimes it’s difficult to find them.

If you want to contribute, you’re welcome!

It’s an spinoff of the activity of the Spanish mailing list:

Some of the most popular articles published:

Interview with Luca Bruno, the creator of Smalltalk YX

Argentinian Smalltalk Congress- Smalltalks 2008

Seaside and Ruby on rails

It has sections:


Smalltalk Frequently Asked Questions

GemStone Frequently Asked Questions


Commercial Smalltalk Environments

Free Smalltalk Environments

Abbandon Smalltalk Environments

Frameworks, Platforms & Tools

and more: Tools, Resources, Community. It has links to Smalltalk Books, like:

Free Books 

Thanks to the work of Stéphane Ducasse, we have a huge collection of Free Smalltalk books online.
Download from

Creative Common Books

Our friend Diego Gomez Deck has written an excellent book in Spanish to start in Smalltalk. You can buy a hardcopy or you can download it under the creative common licence from
If you like it, we recommend to buy it, we are proud of this kind of projects.

The site is in its infancy, but I hope that with the help of the Smalltalk community, it will grow and become a reference to anyone interested in ST.

It’s supported by PHP. In my opinion, it’s a good sign: for years, Smalltalk community was reluctant to integrate or use other tools or technologies. In these days, with the plethora of languages, frameworks and platforms, we must abandon such isolated trend, and be more integrated.

Angel “Java” Lopez

Agiles 2008 in Argentina

A group of people and companies, agile practicioners and enthusiasts, are organizing (in agile way, what else?) the forthcoming:

First Latin-American Conference on Agile Development Methodologies


Among the international experts that have already confirmed their participation in Ágiles 2008 are Mary and Tom Poppendieck, Matt Gelbwaks and Tobias Mayer.

Tobias Mayer is an agile coach, that teach agile methodologies to most of us, here, in Buenos Aires and in other cities of Argentina. He is a kindly man, with great abilities to inspire and engage people in agile way. He could be considered the “godfather” of agile movement in this country… 🙂

The organizers are calling for papers, ideas, proposals for activities:

Attending a conference without saying a word is too boring! We welcome your ideas to actively take part in Ágiles 2008. We have three kinds of activities in mind: Talks (the usual slideshow, people seated, Q & A at the end), Interactive Sessions (people standing, moving around, talking, doing) and Panels (subject open to discussion, format to be defined). But fear not: we are eager to receive your craziest idea! Just write us and we will try to find its place in the world.

Slots are 45 minutes long, but you may take more than one for a single activity.

Deadline is September 1st. You may leave us your proposal filling the form in

Ágiles 2008 Organization Team

For years, agile methodologies were gaining acceptance in my country, Argentina, and in Latin America. And now is the time to show to the rest of the industry what is all that agile movement.

Just do it (with a backlog… 😉

Angel “Java” Lopez

Smalltalk 2008 in Argentina, Call for Papers

Last year was the first installment of this argentinian Smalltalk conference. Now, a group is preparing the 2008 version. This is the site (Seaside based) and annoucement:

Smalltalks 2008 – 2nd Argentinian Smalltalk Conference


This year’s conference will take place on the 13th, 14th and 15th of November on the Universidad Abierta Interamericana, Av. Montes de Oca 745, Buenos Aires, Argentina. Like the 2007 conference, the registration will be free of charge.

This year we are willing to offer new activities. For this reason we open the calls for:


The conference will have two tracks, one on Scientific Research and other on Software Development for Industries.

Programming Contest

This year we will host a programming contest, encompassing all Smalltalks dialects.


Guest lectures by outstanding personalities.

Hands on

Tutorial sessions.

There is a call for papers (PDF version), about topics:


  • Aspects, Aspect Languages and Applications.
  • Ambient Intelligence, Ubiquitous / Pervasive Computing and Embedded Systems.
  • Compilation Technology, Optimization, Virtual Machines.
  • Educational Material.
  • Language Engineering, Extensions.
  • Model Driven Engineering / Development.
  • Meta-Modeling.
  • Programming in the Large, Design, Architectures and Components.
  • Programming Environments, Browsers, User Interfaces, UI Frameworks.
  • Reasoning About Code (Analyses, Refactoring, Type Inference, Metrics).
  • Reflection and Meta-programming.
  • Team management.
  • Testing, Extreme Programming / Practices.
  • Web Services, Internet Applications, Event-driven Programming.
  • Experience Reports.

Interesting, this year they are extending the scope of the research and educational track to include other dynamic languages, not only Smalltalk. They have an impressive Program Committee:

  • Federico Balaguer (LIFIA, Universidad Nacional de La Plata, Argentina)
  • Tulio Ballari (UTN, Buenos Aires, Argentina)
  • Alexandre Bergel (INRIA, Lille, France)
  • Gilad Bracha (Cadence Design Systems, USA)
  • Johan Brichau (Université Catholique de Louvain, Belgium)
  • Cecilia Challiol (LIFIA, Universidad Nacional de La Plata, Argentina)
  • Marcus Denker (SCG, University of Bern, Switzerland)
  • Fernando Dodino (UTN, Buenos Aires, Argentina)
  • Stéphane Ducasse (INRIA, Lille, France)
  • Alejandra Garrido (LIFIA, Universidad Nacional de La Plata, Argentina)
  • Tudor Girba (SCG, University of Bern, Switzerland)
  • Orla Greevy (SCG, University of Bern, Switzerland)
  • Julián Grigera (LIFIA, Universidad Nacional de La Plata, Argentina)
  • Andy Kellens (PROG, Vrije Universiteit Brussels, Belgium)
  • Kim Mens (Université Catholique de Louvain, Belgium)
  • Guillermo Adrián Molina (ESSI Projects, Spain)
  • Damien Pollet (INRIA, Lille, France)
  • David Röthlisberger (SCG, University of Bern, Switzerland)
  • Daniel Solmirano (UTN, Buenos Aires, Argentina)
  • Tom Van Cutsem (PROG, Vrije Universeit Brussels, Belgium)
  • Roel Wuyts (IMEC, Belgium)

Smalltalk is a technology that, in my opinion, failed to crossing the chasm. At late 80s, early 90s, the community was divided in many diverging dialects and commercial implementations. But it has impetus and loyalty members, as was proved last year, here, in Argentina, with the success of the last year conference. I hope Smalltalk could integrate with other technologies, like .NET and Java, in order to gain more momentum and acceptance. See, as an example, F# adoption in scientific community: the access to a popular class framework is a key feature in today mainstream. Insisting in one world, one language attitude is not an option, nowadays. I celebrate, then, the open of the above call for papers to other dynamic languages.

Angel “Java” Lopez

Closures in F#

In my previous post about F#:

First steps in F#

I declared that there is no variable in the language, instead, we talk about identifiers. Why? Let’s explore the concept of closure, and how is used in F#.

According to Wikipedia article about closures in computer science:

a closure is a function that is evaluated in an environment containing one or more bound variables

But, what does this mean? To reveal its meaning, let’s assign a value to an identifier, using fsi.exe, the F# interactive interpreter:

MSR F# Interactive, (c) Microsoft Corporation, All Rights Reserved
F# Version, compiling for .NET Framework Version v2.0.50727

NOTE: See ‘fsi –help’ for flags
NOTE: Commands: #r <string>; reference (dynamically load) the given DLL.
NOTE: #I <string>; add the given search path for referenced DLLs.

NOTE: #use <string>; accept input from the given file.
NOTE: #load <string> …<string>;
NOTE: load the given file(s) as a compilation unit.
NOTE: #time;; toggle timing on/off.
NOTE: #types;; toggle display of types on/off.
NOTE: #quit;; exit.
NOTE: Visit the F# website at
NOTE: Bug reports to Enjoy!

> let x = 2;;

val x : int

Now, we have an identifier named x. We can show its value:

> x;;
val it : int = 2

A simple integer. Now, we cannot change its value: this identifier was carved in stone as an integer 2. Nothing in the human history could change its value. Is it true? Let’s define a function:

> let dup n = n * x;;

val dup : int -> int

This function dup takes an argument n and multiplies it by the value of identifier x. This identifier is a free “variable” in the function. During the evaluation of the function, x takes its value from the environment. Let’s try now:

> dup 3;;
val it : int = 6

The result was six, as expected. But now, let’s “change” the value of x:

> let x = 3;;

val x : int

> x;;
val it : int = 3

But this is the point to understand closures: this “x” is ANOTHER identifier, that it shadows the previous one. BUT, for the function dup, the identifier x is STILL the previous one. Let’s try again to invoke the function:

> dup 3;;
val it : int = 6

The dup still uses the original x!! That’s the closure in action. If we try:

> dup;;
val it : (int -> int) = <fun:clo@0>

Note the clo @ 0 : its the signature of the closure this function is using. It points to the original environment where the function was defined.

This feature implies that the behaviour of a function doesn’t change after its definition. Even the apparently “free variables” are bounded at definition time. All this is part of the solid fundations of functional programming, in general, and F#, in particular.

About closures and related concept, lambdas, these are the seminal papers:

The Original ‘Lambda Papers’ by Guy Steele and Gerald Sussman

You can learn a lot about Lisp, and closures/lambdas, visiting:

Closures + Lambda = The key to OOP in Lisp « Learning Lisp


I implemented some lambdas and closures, in my Lisp interpreter:

AjLisp: a Lisp interpreter in .NET

More C# related stuff about closures:

What’s In A Closure?
Fibonacci Numbers, Caching and Closures

Angel “Java” Lopez