Re: A case for HTML as a programming language
From: Arthur J. O'Dwyer (ajo_at_nospam.andrew.cmu.edu)
Date: 11/11/04
- Next message: Arthur J. O'Dwyer: "Re: A case for HTML as a programming language"
- Previous message: Randy Howard: "Re: Home programming job....???????????"
- In reply to: Michael Mendelsohn: "Re: A case for HTML as a programming language"
- Next in thread: Michael Mendelsohn: "Re: A case for HTML as a programming language"
- Reply: Michael Mendelsohn: "Re: A case for HTML as a programming language"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Wed, 10 Nov 2004 18:13:00 -0500 (EST)
On Wed, 10 Nov 2004, Michael Mendelsohn wrote:
>
> Casey Hawthorne schrieb:
>> Doesn't a programming language have to be able to branch, loop,
>> recurse, etc. under program control -- contents of variables?
>
> Why?
Good question; after all, there exist plenty of languages without
either explicit branch statements (functional languages with pattern
matching) or variables (functional languages, Turing tarpits).
However...
> A program can be completely characterized by its input-output relation.
> The program gets some input and provides some output. How it does that
> is completely irrelevant. For reasons of economy, most programs use
> branching and looping when going from input to output; HTML does that
> directly.
That argument is not supported by the mathematics. There are some
algorithms --- some programs, some input-output relationships --- that
simply require the use of loops. Some algorithms *cannot* be represented
by a finite state machine, no matter how big. One example would be a
program that reads input until it finds a "Q", and then prints out all
the input it's seen before that point... in reverse order. No HTML
finite state machine can duplicate that relationship; it requires a
"push-down automaton" --- an FSM connected to a data stack. Your
simplistic HTML model has no such "stack."
>> If it is only branching user control, isn't that just like shuffling a
>> bunch of index cards (as somebody else has pointed out)!
>
> No, it's not.
>
> When shuffling index cards, the user performs the algorithm; with the
> HTML "program", the user need only provide the input.
A nonsensical distinction. Where do you draw the line between "using an
input device" and "performing an algorithm"? If the user has to turn a
crank in order to get results, is he "performing" an algorithm? Suppose
he has to turn a crank simply in order to see a placard informing him
which lever to pull in order to get results --- is he "performing" yet?
> Have you tried my sorting program [1] mentioned upthread? All you need
> to provide are the numbers 1 through 5, in any order, and the program
> sorts them. You can even watch it sort them. It can sort any subset of
> those 5 numbers, too!
It's not sorting them --- the user is sorting them! After all, for
your little demonstration to prove anything, I have to know it actually
works... and to know that, I have to sort the numbers myself, don't I? ;-)
Serious points: (1) Lose the "inputting/performing" semantic argument;
it's a hopeless case. (2) And learn the fundamental differences between
FSMs, PDAs, and Turing machines.
(I'm not (yet) denying that standard HTML (4.0) might be
Turing-complete, since I haven't gotten the time to investigate it yet,
but certainly Michael's simple arguments aren't valid.)
-Arthur
- Next message: Arthur J. O'Dwyer: "Re: A case for HTML as a programming language"
- Previous message: Randy Howard: "Re: Home programming job....???????????"
- In reply to: Michael Mendelsohn: "Re: A case for HTML as a programming language"
- Next in thread: Michael Mendelsohn: "Re: A case for HTML as a programming language"
- Reply: Michael Mendelsohn: "Re: A case for HTML as a programming language"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
