Bertrand Meyer

See http://bertrandmeyer.com/about

Memories of a dark time

by

 

A few years back my mother started writing her memoirs. She only completed a few chapters, hand-written, and I offered to type them up. There was not enough material to approach a publisher (my fault, for not pushing her to write more); the text has remained unpublished. I am making it available now: see here.

It is in French; if there is enough interest I will translate it. (Although the text is not very long, it is well written so the translation should be done carefully.) For reference I have included below the entry about my mother in one of many books about the period.

Here as a taste of her text is a translation of a short extract from chapter 5 (Grenoble, 1942, where her mission in the resistance network was to find safe havens for Jewish children):

 Along with hosting families there were religious boarding schools, and I should pay homage to a young Mother Superior, whose name I unfortunately forgot, who accepted some of our little girls cordially and without any afterthoughts. From schools for boys, however, how many rejections we had to suffer!

I also have to evoke that other Mother Superior, stern and dry, who after making me languish for several days while asking for the approval of her supervisors finally consented to see four or five little girls. I arrived with five of my charges, whom my neighbor had brought to me after their parents were arrested on that very morning. I can still see the high-ceilinged parlor, the crucifix on the wall, the freshly waxed and shining floor, the carefully polished furniture and a tiny figure with curly brown hair, all trembling: the eldest girl, who at the point of entering stepped back and burst into tears.  “One does not enter crying the house of the Holy Virgin Mary”, pronounced the Mother Superior, who had me take my little flock back to Grenoble, without further concerning herself with its fate.

And this note from the final chapter about the days of the Liberation of France, when under a false name she was working as a nurse for the Red Cross in the Limoges area:

This time it was the collaborationists’ turn to flee. I almost became a victim in a tragicomic incident when once, doing my daily rounds, I had to show my papers to a young FFI [members of the internal resistance army], aged maybe eighteen, who claimed the papers were fakes. Indeed they were: I still had not been able to re-establish my true identity. I tried to explain that as a Jew I had had to live under a borrowed name. He answered that by now all the “collabos” claimed to be Jewish to escape the wrath of the people…

 To understand the note that follows it is necessary to know a bit about the history of the period: the Drancy camp, OSE (see the Wikipedia entry), the Garel network. For the 100-th anniversary of OSE a documentary film was produced, featuring my mother among the interviewees; see a short reference to the movie here.

Biographical entry

From: Organisation juive de combat — Résistance / Sauvetage (Jewish Combat Organization: Resistance and Rescue), France 1940-1945, under the direction of Jean Brauman, Georges Loinger and Frida Wattenberg, Éditions Autrement, Paris, 2002.
Comments in brackets […] are by me (BM).

Name: Meyer née Kahn, Madeleine
Born 22 May 1914 in Paris
Resistance networks: Garel
Resistance period: from 1941 to the Liberation: Rivesaltes (Pyrénées-Orientales), Font-Romeu (Pyrénées-Orientales), Masgelier (Creuse), Lyons, Grenoble, Limoges
Supervisors: Andrée Salomon, Georges Garel

In July of 1942, Madeleine Kahn was sent by Andrée Salomon and Georges Garel to work at Rivesaltes [a horrendous “transit camp”, see here] as a social worker. She worked there for several weeks and helped improve the life of people interned there; she managed to extricate from the camp a number of children that she took to Perpignan and moved to several hosting places such as Font-Romeu and Le Masgelier. In Le Masgelier [a center that hosted Jewish children], she was assigned the mission of convoying to Marseilles, for emigration to the United States, Jewish children who were of foreign origin and hence in a particularly dangerous situation. [These were children from Jewish families that had fled Germany and Austria after Hitler’s accession to power and were particular sought by the Nazis.] The local authorities had put them up in the castle of Montgrand, already used as a hosting camp for elderly Austrian refugees. The Germans’ arrival  into the Southern half of France [until 1942 they were only occupying the Northern half of the country] abruptly stopped the departures for the US, and the authorities changed the children’s status to prisoners, held in appalling conditions. Madeleine Kahn remained alone with the children. All escape attempts failed. They were only freed after a long time, and sent back in some cases to their families and in others to Le Masgelier.

