http://qs1969.pair.com?node_id=499729


in reply to Re: Looking for old Perl CGI code
in thread Looking for old Perl CGI code

HTML isn't a series of commands executable by anything

Well, it's a muddy issue but the long and short of it is that you're the one that's going to end up dirty if you take that stance. Given what we do, we tend to have very specific ideas of what words like "executable" should mean. Broader definitions exist, though, than the technical ones we are most comfortable with. 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.

Our predisposition to think of things like "commands" as being part of "programming languages" and to think of "programming languages" as usually being Turing complete is, it turns out, more a matter of jargon than anything. Try debating with an intelligent but non-technical person about whether HTML is a programming language or not. It's not an easy debate to win.

Dennis Ritchie didn't have anything to do with this patent, by the way.

-sauoq
"My two cents aren't worth a dime.";

Replies are listed 'Best First'.
Re^3: Looking for old Perl CGI code
by dragonchild (Archbishop) on Oct 13, 2005 at 13:37 UTC
    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:
    1. Does it work?
    2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

      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.";
      
        I'm not speaking from the viewpoint of the consumer of the browser. I'm speaking from the viewpoint of the CGI application. It emits a set of containers (PerlMouse is correct) and those tags contain additional data. Those containers and the data they contain are all specified in plaintext and that plaintext is optionally parsed by the browser's rendering engine. 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. That is a legitimate browsing client for a given HTTP stream.

        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.


        My criteria for good software:
        1. Does it work?
        2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
      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.
      Perl --((8:>*
        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.";