Archive for April 2013

Bringing C code to the modern world

The C2Eif translator developed by Marco Trudel takes C code and translates it into Eiffel; it produces not just a literal translation but a re-engineering version exhibiting object-oriented properties. Trudel defended his PhD thesis last Friday at ETH (the examiners were Hausi Muller from Victoria University, Manuel Oriol from ABB, Richard Paige from the University of York,  and me as the advisor). The thesis is not yet available online but earlier papers describing C2Eif are, all reachable from the project’s home page [1].

At issue is what we do with legacy code. “J’ai plus de souvenirs que si j’avais mille ans”, wrote Charles Baudelaire in Les Fleurs du Mal (“Spleen de Paris”). The software industry is not a thousand years old, but has accumulated even more “souvenirs” than

A heavy chest of drawers cluttered with balance-sheets,
Poems, love letters, lawsuits, romances
And heavy locks of hair wrapped in invoices

We are suffocating under layers of legacy code heaped up by previous generations of programmers using languages that no longer meet our scientific and engineering standards. We cannot get rid of this heritage; how do we bring it to the modern world? We need automatic tools to wrap it in contemporary code, or, better, translate it into contemporary code. The thesis and the system offer a way out through translation to a modern object-oriented language. It took courage to choose such a topic, since there have been many attempts in the past, leading to conventional wisdom consisting of two strongly established opinions:

  • Plain translation: it has been tried, and it works. Not interesting for a thesis.
  • Object-oriented reengineering: it has been tried, and it does not work. Not realistic for a thesis.

Both are wrong. For translation, many of the proposed solutions “almost work”: they are good enough to translate simple programs, or even some large programs but on the condition that the code avoids murky areas of C programming such as signals, exceptions (setjmp/longjmp) and library mechanisms. In practice, however, most useful C programs need these facilities, so any tool that ignores them is bound to be of conceptual value only. The basis for Trudel’s work has been to tackle C to OO translation “beyond the easy stuff” (as stated in the title of one of the published papers). This effort has been largely successful, as demonstrated by the translation of close to a million lines of actual C code, including some well-known and representative tools such as the Vim editor.

As to OO reengineering, C2Eif makes a serious effort to derive code that exhibits a true object-oriented design and hence resembles, in its structure at least, what a programmer in the target language might produce. The key is to identify the right data abstractions, yielding classes, and specialization properties, yielding inheritance. In this area too, many people have tried to come up with solutions, with little success. Trudel has had the good sense of avoiding grandiose goals and sticking to a number of heuristics that work, such as looking at the signatures of a set of functions to see if they all involve a common argument type. Clearly there is more to be done in this direction but the result is already significant.

Since Eiffel has a sophisticated C interface it is also possible to wrap existing code; some tools are available for that purpose, such as Andreas Leitner’s EWG (Eiffel Wrapper Generator). Wrapping and translating each have their advantages and limitations; wrapping may be more appropriate for C libraries that someone else is still actively updating  (so that you do not have to redo a translation with every new release), and translation for legacy code that you want to take over and bring up to par with the rest of your software. C2Eif is engineered to support both. More generally, this is a practitioner’s tool, devoting considerable attention to the many details that make all the difference between a nice idea and a tool that really works. The emphasis is on full automation, although more parametrization has been added in recent months.

C2Eif will make a big mark on the Eiffel developer community. Try it yourself — and don’t be shy about telling its author about the future directions in which you think the tool should evolve.


[1] C2Eif project page, here.

VN:F [1.9.10_1130]
Rating: 10.0/10 (13 votes cast)
VN:F [1.9.10_1130]
Rating: +8 (from 8 votes)

The origin of “software engineering”

RecycledEveryone and her sister continues to repeat the canard that the term “software engineering” was coined on the occasion of the eponymous 1968 NATO conference. A mistake repeated in every software engineering textbook remains a mistake. Below is a note I published twenty years ago on the topic in a newsgroup discussion. I found it in an archive here, where you can read the longer exchange of which it was part.

All textbooks on software engineering that I know, and many articles in the field, claim (that is to say, repeat someone else’s claim) that the term “software engineering” itself was coined on the occasion of the Fall 1968 Garmisch-Partenkirchen conference on S.E., organized by the NATO Science Affairs committee. (See [1] for the proceedings, published several years later.)