In November of 1942, Georges Garel and Andrée Salomon put Madeleine Kahn in charge of organizing the reception and hiding of children in the Isère area [the region around Grenoble], which by then was still part of the Italian-occupied zone. [Italian occupation was generally felt much lighter than the German one, in particular regarding persecution of Jews.] The mission was to find hosting families or religious institutions, catholic or protestant, and in advance of such placement to prepare the children to their new [false] identities and help separate them from their parents [when still alive and not deported]. It was also necessary to obtain the support of some authorities, such as Mme Merceron-Vicat from the child support administration and Sister Joséphine of Our Lady of Sion. After a while Madeleine was joined by Dr. Selinger and Herta Hauben, both of whom were eventually deported. Later on she collaborated with Fanny Loinger [another key name in the Jewish resistance], who for safety reasons took over in Isère and particularly in the Drôme.

After the departure of the Italians [and their replacement by the Germans], the situation became extremely dangerous and she had constantly to move the children around.

Warned that she was being tracked, Madeleine Kahn hurried to reclaim two babies that had been left in the La Tronche nursery. The director refused to give her Corinne, aged one, as earlier on three Germans had come for her, wanting to take her to Drancy [the collection point in France for the train convoys en route for Auschwitz], where her parents were being held. Upon seeing the child’s age, the Germans had left, announcing they would come back with a nurse. Instantly, Madeleine summons her friends in various [resistance] organizations and the process sets into motion: produce a fake requisition order in German with a fake seal stenciled from a war prisoner’s package; hire a taxi; make up a nurse’s uniform for Renée Schutz, German-born in Berlin as Ruth Schütz. Equipped with the requisition order, the false German nurse arrives at the nursery while Madeleine acts as a sentry to stop the Germans if needed. Corinne, the baby, is saved. [I became friends with her in the nineteen-seventies.]

The duped Germans were enraged. From an employee of the nursery they obtained Madeleine’s address, but she had left. The landlady gave them the address of Simone, Madeleine’s sister. [Simone was not a member of the network but knew all about it.] Interrogated under torture, she gave nothing away. All attempts to free her failed. She was deported to Auschwitz from where [adopting along the way an 8-year-old girl whose parents had already been deported, who clung to her, causing her to be treated like mothers with children, i.e. gassed immediately] she never returned.

Technology plus

by

As the name indicates, this blog is particularly devoted to technology, and even more particularly to software technology. My technical persona is not, however, completely cut off from my personal persona and I increasingly include non-software topics.

Whether there is any readership equally interested in learning about using domain theory for specification and finding out what is the most beautiful monument of Europe remains to be seen, but from now on this will be my “technology+” blog.

Habit, happiness, and programming languages

by

One of the occupational hazards of spreading the word about Eiffel is the frequent answer “yes, it’s much better than the language I use now, I would like to switch, but…“, followed by some sheepish excuse.

Last night I went to see Eugene Onegin once more (I still hope some day to land the part of Monsieur Triquet). Towards the beginning of the first act [1], Tatiana’s mother (Larina), reflecting in a melancholic tone on the vicissitudes of her (long ago) arranged marriage (and (amazingly) anticipating the very fate (as sketched in the last act) of her own daughter (talking about (amazing) anticipation, is there any other similarly hair-raising case of an author (here of the text behind the libretto) so presciently staging the (exact (down to the very last details)) story of his own future tragic death) but enough digressions (sorry (this is supposed (after all) to be (although it is not the first time (and probably not the last either) it strays from the script) a technology blog))), sings

From above, we were given habit:
It is a substitute for happiness

Is this not exactly the excuse?

Reference

[1] Libretto of Onegin, in English here, in the original there.

 

 

Handshake with a clown

by

Cirque Zavattta posterIn the circus business, the Zavatta family is a legend. From father to son and grandson, a Zavatta has for decades been the foremost clown of his generation, first in Italy, then in French North Africa, then in France proper. None was ever more famous than Achille Zavatta, who carried the family name through the sixties and seventies.

