Programming languages


, , , ,

Along my studies and professional career I have used a large number of programming languages, as may have been the case for most people who has had a long technical career in software development.

I started using Basic, it was 1990, then I moved to Pascal and C. When I arrived to the university it was Modula-2 (a Pascal dialect, or maybe is the other way round), C became often C++ and other languages like Eiffel (that we had to use with a compiler limited to 100 classes). In addition to that, there were the mathematical languages Matlab, Mathematica, Maple or because I used it in that context Fortran and some other related to circuit design that I can’t even remember now despite the many hours spent. In Artificial Intelligence courses I used Clips, as far as I remember it was introduced as a variant of Lisp, maybe because of the use of parentheses, maybe for deeper reasons.

When I started working most of the languages evolved ( or I found their evolved version) and they got a V in front of them, Visual Basic, Visual C++ and even Pascal got a “Visual” version that was named Delphi. I also worked for a while in Java and Python.

Legacy systems where still there and many big corporations depended on them (and still do) like Cobol. Many other languages became popular with the Internet boom: javascript, Perl, PHP but I had no exposure to them although I took some time to read even if just a short tutorial about the language. Honestly, quite often it was difficult to remember which language was what because they were too similar.

This is still a very narrow perspective of available and popular technologies back in 2007. It was hopeless trying to keep track of all the programming languages. I was not the only, not the first in getting to that conclusion. The United States Department of Defense had got to the same conclusion in the early seventies. Here you can find a more comprehensive perspective of the existing programming languages.

Internally the DoD was using more than 100 different programming languages in a number of different systems. In order to address this issues, yes, it’s an issue when an organization has to deal with that, they developed a new programming language, ADA, that should be of universal use in the organization, I haven’t read though about the percentages of adoption in the organization and certainly it has not become very popular in general.

Yet, the solution to too many programming languages was to define a new one, not evolve one of the existing ones. This is probably just a matter of “how to name things” as the new language was for sure influenced by the existing languages but still it matters as it gives us hints that authorship and collaboration are part of the main problem. Certainly, I doubt that the reasons are so devilish as the ones attributed to Bjarne Stroustrup for designing C++, a hoax that has been around for a while, you can read an article explaining about it here.

As technology has become accessible to more people, the number of programming languages has continued growing and my perception is that the pace is faster too. In some cases, few of them, languages contribute new paradigms to address new scenarios, in other cases, my understanding is that the claim is speed of development for the most common tasks in a certain context.

If you are still not convinced of the magnitude of the issue, here you can find a more visual and compelling representation up to 2004, no, it is not obsolete now, it was already obsolete the moment it was published!!!

Good then, SW developers have plenty of tools to choose from. This should be all good, right? Well, it has some advantages true… but to me is more like a Divide and Dillute approach. Many of this programming languages, the ones that reach some popularity achieve so because they manage to have the support of the community that adopt the language and start contributing new developments to the language ( tools, libraries, tutorials, …). But as it happens in many other fields there is the long tail, those languages that do not generate traction. There is a huge effort put whose return is small, except for the people directly involved that in the process have learned a lot. And the drawbacks are significant, because every new programming language implies starting from zero to create all the ecosystem required to be productive using it.

Who knows where computing would be if the open source initiatives (I put aside the commercial efforts) tried to collaborate more often and do it from scratch when a new need is detected. Obviously, the community becomes very efficient when a programming language has gained some visibility and there is some kind of snowball effect that helps to bring a lot of collaboration together. But this efficiency does not happen or is not sought when the programming language is being defined.

Wouldn’t it be a great thing if there was an organization that helped to unify efforts and avoid “duplicates” when someone decides to design or considers there is need for one new programming language?