The very term, it is said, was a challenge to the software community to get its act together and start rationalizing the software production process.

This common wisdom may need to be revised. The August, 1966 issue of Communications of the ACM (Volume 9, number 8) contains an interesting “letter to the ACM membership” by Anthony A. Oettinger, then ACM President. I must confess I don’t know much about the author; he is identified (in the announcement of his election in the June 1966 issue) as Professor of Applied Mathematics and Linguistics, Harvard University, and from his picture looks like a nice fellow. The sentence of interest appears on page 546 at the end of a long paragraph, which I have reproduced below in its entirety because by looking at the full context it appears clearly that Professor Oettinger did not just use two words together by accident, as it were, but knew exactly what he was talking about. Here is the paragraph (italics in original):

“A concern with the science of computing and information processing, while undeniably of the utmost importance and an historic root of our organization [i.e. the ACM – BM] is, alone, too exclusive. While much of what we do is or has its root in not only computer and information science, but also many older and better defined sciences, even more is not at all scientific but of a professional and engineering nature. We must recognize ourselves – not necessarily all of us and not necessarily any one of us all the time – as members of an engineering profession, be it hardware engineering or software engineering, a profession without artificial and irrelevant boundaries like that between ‘scientific’ and ‘business’ applications.”

(The last point would still be worth making today. The end of the second sentence would seem to indicate that the writer viewed engineering as being remote from science, but this would not be accurate; in the paragraph following the one reproduced above, Prof. Oettinger discussed in more detail his view of the close relation between science and engineering.)

The above quotation is clear evidence that the term “software engineering” was used significantly earlier than commonly thought – more than two years before the Garmisch conference.

What I don’t know is whether Prof. Oettinger created the term, or whether it had been in use before. In the latter case, does anyone know of an older reference? Is Prof. Oettinger still around to enlighten us? (For all I know he could be reading this!)

Switching now our theme from the past to the future: does anyone have an idea of when some actual semantics might become attached to the expression “software engineering”? Is 2025 too optimistic?


[1] J. M. Buxton, P. Naur, B. Randell: Software Engineering Concepts and Techniques (Proceeedings of 1968 NATO Conference on Software Engineering), Van Nostrand Reinhold, 1976.

The last sentence’s sarcasm is, by the way, no longer warranted today.

VN:F [1.9.10_1130]
Rating: 8.2/10 (5 votes cast)
VN:F [1.9.10_1130]
Rating: 0 (from 2 votes)

LASER summer school: Software for the Cloud and Big Data

The 2013 LASER summer school, organized by our chair at ETH, will take place September 8-14, once more in the idyllic setting of the Hotel del Golfo in Procchio, on the island of Elba in Italy. This is already the 10th conference; the roster of speakers so far reads like a who’s who of software engineering.

The theme this year is Software for the Cloud and Big Data and the speakers are Roger Barga from Microsoft, Karin Breitman from EMC,  Sebastian Burckhardt  from Microsoft,  Adrian Cockcroft from Netflix,  Carlo Ghezzi from Politecnico di Milano,  Anthony Joseph from Berkeley,  Pere Mato Vila from CERN and I.

LASER always has a strong practical bent, but this year it is particularly pronounced as you can see from the list of speakers and their affiliations. The topic is particularly timely: exploring the software aspects of game-changing developments currently redefining the IT scene.

The LASER formula is by now well-tuned: lectures over seven days (Sunday to Saturday), about five hours in the morning and three in the early evening, by world-class speakers; free time in the afternoon to enjoy the magnificent surroundings; 5-star accommodation and food in the best hotel of Elba, made affordable as we come towards the end of the season (and are valued long-term customers). The group picture below is from last year’s school.

Participants are from both industry and academia and have ample opportunities for interaction with the speakers, who typically attend each others’ lectures and engage in in-depth discussions. There is also time for some participant presentations; a free afternoon to discover Elba and brush up on your Napoleonic knowledge; and a boat trip on the final day.

Information about the 2013 school can be found here.

LASER 2012, Procchio, Hotel del Golvo

VN:F [1.9.10_1130]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.10_1130]
Rating: 0 (from 0 votes)