Legend or not, everyone has to make ends meet; the Zavatta troupe toured the beach resorts of Brittany in the summer, and was not above resorting to the occasional publicity gimmick to lure vacationers to the evening show.

I think I was 15, so the year must have been 1966. I was, like every year, spending the summer in Trébeurden in Northern Brittany, to which (after reading how it was forever spoiled, a decade or two later, by the unbridled development that has disgraced much of the French coast) I shall never return. Then it was paradise, if a wintry and rainy kind of paradise. We were told that at three in the afternoon a swimming competition would take place and — supreme enticement! — the winner would receive a prize of fifty francs from the very hands of Monsieur Achille Zavatta, the great clown. 50 francs was a not inconsiderable sum for a 15-year-old (with inflation it might be something like fifty dollars or euros today), but the name of the prize-giver was an even stronger attraction. So at the appointed time I was at the harbor, together with a dozen or so other boys, in our swimming suits. I don’t remember any girls; they probably had their own race.

No one has ever called me athletic. I could swim pretty well, and was good at staying in the water for a long time — I am still amazed that my parents once let me do a tour of several kilometers and several hours, far away from the coast, just by myself — but I certainly was not fast. Still, I wanted to try. At school we were always told what Pierre de Coubertin said when he founded the modern Olympic games: l’important, c’est de participer. What counts is to be in the game.

The swimming contest was a simple affair. A man on the pier told us: “See the small boat out there, where a boy is standing? You go swim around it, then you come back”. Trois, deux, un, partez: we jumped in and started moving towards the boat. I was not last, but definitely was not first; three or four boys were ahead of me, and maybe as many behind, a fair reflection of my place in the order of the world. I would never have thought of winning anyway.

Then I saw something interesting. The first swimmer, truly fast and modestly triumphant, held his hand out to the boy in the boat, who obligingly extended his own and helped him jump inside. The second followed, then the third. All were in the boat, looking quite happy with themselves.

SwimmerNow I may not be the fastest swimmer in the former kingdom of Brittany, but when it comes to carrying out a clearly stated specification I do not let myself be influenced by the first guy or two, or three, who just did not pay attention. I knew what we had been told to do, and I was going to do it whatever anyone else was thinking. I went all the way to the boat, ignored the hand stretched out to me as it had been to my predecessors, swam around, and started going back towards the shore.

It did not take long for the others to realize their mistake. They jumped back. By now, however, I was far ahead. For the remainder of the race I quietly enjoyed the position of the one with whom everyone else is trying to catch up, rather than the other way around, to which I was more accustomed. They were still faster, but by then I had secured my advantage: I reached the shore first, gaining my first ever victory in a sports competition. Regrettably my last one too, so far.

In the years since, I have many times been in the company of people faster and — in science — brighter than I; often, as in the harbor of Trébeurden in the summer of 1966, they did not prevail in the end. Knowing your limitations does not mean you should let yourself be intimidated by the smart guys. How often have I seen the students whom everyone thought the most brilliant of all collapse on the day of the exam; the “most promising researcher of his generation” peter out; the author of a breakthrough paper succumb to the comfortable laziness of tenured life! Although outside of fables the race never goes to the turtle, the hare does not always win either; neither does the frog (or froggy, as I have been called a few times to my face and no doubt more behind my back); but the patient donkey, having memorized the instructions and never forgetting the destination, may well finish ahead of them all.

On that summer evening I received the fifty francs from the hands of Monsieur Achille Zavatta. In the following days I made good use of them. From the prize-giving event I remember the handshake, and the envious look of the other boys. I remember, too, my mother’s comment; at least this is the only reaction I remember from her: “Did you make sure to say ‘thank you, sir’?”.

Word of the day

by

Word

Umlottery [ˈʊm.lɑːɾɚɹi] (fr. umloterie, f; ger. Umlotterie, f.; it. umlotteria, f.; rus. умлотерия , f.).

Definition

A spur-of-the-moment and generally random decision, by a hesitant speaker of German talking in front of a (typically large) native-speaker audience, to pronounce the next intended word with, or without, an umlaut on the decisive syllable.

Example use

“My programming teacher seems to play the umlottery a lot recently, and most of the time he loses.“

