and asks:
>So what da ya think? Is this syntax too complex?
Yep. (Indeed, I think it's slightly worse than a simple Lisp, but that's
not the point I'm going to make.)
I'm going to make a few assertions; they are unquestionably subjective,
but they're backed up by a number of years of watching how people
interact with computers. (I have something of an advantage in my
family, which ranges the full spectrum from professional programmers
to mild technophobes, but all of whom use the things.)
First: *any* language which has "syntax" is going to scare most
people off. We're talking about normal people here, not technophiles.
Most of these are the people who turn to Prodigy, not because it's
the coolest service around, but because it's trivial to use and has
good tech support anyway. And most of them are going to be scared off
by *anything* that smacks of a real computer language. They want to
be able to tell the computer what to do in as natural a way as possible.
Second: there is no way this project is going to come up with a
language that *is* natural for these folks. It's a very hard problem,
which people have been working on for decades. Every attempt I've
ever seen or worked in (and I've worked in a bunch, from Cobol to
Progress) has been a bastard, sacrificing real expressive power
while still not being *nearly* intuitive enough. People want to
be able to use natural language to describe behaviour, and that's
hard. (And please don't cite adventure games at me as counter-
evidence; there is a *world* of difference between interactive and
algorthmic expression.)
Third: frankly, I believe, deep in my heart, that *no* language, no
matter how natural, will suffice to enable non-programmers to develop
descriptions of any sohpistication. The problem isn't the mode of
expression, but the mode of thought. Creating any sort of real
application requires algorithmic thinking, and thinking like that
requires some training. I honestly believe that, even if there
existing a "programming language" as natural to people as English,
most still wouldn't be able to program -- they're not used to thinking
that way.
(A caveat here: my definition of a "programmer" is somewhat recursive
here -- it basically means someone who *can* develop applications,
because they *do* understand algorithmic thought. My wife isn't a
professional programmer, but *is* a programmer in a very real sense,
because she groks the necessary concepts, and she *does* develop at
least modest programs. My mother, on the other hand, is a true
non-programmer -- she's perfectly comfortable with computers, but
simply doesn't understand programming and has no desire to learn...)
Fourth: the sort of simple problem Peter describes shouldn't be solved
by any sort of programming language, but by parameterized
"engines". One of the reasons I've come to favor Inventor is that its
engine mechanism is a very elegant way of expressing whatcha might
call "static dynamic behaviour" -- that is, simple loops and
triggers. It describes them in a pleasantly unalgorithmic, object-like
way. This sort of mechanism is *very* amenable to creating good tools
that *are* intuitive for the average person to use. Instead of the
program Peter gave above, the user would go through an interaction
(using mouse clicks) running like,
"Okay, take that widget. Now, start it spinning. No, a little faster
than that. Yeah, that's good. Now, let it spin halfway around, then
stop and come back."
Same effect; better intuition. It requires us to decide what engines
people are likely to want (Gavin has pointed out to me in private use
that even SGI recognizes that Inventor's base set is minimal). For
those concepts, we can have mechanisms that are extremely easy-to-use;
hopefully, easy enough for the non-programmer to utilize.
Finally: the tradeoff is simplicity of use vs. flexibility. My final
assertion is that we will not find a single mechanism that satisfies
both at all well, for the reasons outlined above. Therefore, it seems
to make sense to have two mechanisms, one that is easy enough for the
non-programmer, but somewhat limited, and one which is hopefully not
*too* complex, but worries most about full expressive richness, and
allows the user to develop arbitrarily complex applications. Without
the truly simple mechanism, only programmers will be able to develop
non-static pages; without the rich one, we will stunt cyberspace's
growth, by making it difficult to push the envelope of what you can
do.
As I said before, I don't think we need to decide on an interface
language now; strictly speaking, we don't even have to decide now that
it will exist, just so long as we don't build things in such a way
that it can't. Ultimately, though, I think the way to go is with a
powerful interfacelanguage, while expressing the simpler capabilities
using engines or some similar mechanism that can be easily
WYSIWYG'ed...
-- Justin
Who is trying to get across that point
that I don't *care* about the simple
problems; they're easy to solve. I'm
more concerned with how one will
handle complex ones...
Random Quote du Jour:
"In England, anything not expressly forbidden is permitted.
In Germany, anything not expressly permitted is forbidden.
In France, even things expressly forbidden are permitted."
-- from the Wall Street Journal