"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.)