Discussion

In the German language some vowels change their pronunciation under the effect of the “umlaut”, a diacritical mark appearing as a double period, as in “ä” (pronounced like an “e” in “Ted“) versus a plain “a” (pronounced “Ah“). Many nouns and verbs add umlauts in some but not all of their inflections (declinations or conjugations).  Non-native speakers find it a challenge to remember when to umlaut and when not. The consequences of incorrect umlauting can be dramatic; for example “drucken” means to print and “drücken” to press. Imagine the consequences of a police chief telling a subordinate “Print a new copy of the witness’s statement” and being understood as “Pressure the witness into making a different statement“. The stress is consequently high on the public speaker who suddenly cannot remember, in the crux of a talk, whether the first syllable of his next chosen word should be umlauted  or not.  Umlottery is the widely practiced technique of taking a big breath, silently praying to some higher power for protection, and taking a chance (as if betting at the lottery) one way or the other.

Etymology

Composite word made up from “umlaut” and “lottery”.

Origin

Precise origin unknown. First attested written occurrence in “Bertrand Meyer’s Technology Blog“, an obscure publication of dubious circulation, in October of 2012. Rumored, without independently confirmed evidence, to have been in common use in the early years of the 21st century among foreign-born professors at the ETH Zurich.

Alternative hypotheses

Some researchers have hypothesized that the word is related to the “Unified Modeling Language” (or “UML“, hence the suggestion), under the argument that using UML for a project is akin to betting on its success at the lottery. There is, however, no scholarly consensus in favor of such a connection.

A fundamental duality of software engineering

by

A couple of weeks ago I proposed a small quiz. (I also stated that the answer would come “on Wednesday” — please understand any such promise as “whenever I find the time”. Sorry.) Here is the answer.

The quiz was:

I have a function:

  • For 0 it yields 0.
  • For 1 it yields 1.
  • For 2 it yields 4.
  • For 3 it yields 9.
  • For 4 it yields 16.

What is the value for 5?

Shortly thereafter I added a hint: the value for 5 is 25, and changed the question to: “What is the value for 6?”. For good measure we can also ask about the value for 1000. Now compare your answer to  what follows.

A good answer for the value at 6 is: 34 . The function in this case is -10 + 5 x + |2 x – 3| + |2 x -7|. It matches the values for the given inputs.

Linear, small values

 

 

 

 

 

 

 

 

 

The value for 1000 is 8980:

Linear function, full range

 

 

 

 

 

 

 

 

 

Another good answer at position 6 is 35.6. It comes up if we assume the function is over reals rather than integers; then a possible formula, which correlates very well (R-square of 0.9997) with the values at the given inputs, is:

869.42645566111 (1 – 0.4325853145802 e-.0467615868913719  (x – 17.7342512233011))2.3116827277657443

Exponential function, initial range

 

 

 

 

 

 

 

 

 

 

with a quite different asymptotic behavior, giving the value 869.4 at position 1000:

Exponential, full range

 

 

 

 

 

 

 

 

 

 

Some readers might have thought of another possibility, the square function x2, which again matches all the given values:

Square function, initial range

 

 

 

 

 

 

 

 

 

 

So which of these answers is right? Each is as good as the others, and as bad. There is in particular no reason to believe that the values given in the quiz’s statement suggest the square function. Any function that fits the given values, exactly (if we stick to integers) or approximately (with reals as simulated on a computer) is an equally worthy candidate. Six inputs, or six thousand, do not resolve the question. At best they are hints.

This difference between a hint and a solution is at the core of software engineering. It is, for example, the difference between a test and a specification. A test tells us that the program works for some values; as Dijkstra famously pointed out, and anyone who has developed a serious program has experienced, it does not tell us that it will work for others. The more successful tests, the more hints; but they are still only hints. I have always wondered whether Dijkstra was explicitly thinking of the Popperian notion of falsifiability: no number of experiments will prove a physical theory (although a careful experiment may boost the confidence in the theory, especially if competing theories fail to explain it, as the famous Eddington expedition did for relativity in 1919 [1]); but a single experiment can disprove a theory. Similarly, being told that our function’s value at 6 is 34 disqualifies the square function and the last one (the exponential), but does not guarantee that the first function (the linear combination) is the solution.

