Programming languages are unique, however, in that the people building them are often also the users (and the more this is true, the better the language tends to be). C was designed to build UNIX, while ADA was designed for a customer...and we know which one survived.
But, I also simply can't buy the "people understand naturally" logic. People understand very little "naturally"...and even if you include pre-existing knowledge (like English, or spatial skills) in this "natural" knowledge you still end up with a pretty horrendous and limited programming language. Explaining an algorithm in English almost always takes a lot more "code" than writing it in a decent high level language.
Yes, yes, of course, sorry for being unclear - I just meant that we shouldn't rely on design-by-focus-groups or design-by-committee exclusively, that imaginative solutions require creativity, and for that you need someone with taste.
People understand very little "naturally"...
Well, OOP utilizes our spacial skills, at least in the form of all those pretty UML graphs? There is certainly a lot of thinking left to do about how exactly we understand programming languages, both on macro and micro levels - what metaphors we use to understand scope, objects, functional concepts, etc. It's from this thinking that new language designs will arise.
I'm sure Ada had a useful life, possibly even in a niche where C would never be an effective tool. I was just saying that design-by-committee, even with a lot of user input, is probably not the right way to build a timeless programming language, and that building a language while using the language probably is.
Isn't that how Vista was designed? Wouldn't it be a better idea to have a really curious and imaginative person (an artist, if you will) work on the language that will last 100 years?
On the other hand, I think this article borders on a good criticism of Arc: could it be that PG's focus on writing a language is misguided? Maybe it would be a better idea to focus on something more abstract: in particular, on inventing better fundamental representations for our programs (as Alan Kay did, when he thought about OOP)? I'd imagine Paul's response would be that macros -the "blurring of the line" between interpreter and interpreted- is the mind-opening change in representation. Does the problem lie in helping people cross this line?