While this doesn’t happen, and while developers need to be able to deliver in record time to cope with tyrannic deadlines and increasing needs of productivity, it is required to find ways to get the job done. And quite often, the way to do it is to put to good use sites where the knowledge is shared (like, where libraries and tools are shared (like and many others. The use of this kind of websites in order to help develop software applications suggests me a concept that I have named “online programming” (but better leave it for another post).

Why not then use this same collaborative platforms in order to help aggregate energy, knowledge and initiative in larger initiatives? It is true that there are many things to agree on when it comes to this much larger projects and that the effort on creating the required consensus may be significant but if there is success the result can be very promising, a programming language created by the community. Can you think of a more ambitious computing project? The esperanto of programming languages.


Management lessons from Vito Corleone


, , , ,

From Florian Mueck blog. Not a funny article, but a serious well structured and with clear points to extract from the movie character about decision taking and leadership.

I hope you enjoy it as much as I have.

The Godfather

Principles, models & inspirations


, , , , , , , , , ,

Unlike other disciplines, software development products cannot be fully validated before they are built. When you design a building or a bridge, applying physical models and laws, it is possible to guarantee that the construction will not collapse under normal conditions and excluding construction issues like concrete composition or the design metrics not been respected. This allows to undertake very complex architectural projects that otherwise would be very risky to assume. In summary, because there is science behind, mankind has the means to achieve mastery in construction.

Software engineering has the aspirational objective of achieving this maturity but unfortunately it is not possible to create a model of what you are building without building it. The model itself, once finished becomes the deliverable. The closer comparison would be moving your software from your development environmet to your production environment, with any intermediate steps you may have (test,preproduction).

To overcome this, and provide the discipline with all kinds of warrants during every step of the implementation, software engineers have come out with a wide variety of models, principles and patterns that guide and inspire them throughout the process, bringing light to a task that otherwise would remain uncertain in terms of achieving its goal and mystical in the means that intervene.

Even when this is true, gurus, ideologist, visionary and Illuminati in the field have created a terminology to keep the knowledge in the initiated circle.

Hence, we have that OOP, a paradigm in itself, should be SOLID, while within our GRASP, DBT must  be ACID what can be weird for newcomers. You better adjust yourself from the beginning being TDD and/or BDD,  maybe modularizing following an AOP approach.

OOP paradigm

In IT security you must remember AAA to have a CIAAN service that you manage using a PDCA iterative cycle that maintains your BCP in sync with your business.

The list is endless even if we keep it limited to Programming paradigms. This doesn’t mean that the rest of science and engineering is free of paradigms that can not be elevated to the category of laws or theorems nor rejected as partial or wrong.

The future though is promising, if we observe scientific paradigms they are at the boundaries of the discipline. It´s not adventorous to consider paradigms progress pushers and hence responsible for any evolution.


The difference is that computer science is a relatively young discipline and paradigms outnumber theorems.

And while it could be contradictory, most of the theorems (Turing Completeness,P vs. NP,Halting Problem, Turing Test) are not relevant to the more daily tasks and problems a computer engineer may require, although some appear or should be considered more often than intruders in the profession may want to admit.

Also, efforts have been made to provide powerful tools for more regular programming tasks. Formal verification lies in this category, but reality is that we don’t see it used very often. Its complexity make it overwhelming for many tasks that would benefit from using it but it should still be kept in mind as a resource.

While computer science doesn’t reach maturity, paradigms are the crutches that help us get to our destination, the baby walker that guides our intuition and  feeds our experience to achieve our goals in computer engineering and software development. They are our best option while the Vademecum for software development is not validated,  approved and published.


Death by Agile fever


, , , , ,

A critical view on Agile software development methodologies:

It is difficult to disagree or agree but I would highlight this paragraph from the conclusions in the article:

In fact, using a model such as The Frog and the Octopus is an effective way to engage people infected with Agile Fever because it removes reference to Agile from the discussion of software development altogether. Instead of putting an infectee immediately on the defensive by suggesting, for example, that an Agile based software development process may not be the best fit, a better tactic is to discuss the applicability and value of adopting development strategies in a general sense. Those discussions might include considerations that are typically associated with Agile based processes such as requirements flexibility, schedule elasticity, extent of customer engagement, ability to co-locate the staff, and any other attributes that might be relevant to the program’s context.

As a developer I have never had that feeling of “this or that programming language or technology fits all needs” and as a project manager the homologous condition would be equally dangerous. Methodologies and processes are a reference that always must be adapted to the specific needs of a project and organization.

Inspirational videos


, , , , , , , , ,

While reading on several topics to prepare for one of my next posts, I have found these two video jewels that I have enjoyed a lot. The joy comes from several aspects.

First, because they agree on some ideas that I had already drafted on my post, that is always something rewarding. We, human beings, like to find people who share our ideas no matter how crazy the idea is. In my case, even when I have been thinking on a new product or service and have found that somebody else had already developed it, after the first initial disappointment of not being so innovative, I have found myself very happy because the idea was worth enough so that other people was already working on it.

Second, because it has answered some questions that I also had on mind that were blocking me to develop some initiatives, in fact, even finishing the post itself. Hopefully, now I will make more progress.

The first video is about testing new products. Not only the keynote is delivered in a very entertaining way it is also very clear and well structured and with brilliant ideas and paradigms. I may say that it is kind of US centric in some aspects(you will understand when watching it),  but except for that it is a ‘must see’ for any person considering to develop a new product/service in the Internet.

The second video, puts together several methodologies from different disciplines: Agile, Lean, new business creation and product definition are combined in a very natural way.

My conclusion, summarizing both videos, is:

The better your product is, the least mature it needs to be before being released because the most eager your users will be to enjoy it.

The conclusion can be more ellaborated but doing so would dillute the essential message, so I will explain it more in a future post.