The specification-testing duality is the extension to computer science of the basic duality of logic. It starts with the elementary boolean operators: to prove a or b it suffices to establish a or to establish b; and to disprove a and b it suffices to show that a does not hold or to show that b does not hold. The other way round, to disprove a or b we have to show that a does not hold and to show that b does not hold; to prove that a and b holds, we have to show that a holds and to show that b holds.

Predicate calculus generalizes or to ∃, “there exists”, and and to ∀, “for all”. To prove ∃ x | p (x) (there is an x of which p holds) it suffices to find one value a such that p (a); let’s be pretentious and say we have “skolemized” x. To disprove∀ x | p (x) (p holds of all x) it suffices to find one value for which p does not hold.

In software engineering the corresponding duality is between proofs and tests, or (equivalently) specifications and use cases. A specification is like a “for all”: it tells us what must happen for all envisioned inputs. A test is like a “there exists”: it tells us what happens for a particular input and hence, as in predicate calculus, it is interesting as a disproof mechanism:

  • A successful test brings little information (like learning the value for 5 when trying to figure out what a function is, or finding one true value in trying to prove a ∀ or a false value in trying to prove a ∃).
  • An unsuccessful test brings us decisive information (like a false value for a ∀): the program is definitely not correct. It skolemizes incorrectness.

A proof, for its part, brings the discussion to an end when it is successful. In practice, testing may still be useful in this case, but only testing that addresses issues not covered by the proof:

  • Correctness of the compiler and platform, if not themselves proved correct.
  • Correctness the proof tools themselves, since most practical proofs require software support.
  • Aspects not covered by the specification such as, typically, performance and usability.

But for the properties it does cover the proof is final.

It is as foolish, then, to use tests in lieu of specifications as it would be to ignore the limitations of a proof. Agile approaches have caused much confusion here; as often happens in the agile literature [2], the powerful insight is mixed up with harmful advice. The insight, which has significantly improved the practice of software development, is that the regression test suite is a key asset of a project and that tests should be run throughout. The bad advice is to ditch upfront requirements and specifications in favor of tests. The property that tests lack and specifications possess is generality. A test is an instance; a thousand tests can never be more than a thousand instances. As I pointed out in a short note in EiffelWorld (the precursor to this blog) a few years ago [3], the relationship is not symmetric: one can generate tests from a specification, but not the other way around.

The same relationship holds between use cases and requirements. It is stunning to see how many people think that use cases (scenarios) are a form of requirements. As requirements they are as useless as one or ten values are to defining a function. Use cases are a way to complement the requirements by describing the system’s behavior in selected important cases. A kind of reality check, to ensure that whatever abstract aims have been defined for the system it still covers the cases known to be of immediate interest. But to rely on use cases as requirements means that you will get a system that will satisfy the use cases — and possibly little else.

When I use systems designed in recent years, in particular Web-based systems, I often find myself in a stranglehold: I am stuck with the cases that the specifiers thought of. Maybe it’s me, but my needs tend, somehow, to fall outside of these cases. Actually it is not just me. Not long ago, I was sitting close to a small-business owner who was trying to find her way through an insurance site. Clearly the site had a planned execution path for employees, and another for administrators. Problem: she was both an employee and the administrator. I do not know how the session ended, but it was a clear case of misdesign: a system built in terms of standard scenarios. Good specification performs an extra step of abstraction (for example using object-oriented techniques and contracts, but this is for another article). Skipping this step means forsaking the principal responsibility of the requirements phase: to generalize from an analysis of the behavior in known cases to a definition of the desired behaviors in all relevant cases.

Once more, as everywhere else in computer science [4], abstraction is the key to solid results that stand the test of time. Definitely better than judging a book by its cover, inferring a function by its first few values, verifying a program by its tests, or specifying a system by its use cases.

References

[1] See e.g. a blog article: Einstein and Eddington, here.

[2] Bertrand Meyer: Agile! The Good, the Hype and the Ugly, 2013, to appear.

