Bonus- Interview - Software Engineering - Bertrand Meyer

I had the great privilege and good fortune of being exposed to Simula 67 which was after 67, I’m not that old. But still Simula kind of was the was still the dominant view of object oriented programming at that time, which very, very few people had encountered. So Simula was the first object oriented language, and well it was quite confidential. So kind of best kept secret for many years, but I got introduced to it, and I immediately knew that it was the right way to program, it was pretty obvious, at least to me. And so for a number of years I worked with Simula both on paper, to help my research work, and to build systems. Bertrand was teaching at UCSB and well, of course, he had already in France started some projects. So his ideas, he came already with some ideas and projects to UCSB. And he continued, and he shared that with his students, and suddenly one night he comes back home and says, well, I have a student from Japan who is excited about my ideas and he wants to talk to his company about it. I said okay, well. It was a new idea. Why not? But I did not really believe in it. But several months later, Bertrand came home and said well the company is interested in my ideas, and they are ready to start to help us start a company. So there it was, and that was the beginning of the second adventure. The first adventure was the move to the U.S. with five children. I found myself in ‘85 in Santa Barbara with a newly created company, building a system which was called ArchiText and which was a very smart editor, on initially with funding from a Japanese company. And well I was looking for a tool to build it, to build that system. And while Simula was kind of fading out at that time I looked at C++ which was there. I opened the book, I closed it pretty quickly afterwards. There was Objective C, there was SmallTalk, these were all interesting developments. But they didn’t really correspond to the kind of strict software engineering standards that my colleagues and I had learned to observe, so we developed our own language which was based on, well the full story would, of course, be longer. But I had written a book which I never finished, but which had a very precise notation for expressing algorithms at the time, so I used that. I used my work on formal specification. I co-wrote the first paper on the Z specification language. So my work on Z and also a successor to Z, which was called M, was also very influential. So, over a half a day, I kind of put all these together and we implemented a pre-processor to, well, we thought of it right from the start as a compiler to generate C. But it was really just for internal purposes. And then what happened is, that we went to OOPSLA. The first OOPSLA in ‘86, where the company had booths, or rather a makeshift booth. We didn’t have that much money. But then we were actually showing the other tool but people wanted to see Eiffel. Well at OOPSLA, Bertrand had some tutorials and that was the first place where Eiffel was really exhibited, and from then on it was clear that the focus of the company was more on that technology, on the tools to help programmers make the most of power of object oriented technology. We realized that contrary to what I had thought, no one else had anything similar because everyone else was going into these kind of AI-oriented developments, experimental programming, no typing, no idea of course of generativity because without typing there is no need for that. Or the kind of C++ direction, which is of course also respectable, but which to us was a diversion, or a transition to help people move to the object oriented world, but didn’t seem like an end in itself. And I’m not saying this to deprecate C++ because obviously it’s been a very successful technology, but to still think that it’s best viewed as as a transition technology. So we realized that there was nothing like it and when we came back from OOPSLA we started kind of refocusing the company. And there’s also something very important which happened at that time. Which is that people who started playing with the language, even with the primitive implementation we had at the time, started telling us. you know, there’s something absolutely new which I’ve never seen before, it’s how easily you can change your mind. And I would say today this is still one of the major assets of Eiffel is the flexibility, to use the technical term, the extendability. So the people don’t necessarily believe us when we say this because it’s like hand waving and to some extent everyone says, oh people talk about flexibility. But this is perhaps one of the major differences between Eiffel and other technologies is how easily you can have a first design, a clean design. I’m not talking about agile style hack it and see if it works. Really, a good design, which however is not perfect, you realize it is not perfect, you change it and you don’t spend your entire life paying for the sins of your youth, so to speak. And it’s not one single aspect, it’s not one single feature of Eiffel, it’s a collection of things. It’s contracts, it’s the modularity mechanism, the information hiding mechanisms. It’s the principle of uniform access. Something that Simula actually had got right, but later languages didn’t. The idea that you don’t distinguish from the outside between accessing a piece of data and calling a function. Which even UML which should be high level, didn’t quite get right, so that’s it’s a whole set of seemingly small properties, that together make a, give a framework in which you can change your designs and integrate new ideas very easily and very quickly without suffering too much. So this is what people started telling us right from the start and which really encouraged us to build the company, the technology around Eiffel. To characterize the typical Eiffel user, well this is someone who typically has a difficult application. So an application often for which he or she has tried something else before. Maybe a couple other technologies that failed. You know hit limits of complexity or limits of reliability and then doesn’t have a choice and he wants it really to succeed. And so it can be in the financial industry where some of our biggest customer applications are, it can be in the aerospace industry, which is also another strong area for us, it can be in healthcare, sometimes also of course in education which is kind of a different kind of application of course. But it’s people who just cannot afford the stuff to fail. So that’s one characteristic, it’s that the reliability and quality requirements are typically very high. often with continuous operation for systems managing to wait for, this kind of thing. A second characteristic is that these applications often need to undergo much change over their lifecycle, which may be years or decades. And here the extendability mechanisms of Eiffel really shine. One of the key distinctive features of Eiffel is that it’s a lifecycle approach. So it’s not just for programming. Not only is it not just a language but also it is not even as a language it’s not just for programming. It’s for analysis, it’s for design, it’s for implementation, it’s for maintenance, it’s for testing, and so on. So it’s really, it’s kind of a holistic, to use a pretentious term, view of software development. So this is kind of really still going against the grain of the software and engineering culture today. Most people think they need some kind of high-level requirements tool, some case tool to do analysis and design, and then Eclipse or something or Visual Studio to do implementation, and then JUnit or something like that to do testing, and what we do is that we integrate everything. Which means that for the developer you don’t have this need to switch between Dr.Jekyll and Mr. Hyde all the time. To switch personalities. To switch gears, context, and so on. You stay in the same conceptual framework. And the basic ideas of Eiffel which are classes, inheritance, single and multiple. Multiple inheritances are important. And of course, as you pointed out, contracts, the use of formal precise specification elements in association with every piece of software, these ideas and a few more apply throughout the lifecycle, throughout the process, from the highest. most abstract levels of thinking about the system, all the way down to the nuts and bolts, the nitty gritty of software construction, debugging, testing, and so on. Although debugging, as you say, we try to have less debugging with Eiffel but well, you wouldn’t believe me if I told you that there are no debugging at all when in fact there is a quite powerful debugger in the environment.