On Tuesday, January 22, 2002, at 04:33 PM, Alain Farmer wrote:
>>> Natural language has always been a major headache
>>> for computer-science types specifically because
>>> of these kinds of token ambiguities.
>
> I am afraid that this is true. Score ONE for Scott.
>
>>> But I wouldn't go so far as to say HT is an
>>> example of poor design (well, it does have its
>>> flaws, but this kind of multi-use token isn't
>>> one of them).
>
> For clarity, nothing beats a one-to-one relationship
> between a token and its meaning, without taking into
> account the context of its use.
That is hardly what makes for clarity. Consider that a
one-to-one relationship exists in assembly languages, INTERCAL,
Universal Turing, and SPL. OTOH, they don't in HyperTalk or C++.
I'm sure that if I gave you, for example, code to calculate
floor(log2(n)) in each of those languages, the HyperTalk and C++
ones would be much easier to read. And you'd be able to figure
out what they do much easier. Even if you'd never seen any of
the languages involved.
A closer, but still horribly wrong, metric is, I'd argue, how
long is it. Another is how close it is to what you already know.
> But that's not how
> natural language works. Some programming languages,
> like Perl and GREP for example, don't work that way
> either.
grep is a Unix command. grep isn't a programming language, it
isn't Turing complete or even close. And tokens always mean one
thing in grep, btw.
<rant>
I'm sick of people who think they program in HTML. First off,
because it isn't programming. Second they are usually more
concerned with which pixel a table (nested in a table [nested
in a frame {inside a popup window}]) draws at than the content.
As long as I'm ranting, let's talk about the spammers that have
sent me no less than 20 messages today...
</rant>
I'm not saying anyone here does thos web sins. As far as I know,
no one here does.
>
> Scott has a point. The "real" programmers dislike
> overly natural/verbose languages like HT and AS. Why?
> I believe that part of the reason is that the
> technological-savvy elite wants to maintain their
> role/importance, e.g. if it was too easy, then anyone
> could do it, and they would not have a job anymore.
Well, I'm going to have to disagree with your hypothesis on two points.
First, don't attribute to plans of world domination what sheer
laziness can easily explain, to butcher a common phrase. Most
programmers do a lot of typing. Repetitive typing is very
boring. In spoken languages, you avoid it through use of
pronouns --- but those lead to ambiguities which are
unacceptable in computer programs, at least unless applied very
carefully. And programs often have ten different "it"s to deal
with, so pronouns really don't work. Instead, we use shorter
names. We don't call our indicies "item_index" but rather "i",
"x", "y", "z", etc. Finding a way to save letters is very
important when you're typing, just like natural language save
words when you're speaking (contractions, pronouns) and even
changing the grammar of the language.
HyperTalk is actually fairly good at saving typing, in many
cases, because each line does so much. Not that it couldn't use
shorter commands in some places ;-)
Second, even if something like HyperTalk were to become common,
or even if programming could be done is plain English, it
wouldn't put programmers out of jobs. Your average joe off the
street couldn't figure out how to quickly find duplicate files
on a hard disk, even if we let him describe it in English (or
French, or German, or anything). That isn't to say he's an
imbecile, he could be quite smart. I personally couldn't write a
novel worth reading. Or run a large company. Or compose a
symphony. Or even paint a portrait. Those are all skills people
acquire, and talents people have.
A programmer would eventually (or quickly, depending on
experience) figure that he shouldn't actually do a compare of
file 1 to file 2, then to file 3, then ... then file 2 to file
1, then file 2 to file 3, then ... comparing every file to every
other. That would take forever. Instead, he'd first gather
metadata. What is the size of each file? Then sort the files by
size. Then take something like the MD5 or SHA1 hash of each file
which has size-wise duplicates. Only compare those hashes. If
the hashes match, the files do[0]. If you're really paranoid,
then compare the files where the hash matched. By doing it this
way, you probably avoided even opening 80% of the files on the
disk, and saved nearly 100% of the very slow file-to-file
compares.
A programmer knows where to look when things don't work. He
knows how to track it down when he doesn't know. And he knows
solutions to the common problems that arise in many programs.
That's not to say that easier languages don't exist, or that
they are of no use. HyperTalk certainly allows people who
otherwise would never learn to program to do so. It certainly
allows more people (most everyone) to do a simple interactive
program, something that they wouldn't be able to pull off in
conventional languages. It allows even the most experience
programmer to do it quicker. But it won't let me write my novel,
and it won't turn John Doe into the next Alan Cox.
[0] The chance of two random files comparing equal by those hashes
are 1/2^64 and 1/2^80, respectively. That's FAR lower than the
bit error rate on any known storage media.
> But it my view, it
> basically comes down to this choice:
>
> a) adapt humans to computers
> b) adapt computers to humans
Don't create an unneeded dichotomy. History has shown that when
new tools come along, both the tools and the people adapt. As a
rather silly (or, at least it would be if I hadn't seen people
not realizing it) example, there is no good reason for a person
to use a pocket calculator to add numbers before entering them
into a spreadsheet. It's just that you used to have to do it
that way, because paper can't add.
Computers can. So you adapt to that by letting it. I don't think
that's such a bad thing. People adapted when calculators came
out, too.
Will computers continue to get more towards people's liking?
Yes. Will people continue to adapt to computers? Yes.
> The second choice is far more interesting (and
> visionary at this point). Micro-computers are powerful
> enough and fast enough these days to shift the burden
> of making it work (interfacing) onto the computer.
They can shift some of it, and they should. But there is no
DWIM[1] instruction, and there never will be. Also, unless done
carefully, you get to the point where you're doing things you
think the user wants --- and most do --- but the user in front
of the machine doesn't. Or doesn't this time.
One such behavior I've seen is the click once in a URL
highlights the entire thing. Grrrr.... and I wanted to edit
it....
It is, and always will be, the responsibility of the user to
express what he means. Even if through mind reading ;-) It is
the responsibility of the machine to make it easy to do, and to
aid in doing it.
[1] Do what I mean
>
>> For example, one could say "the function sine of the
>> variable x", but it is more compact to write "sin x"
>
> Yeah, but if give a mathematical proof, loaded-down
> with compact unambiguous symbols, to someone that does
> not have the math training, they would stare back at
> you blankly.
If you gave me a even a simple argument in French, I'd stare
back at you blankly, at least until I ran it through babelfish,
and started laughing that you were arguing that 곳에 물고기가 작은 퍼
센트는 파랗다, 있다. . Then I'd hit the right option, and find:
The green onion lah all, there is a percent where
the fish is small in the place.
Ummm.... yeh. [Yes, I actually did get this with Babelfish. I
think I started with "A small percentage of fish are blue."]
> Even with the appropriate math bkgnd,
> proofs are very hard to read/understand. Casting the
> proof in natural language, OTOH, simplifies the
> reading/grasping of the proof (for most folks).
Translating everything from French does, too. French is, I
think, the fourth most widely spoken language in the West.
> In terms of implementation, I suggest that we package
> these code-transformations as Apple did in HyperCard,
> e.g. the Script Translator.
That's what the Deparser is, just done right.
_______________________________________________
Freecard-general mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freecard-general