[3] Bertrand Meyer: Test or spec? Test and spec? Test from spec!, EiffelWorld column, 2004 available here.

[4] Jeff Kramer: Is Abstraction the Key to Computer Science?, in Communications of the ACM, vol. 50, no. 4, April 2007, pages 36-42,  available from CiteSeer here

Precedent

by

Alexander Kogtenkov pointed out to me that precursor work to my papers on the Alias Calculus [1] [2] had been published by John Whaley and Martin Rinard [3]. There are some significant differences; in particular my rules are simpler, and their work is not explicitly presented as a calculus. But many of the basic ideas are the same. The reason I did not cite that paper is simply that I was not aware of it; I am happy to correct the omission.

References

[1] Bertrand Meyer: Towards a Theory and Calculus of Aliasing, in Journal of Object Technology, vol. 9, no. 2, March-April 2010, pages 37-74, available here (superseded by [2])
[2] Bertrand Meyer: Steps Towards a Theory and Calculus of Aliasing, in International Journal of Software and Informatics, 2011, available here (revised and improved version of [1].)
[3] John Whaley and Martin Rinard: Compositional Pointer and Escape Analysis for Java Programs, in POPL 1999, available here.

Quiz (1): What is this function?

by

For various reasons there have been no articles in recent weeks; now we are restarting on a regular basis!

A the first topic for this new season, here is a little quiz. I have a function:

  • For 0 it yields 0.
  • For 1 it yields 1.
  • For 2 it yields 4.
  • For 3 it yields 9.
  • For 4 it yields 16.

The question: what is the value for 5?

Answer next Wednesday (at least it will be Wednesday in some time zone).

Salad requirements, requirements salad

by

 

You know what salad is.

Salad is made of green leaves. Actually no, there are lots of other colors, lots of other kinds; and many, such as rice salad, pasta salad, potato salad, include no leaves at all.

In any case, salad is made of vegetables. Actually no: fruit salad.

I meant vegetal, as in non-animal. Actually no: salads often contain cheese, meat, fish, seafood.

In any case, salad is a cold dish. Actually no: did you never try a warm goat cheese salad?

Salad has dressing. Actually no: I know quite a few people who shun dressings.

Salads are consumed at the beginning of a meal. Actually no: in France, the normal place of a salad is after the main course.

At least they are only part of a meal. Actually no: have you not heard of the dinner salad?

Salads have something to do with salt. Actually no: although you are right etymologically, as the word comes through the French salade from the Latin saleta, salty, in our blood-pressure-conscious world the cook often does not put any salt.

Salads are only consumed at lunch. At dinner too. And maybe… I take that back.

I know a salad when I see one. Or maybe when I taste one. Although I have never tried blindfolded.

Then explain to us what it is.

Well, if it says “salad” on the menu it must be a salad.

Can you do better?

I will have to come back to you on that one.

If it is so hard to come up with a convincing definition for such a banal notion (and it is real fun to look at good dictionaries and see the contortions they go through in trying to make some sense of it), no wonder software requirements specifications (SRS) are so hard. One of the obligatory steps in a requirements process —  “agile” or not — is to build up a glossary for the project [1]: a set of definitions for the terms of the trade, those words from the problem domain that the stakeholders throw in assuredly all the time in discussions, with the assumption that everyone else understands, except that when you try to understand too you realize there is no clear definition and even, in some cases, different people understand them in different ways.

If definitions are so hard, are requirements then impossible? The trick is that we often do not need a dictionary-style definition of what things are; we only need to know what they have, in other words what are their properties and operations. This is the abstract data type approach, also known as object technology. But it is still hard to convince the stakeholders to explain what they mean.

The German language has one more use of salads: the affectionate term to describe the jumble of wires that mars the back of your desk (I am guessing) and also the front of mine (in this case I know) is Kabelsalat, cable salad [2]. More than a few SRS are like that too: requirements salads.

References

[1] IEEE: Standard 830-1998, Recommended Practice for Software Requirements Specifications, available (for a fee) here.

[2] German Wikipedia: Kabelsalat entry, available here.