Bertrand Meyer's technology+ blog

(Reposted from the CACM blog [*].)

Software engineering was never a popular subject. It started out as “programming methodology”, evoking the image of bearded middle-aged men telling you with a Dutch, Swiss-German or Oxford accent to repent and mend your ways. Consumed (to paraphrase Mark Twain) by the haunting fear that someone, somewhere, might actually enjoy coding.

That was long ago. With a few exceptions including one mentioned below, to the extent that anyone still studies programming methodology, it’s in the agile world, where the decisive argument is often “I always say…”. (Example from a consultant’s page:  “I always tell teams: `I’d like a [user] story to be small, to fit in one iteration but that isn’t always the way.’“) Dijkstra did appeal to gut feeling but he backed it through strong conceptual arguments.

The field of software engineering, of which programming methodology is today just a small part, has enormously expanded in both depth and width. Conferences such as ICSE and ESEC still attract a good crowd, the journals are buzzing, the researchers are as enthusiastic as ever about their work, but… am I the only one to sense frustration? It is not clear that anyone outside of the community is interested. The world seems to view software engineering as something that everyone in IT knows because we all develop software or manage people who develop software. In the 2017 survey of CS faculty hiring in the U.S., software engineering accounted, in top-100 Ph.D.-granting universities, for 3% of hires! (In schools that stop at the master’s level, the figure is 6%; not insignificant, but not impressive either given that these institutions largely train future software engineers.) From an academic career perspective, the place to go is obviously  “Artificial Intelligence, Data Mining, and Machine Learning”, which in those top-100 universities got 23% of hires.

Nothing against our AI colleagues; I always felt “AI winter” was an over-reaction [1], and they are entitled to their spring. Does it mean software engineering now has to go into a winter of its own? That is crazy. Software engineering is more important than ever. The recent Atlantic  “software apocalypse” article (stronger on problems than solutions) is just the latest alarm-sounding survey. Or, for just one recent example, see the satellite loss in Russia [2] (juicy quote, which you can use the next time you teach a class about the challenges of software testing: this revealed a hidden problem in the algorithm, which was not uncovered in decades of successful launches of the Soyuz-Frigate bundle).

Such cases, by the way, illustrate what I would call the software professor’s dilemma, much more interesting in my opinion than the bizarre ethical brain-teasers (you see what I mean, trolley levers and the like) on which people in philosophy departments spend their days: is it ethical for a professor of software engineering, every morning upon waking up, to go to cnn.com in the hope that a major software-induced disaster has occurred,  finally legitimizing the profession? The answer is simple: no, that is not ethical. Still, if you have witnessed the actual state of ordinary software development, it is scary to think about (although not to wish for) all the catastrophes-in-waiting that you suspect are lying out there just waiting for the right circumstances .

So yes, software engineering is more relevant than ever, and so is programming methodology. (Personal disclosure: I think of myself as the very model of a modern methodologist [3], without a beard or a Dutch accent, but trying to carry, on today’s IT scene, the torch of the seminal work of the 1970s and 80s.)

What counts, though, is not what the world needs; it is what the world believes it needs. The world does not seem to think it needs much software engineering. Even when software causes a catastrophe, we see headlines for a day or two, and then nothing. Radio silence. I have argued to the point of nausea, including at least four times in this blog (five now), for a simple rule that would require a public auditing of any such event; to quote myself: airline transportation did not become safer by accident but by accidents. Such admonitions fall on deaf ears. As another sign of waning interest, many people including me learned much of what they understand of software engineering through the ACM Risks Forum, long a unique source of technical information on software troubles. The Forum still thrives, and still occasionally reports about software engineering issues, but most of the traffic is about privacy and security (with a particular fondness for libertarian rants against any reasonable privacy rule that the EU passes). Important topics indeed, but where do we go for in-depth information about what goes wrong with software?

Yet another case in point is the evolution of programming languages. Language creation is abuzz again with all kinds of fancy new entrants. I can think of one example (TypeScript) in which the driving force is a software engineering goal: making Web programs safer, more scalable and more manageable by bringing some discipline into the JavaScript world. But that is the exception. The arguments for many of the new languages tend to be how clever they are and what expressive new constructs they introduce. Great. We need new ideas. They would be even more convincing if they addressed the old, boring problems of software engineering: correctness, robustness, extendibility, reusability.

None of this makes software engineering less important, or diminishes in the least the passion of those of us who have devoted our careers to the field. But it is time to don our coats and hats: winter is upon us.

Notes

[1] AI was my first love, thanks to Jean-Claude Simon at Polytechnique/Paris VI and John McCarthy at Stanford.

[2] Thanks to Nikolay Shilov for alerting me to this information. The text is in Russian but running it through a Web translation engine (maybe this link will work) will give the essentials.

[3] This time borrowing a phrase from James Noble.

[*] I am reposting these CACM blog articles rather than just putting a link, even though as a software engineer I do not like copy-paste. This is my practice so far, and it might change since it raises obvious criticism, but here are the reasons: (A) The audiences for the two blogs are, as experience shows, largely disjoint. (B) I like this site to contain a record of all my blog articles, regardless of what happens to other sites. (C) I can use my preferred style conventions.

On display in the exhibition mentioned in the previous article is a citation, from Urmanche’s writings, of an aphorism by Qol Ghali (who, as I did not know, was a medieval Muslim Volga poet). It reads [1]:

Emerald is a stone
But not every stone is an emerald
And not everyone can distinguish emerald from stone

This sounds like an excellent way to extend my new-year greetings and wishes to the esteemed readers of this blog. May you, throughout 2018, have the wisdom to distinguish emeralds [2] from stones.

Notes

[1] Изумруд — камень. Но не каждый камень изумруд. И не каждый человек может отличить изумруд от камня. (Already a translation, since the original must be in some ancient Turkic language.)

[2] Not that (mentioning this to avoid any confusion) I am specifically wishing you any Ruby.

There is currently in Kazan an exhibition of the works of the Tatar painter Baki Urmanche (1897-1990). One of his early drawings is entitled “The painter, the muse, and death” [1]:

It makes a good point. Not just about painters.

Note

[1] Художник, муза и смерть. The first word means “artist” but also, more specifically, “painter”, which Urmanche was (although he occasionally dabbled in other arts), so either translation is possible.

… at my would-be coauthors, would someone please tell them, and every non-native-English-speaker-but-aspiring-English-author, to read this? Please, please, please, please, please.

In English the verb “allow” cannot take an infinitive as a complement. Ever. You may not write “my method allows to improve productivity” (even if it’s true, which it probably isn’t, but never mind). Ever. You may write the equivalent in French, German, Russian, Italian and whatever, but not in English. Ever. In English you do not “allow to” do something. Ever. You allow someone or something to do something. Maybe, or maybe not, your method allows its users to improve productivity. That’s correct English. It is also OK to use a gerund [1]: your method allows improving productivity. Actually that sounds clumsy but at least it is grammatically correct.

The reason the gerund does not sound quite right here is that  in situations where foreign speakers instinctively think “allow to…” in their mother tongues and transport it directly to English, the native English speaker instinctively comes up with  something  different. Typically, one of:

• Allow someone to, using a specific word instead of “someone”. The English language has a concrete slant and favors expressing all details, including some that in other languages remain implicit.
• Make it possible to:  a bit wordy, but common and convenient, and definitely correct when followed by an infinitive (“my method makes it possible to improve productivity”). We politely leave it unsaid what the “it” is that is being made possible. This turn of phrase is the easiest if you want to remain as close to the original “allow to…” in your native language. Consider “make it possible to” as a mechanical translation of “allow to”. It works.
• Support something. Remember this word. It is used more widely in English than its typical translations in other languages. Often it fits just where you initially would come up with “allow to”. Your method may support policies for improving productivity.
• The gerund. It will sound less clumsy if what you are “allowing” is truly a process, and you are using “allow” in its direct sense of giving permission [2], rather than in the more general and weaker sense of supporting. The rules of tennis allow playing in either singles or doubles.
• Generalizing the gerund, a plain noun (substantive). You can, in fact, allow something. Your methodology allows productivity improvements. Like the gerund, it does not sound as good as the other forms (“support” is better unless there truly is a notion of permission), but it is correct.
• Or… nothing at all. Paraphrased from a text seen recently: “some techniques only allow to model internal properties, others allow to model external properties too”. So much better (in any language): some techniques only model internal properties, others also cover external ones. Whoever wrote the first variant should not, in the next three years, be allowed anywhere near the word “allow”.

Some people go around the issue by using “allow for doing something”. That usage is acceptable in American English (less so in British English), but by default “allow for” means something else: tolerating some possible variation in an estimate, as in “plan two hours for your drive, allowing for traffic”. As a substitute for “allowing to” this phrase has no advantage over the solutions listed above.

On last count, I had corrected “allow to” in drafts from coworkers, using one of these solutions, approximately 5,843,944,027 times (allowing for a few cases that I might have forgotten). Enough! Please, please, please, please, please, please, please. Make a note of this. It will allow me to live better, it will allow you to avoid my wrath, it  will make it possible for us to work together again, it will support a better understanding among the people in the world, it will allow faster refereeing and a better peer review process, it covers all needs, and it still allows for human imperfection.

Notes

[1] Or gerundive, or present participle: a word form resulting from addition of the suffix “-ing” to a verb radical.

[2] Note that beyond “allow” this discussion also applies to the verb “permit”. You permit someone to do something.

[3] Post-publication, Oscar Nierstrasz mentioned on Facebook that he has a Web page addressing the same point.

The full lineup of speakers at the 2018 LASER summer school on Software for Blockchains, Bitcoin and Distributed Trust is now ready, with the announcement of a new speaker, Primavera De Filippi from CNRS and Harvard on social and legal aspects.

The other speakers are Christian Cachin (IBM), Maurice Herlihy (Brown), Christoph Jentzsch (slock.it), me, Emil Gun Sirer (Cornell) and Roger Wattenhofer (ETH).

The school is the 14th in the LASER series and takes place June 2-10, 2018, on the island of Elba in Italy.

Early-fee registration deadline is February 10. The school’s page is here.

(Reproduced from my CACM blog.)

One of the small pleasures of life is to win a technical argument with a graduate student. You feel good, as well you should. It is only human to be want to be right. Besides, if you ended up being wrong all or most of the time, you should start questioning your sanity: why are they the students and you the supervisor, rather than the other way around?

One of the big pleasures of life is to lose an argument with a graduate student. Then you have learned something.

One of the most significant recent developments in software engineering is the concept of Devops*. Dismissing the idea as “just the latest buzzword” would be wrong. It may be a buzzword but it reflects a fundamental change in the way we structure system development; with web applications in particular the traditional distinctions between steps of development, V&V** and deployment fade out. If you are using Microsoft Word, you know or can easily find out the version number; but which version of your search engine are you using?

With the new flexibility indeed come new risks, as when a bug in the latest “devopsed”  version of Google Docs caused me to lose a whole set of complex diagrams irretrievably; an earlier article on this blog (“The Cloud and Its Risks“, October 2010) told the story.

In the new world of continuous integrated development/V&V/deployment, software engineering principles are more necessary than ever, but their application has to undergo a profound adaptation.

With Jean-Michel Bruel (Toulouse), Elisabetta Di Nitto (Milan) and Manuel Mazzara (Innopolis), we are organizing a workshop on the topic, DEVOPS 18, on 5-6 March 2018 near Toulouse. The Call for Papers is available here, with Springer LNCS proceedings. The submission deadline is January 15, but for that date a 2-page extended abstract is sufficient. I hope that the event will help the community get a better grasp of the software engineering techniques and practices applicable to this new world of software development.

Notes

*I know, it’s supposed to be DevOps (I am not a great fan of upper case in the middle of words).
** Validation & Verification.

Many programs take “execution arguments” which the program users provide at the start of execution. In EiffelStudio you can enter them under Execution -> Execution parameters.

The program can access them through the Kernel Library class ARGUMENTS. Typically, the root class of the system inherits from ARGUMENTS and its creation procedure will include something like

if argument_count /= N then
……..print (“XX expects exactly N arguments: AA, BB, …%N”)
else
……..u := argument (1) ; v := argument (2) ; …
……..“Proceed with normal execution, using u, v, …”
end

where N is the number of expected arguments, XX is the name of the program, and AA, …. are the roles of arguments. u, v, … are local variables. The criterion for acceptance could be “at least N” instead of exactly N. The features argument_count and arguments come from class ARGUMENTS.

In all but trivial cases this scheme (which was OK years ago, in a less sophisticated state of the language) does not work! The reason is that the error branch will fail to initialize attributes. Typically, the “Proceed with…” part in the other branch is of the form

               attr1 := u
                attr2 := v
                …
                create obj1.make (attr1, …)
                create obj2.make (attr2, …)
                “Work with obj1, obj2, …”

If you try to compile code of this kind, you will get a compilation error:

Eiffel is void-safe: it guarantees that no execution will ever produce null-pointer dereference (void call). To achieve this guarantee, the compiler must make sure that all attributes are “properly set” to an object reference (non-void) at the end of the creation procedure. But the error branch fails to initialize obj1 etc.

You might think of replacing the explicit test by a precondition to the creation procedure:

               require
                                argument_count = N

but that does not work; the language definition explicit prohibits preconditions in a root creation procedure. The Ecma-ISO standard (the official definition of the language, available here) explains the reason for the corresponding validity rule (VSRP, page 32):

A routine can impose preconditions on its callers if these callers are other routines; but it makes no sense to impose a precondition on the external agent (person, hardware device, other program…) that triggers an entire system execution, since there is no way to ascertain that such an agent, beyond the system’s control, will observe the precondition.

The solution is to separate the processing of arguments from the rest of the program’s work. Add a class CORE which represents the real core of the application and separate it from the root class, say APPLICATION. In APPLICATION, all the creation procedure does is to check the arguments and, if they are fine, pass them on to an instance of the core class:

                note
                                description: “Root class, processes execution arguments and starts execution”
                class APPLICATION create make feature
                                core: CORE
                                                — Application’s core object
                                make
……..……..……..……..……..……..— Check arguments and proceed if they make sense.
                                                do
                                                             if argument_count /= N then
                                                                                print (“XX expects exactly N arguments: AA, BB, …%N”)
                                                                else
                                                                                create core.make (argument (1), argument (2) ; …)
                                                                                                — By construction the arguments are defined!
                                                                                core.live
                                                                                                — Perform actual work
                                                                                               — (`live’ can instead be integrated with `make’ in CORE.)

                                                                end
                                                end
                 end
 
We may call this little design pattern “Split the Root”. Nothing earth-shattering; it is simply a matter of separating concerns (cutting off the Model from the View). It assumes a system that includes text-based output, whereas many applications are graphical. It is still worth documenting, for two reasons.

First, in its own modest way, the pattern is useful for simple programs; beginners, in particular, may not immediately understand why the seemingly natural way of processing and checking arguments gets rejected by the compiler.

The second reason is that Split the Root illustrates the rules that preside over a carefully designed language meant for carefully designed software. At first it may be surprising and even irritating to see code rejected because, in a first attempt, the system’s root procedure has a precondition, and in a second attempt because some attributes are not initialized — in the branch where they do not need to be initialized. But there is a reason for these rules, and once you understand them you end up writing more solid software.

Just about a year ago I posted this announcement about my just released Agile course:

In spite of all the interest in both agile methods and MOOCs (Massive Open Online Courses) there are few courses on agile methods; I know only of some specialized MOOCs focused on a particular language or method.

I produced for EdX, with the help of Marco Piccioni, a new MOOC entitled Agile Software Development. It starts airing today and is supported by exercises and quizzes. The course uses some of the material from my Agile book.

The course is running again! You can find it on EdX here.

Such online courses truly “run”: they are not just canned videos but include exercises and working material on which you can get feedback.

Like the book (“Agile: The Good, the Hype and the Ugly“, Springer), the course is a tutorial on agile methods, presenting an unbiased analysis of their benefits and limits.

As part of the continuation of the ERC Advanced Investigator Grant project “Concurrency Made Easy” (started at ETH Zurich, see the project pages at cme.ethz.ch), I have positions at Politecnico di Milano for:

• Postdocs (having a doctoral degree)
• Research associates (officially: “Assegno di Ricerca”, with the requirement of having a master degree), which can lead to a PhD position.

The deadline for applications is October 11. Please contact me directly if interested. What I expect:

• The requisite degrees as stated above.
• Innovative and enterprising spirit, passion for quality work in software engineering.
• Either or both of excellent programming abilities and strong CS theoretical background.
• Knowledge of as many of possible of: object-oriented programming, concurrency/parallelism, software verification/formal methods, Eiffel.
• Familiarity with the basics of the project as described in the project pages at the URL above.

Much of the progress in robotics is due to software advances, and software issues remain at the heart of the formidable challenges that remain. The 2017 LASER summer school, held in September in Elba, brings together some of the most prestigious international experts in the area.

The LASER school has established itself as one of the principal forums to discussed advanced software issues. The 2017 school takes place from 9 to 17 September in the idyllic setting of the Hotel del Golfo in Procchio, Elba Island, Italy.

Robotics is progressing at an amazing pace, bringing improvements to almost areas of human activity. Today’s robotics systems rely ever more fundamentally on complex software, raising difficult issues. The LASER 2017 summer school covers both the current state of robotics software technology and open problems. The lecturers are top international experts with both theoretical contributions and major practical achievements in developing robotics systems.
The LASER school is intended for professionals from the industry (engineers and managers) as well as university researchers, including PhD students. Participants learn about the most important software technology advances from the pioneers in the field. The school’s focus is applied, although theory is welcome to establish solid foundations. The format of the school favors extensive interaction between participants and speakers.

We have lined up an impressive roster of speakers from the leading edge of both industry and academia:

• Rodolphe Gélin, Aldebaran Robotics
• Ashish Kapoor, Microsoft Research
• Davide Brugali, University of Bergamo, on Managing software variability in robotic control systems
• Nenad Medvidovic, University of Southern California, on Software Architectures of Robotics Systems
• Bertrand Meyer, Politecnico di Milano & Innopolis University, on Concurrent Object-Oriented Robotics Software
• Issa Nesnas, NASA Jet Propulsion Laboratory, on Experiences from robotic software development for research and planetary flight robots
• Hiroshi (“Gitchang”) Okuno, Waseda University & Kyoto University, on Open-Sourced Robot Audition Software HARK: Capabilities and Applications

The school takes place at the magnificent Hotel del Golfo in the Gulf of Procchio, Elba. Along with an intensive scientific program, participants will have time to enjoy the countless natural and cultural riches of this wonderful, history-laden jewel of the Mediterranean.

For more information about the school, the speakers and registration see the LASER site.

Microsoft Office tools offer  features for (1) spelling correction and (2) multi-language support. They are not very good at working together, another example of the perils of feature interaction.

Spelling correction will by default

when misspelled, but in the case of common misspellings known to the tools it will simply correct words without bothering the user. For example if you type “bagage” it will change it silently to “baggage”. This feature can be turned off, and the list of known misspellings can be edited, but most people use the defaults, as I am assuming here.

Multi-language support enables you to “install” several languages. Then when you type a text it will after a few words guess the relevant language. From then on it can  apply the proper spell checks and corrections.

These features are both useful, and by and large they both work. (The second one is not always reliable. I regularly end up, particularly in Microsoft Word, with entire paragraphs underlined in red because for some inscrutable reason the tool assigns them the wrong language. In such cases you must tell it manually what language it should apply.)

Their combination can lead to funny results. Assume your default language is English but you also have French installed, and you are typing an email in French under Outlook. Your email will say “Le bagage est encore dans l’avion”, meaning “The baggage is still in the plane”. The word “baggage” has one more “g” in English than in French. You start typing  “Le bagage”, but because at that point the tool assumes English it corrects it silently:

Next you type “est encore”:

The  word “est” (is) gets flagged because (unlike “encore”, here meaning “still”) it does not exist in English. When you add the next word, “dans” (in), the tool is still assuming an English text, so it flags it too:

Now you type “l” and when you add the apostrophe, you can almost hear a “silly me, I see now, that’s French!”. Outlook  switches languages and unflags the previously flagged words, removing the red squiggle under the ones that are correct in French:

But that is too late for “baggage”: the automatic respelling of “bagage”, coming from the default assumption that the text was in English, no longer makes sense now that we know it is in French. So the word gets flagged as a misspelling. You have to go back and correct it yourself. That is frustrating, since you typed the correct spelling in the first place (“bagage”), and it is the tool that messed it up.

This bug hits me often. It is indeed a bug, which can introduce misspellings into a text when the user typed it correctly. When the tool recognizes that the text is in another language than the one assumed so far, and performs a second pass over the part already analyzed, it should reconsider both the words previously flagged as misspellings but also those previously corrected. There is no justification for doing one and not the other.

Among the world’s most momentous problems, this one does not rank very high. It is only a small annoyance, and only a tiny set of people will ever notice it. But it provides another illustration of how tricky it is to go from good individual features to a good overall design.

Related:

• Ado About the Resource That Was (Not)
• Infinite Loop in Microsoft Word
• The Perils of Feature Interaction

One of the most delicate aspects of design is feature interaction. As users, we suffer daily from systems offering features that individually make sense but clash with each other. In my agile book [1] I explained in detail, building on the work of Pamela Zave, why this very problem makes one of the key ideas of agile methods,  the reliance on “user stories” for requirements, worthless and damaging.

A small recent incident reminded me of the perils of feature interaction. I used my Lenovo W540 laptop without power for a short while, then reached a sedentary location and plugged it in. Hence my surprise when, some hours later, it started beeping to alert me that it was running out of battery. The natural reactions — check the outlet and the power cord — had no effect. I found the solution, but just in time: otherwise, including if I had not heard the warning sound, I would have been unable to use the laptop any further. That’s right: I would not have been able to restart the computer at all, even with access to a power outlet, and even though it was perfectly functional and so was its (depleted) battery. The reason is that the problem arose from a software setting, which (catch-22 situation) I could not correct without starting the computer [2].

The only solution would have been to find another, non-depleted battery. That is not a trivial matter if you have traveled with your laptop outside of a metropolis: the W540 has a special battery which ordinary computer shops do not carry [3].

The analysis of what made such a situation possible must start with the list of relevant hardware and software product features.

Hardware:

• HA. This Lenovo W series includes high-end laptops with high power requirements, which the typical 65-watt airplane power jack does not satisfy.
• HB. With models prior to the W540, if you tried to connect a running laptop to the power supply in an airplane, it would not charge, and the power indicator would start flickering.  But you could still charge it if you switched it off.
• HC. The W540 effectively requires 135 watts and will not take power from a 65-watt power source under any circumstances.

Software:

• SA. The operating system (this discussion assumes Windows) directly reflects HC by physically disabling charging if the laptop is in the “Airplane” power mode.
• SB. If you disable wireless, the operating system automatically goes into the “Airplane” power mode.
• SC. In the “Airplane” power mode, the laptop, whether or not connected through a charger to a power outlet of any wattage, will not charge. The charging function is just disabled.
• SD. One can edit power modes to change parameters, such as time to automatic shutoff, but the no-charging property in Airplane mode is not editable and not even mentioned in the corresponding UI dialog. It seems to be a behind-the-scenes property magically attached to the power-mode name “Airplane”.
• SE. There is a function key for disabling wireless: F8. As a consequence of SB it also has the effect of switching to “Airplane” mode.
• SF. Next to F8 on the keyboard is F7.
• SG. F7 serves to display the screen content on another monitor (Windows calls it a “projector”). F7 offers a cyclic set of choices: laptop only, laptop plus monitor etc.
• SH. In the old days (like five years ago), such function keys setting important operating system parameters on laptops used to be activated only if you held them together with a special key labeled “Fn”. For some reason (maybe the requirement was considered too complicated for ordinary computer users) the default mode on Lenovo laptops does not use the “Fn” key anymore: you just press the desired key, such as F7 or F8.
• SI. You can revert to the old mode, requiring pressing “Fn”, by going into the BIOS and performing some not-absolutely-trivial steps, making this possibility the preserve of techies. (Helpfully, this earlier style is called “Legacy mode”, as a way to remind you that your are an old-timer, probably barely graduated from MS-DOS and still using obsolete conventions. In reality, the legacy mode is the right one to use, whether for techies or novices: it is all too easy to hit a function key by mistake and get totally unexpected results. The novice, not the techie, is the one who will be completely confused and panicked as a result. The first thing I do with a new laptop is to go to the BIOS and set legacy mode.)

By now you have guessed what happened in my case, especially once you know that I had connected the laptop to a large monitor and had some trouble getting that display to work. In the process I hit Fn-F7 (feature SG) several times.  I must have mistakenly (SF) pressed F8 instead of F7 at some point. Normally, Legacy mode (SI) should have made me immune to the effects of hitting a function key by mistake, but I did use the neighboring key F7 for another purpose. Hitting F8 disabled wireless (SE) and switched on Airplane power mode (SB). At that point the laptop, while plugged in correctly, stopped charging (SC, SD).

How did I find out? Since I was looking for a hardware problem I could have missed the real cause entirely and ended up with a seemingly dead laptop. Fortunately I opened the Power Options dialog to see what it said about the battery. I noticed that among the two listed power plans the active one was not “Power Saver”, to which I am used, but “Airplane”. I did not immediately pay  attention to that setting; since I had not used the laptop for a while I just thought that maybe the last time around I had switched on “Airplane”, even though that made little sense since I was not even aware of the existence of that option. After trying everything else, though, I came back to that intriguing setting, changed to the more usual “Power Saver”, and the computer started to charge again. I was lucky to have a few percent of battery still left at that point.

Afterwards I found a relevant discussion thread on a Lenovo user forum.

As is often the case in such feature-interaction mishaps, most of the features make sense individually [4]. What causes trouble is some unforeseen combination of features.

There is no sure way to avoid such trouble, but there is a sure way to cause it: design a system feature by feature, as with user stories in agile development. The system must do this and it must do that. Oh, by the way, it must also do that. And that. User stories have one advantage: everyone understands them. But that is also their limitation. Good requirements and design require professionals who can see the whole beyond the parts.

A pernicious side of this situation is that many people believe that use cases and user stories are part of object-oriented analysis, whereas the OO approach to requirements and design is the reverse: rise above individual examples to uncover the fundamental abstractions.

As to my laptop, it is doing well, thanks. And I will be careful with function keys.

Reference and notes

[1] Bertrand Meyer: Agile! The Good, the Hype and the Ugly, Springer, 2014,  Amazon page: here, book page: here. A description of the book appeared here on this blog at the time of publication.

[2] Caveat: I have not actually witnessed this state in which a plugged-in laptop will not restart. The reason is simply that I do not have an alternate battery at the moment so I cannot perform the experiment with the almost certain result of losing the use of my laptop. I will confirm the behavior as soon as I have access to a spare battery.

[3] It has been my systematic experience over the past decade and a half that Lenovo seems to make a point, every couple of years, to introduce new models with incompatible batteries and docking stations. (They are also ever more incredibly bulky, with the one for the W540 almost as heavy as the laptop itself. On the other hand the laptops are good, otherwise I would not be bothering with them.)

[4] One exception here is feature SB: switching wireless off does not necessaril y mean you want to select a specific power mode! It is a manifestation of the common syndrome  of software tools that think they are smarter than you, and are not. Another exception is SE: to let a simple key press change fundamental system behavior is to court disaster. But I had protected myself by using legacy mode and was hit anyway.

Когда-то очень давно великий советский ученый Андрей Петрович Ершов мне рассказал следующий анекдот. Действие происходит в московском метро. Стоит бабушка, а за ней высокий студент из Университета Имени Патрицы Лумумбы. Он стучит ей по плечу, она поворачивает голову, видит его, вскрикивает (она никогда в жизни не видела Африканца), и падает в обморок.

Другие пассажиры успокаивают ее («ничего страшного, он такой же человек, как и мы!») и она постепенно приходит в себя. Африканский студент объясняет: «Прошу прощения, я только хотел Вас спросить: Вы на следующей выходите?».

Она испуганно смотрит на него и опять падает в обморок, крича: « Ах! Говорит!».

Ершовский анекдот точно описывает ежедневный опыт иностранца в России, который сносно владеет русским языком; но все всегда и везде тотчас же узнают, что он иностранец. Никто и не полагает, что такое существо способно произвести толковые звуки. А если он, вопреки всем ожиданиям, открывает рот и что-нибудь говорит в своей имитации русского языка, выражение на лице собеседника сразу же меняется в испугу : «Ах! Говорит!».

The unspeakable in flight of the uneatable. One of the sad scenes of today’s Europe does not even take place in continental Europe, and does not even look sad. It happens every Friday afternoon at London’s Saint Pancras railway station as young expats from the continent joyfully board the Eurostar train on their way home for the week-end. They are all smiles, but the scene is nonetheless heartbreaking: why did these young and energetic graduates, some of the best the continent’s universities have trained in science, technology, finance and entrepreneurship, feel compelled to cross the Channel to deploy their talents? Sure, it is a great idea to try your luck abroad, but then the flux should be symmetric. Today, it is largely one-way.

That flux will stop. With Brexit, Britain has condemned itself to irrelevance. What a mournful end for one of the greatest civilizations in the history of humankind, which gave us both Newton and Darwin, as well as habeas corpus and the concept of individual liberty [1]! Faced with an obvious choice between grandeur and decline, a majority of Britons voted for decline and there is no going back. The word “Brexit” was coined to mean “British Exit”; there is no mention of Europe in it, an appropriate omission since Britain did not really choose to exit Europe, it chose to exit the modern world. The best that can now happen to it is that Britain keeps its oil and becomes something like Norway. Even that is not certain; the Scots may decide otherwise.

For a while I felt awfully sorry for my British friends and colleagues. They do not deserve this. Of course they did not vote for Brexit — no one with an ounce of reason did — but they have to suffer the consequences. On the other hand things may not be so bad in the long term. Many of them are Europhiles already; they will just move to more auspicious climes. Already the British are pumping up Paris real estate [2].

In the US, the tragic buffoonery goes on. Some days are more buffoon, others more tragic, but the destruction of one of the most successful societies on earth has started, and even though a majority of Americans are horrified with what is happening to their country the movement seems impossible to reverse because of the particular political system to which the US has now arrived. We may call it gerrycracy: democracy bridled by gerrymandering  (plus the Supreme Court). This system, although a recent invention in its current form, is designed to be self-reproducing, a phenomenon compounded by the evolution of the dominant party, which seems to have lost any sense of decency. The country’s greatness will not disappear in one day or one year; all that the world admires in the US, from Stanford and Harvard and MIT to the Metropolitan Museum and the Metropolitan Opera and the New York Review of Books to the Jet Propulsion Laboratory and Silicon Valley and Tesla is still up and churning. But the trajectory is set: downhill.

The programmed self-immolation of these two intellectual and economic powerhouses, depressing as it is, provides an extraordinary opportunity for Europe [3]. Here is a mosaic of democracies sharing an acute determination to do everything in their power to ensure that the horrors of their past will never occur again. People in Europe (not just the French) complain all the time, but they have, overall, the best deal in the entire world. Bewildering cultural riches, a non-extreme climate at least so far, decent economic standards, good-quality and largely free education, well-functioning basic services, a social safety net, tolerance for minorities, recognition of private enterprise, the rule of law… Where else on earth?

Europe has its challenges. Those of us who admire Macron’s bravado in inviting (in English) US scientists and engineers to come to France, and who also know how things work in European universities and business, are a little nervous. Convincing as the appeal is, it requires a serious redesign of the European university system and a concerted attack on the bureaucratic shackles and societal pettiness that stifle European creativity at all levels. It is doable. If someone like Macron could overcome the assault of demagogues and defeatists from the left and the right to get elected, he can start, with his counterparts in other European countries, to address the structural problems that hinder European progress. The context is right: the main countries have adults at the helm (in Germany this will remain true whether we get Merkel or Schulz) and the winds of optimism are blowing again. While Europe faces other major issues, present in the headlines everyday and hard enough on their own, the main challenge is economic: Europe needs to get richer. It is remarkable how much more smoothly a society functions, and how much happier people sound, when there is enough money going around. Just look at Switzerland. Macron and some of his international colleagues are the kind of strong and pragmatic leaders who understand this goal. They will also benefit, if Europe does not falter in its collective negotiating strategy, from a welcome windfall: the many billions that the UK will have to pay to disengage from its obligations. They should invest that money where it can make a difference: not the traditional European pork barrels, but science and technology, where it will catalyze Europe’s growth and wealth.

While the US and the UK are wasting their time, energy and money on non-problems, unimportant problems and self-inflicted problems, on building Maginot walls, on investing in technologies of the past and on closing themselves off from the sources of their own future, Europe should work on what matters. It should, and I think it will, at least as long as the King Ubu in the White House doesn’t get us into WW3 in response to some disagreeable tweet.

In forthcoming articles I will provide more detailed analyses of the various points sketched here. And yes, I know this venue started out as a technology blog and I will continue to talk about void safety, effective concurrent programming and how to verify programs. But the stakes are too high for scientists and engineers to stay neutral. Through what we know, see and understand, it is our duty to help Europe and with it the rest of humankind.

It could just work. I cannot wait for the scene at Paris’s Gare du Nord, a few years from now, on the typical Friday evening: lads and gals from London and Birmingham and Stoke-on-Trent, eager to go home and get their hands on some fish and chips, but ready to return on Sunday night to resume their cheerful part in the new European renaissance.

References

[1] A remarkable  symbol of personal liberty is Blonde’s answer to Osmin, the head of the Janissaries who attempts to subdue her in Mozart’s Abduction from the Seraglio (from 1782, seven years before the French revolution!): Ich bin eine Engländerin, zur Freiheit geboren (I am an Englishwoman, born to freedom). Blonde is not even the opera’s heroine but her servant.

[2] Brexit and the “Macron effect” are attracting the British to Paris (in French), in Le Monde, 31 May 2017, available here.

[3] Britain having officially thumbed its nose at Europe, we should from now on use the term to denote the continental part.

[4] Macron’s speech is available here, particularly from 1:34.

(First published on the CACM blog.)

A book by Laurent Bossavit [1] lists what he calls “leprechauns” of software engineering: pearls of conventional wisdom that do not necessarily survive objective analysis. Whether or not we agree with him on every specific example, his insights are fruitful and the general approach commendable: it is healthy to question revered truths.

A revered truth not cited in his book but worth questioning is “Brooks’ Law” from The Mythical Man-Month [2]. Disclosure: I never cared much for that book, even when I read it at the time of its first publication. I know it is supposed to be a font of wisdom, but with one exception (the “second-system effect”, which actually contradicts some of the book’s other precepts) I find its advice either trivial or wrong. For those readers still with me after this admission of sacrilege, one of the most quoted pronouncements is the modestly titled “Brooks’ Law” according to which adding manpower to a late project makes it later.

Like many unwarranted generalizations, this supposed law can hold in special cases, particular at the extremes: you cannot do with thirty programmers in one day what one programmer would do in a month. That’s why, like many urban legends, it may sound right at first. But an extreme example is not a general argument. Applied in meaningful contexts, the law is only valid as a description of bad project management. If you just add people without adapting the organization accordingly, you will run into disaster. True, but not a momentous discovery.

The meaningful observation is that when a team’s size grows, communication and collaboration issues grow too, and the manager must put in place the appropriate mechanisms for communication and collaboration. Also not a strikingly original idea. Good managers know how to set up these mechanisms. Such an ability is almost the definition of  “good manager”: the good manager is the one to whom Brooks’ Law does not apply. Anyone with experience in the software industry has seen, along with disasters, cases in which a good manager was able to turn around a failing project by, among other techniques, adding people. The tools and methods of modern software engineering and modern project management are of great help in such an effort. Pithy, simplistic, superficial generalizations are not.

I thought of the matter recently when chancing upon Nathan Fielder’s Maid Service video [3]. (Warning: Fielder is sometimes funny — and sometimes not — but always obnoxious.) While programming is not quite the same as house cleaning, there is still a lesson there. With good organization, a competent manager can indeed reduce time, perhaps not linearly but close, by multiplying the number of workers.

One leprechaun dispatched, many to go.

References

[1] Laurent Bossavit:  The Leprechauns of Software Engineering – How folklore turns into fact and what to do about it, e-book available here (for a fee, with a free preview).

[2] Fred Brooks: The Mythical Man-Month – Essays on Software Engineering, Addison-Wesley, 1975, new editions 1982 and 1995.

[3] Nathan for You: Maid Service, video available here.

The LASER summer school, now in its 13th edition, will take place this September (postponed from last year). The theme is new for the school, and timely: software for robotics. Below is the announcement.

The school site is here.

Full announcement:

The 2017 LASER summer school will be devoted to Software for Robotics. It takes place from 9 to 17 September in the exceptional setting of the Hotel del Golfo in Procchio, Elba Island, Italy.

Robotics is progressing at an amazing pace, bringing improvements to almost areas of human activity. Today’s robotics systems rely ever more fundamentally on complex software, raising difficult issues. The LASER 2017 summer school both covers the current state of robotics software technology and open problems. The lecturers are top international experts with both theoretical contributions and major practical achievements in developing robotics systems.
The LASER school is intended for professionals from the industry (engineers and managers) as well as university researchers, including PhD students. Participants learn about the most important software technology advances from the pioneers in the field. The school’s focus is applied, although theory is welcome to establish solid foundations. The format of the school favors extensive interaction between participants and speakers.

We have lined up an impressive roster of speakers from the leading edge of both industry and academia:

• Rodolphe Gélin, Aldebaran Robotics
• Ashish Kapoor, Microsoft Research
• Davide Brugali, University of Bergamo, on Managing software variability in robotic control systems
• Nenad Medvidovic, University of Southern California, on Software Architectures of Robotics Systems
• Bertrand Meyer, Politecnico di Milano & Innopolis University, on Concurrent Object-Oriented Robotics Software
• Issa Nesnas, NASA Jet Propulsion Laboratory, on Experiences from robotic software development for research and planetary flight robots

The school takes place at the magnificent Hotel del Golfo in the Gulf of Procchio, Elba. Along with an intensive scientific program, participants will have time to enjoy the countless natural and cultural riches of this wonderful, history-laden jewel of the Mediterranean.

For more information about the school, the speakers and registration see the LASER site.

The Orbitz page for booking a flight itinerary has an interesting menu option:

Longest duration? If you find that the direct route is too short, you can always add a stop in Vladivostok. Under a few basic assumptions it has to be a theorem that, given any itinerary from A to B, there exists a longer itinerary from A to B.

Experiments with the site suggest, however, that the result of selecting that option is (regrettably from a theoretical perspective, but perhaps preferably for travelers) finite.

Headline of a recent article in the Financial Times, part of a supplement on “Investing in Germany”:

Germany’s coffers are overflowing but optimism is wearing thin

Oh, the humanity!

On reflection, though, better than the other way around.

The character of Ubu, created by Alfred Jarry (1873-1907), deserves to be better known. The Wikipedia entry on Jarry’s 1896 play Ubu Roi (Ubu the King) explains:

According to Jane Taylor, “the central character is notorious for his infantile engagement with his world. Ubu inhabits a domain of greedy self-gratification”. Jarry’s metaphor for the modern man, he is an antihero — fat, ugly, vulgar, gluttonous, grandiose, dishonest, stupid, jejune, voracious, greedy, cruel, cowardly and evil …

“There is”, wrote Taylor, “a particular kind of pleasure for an audience watching these infantile attacks. Part of the satisfaction arises from the fact that in the burlesque mode which Jarry invents, there is no place for consequence. While Ubu may be relentless in his political aspirations, and brutal in his personal relations, he apparently has no measurable effect upon those who inhabit the farcical world which he creates around himself. He thus acts out our most childish rages and desires, in which we seek to gratify ourselves at all cost”.

The derived adjective ubuesque is recurrent in French and francophone political debate.

An English translation of the play can be found here. The original French text (two versions of it) is available here.

The AutoProof technology pursues the goal of “Verification As a Matter Of Course”, integrated into the EVE development environment. (The AutoProof  project page here; see particularly the online interactive tutorial.) A one-day workshop devoted to the existing AutoProof and current development will take place on October 1 near Toulouse in France. It is an informal event (no proceedings planned at this point, although based on the submissions we might decide to produce a volume), on a small scale, designed to bring together people interested in making the idea of practical verification a reality.

The keynote will be given by Rustan Leino from Microsoft Research, the principal author of the Boogie framework on which the current implementation of AutoProof relies.

For submissions (or to attend without submitting) see the workshop page here. You are also welcome to contact me for more information.

In spite of all the interest in both agile methods and MOOCs (Massive Open Online Courses) there are few courses on agile methods; I know only of some specialized MOOCs focused on a particular language or method.

I produced for EdX, with the help of Marco Piccioni, a new MOOC entitled Agile Software Development. It starts airing today and is supported by exercises and quizzes. The course uses some of the material from my Agile book.

Registration is free and open to anyone at this address.

Many robotics applications are by nature concurrent; in his ongoing PhD work, Andrey Rusakov [1] is building a comprehensive concurrent robot programming framework, Roboscoop [2], based on the SCOOP model for simple concurrent object-oriented programming [3] and the Ros operating system. As part of this work it is important to know how much robotics applications use concurrency, stay away from concurrency — perhaps because programmers are afraid of the risks — and could benefit from more concurrency. Rusakov has prepared a questionnaire [4] to help find out. If you have experience in robot programming, please help him by answering the questionnaire, which takes only a few minutes.

References

[1] Rusakov’s home page here.

[2] Roboscoop project page, here,

[3] Simple Concurrent Object-Oriented Programming, see here.

[4] The questionnaire is here.

The 2016 session of the LASER summer school, now in its 13th edition, has just been announced. The theme is new for the school, and timely: software for robotics. Below is the announcement.

School site: here

The 2016 LASER summer school will be devoted to Software for Robotics. It takes place from 10 to 18 September in the magnificent setting of the Hotel del Golfo in Procchio, Elba Island, Italy.

Robotics is progressing at an amazing pace, bringing improvements to almost areas of human activity. Today’s robotics systems rely ever more fundamentally on complex software, raising difficult issues. The LASER 2016 summer school both covers the current state of robotics software technology and open problems. The lecturers are top international experts with both theoretical contributions and major practical achievements in developing robotics systems.
The LASER school is intended for professionals from the industry (engineers and managers) as well as university researchers, including PhD students. Participants learn about the most important software technology advances from the pioneers in the field. The school’s focus is applied, although theory is welcome to establish solid foundations. The format of the school favors extensive interaction between participants and speakers.
The speakers include:

• Joydeep Biswas, University of Massachussetts, on Development, debugging, and maintenance of deployed robots
• Davide Brugali, University of Bergamo, on Managing software variability in robotic control systems
• Nenad Medvidovic, University of Southern California, on Software Architectures of Robotics Systems
• Bertrand Meyer, Politecnico di Milano and Innopolis University, with Jiwon Shin, on Concurrent Object-Oriented Robotics Software: Concepts, Framework and Applications
• Issa Nesnas, NASA Jet Propulsion Laboratory, on Experiences from robotic software development for research and planetary flight robots
• Richard Vaughan, Simon Fraser University

Organized by Politecnico di Milano, the school takes place at the magnificent Hotel del Golfo (http://www.hoteldelgolfo.it/) in Golfo di Procchio, Elba. Along with an intensive scientific program, participants will have time to enjoy the natural and cultural riches of this history-laden jewel of the Mediterranean.

For more information about the school, the speakers and registration see here.

.

— Bertrand Meyer

(A version of this article also appeared on the CACM blog.)

Miracles happen!

Many months ago I accepted, perhaps too fast, a kind invitation to talk at the European Computer Science Summit, the annual conference of Informatics Europe, this week in Vienna. It came with a catch: I was not to choose my own topic but to talk on an imposed theme, ethics in relation to computer science.

As the summer advanced, I became increasingly worried about the talk. What was I going to say? For a nerd, an invited lecture on a free topic is easy: talk about how alias analysis makes automatic frame inference possible, explain the bizarre mixture of the best and worst in agile methods, present a simple method of concurrent programming, describe an environment enabling common mortals to prove programs correct, reflect on our 13-year experience of teaching programming and the supporting MOOCs, and so on. All straightforward stuff which one can present in one’s sleep. But ethics!

The summer receded, but the worry did not. What in the world would I talk about?

And then!

From the deepest of my heart: thank you, Volkswagen.

A third ACM webinar this year (after two on agile methods): I will be providing a general introduction to Design by Contract. The date is this coming Thursday, September 17, and the time is noon New York (18 Paris/Zurich, 17 London, 9 Los Angeles, see here for hours elsewhere). Please tune in! The event is free but requires registration here.

Sometimes it is better not to know French. You will never quite get what Voltaire, Molière, Beauvoir, Zola, Hugo and Proust really mean and what Carmen and Faust really sing. But at least you will not find out what the Marseillaise really says. It is France’s national anthem and, according to a site dedicated to it, marseillaise.org, “believed by many to be the most stirring of all anthems“. Stirring, sure. Until you pay attention to the words.

I wrote an article on this blog, in French, proposing to shed the Marseillaise from its worst parts. A few people asked me to provide an English version; here it is. A rendition rather than a translation.

July the 14th, “Bastille day”, was France’s national holiday, and the opportunity for singing the Marseillaise. Politicians in towns large and small make a point of intoning it, in tune or (more often) out of it. One assumes — rather, one hopes — that occasionally they feel some embarrassment. You see, they understand French. The rest of the world hears the music, apparently good enough to have led such diverse composers as Rossini, Tchaikovsky, Schumann and Beethoven to cite it in their own works, and has the luxury of ignoring the words. Better so. Here are some of the gems (in my almost literal translation, all those I found on the Web are awful):

It’s us versus tyranny
We have raised our blood-stained flag

and

Do you hear, in the countryside,
The howling of these ferocious soldiers?
They come to snatch our sons and wives from our arms
And slit their throats

and the triumphal part of the chorus:

Let’s march, let’s march!
Let an impure blood
Soak the grooves of our fields!

So kind and welcoming.

What makes someone’s blood so impure that every patriot must take as his sacred duty to spill floods of it?

As a matter of fact, it happened, three quarters of a century ago. Hundreds of thousands of French people learned that their blood was now officially non-conformant. There are a few more episodes of that kind in the country’s history. They are not, to put it politely, the most glorious, and not the most appropriate to recall for celebration in the national anthem.

In the days before the festivities, hearing a 7-year old sing (in tune) the impure blood that must soak the grooves, I wondered what kind of thoughts such slogans can evoke among schoolchildren, who are instructed to memorize them and sing along. What about the blood-stained flag? What about the tyrants (Matteo Renzi? Mario Draghi?) who unleash on us their ferocious soldiers, not only to howl, but to snatch, from our arms, our sons and our wives, and slit their throats?

It is time to reform this racist and hateful song.

We need not quarrel about history. The song had a role. The revolution faced enemies, it was defending itself. When we commemorate that revolution today, we think not of Robespierre and the murder of Lavoisier (the creator of modern chemistry, whose executors famously explained that “the republic has no use for scientists“); we think of its message of liberty and fraternity. Enough blood, battles, ferocity. Sing what unites us today.

A national anthem should not, of course, be changed every year as a response to changes in fashion. By nature, it will always be a bit off. But after two hundred and thirteen years of existence, including one hundred and thirty-six of service as national anthem, it is time to shed the Marseillaise of the most shameful remnants of its original text. The music will stay; but the words must adapt to today’s France, which does not whine about a troubled past but looks forward to a bright future.

Only weak peoples seek unity only through the detestation of others. Their songs are full of rejection and negation. Strong peoples, for their part, invoke positive images. Which phrase better projects the proud attitude of a nation that believes in its destiny: “it’s us versus tyranny“, or “with us, marches democracy”? “Their impure blood” or “our pure hearts”? “Slit throats” or “admire”? Be the judge.

There have been proposals for alternative Marseillaises before, but they tend to be mirror images of the original, falling into their own excesses, such as a rabidly anti-militaristic version which can only exacerbate divisions. We will not gain anything by replacing ancient grievances by modern insults.

The following version, illustrated below by the first verse and the chorus (and given in a literal English translation not meant for singing, whereas the French text respects the prosody and versification of the original Marseillaise) pursues a different goal: not antagonizing people, but uniting them; highlighting not differences, but affinities; and allowing everyone to bellow it: with no shame; instead, with pride.

Children of the fatherland, come along
The day of glory has come
With us, marches democracy
We have raised our shining flag.
Do you hear, in the countryside,
The murmur of those envious peoples?
They come to our towns and mountains
And cannot stop admiring them.

(Chorus)

Together, citizens!
Let us make our union stronger!
Let our pure hearts
Vibrate in unison.

[This blog is normally in English, but today’s article is particularly relevant to French speakers. The topic: freeing a national anthem of its hateful overtones.]

Mardi dernier quatorze juillet, une fois de plus, la Marseillaise a retenti un peu partout. C’est le jour où les hommes politiques s’essayent à l’entonner, juste ou (plus souvent) faux. On peut s’imaginer, en fait on espère, qu’ils sont ici et là un peu gênés. “D’un sang impur, abreuve les sillons!“. Vraiment ? Qu’est-ce qui rend un sang si impur que tout bon patriote ait le devoir de le faire jaillir ?

Certes, c’est arrivé, il y a trois quarts de siècle, quand on a soudain avisé des centaines de milliers de Français que leur sang était désormais classé non conforme. Il y a quelques autres épisodes de ce genre dans l’histoire du pays ; ce ne sont pas — pour dire les choses poliment — les plus reluisants, et certainement pas ceux que le chant national devrait glorifier.

À entendre ces jours-ci une petite tête blonde de sept ans chanter (juste) le sang impur qui doit abreuver les sillons, je me suis demandé quelles pensées ces slogans pouvaient bien éveiller pour les enfants des écoles à qui l’on enjoint de les répéter en choeur. Et l’étendard sanglant ? Et les tyrans (Matteo Renzi ? Mario Draghi ?) qui nous envoient leurs féroces soldats non seulement mugir mais, jusque dans nos bras, égorger nos fils, nos compagnes?

Il est temps de réformer ce chant raciste et haineux. Qu’il ait joué son rôle n’est pas la question. La révolution avait ses ennemis, elle se défendait. Quand nous l’invoquons aujourd’hui, cette révolution, ce n’est pas à Robespierre et à l’assassinat de Lavoisier (la république n’a pas besoin de savants) que nous devrions faire appel, mais à son message de liberté et de fraternité. Assez de sang, de batailles, de férocité. Place à ce qui nous définit vraiment aujourd’hui.

Il ne s’agit pas de changer tous les ans d’hymne national en réponse aux modes. Il sera toujours, par nature, un peu déphasé. Mais après deux cent treize ans de Marseillaise, dont cent trente-six ans de service continu comme chant officiel du pays, il est temps de se séparer des relents les plus honteux de son texte d’origine. La musique restera, assez bonne pour avoir été reprise par Schumann, Tchaikowsky, Beethoven, Rossini et bien d’autres ; mais les paroles doivent être adaptées à ce qu’est la France moderne, tournée vers  l’avenir.

Seuls les peuples faibles ne savent s’unir qu’à travers la détestation des autres. Leurs chants sont emplis de rejets et de négations. Les peuples forts s’appuient, eux, sur des images positives. Quelle formule projette le mieux  l’attitude fière d’une nation confiante en son avenir : “contre nous, de la tyrannie“, ou “avec nous, la démocratie” ? “Un sang impur” ou “nos coeurs purs” ?  “Égorger” ou “admirer” ?Jugez-en.

Il existe des Marseillaises alternatives, mais souvent elles ne sont que le miroir de la première, avec leurs propres excès ; voir par exemple cette version sympathique de prime abord mais d’un anti-militarisme qui ne peut que diviser encore. Point n’est besoin de remplacer les anciens cris par des insultes nouvelles.

La version qui suit — chantable, respectant la métrique,  et dont je fournirai les autres couplets si elle provoque autre chose que des invectives — a un tout autre but : non pas diviser, mais réunir ; attiser non pas les différences mais les affinités ; et permettre à chacun de la chanter à pleine voix : sans honte ; au contraire, avec fierté.

Allons enfants de la patrie
Le jour de gloire est arrivé
Avec nous la démocratie
L’étendard vaillant est levé (bis)
Entendez-vous, dans les campagnes,
Frémir tous ces peuples envieux ?
Ils viennent, jusque sous nos cieux,
Admirer nos villes, nos montagnes.

(Refrain)

Ensemble, citoyens !
Renforçons notre union !
Que nos cœurs purs
Vibrent à l’unisson.

Résidence de l’ambassade de France, Berne, le 14 juillet 2015

Most people in technology, trade, research or education work in an international environment and need to use a foreign language which they learned at some earlier stage [1]. It is striking to see how awfully most of us perform. International conferences are a particular pain; many speakers are impossible to understand. You just want to go home and read the paper — or, often, not.

Teachers — English teachers in the case of the most commonly used international language — often get the blame, as in “They teach us Shakespeare’s English instead of what we need for today’s life“, but such complaints are  unfounded: look at any contemporary language textbook and you will see that it is all about some Svetlanas or Ulriches or Natsukos meeting or tweeting their friends Cathy and Bill.

It is true, though, that everyone teaches languages the wrong way.

There is only one way to teach languages right: start with the phonetics. Languages were spoken [2] millennia before they ever got written down. The basis of all natural languages is vocal. If you do not pronounce a language right you do not speak that language. It is unconscionable for example that most of us non-native speakers, when using English, still have an accent. We should have got rid of its last traces by age 12.

I cannot understand why people who are otherwise at the vanguard of intellectual achievement make a mess of their verbal expression, seemingly not even realizing there might be a problem. Some mistakes seem to be handed out from generation to generation. Most French speakers of English, for example, pronounce the “ow” of “allow” as in “low”, not “cow” (it took a long time before a compassionate colleague finally rid me of that particular mistake, and I don’t know how many more I may still be making); Italians seem to have a particular fondness for pronouncing as a “v” the “w” of “write”; an so on.

The only place I ever saw that taught languages right was a Soviet school for interpreters. Graduating students of French, having had no exposure to the language before their studies, spoke it like someone coming out of a Métro station. (Actually they spoke more like a grandmother coming out of the Métro, since they had little access to contemporary materials, but that would have been easy to fix.) The trick: they spent their entire first year doing phonetics, getting the “r”and the “u” and so on right, shedding the intonation of their native tongue. That year was solely devoted to audio practice in a phonetics lab. At the end of it they did not know the meaning of what they were saying,but they said it perfectly. Then came a year of grammar, then a year of conversation. Then came the Métro result. (This is not an apology of the Soviet Union. Someone there just happened to get that particular thing right.)

We should teach everyone this way. There is no reason to tolerate phonetic deviations. If you do not get the sounds exactly as they should be, everything else will be flawed. Take, for example, the “r”. If, like me, you cannot roll your “r”s, then when you try to speak Russian or Italian, even if you think you can get the other sounds right you don’t because  your tongue or palate or teeth are in the wrong place. Another example is the “th” sound in English (two distinct sounds in fact) which I never got right. I can fake it but then something else comes out wrong and I still sound foreign. My high-school teachers — to whom I owe gratitude for so much else — should have tortured me until my “th”s were perfect. True, teaching time is a fixed-pie problem, but I am sure something else could have been sacrificed. Since, for example, I can answer in a blink that seven times nine is sixty-three, I must at some stage have taken the time to memorize it. In retrospect I would gladly sacrifice that element of knowledge, which I can reconstruct when needed, for the ability to roll my “r”s.

Age is indeed critical. While we humans can learn anything at any time, it is a well-known fact (although the reasons behind it remain mysterious) that until puberty we are malleable and can learn languages perfectly.  Witness bilingual and trilingual children; they do not have any accent. But around the time we develop new abilities and desires our brain shuts itself off to that particular skill; from then on we can only learn languages at great pain, with only remote hopes of reaching the proficiency of natives. The time to learn the phonetics of a foreign language, and learn it perfectly, is around the age of nine or ten at the latest. Then, at the age of reason, we should learn the structures — the grammar. Declensions in German, the use of tenses in English, the perfective and imperfective aspects of Russian. Conversation — Svetlana greeting Cathy — can come later if there is time left. Once you have the basics wired into your head, the rest is trivial.

Focusing children on phonetics as the crucial part of learning a language will also help them shine. Like physical appearance, verbal clarity is an enormous advantage. I must not be the only one in conferences who pays far more attention to the content of an article if the speaker has impeccable pronunciation, innate or learned. Syntax and choice of words come next. Of course substance matters; we have all heard top scientists with accents thicker than a Humvee tire and grammar thinner than a summer dress.  Everyone else needs fluency.

Conceivably, someone might object that a year of phonetic drilling is not the most amusing pastime for a 10-year-old. Without even noting that it’s not worse than having to learn to play the violin — where did we ever get the idea that learning should be fun?

As to me, like those who before they die want to get into space, visit the capitals of all countries on earth or reach the top of Mount Everest, I have my dream; it has lesser impact on the environment and depends on me, not on the help of others: just once, I’d like to roll an “r” like a Polish plumber.

Notes

[1] Many native English speakers provide the exception to this observation, since they often do not learn any foreign language beyond “Buon giorno” and “melanzane alla parmigiana”, and hence will probably not see the point of this article.

[2] And motioned. Sign language as practiced by deaf people (informally before it was codified starting from the 17th century on) is also a potential teaching start.

Programming, wrote Dijkstra many years ago, is a branch of applied mathematics. That is only half of the picture: the other half is engineering, and this dual nature of programming is part of its attraction.

Descriptions of the mathematical side are generally, in my view, too complicated. This article [1] presents a mathematical theory of programs and programming based on concepts taught in high school: elementary set theory. The concepts covered include:

• Programming.
• Specification.
• Refinement.
• Non-determinism.
• Feasibility.
• Correctness.
• Programming languages.
• Kinds of programs: imperative, functional, object-oriented.
• Concurrency (small-step and large-step)
• Control structures (compound, if-then-else and Dijkstra-style conditional, loop).
• State, store and environment.
• Invariants.
• Notational conventions for building specifications and programs incrementally.
• Loop invariants and variants.

One of the principal ideas is that a program is simply the description of a mathematical relation. The program text is a rendering of that relation. As a consequence, one may construct programming languages simply as notations to express certain kinds of mathematics. This approach is the reverse of the usual one, where the program text and its programming languages are the starting point and the center of attention: theoreticians develop techniques to relate them to mathematical concepts. It is more effective to start from the mathematics (“unparsing” rather than parsing).

All the results (74 properties expressed formally, a number of others in the text) are derived as theorems from rules of elementary set theory; there are no new axioms whatsoever.

The paper also has a short version [2], omitting proofs and many details.

References

[1] Theory of Programs, available here.
[2] Theory of Programs, short version of [1] (meant for quick understanding of the ideas, not for publication), available here.