|
in reply to Re^2: Looking for old Perl CGI code
in thread Looking for old Perl CGI code
For instance, you can think of an <h1> tag as a "command" to a "browsing device" to start rendering text as a level one header. The end tag, </h1> can similarly be thought of as a command to stop rendering text as a level one header. And so forth.
There's only one problem with that - HTML tags are requests, not commands. And, no, I'm not thinking in terms of Turing completeness. I'm thinking in terms of the difference between a command and a markup tag. A command (which may or may not be part of a Turing-complete language) is not a request or an option. It's a requirement. If the recipient of an "executable command" does not perform the action in a well-defined manner (that is not implementation-dependent), then the recipient is broken.
HTML, on the other hand, is completely optional and implementation-dependent. Yes, we have certain expectations of how a standard browser on a standard computer is going to behave and we would definitely consider IE or FF buggy if it displayed h3 tags as bigger than h1 tags. However, go watch a blind guy on the Net for a few hours and watch how his browser handles tags. Half are ignored and the other half are rendered in speech emphasis, not upon the screen. And, what about mobile devices?
The gist is that HTML is a format for specifying how to optionally decorate plaintext. It has nothing to do with commands, executables, or anything else of the sort.
My criteria for good software:
- Does it work?
- Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
|
Re^4: Looking for old Perl CGI code
by sauoq (Abbot) on Oct 13, 2005 at 17:04 UTC
|
I want to make it abundantly clear here that I'm really playing devil's advocate in arguing with you. From a technical standpoint, I agree with you completely because the distinctions you are making are useful from that standpoint. Those distinctions, however, aren't so necessary or even so easy to make outside of a technical discussion.
There's only one problem with that - HTML tags are requests, not commands.
There's no such thing as "requesting" that a computer does something because a computer doesn't have free will. Its behavior is well-defined and predictable.† How a browser implements the specification isn't the issue; those choices have already been made by the browser developers.
Also, the issue isn't whether all computers do exactly the same thing with the input. But, that should be obvious. Give C source to two different compilers and you probably aren't going to get the same output (even on the same platform.)
The distinction between data and code is blurry. Which, for instance, is a perl script? It isn't machine code, but it does contain strings of symbols that, when fed to a perl interpreter, determine the behavior of that interpreter. Perl itself is written in C. C isn't machine code either, but it does contain strings of symbols that, when fed to a compiler, determine the behavior of that compiler. And HTML isn't machine code, but it does contains strings of symbols that, when fed to a browser, determine the behavior of that browser.
By the way, I had this argument with a college professor once (and he, as I, played devil's advocate and argued the side I am now.) It was a little more specific in that the question was "is HTML a programming language?" At one point I decided to appeal to higher authority and I wrote email to Guy Steele, Bjorne Stroustrup, and one or two other famous names. The only reply I got was from Stroustrup. His reply was that, yes, a case can be made for calling HTML a programming language. I've been looking for that email, but I guess I no longer have a copy. In any case, his response shocked me into a more flexible point of view. While I do agree with you from a technical standpoint, I understand completely why your argument won't hold up in court.
† Predictable to someone and in theory (ignoring implementation errors.)
-sauoq
"My two cents aren't worth a dime.";
| [reply] |
|
|
| [reply] |
|
|
The browser doesn't have to be a GUI browser a la IE or FF. It can be something as simple as Notepad or some other editor.
Sure. And, I could step through an algorithm written in C using nothing but pencil and paper too... I don't think you are making a point here.
As for HTML being a programming language, I think Stroustrop is trying to find ducks that dig. It just doesn't pass the sniff test.
It only smells funny because you've had your nose so close to—uh... for lack of a better word—"real" programming languages. It is, however, a communication standard and it is used to control devices. Outside of the technical community, that's enough. Inside the technical community, we kind of draw a line between "programming languages" and more general "computer languages" but, again, that distinction isn't very useful to anyone but us. And more importantly, in a legal context it isn't going to help much if at all.
-sauoq
"My two cents aren't worth a dime.";
| [reply] |
|
|
|
|
|
Re^4: Looking for old Perl CGI code
by Perl Mouse (Chaplain) on Oct 13, 2005 at 13:57 UTC
|
HTML tags are requests, not commands.
Actually, they are neither. HTML tags delimit HTML elements, for instance in:
<H1>This is an example</H1>
the tags <H1> and </H1> delimit a first level header element, whose content is This is an example (which has type PCDATA).
HTML, on the other hand, is completely optional and implementation-dependent
There's little implementation dependent in HTML. You have of course your choice of DTD, but that's about it.
Yes, we have certain expectations of how a standard browser on a standard computer is going to behave and we would definitely consider IE or FF buggy if it displayed h3 tags as bigger than h1 tags.
I'd consider a browser buggy if it showed me the tags at all. It should show me the data - not the tags. It should use the tags to know what kind of data the document contains, and use that to decide how it should be rendered, but it should not show the tags.
However, go watch a blind guy on the Net for a few hours and watch how his browser handles tags. Half are ignored and the other half are rendered in speech emphasis, not upon the screen.
I've some close friends who are blind. They all use IE to browse the web. They do use a screen reader to know what IE displays though.
And, what about mobile devices?
Yes, what about them? I'd consider any HTML processing device, whether it's mobile or not, broken if it "ignored tags". Just like I'd consider a (Perl) compiler broken if it ignored double quotes.
The gist is that HTML is a format for specifying how to optionally decorate plaintext.
Eh, no. HTML is a format to specify what is plaintext or not. Or what's a header, a list or a link.
Neither tags, nor elements are commands or request. They are just that, structural parts of a document. They just exist, they do not act.
| [reply]
[d/l]
[select] |
|
|
I'd consider a browser buggy if it showed me the tags at all.
I suspect that dragonchild was speaking loosely when he said, "if it displayed h3 tags as bigger than h1 tags." It seems likely that he meant the content of those tags.
Neither tags, nor elements are commands or request. They are just that, structural parts of a document. They just exist, they do not act.
In other words, HTML is declarative rather than imperative. As the wikipedia entry on declarative programming languages states though: The distinctions are never sharp; any computer language has an element of initializing a process in a computer, in order to be of any use.
So, again, the distinctions are really only useful from a technical vantage point. As far as legal arguments go, this won't buy anything.
-sauoq
"My two cents aren't worth a dime.";
| [reply] |
|
|
