In article <jameslE8uvL5.Kt9@netcom.com>,
James Logajan <jamesl@netcom.com> wrote:
>Ken Tilton (tilt@bway.net) wrote:
>: Pragmatics have no place in a theological debate or language flame war.
>: They might blow out the fire. <g>
There is a difference between theories and theology, though either is often
easy to mistake for the other.
>: We're comparing languages, so I suggest we fight to the death over (or
>: until we agree upon) The One Best Language for Everything <g>.
I don't think many poeple here believe there is One Best Language for
Everything. There are, however, languages that are good for more things
than others. (Say Pascal vs. Modula-2, to pick a similar-but-different
pair.)
>: I suggest Lisp. Any counter-offers must include full dynamism,
>: introspection, procedural macros, lexically-scoped closures and generic
>: functions and must not include static typing. You know, Lisp. <g>
I like all of those features myself, but let's not get greedy. :-)
(And by the way, generic functions are not part of Lisp per se, they're
part of Common Lisp with CLOS and some other languages that adopted
the idea, including some OOP languages.)
I suggest talking about which features are crucial and work well
together, so we can swipe the best features of various languages
and combine them into a coherent whole, rather than just kludging
scripting languages together.
There's too much of a religious/propagandistic tendency for people
to either say "A tool for each job", or to say "one tool for every
job," rather than talking about "a handy combination of a few
tools." This just leads to misunderstanding and flame wars.
I for one, have never said that Scheme is the ideal scripting
language. I know it's not. However, I do think some of the core
ideas of Scheme are very useful and would work well in that
setting. I also think something like Self might be a good
start, and it's a very different language.
I also think that Tcl has some good stuff in it. What I'm trying to
figure out is which features are due to simple lack of knowledge
of the alternatives, and which say something fairly deep about
how a scripting language should be designed.
>I represent a rabble of one that takes no prisoners! Counterthrust:
>where the bleep is human-factors in this never-ending thread? Anybody
>care to actually reference what little research has been done in this
>area?
Not the research I know about. It's mostly baby-stuff because the
main issues are hard to conduct good, controlled experiments about.
(The results about how many characters of indenting are more readable
come to mind as some of the *better* research, though the studies weren't
thorough enough in several ways. Beyond that, you tend to get
experiments that *seem* to say something basic, but it's not clear how
to apply it to the richer context of real programming in real languages,
or stuff that's so simplistic it's more likely wrong than right.
Counterexamples very welcome.)
>I couldn't help but notice that the Ousterhout white paper had only one
>reference to one measly result of human factors research; and it came
>from a secondary source. I believe that ALL the designers of ALL the languages
>this thread is cross-posted to (and many that aren't) didn't even attempt
>to study software psychology (or psycholinguistics).
I don't know if that's true of the designers of the popular languages.
I know it's not true of all of the readers of this thread. (I for one,
worked in HCI for a while, and studied psychology, some linguistics, and
philosophy of psychology in grad school. Of course, that doesn't make
me any kind of authority, though.)
I'm just saying that some of us are aware of some of the research, but it
tends to be hard to interpret for a realistic context. Little studies
tend to be wildly unrealistic and test absolute beginners' skills, and
big ones tend to be hard to interpret because there are too many
uncontrolled variables. For this stuff to be done well, there should
be lots of studies at various granularities, which will inevitably
support quite a few conflicting conclusions. Only then will people
get a better idea of which questions to ask, to show *why* some
things turn out one way, and other work out in other wasy. That's the
way work in psychology tends to go, because it's an intrinsically
difficult, multi-leveled subject.
>NOTE TO LISP AND FORTH FANS: one important reason your languages
>have never caught on may be due to the fact that many natural languages
>follow the "subject verb object" form. Usage of SOV, OSV, VSO, and VOS
>are less likely (I don't have any references in front of me; if anybody
>wants details, I'll try to locate what I have).
I think this is mostly a red herring, but maybe not entirely. First,
different natural languages tend to vary wildly in the orderings
of terms. Consider French and Spanish postfix adjectives vs.
English prefix adjectives. Which is better? Hard to say. And look
at basic sentence structure in English. Often we force things into
our "normal" syntax when it makes no particular semantic sense, and
end up with funny constructions that confuse non-native speakers.
With respect to SVO structure, I think there's a good argument that
VSO is more natural for English speakers because in programming
languages we're often writing imperative sentences, e.g.,
"Put [ the ] cat [ on the ] mat" is more familiar than
"Cat put [yourself] on [the mat}".
The latter makes some sense in Smalltalk, where it's assumed there's
a privileged receiver of the message, and that we really are telling
the cat to put itself on the mat. But some things don't fall
gracefully into that framework, which is why some OO languages now
have generic functions (or multimethods, which is essentially the
OOP term for the same thing). Often method selection depends
on more than one argument, because the "sentence" has more than one
"object". (If your language doesn't support that concept, you may
have to kludge it.)
The difference isn't usually crucial, because putting the action
(or function name) first often tips you off to facts about the
arguments. e.g., if I say add(a,b) or (in Lisp syntax)
(+ a b), once you see the operator you can guess that the operands
are things it makes sense to add.
A major difference between computer
>They also lack visual
>redundancy (they aren't alone in this short-coming of course).
I think this problem is largely due to bad teaching. (Especially
in programming language courses where neither the teacher nor
the writer of the textbook understands Lisp/Scheme style.) The
visual redundancy in Lisp and Scheme comes largely from the indenting,
so you really have to teach/learn good indenting to be able to
read the code visually. Indenting is important anyway, in
any language, so it should be taught regardless, but it's
crucial in Lisp/Scheme, so learners need to know the rules
and know what they signify.
On the other hand, I do allow that Lisp and Scheme have
fewer visual irregularities than other languages. I'd like
to point out, though, that this is largely a choice by
Lispers and Schemers. You could build a language based on
Lisp/Scheme technology with a more conventional syntax,
and more redundant keywords. For example, it's trivial
to redefine if so that instead of writing
(if (< a b)
a
b)
you could write
(if (< a b)
a
else
b)
Note that in Scheme we don't have to write returns, because everything's
an expression. We don't have to use returns to return a value. So
where in a C-influenced language like Java or Tcl we might write
something like
proc min(a, b)
{
if (a < b)
return a;
else
return b;
}
In Scheme we'd write
(define (min a b)
(if (< a b)
a
b))
If you wanted a more conventional syntax, you could add infix
operators as well as extra keywords, and make it look pretty much
like C or Tcl. (If we really want terseness, we can use a C-like
ternary operator instead of if. In a Scheme-like language if
works just like the ternary operator AND if, because everything
is an expression that returns a value, but which may have side
effects.)
Common Lisp and many Schemes also have keyword arguments, too, as
was shown earlier in this thread by translating Ousterhout's
Tcl/Tk example into Common Lisp. So if you want more redundancy
and terseness within a basically Lisp-like framework, you can
easily get it.
By slapping a conventional-syntax parser on Scheme, and changing
a few keywords, you can get a version of Scheme with a syntax like
this:
proc min(a, b)
{
if (a < b)
then a;
else b;
}
or this:
proc min(a, b)
(a < b) ? a : b;
depending on how much of a terseness fanatic you are.
--
| Paul R. Wilson, Comp. Sci. Dept., U of Texas @ Austin (wilson@cs.utexas.edu)
| Papers on memory allocators, garbage collection, memory hierarchies,
| persistence and Scheme interpreters and compilers available via ftp from
| ftp.cs.utexas.edu, in pub/garbage (or http://www.cs.utexas.edu/users/wilson/)
|