- Used Books
- Staff Picks
- Gifts & Gift Cards
- Sell Books
- Stores & Events
- Let's Talk Books
Special Offers see all
More at Powell's
Recently Viewed clear list
Used Trade Paper
Ships in 1 to 3 days
available for shipping or prepaid pickup only
Available for In-store Pickup
in 7 to 12 days
More copies of this ISBN
Software Language Engineering (09 Edition)by Anneke Kleppe
This book started out as a PhD thesis, a work I started rather late in my career. In it you can find a condensed report of the knowledge that I have gained over the years, on the topic of designing languages for the software industry. I hope this book will be helpful for you in learning about languages, what their constituting elements are and how they can be defined. However, before you start reading, I would like to explain why this book is not a thesis.
Not a Thesis
As it turned out, for me it was a wrong move to go from industry to academia. There are certain requirements to a PhD thesis (or maybe it is the way these requirements are upheld?) that prohibited a truthful expression of my ideas and insights in the subject matter. First, the work should be new. Second, the work should be judged by a jury of peers. Third, the work should be based on a sound theory. So, you might ask, what’s wrong with that? These requirements certainly appear to be very good ones. Let me elaborate on these for a bit.
For a scientist to be sure that the work he/she is doing is new, requires a large investment in studying what other people have been doing. With the amount of scientists ever growing, as well as the amount of publications per scientist, this requirement can in practice not be verified, only falsified. The limited life span of the average scientist is simply too short in view of the large body of scientific publications. This is the reason that the work of most scientists resembles the work being done by a worm: dissecting a single square yard (or even worse using metrics: a single square meter) of the garden of knowledge completely and ever so thoroughly. Only on this small area the scientist can be sure he/she knows all related work. Unfortunately, the work I wanted to do is better resembled by the work of a bee: visiting the many wonderful flowers in the garden of knowledge and bringing ideas, concepts, and techniques from the one to the other.
Furthermore, one can question this requirement even more fundamentally: what is newness? How do we decide what is new and what is not? The following quote1 expresses beautifully how deceptive the difference between old and new is.
As an example, when Jos Warmer and I created the Object Constraint Language, did we create something new? In one way we did not, because every element of the language was already there: set theory, object-orientation, the notation used in Smalltalk, pre- and postconditions, you name it. Yet somehow we managed to put all these things together like ingredients in a soup, stir them, and end up with something that most people consider to be a new language.
The second scientific requirement is that the work should be judged by a jury of peers. In practice this means that the life of a scientist is all about judging (doing reviews) and being judged (getting reviewed). I have found that this is not beneficial for qualities like open-mindedness and creativity which every scientist is assumed to possess and cherish. Nor does it encourage cooperation, for who takes the credits? This life full of judgement, combined with the pressure to publish regularly, simply does not provide the right breeding ground for innovative research.
Furthermore, who are these peers that should do the judging? When you are a worm-like scientist, most of the times it is possible to find a few others working on the same square yard of the garden; people that are able to understand the work presented. Still many scientists complain about the quality of the reviewers assigned to judge their work. Even worse is the case for a bee-like scientist. Suppose the bee takes an idea from patch A and applies it to patch B. The people in A will not be interested, whereas the people in B will have trouble understanding this strange idea. In a world full of worms the bee has no peers. Please note that I do not object to having worms in the garden of knowledge. The work of the worms is necessary to keep the soil fertile. I just wish there where more bees, because they are just as necessary; without their work the garden cannot bear fruit.
Let’s proceed to the last requirement, which is that the work should be based on a sound theory. Actually, I have found that this requirement collides with the first. If you want to do innovative research, which I do, it appears that in computer science, the advances in theory no longer precede the advances in practice. Most of the major programming languages (Java, C#), modeling languages (UML), combined with model driven software development, application architectures (SOA), network architectures (.Net, J2EE) of the last two decades were conceived in industry. Academic computer science is in danger of slowly becoming an empirical field which studies the advances being made in industry.
Furthermore, most theory in academic computer science is mathematics based. Because only the very basic elements of mathematics are taught to students, most of whom end up working in industry, the gap between theory and practice is growing larger and larger. That leaves us with innovative research on the one side of the gap, in industry, and sound theory on the other, in academia.
A thing that widens the gap even further, is the existence of a certain disdain for applied research in academia. When faced with making their theories applicable to industry most scientists react as the mathematician in a well-known joke. This mathematician wakes up to see a starting fire in his bedroom. He looks at the fire and thinks: "Well, I have got a bucket in kitchen, water in the bathroom, and I know how to apply these to put out the fire. So, all’s well." And he goes back to sleep. In my opinion, progress in computer science is not only about knowing how to do things, but also about doing them. Specially because doing things always poses new challenges, thus providing you with extra knowledge about how to do (or not to do) these things. On the other hand, a different type of disdain exists in industry. Scientist are regarded as being strange creatures that speak gibberish and are extremely unpractical. Because of this, people from industry are rather reluctant to use new ideas from academia, even when they are good ones.
As is, this book is not a thesis. It presents some things that are new but which are based on existing concepts, and some things which are old but still relevant for software language design. It is not in detail judged by peers, although many parts have been published in reviewed conferences. Finally, I am certain that the theory on which it is based, leaves lots of room for worm-like scientists to work on and improve what is presented here.
What is in this Book
If this book is not a thesis, then what can you expect to find in it? First, there are many areas of expertise that can contribute to your knowledge of software languages. In this book the following areas of expertise will be visited (randomly ordered):
Not all of these areas are as standalone as they appear to be. Studying the wealth of knowledge that these areas comprise, you can find many connections between them and similarities in the concepts used. Examples are grammar versus metamodel, model versus graph, and textual versus visual (graphical) language. Building on these connections and similarities, this book offers you:
What you will not find in this book is a step-by-step plan of how to create a new software language. Instead it shows you what the ingredients of a language specification are and how each of these can be best expressed.
During the years many people have helped me gain the knowledge that I am sharing with you in this book, for which I am very grateful to them. However, there are a number of people that on this occasion deserve special attention. First and foremost, I want to thank Arend Rensink for given me the opportunity to experience life in academia. We cooperated on the work for Chapter 5, and together with Harmen Kastenberg we worked on the topic of operational semantics for software languages, which you can find in Chapter 9. In all this he proved to be much more than a worm-like scientist: open and broad-minded, while remaining critical on details and underlying theory.
I would also like to thank another former colleague from the University of Twente: Theo Ruys. Our discussions on the grammar generator where very helpful. My thanks go to David Akehurst for working with me on the comparison of textual and graphical syntaxes, to Jos Warmer for his cooperation on multi-language support, and to my students for bringing some fun into my research. Certainly the reviewers of early versions of this book deserve to be mentioned: Tony Clark, Ron Kersic, Markus Vöter, Anders Hessellund, Dave Hendricksen, and Barney Boisvert. I am grateful for their remarks, which hopefully made this book a better read for all of you.
Finally I want to thank the Netherlands Organization for Scientific Research (NWO) which funded the GRASLAND project at the University of Twente of which I have been part.
As I wrote in the first paragraph of this preface, I hope this book will be helpful for you in learning about software languages. Like the author of a thesis I too feel that I have gained some good insights in this topic. I have written this book simply to offer my knowledge to you, its reader. Whether or not you agree with what I write, I hope it will improve your knowledge of the subject.
Soest, Netherlands, June 2008
© Copyright Pearson Education. All rights reserved.
What Our Readers Are Saying
Computers and Internet » Computers Reference » General