Download Understanding Programming Languages: Lisp, APL, User Types, & Overloaded Operators and more Exams Programming Languages in PDF only on Docsity!
Growing a Language
Guy L. Steele Jr. Sun Microsystems Lab oratories [email protected]
Octob er 22, 1998
Most of the time, I do not read my talks; I plan the main p oints and then sp eak o the top of my head. For this talk, I need to stick to a text, and for go o d cause. Please b ear with me. I think you know what a man is. A woman is more or less like a man, but not of the same sex. (This may seem like a strange thing for me to start with, but so on you will see why.) Next, I shall say that a person is a woman or a man (young or old). To keep things short, when I say \he" I mean \he or she," and when I say \his" I mean \his or her." A machine is a thing that can do a task with no help, or not much help, from a p erson. (As a rule, we can sp eak of two or more of a thing if we add an \s" or \z" sound to the end of a word that names it.)
hnouni ::= hnoun that names one thingi \s" j hnoun that names one thingi \es"
These are names of p ersons: Alan Turing, Alonzo Church, Charles Kay Ogden, Christo- pher Alexander, Eric Raymond, Fred Brooks, John Horton Conway, James Gosling, Bil l Joy, and Dick Gabriel. The word other means \not the same." The phrase other than means \not the same as." A number may b e nought, or may b e one more than a numb er. In this way we have a set of numb ers with no b ound.
hnumb eri ::= 0 j 1 + hnumb eri
There are other numb ers as well, but I shall not sp eak more of them yet. These numb ers|nought or one more than a numb er|can b e used to count things. We can add two numb ers if we count up from the rst numb er while we count down from the numb er that is not the rst till it come to nought; then the rst count is the sum.
4 + 2 = 5 + 1 = 6 + 0 = 6
We shall take the word many to mean \more than two in numb er." Think of a machine that can keep track of two numb ers, and count each one up or down, and test if a numb er b e nought and by such a test cho ose to do this or that. The
list of things that it can do and of choices that it can make must b e of a known size that is some numb er.
A
0
B
47
Q 0 up A Q 1 Q 1 down B Q 0 Q 2 Q 2 up A Q 3 Q 3 up B Q 4 Q 4 down A Q 4 Q 4
STATE
Q
QQ
J
JJ
Here you can see the two numb ers and a list. Each row in the list has a state name; the word \up" or \down"; and which numb er to count up or count down. For \up," we have the name of the next state to go to (and the machine counts the numb er up by one); for \down," the machine rst tests the numb er, and so we have the name of the new state to go to if the numb er b e nought and the name of the new state to go to if the numb er b e other than nought (in which case the machine counts the numb er down by one). A computer is a machine that can do at least what that machine can|and we have go o d cause to think that if a computer task can b e done at all, then the two-numb er machine can do it, to o, if you put numb ers in and read them out in the right way. In some sense, all computers are the same; we know this thanks to the work of such p ersons as Alan Turing and Alonzo Church. A vocabulary is a set of words. A language is a vo cabulary and rules for what a string of words might mean to a p erson or a machine that hears them. (To de ne a word is to tell what it means. When you de ne a word, you add it to your vo cabulary and to the vo cabulary of each p erson who hears you. Then you can use the word.) To program is to make up a list of things to do and choices to make, to b e done by a computer. Such a list is called a program. (A noun can b e made from a verb to mean that which is done as meant by that verb; to make such a noun, we add \ing" to the verb stem. Thus we can sp eak of \programming.")
hnouni ::= hverb stemi \ing"
and in each new program we must de ne it once more. A go o d example of this is max, which yields the more large of two numb ers. It is a primitive thought to me, but few programming languages have it as a primitive; I have to de ne it. This is the sort of thing that makes a computer lo ok like a p erson who is but four years old. Next to English, all computer programming languages are small; as we write co de, we must stop now and then to de ne some new term that we will need to use in more than one place. Some p ersons nd that their programs have a few large chunks of co de that do the \real work" plus a large pile of small bits of co de that de ne new words, so to sp eak, to b e used as if they were primitives. I hop e that this talk brings home to you|in a way you can feel in your heart, not just think in your head|what it is like to have to program in that way. This should show you, true to life, what it is like to use a small language. Each time I have tried this sort of thing, I have found that I can not say much at all till I take the time to de ne at least a few new terms. In other words, if you want to get far at all with a small language, you must rst add to the small language to make a language that is more large. (In some cases we will nd it more smo oth to add the syllable \er" to the end of a word than to use the word \more" in front of it; in this way we might say \smo other" in place of \more smo oth." Let me add that better means \more go o d.")
hword that can change what a noun meansi ::= hword that can change what a noun meansi \er" In truth, the words of one syllable form quite a rich vo cabulary, with which you can say many things. You may note that this vo cabulary is much larger than that of the language called Basic English, de ned by Charles Kay Ogden in the year one-nine-three-nought. I chose not to use Basic English for this talk, the cause b eing that Basic English has many words of two or more syllables, some of them quite long, handed down to us from the dim past of Rome. While Basic English has fewer words, it do es not give the feel, to one who sp eaks full English, of b eing a small language. (By the way, from now on I shall use the word because to mean \the cause b eing that.") If we lo ok at English and then at programming languages, we see that all our program- ming languages seem small. And yet we can say, to o, in some cases, that one programming language is smaller than some other programming language. A design is a plan for how to build a thing. To design is to build a thing in one's mind but not yet in the real world|or, b etter yet, to plan how the real thing can b e built. The main thing that I want to ask in this talk is: If I want to help other p ersons to write all sorts of programs, should I design a small programming language or a large one? I stand on this claim: I should not design a small language, and I should not design a large one. I need to design a language that can grow. I need to plan ways in which it might grow|but I need, to o, to leave some choices so that other p ersons can make those choices at a later time. This is not a new thought. We have known for some time that huge programs can not b e co ded from scratch all at once. There has to b e a plan for growth. What we must stop to think on now is the fact that languages have now reached that large size where they can not b e designed all at once, much less built all at once. (Let me pause to de ne some names for numb ers. Twenty is twice ten. Thirty is thrice ten. Forty is twice twenty. A hundred is ten times ten. A mil lion is a hundred times a hundred times a hundred. Sixteen is twice eight. Seven is one plus six. Fifty is one more than seven squared. One more thing: ago means \in the past, counting back from now.")
In the past, it made sense to design a whole language, once for all. Fortran was a small language forty years ago, designed for tasks with numb ers, and it served well. PL/I was thought a big language thirty years ago, but now we would think of it as small. Pascal was designed as a small, whole language with no plan to add to it at a later time. That was ve-and-twenty years ago. What came to pass? Fortran has grown and grown. Many new words and new rules have b een added. The new design is not bad; the parts t well, one with the other. But to many programmers who have used Fortran for a long time, the Fortran of here and now is not at all the same as the language they rst came to know and love. It lo oks strange. PL/I has not grown much. It is, for the most part, just as it was when it rst came out. It may b e that this is just from lack of use. The ip side is that the lack of use may have two causes. Numb er one: PL/I was not designed to grow|it was designed to b e all things to all who program right from the start. Numb er two: for its time, it started out large. No one knew all of PL/I; some said that no one could know all of PL/I. Pascal grew just a tad and was used to build many large programs. One main fault of the rst design was that strings were hard to use b ecause they were all of xed size. Pascal would have b een of no use for the building of large programs for use in the real world if this had not b een changed. But Wirth had not planned for the language to change in such ways, and in fact few changes were made. At times we think of C as a small language designed from whole cloth. But it grew out of a smaller language called B, and has since grown to b e a larger language called C plus plus. A language as large as C plus plus could not have spread so wide if it had b een foisted on the world all at once. It would have b een to o hard to p ort. (One more rule for making words: if we add the syllable \er" to a verb stem, we make a noun that names the p erson or thing that do es what the verb says to do. For example, a buyer is one who buys. A user is one who do es use.)
hnouni ::= hverb stemi \er"
As you may by now have guessed, I am of like mind with my go o d friend Dick Gabriel, who wrote the well known screed \Worse Is Better."
http://www.ai.mit.edu/docs/articles/good-news/good-news.html http://www.naggum.no/worse-is-better.html
(The real name was \Lisp: Go o d News, Bad News, How to Win Big," which is all words of just one syllable|which might seem like go o d luck for me, but the truth is that Dick Gabriel knew how to cho ose words with punch. Yet what rst comes to mind for most p ersons is the part headed \Worse Is Better" and so that is how they cite it.) The gist of it is that the b est way to get a language used by many p ersons is not to design and build \The Right Thing," b ecause that will take to o long. In a race, a small language with warts will b eat a well designed language b ecause users will not wait for the right thing; they will use the language that is quick and cheap, and put up with the warts. Once a small language lls a niche, it is hard to take its place. Well, then, could not \The Right Thing" b e a small language, not hard to p ort but with no warts? I guess it could b e done, but I, for one, am not that smart (or have not had that much luck). But in fact I think it can not b e done. Five-and-twenty years ago, when users did
I now think that I, as a language designer helping out with the Java programming language, need to ask not \Should the Java programming language grow?" but \How should the Java programming language grow?" There is more than one kind of growth and more than one way to do it. But, as we shall see, if the goal is to b e quick and yet to do go o d work, one mo de may b e b etter by far than all other mo des. There are two kinds of growth in a language. One can change the vo cabulary, or one can change the rules that say what a string of words means. A library is a vo cabulary designed to b e added to a programming language to make the vo cabulary of the programming language larger. Libraries means more than one library. A true library do es not change the rules of meaning for the language; it just adds new words. (You can see from this that, in my view, the co de that lets you do a \long jump" in C is not a true library.) Of course, there must b e a way for a user to make libraries. But the key p oint is that the new words de ned by a library should lo ok just like primitives of the language. Some languages are like this and some are not. Those that are not are harder to grow with the help of users. It may b e go o d as well to have a way to add to the rules of meaning for a language. Some ways to do this work b etter than other ways. But the language should let work done by a user lo ok just like what was designed at the start. I would like to grow the Java programming language in such a way that users can do more of this. In the same way, there are two ways to do the growing. One way is for one p erson (or a small group) to b e in charge and to take in, test, judge, and add the work done by other p ersons. The other way is to just put all the source co de out there, once things start to work, and let each p erson do as he wills. To have a p erson in charge can slow things down, but to have no one in charge makes it harder to add up the work of many p ersons. The way that is faster and b etter than all other ways do es b oth. Put the source co de out there and let all p ersons play with it. Have a p erson in charge who is a quick judge of go o d work and who will take it in and shove it back out fast. You don't have to use what he ships, and you don't have to give back your work, but he gives all p ersons a fast way to spread new co de to those who want it. The b est example of this way to do things is Linux, which is an operating system, which is a program that keeps track of other programs in a computer and gives each its due in space and time. You ought to read what Eric Raymond had to say of how Linux came to b e. I shall tell you a bit of it once I de ne two more words for you. A cathedral is a huge church. It may b e made of stone; it may ll you with awe; but the key thought, in the mind of Eric Raymond, is that there is but one design, one grand plan, which may take a long time|many years|to make real. As the years pass, few changes are made to the plan. Many, many p ersons are needed to build it, but there is just one designer. A bazaar is a place with many small shops or stalls, where you can buy things from many p ersons who are there to sell their wares. The key thought here is that each one sells what he wants to sell and each one buys what he wants to buy. There is no one plan. Each seller or buyer may change his mind at whim. Eric Raymond wrote a short work called \The Cathedral and the Bazaar" in which he lo oks at how programs are built or have b een built in the past. (You can nd it on his web site.)
http://www.tuxedo.org/~esr/writings/cathedral-bazaar
He talks of how he built a mail fetching program with the help of more than two hundred users. He quotes Fred Bro oks as saying, \More users nd more bugs," and backs him up with tales from this example of building a program in the bazaar style. As for the role of the programmer-in-charge, Eric Raymond says that it is ne to come up with go o d thoughts, but much b etter to know them when you see them in the work of other p ersons. You can get a lot more done that way. Linux rose to its heights of fame and wide use in much the same way, though on a much larger scale. (To take this thought to the far end of the line: it may b e that one could write an op erating system by putting a million ap es to work at a million typing-machines, then just sp otting the bits of go o d work that come out by chance and pasting them up to make a whole. But that might take a long time, I guess. To o bad!) But the key p oint of the bazaar is not that you can get many p ersons to work with you at a task, for cathedral-builders had a great deal of help, to o. Nor is the key p oint that you get help with the designing as well as with the building, though that in fact is a big win. No, the key p oint is that in the bazaar style of building a program or designing a language or what you will, the plan can change in real time to meet the needs of those who work on it and use it. This tends to make users stay with it as time go es by; they will take joy in working hard and helping out if they know that their wants and needs have some weight and their hard work can change the plan for the b etter. Which brings me to the high p oint of my talk. It seems, in the last few years, at least, that if one is asked to sp eak at this meeting, one must quote Christopher Alexander. I know a bit of his work, though not a lot, and I must say thanks to Dick Gabriel for p ointing out to me a quote that has a lot to do with the main p oint of this talk. I am sad to say that I do not know what this quote means, b ecause Christopher Alexander tends to use many words of more than one syllable and he do es not de ne them rst. But I have learned to say these words by rote and it may b e that you out there can glean some thoughts of use to you. Christopher Alexander says:
Master plans have two additional unhealthy characteristics. To b egin with, the existence of a master plan alienates the users : : : After all, the very exis- tence of a master plan means, by de nition, that the memb ers of the commu- nity can have little impact on the future shap e of their community, b ecause most of the imp ortant decisions have already b een made. In a sense, under a master plan p eople are living with a frozen future, able to a ect only relatively trivial details. When p eople lose the sense of resp onsibility for the environment they live in, and realize that they are merely cogs in someone else's machine, how can they feel any sense of identi cation with the community, or any sense of purp ose there? (from The Oregon Experiment)
I think this means, in part, that it is go o d to give your users a chance to buy in and to pitch in. It is go o d for them and it is go o d for you. (In p oint of fact, a numb er of cathedrals were built in the bazaar mo de.) Do es this mean, then, that it is of no use to design? Not at all. But in stead of designing a thing, you need to design a way of doing. And this way of doing must make some choices now but leave other choices to a later time.
may b e overloaded. I would like to change that. I have said in the past, and will say now, that I think it would b e a go o d thing for the Java programming language to add generic typ es and to let the user de ne overloaded op erators. Just as a user can co de metho ds that can b e used in just the same way as metho ds that are built in, the user ought to have a way to de ne op erators for user- de ned classes that can b e used in just the same way as op erators that are built in. What is more, I would add a kind of class that is of light weight, one whose ob jects can b e cloned at will with no harm and so could b e kept on a stack for sp eed and not just in the heap. Classes of this kind would b e well-suited for use as user-de ned numb er typ es but would have other uses, to o. You can nd a plan for all this on a web page by James Gosling.
http://www.javasoft.com/people/jag/FP.html
(There are a few other things we could add as well, such as tail calls and ways to read and write those machine ags for numb ers whose p oints oat. But these are small language tweaks next to generic typ es and overloaded op erators.) If we grow the language in these few ways, then we will not need to grow it in a hundred other ways; the users can take on the rest of the task. To see why, think on these examples. A complex number is a pair of numb ers. There are rules for how to nd the sum of two complex numb ers, or a complex numb er times a complex numb er:
(a; b) + (c; d) = (a + c; b + d)
(a; b) (c; d) = (a c b d; a d + b c)
Some programmers like to use them a lot; other programmers do not use them at all. So should we make \complex numb er" a typ e in the Java programming language? Some say yes, of course; other p ersons say no. A rational number is a pair of numb ers. There are rules (not the same as the rules for complex numb ers, of course) for how to nd the sum of two rational numb ers, or a rational numb er times a rational numb er:
(a; b) + (c; d) = (a d + b c; b d)
(a; b) (c; d) = (a c; b d)
A few programmers like to use them a lot; most do not use them at all. So should we make \rational numb er" a typ e in the Java programming language? An interval is a pair of numb ers. There are rules (not the same as the rules for complex numb ers or rational numb ers, of course) for how to nd the sum of two intervals, or an interval times an interval:
(a; b) + (c; d) = (a + c; b + d)
(a; b) (c; d) = (min(a c; a d; b c; b d); max(a c; a d; b c; b d))
A few programmers like to use them a lot and wish all the other programmers who use numb ers would use them, to o; but most do not use them at all. So should we make \interval" a typ e in the Java programming language?
John Horton Conway once de ned a game to b e a pair of sets of games (see his b o ok On Numbers and Games), then p ointed out that some games may b e thought of as numb ers that say how many moves it will take to win the game. There are rules for how to nd the sum of two games, and so on:
( A ; B ) + ( C ; D) =
f a + ( C ; D) j a 2 A g [ f ( A ; B ) + c j c 2 C g; f b + ( C ; D) j b 2 B g [ f ( A ; B ) + d j d 2 D g
( A ; B ) =
f b j b 2 B g; f a j a 2 A g
A B = A + ( B )
( A ; B ) ( C ; D ) =
f a ( C ; D) + ( A ; B ) c a c j a 2 A ; c 2 C g [ f b ( C ; D) + ( A ; B ) d b d j b 2 B ; d 2 D g; f a ( C ; D) + ( A ; B ) d a d j a 2 A ; d 2 D g [ f b ( C ; D) + ( A ; B ) c b c j b 2 B ; c 2 C g
From this he worked out for hundreds of kinds of real games how to know which player will win. I think, oh, three p ersons in the world want to use this kind of numb er. Should we make it a typ e in the Java programming language? A vector is a row of numb ers all of the same typ e, with each place in the row named by the kind of numb er we rst sp oke of in this talk. There are rules : : : In fact, for vectors of length three there are two ways to do \a vector times a vector," so you can have twice the fun!
(a; b; c) + (d; e; f ) = (a + d; b + e; c + f )
(a; b; c) (d; e; f ) = a d + b e + c f
(a; b; c) (d; e; f ) = (b f c e; c d a f ; a e b d)
Vectors of length three or four are a great aid in making bits on the screen lo ok like scenes in the real world. So should we make \vector" a typ e in the Java programming language? A matrix is a set of numb ers laid out in a square. And there are rules (not shown here!). So should we make \matrix" a typ e in the Java programming language? And so on, and so on, and so on. I might say \yes" to each one of these, but it is clear that I must say \no" to al l of them! And so would James Gosling and Bill Joy. To add all these typ es to the Java programming language would b e just to o much. Some parts of the programming vo cabulary are t for all programmers to use, but other parts are just for their own niches. It would not b e fair to weigh down all programmers with the need to have or to learn all the words for all niche uses. We should not make the Java programming language a cathedral, but a plain bazaar might b e to o lo ose. What we need is more like a shopping mall, where there are not quite as many choices but most of the go o ds are well designed and sellers stand up and back what they sell. (I could sp eak at length on the ways in which a shopping mall is like a cathedral|but not here, not now!)
twenty years ago. Back then, you could set out to design a whole language and then build it by your own self, or with a small team, b ecause it was small and b ecause what you would then do with it was small. Now programs are big messes with many needs. A small language won't do the job. If you design a big language all at once and then try to build it all at once, you will fail. You will end up late and some other language that is small will take your place. It would b e great if there were some small programming language that felt large, the way Basic English is small but feels large in some ways. But I don't know how to do it and I have go o d cause to doubt that it can b e done at all. In its day, APL was a small language that felt large; but our needs have grown and APL did not have a go o d pattern for growth. So I think the sole way to win is to plan for growth with help from users. This is a win for you b ecause you have help. This is a win for the users b ecause they get to have their say and get to b end the growth to their needs. But you need to have one or more p ersons, to o, or one or more groups, to take on the task of judging and testing and sifting what the users do and say, and adding what they think b est to the big pile of co de, in the hop e that other users will trust what they say and not have to go to all the work to test and judge and sift each new claim or each new piece of co de, each for his own self. Parts of the language must b e designed to help the task of growth. A go o d set of typ es, ways for a user to de ne new typ es, to add new words and new rules to the language, to de ne and use all sorts of patterns|all these are needed. The designer should not, for example, de ne twenty kinds of numb er typ es in the language. But there will b e users who, all told, b eg for twenty kinds of numb ers. The language should have a way for the user to de ne numb er typ es that work well with each other, and with plus signs and other such signs, and with the many ways of pushing bits in and out of the computer. One might de ne just one or two numb er typ es at the start, to show how it ought to b e done. Then leave the rest to the users. Help them all as b est you can to work side by side (and not nose to nose). You may nd that you need to add warts as part of the design, so that you can get it out the do or fast, with the goal of taking out the warts at a later time. Now, there are warts and then there are warts! With care, one can design a wart so that it will not b e to o hard to take out or patch up later on. But if you do not take care at the start, you may b e stuck for years to come with a wart you did not plan. Some warts are not bad things you put in, but go o d things you leave out. Have a plan to add those go o d things at a later time, if you should cho ose to do so, and make sure that other parts of your design don't cut you o from adding those go o d things when the time is right. I hop e to bring these thoughts to b ear on the Java programming language. The Java programming language has done as well as it has up to now b ecause it started small. It was not hard to learn and it was not hard to p ort. It has grown quite a bit since then. If the design of the Java programming language as it is now had b een put forth three years ago, it would have failed|of that I am sure. Programmers would have cried, \To o big! To o much hair! I can't deal with all that!" But in real life it has worked out ne b ecause the users have grown with the language and learned it piece by piece, and they buy in to it b ecause they have had some say in how to change the language. And the Java programming language needs to grow yet some more|but, I hop e, not a lot more. At least, I think only a few more rules are needed|the rest can b e done with libraries, most of them built by users and not by Sun.
If we add hundreds of new things to the Java programming language, we will have a huge language, but it will take a long time to get there. But if we add just a few things|generic typ es, op erator overloading, and user-de ned typ es of light weight, for use as numb ers and small vectors and such|that are designed to let users make and add things for their own use, I think we can go a long way, and much faster. We need to put to ols for language growth in the hands of the users. I hop e that we can, in this way or some other way, design a programming language where we don't seem to sp end most of our time talking and writing in words of just one syllable. One of the go o d things I can say for short words is that they make for short talks. They gave me an hour and a half for this talk and I have used less than an hour. Once I am done, you will have time to go out in the hall, have a cup of tea, and talk with your friends. But rst, I would like to tell you what I have learned from the task of designing this talk. In cho osing to give up the many long words that I have come to know since I was a child, words that have many ne shades of meaning, I made this task much harder than it needed to b e. I hop e that you have not found it to o hard on your ears. But I found that sticking to this rule made me think. I had to take time to think through how to phrase each thought. And there was this choice for each new word: is it worth the work to de ne it, or should I just stick with the words I have? Should I do the work of de ning a new word such as \mirror," or should I just say \lo oking glass" each time I want to sp eak of one? (As an example, I was tempted more than once to state the \ly" rule for making new words that change what verbs mean, but in the end I chose to cast all such words to one side and make do. And I came that close to de ning the word \without," but each time, for b etter or for worse, I found some other way to phrase my thought.) I learned in my youth, from the b o oks of such great teachers of writing as Strunk and White, that it is b etter to cho ose short words when I can. I should not cho ose long, hard words just to make other p ersons think that I know a lot. I should try to make my thoughts clear; if they are clear and right, then other p ersons can judge my work as it ought to b e judged. From the work of planning this talk, in which I have tried to go with this rule much more far than in the past, I found that for the most part they were right. Short words work well, if I cho ose them well. Thus I think that programming languages need to b e more like the languages we sp eak|but it might b e go o d, to o, if we were to use the languages we sp eak more in the way that we now use programming languages. All in all, I think it might b e a go o d thing if those who rule our lives|those in high places who do the work of state, those who judge what we do, and most of all those who make the laws|were made to de ne their terms and to say all else that they say in words of one syllable. For I have found that this mo de of sp eech makes it hard to hedge. It takes work, and great care, and some skill, to nd just the right way to say what you want to say, but in the end you seem to have no choice but to talk straight. If you do not veer wide of the truth, you are forced to hit it dead on. I urge you, to o, to give it a try.
