"Growing a Language"
[1/3] from: joel::neely::fedex::com at: 28-May-2001 13:48
This talk is a bit like a joke or a murder mystery. I can't tell you the ending without ruining it. However, I think GLS makes a tremendous point, and tremendously well. http://wws.editthispage.com/stories/storyReader$50 -jn- ------------------------------------------------------------ Programming languages: compact, powerful, simple ... Pick any two! joel'dot'neely'at'fedex'dot'com
[2/3] from: brett:codeconscious at: 29-May-2001 8:39
Hi Joel, It took me almost to read as long as one of your recent posts ;-) Seriously though. A great read. A number of good points were made - but it started going blury at the Java specific stuff. Brett.
[3/3] from: kenneth:nwinet at: 30-May-2001 0:27
From: Joel Neely
> This talk is a bit like a joke or a murder mystery. I can't > tell you the ending without ruining it. However, I think GLS > makes a tremendous point, and tremendously well. > > http://wws.editthispage.com/stories/storyReader$50
Good link with an amusing climax. Some serious points, some of which I emphatically agree and others I would take issue with. Just the way I like it! ;-))
>In some sense, all computers are the same; we know this thanks to the work
of such persons as Alan Turing and Alonzo Church. I'm embarrassed to admit I hadn't heard of Alonso Church (1903) before. His major contribution states that any function for which an informal algorithm can be written to compute the value of the function is computable. Which certainly makes sense although apparently it's not provable. Only shows to go ya. I find it useful to keep in mind that all a computer does is copy and sometimes complement bits. GLS makes the point that serious programming languages allow you to define new words then asks... "Should a programming language be small or large?" My answer would be a paraphrase of Albert Einstein, as small as it should be, but no smaller. One thing I note about Rebol is that you can not look at a piece of code and determine what it does. This is an implication of allowing redefinition of words that already exist. This would seem to be a bad thing although it is considered to be one of the strengths of the language. It can certainly be shown to be useful but I would contend that it is also limiting. Very often a maintenance programmer finds himself in a situation where the 'big picture' just isn't available (in a reasonable timeframe) so they must make logical assertions in a restricted domain. In such a case where code itself is indeterminate, bugs are unavoidable. This is typified today by programmers that reject the concept of bug free software (even if your own code is faultless, it's built on top of or interfaces with something that may not be.) Rebol takes this even a step further in that even if all the words used in a clause are not redefined, some of the words that define a word may be. That's a real hazard, and remains a hazard regardless of any other consideration. Even though GLS asks the question about the language being small or large, the assumption is that the code produced could be considerably large. The redefinition hazard would tend to limit the reasonable size of a project (unless the project simply consisted of modules that transmit data, but are not code linked.)
>For this talk, I wanted to show you what it is like to use a language that
is much too small. He says too small, but then goes on to show quite well that it is not too small at all (although perhaps restrictive.)
>A thought that seems like a primitive in our minds turns out not to be a
primitive in a programming language, and in each new program we must define it once more. This is the whole art of crafting a language. My contention is that as long as the primitives provided allow creation of a library of reusable code, it serves the purpose. I would be the first to admit that no one language can be all things to all people (that's why we have programmers after all;) but just like Church's theory a thing doesn't have to be provable to be generally useful.
>If you want to get far at all with a small language, you must first add to
the small language to make a language that is more large. Yep. This is called programming.
>If I want to help other persons to write all sorts of programs, should I
design a small programming language or a large one? Same answer as before... as small as possible with carefully chosen words.
>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. Now I emphatically agree (giving liberal interpretation to small and large.)
>Well, then, could not "The Right Thing" be a small language, not hard to
port but with no warts? Although the author says, "I think it can not be done." I think it's still too early to give up trying. I see too much promise in the attempts made so far, especially considering how young computer science is; but then, maybe we should close the patent office because all of the inventions that can be have been discovered? The internet becomes powerful when committees quit trying to define the content of packages and simply considered how to get them from point a to point b. When boiled down to the essence, you get something simple that can be extended in powerful ways. (The fact that committees continue to do their committee thing doesn't weaken my point.)
>The small language will grow. The warts will be shaved off or patched.
I guess we agree after all. Perhaps then it's best to define the language in layers with a powerful complete core (as in Rebol?) The next two topics are how a programmer should grow and write programs. Here the author seems to be taking a page right out of Rebol...
>If one person does all the work, then growth will be slow. ... If many
persons work side by side, and the best work is added with care and good taste, a great deal can be added in a short time. ... There are two kinds of growth in a language. One can change the vocabulary, or one can change the rules that say what a string of words means.
>My point is that a good programmer in these times does not just write
programs. A good programmer builds a working vocabulary. In other words, a good programmer does language design, though not from scratch, but building on the frame of a base language. Finally the author makes my point (sort of.)
>This mode of speach [programming] makes it hard to hedge.
He describes the language as 'straight' and 'truthful'. In other words, pure communication on both the level of --to the computer and --to the reader of the code. To me this stresses the requirement that within a context words must be immutable or they risk losing the ability to communicate truthfully. In another article about Rebol http://www.sweb.cz/LMecir/rep.html in the tenth section it describes ambiguity in meaning dependant on word order. I'm not sure what this all means except that the journey continues... (and that I'm pleased to have found Rebol on the path.)