Jargons of Info Tech industry

Discussion in 'Python' started by Steve, Oct 19, 2005.

  1. Steve

    Steve Guest

    Just passin' through....

    Xah Lee, on Aug 22, 2:43 pm wrote:
    Unix, RFC, and Line Truncation
    [snippage]
    > There is no reason for a paragraph encoding to be splattered with end
    > of line characters, nor the human labor expended. There is reason for
    > paragraphs to be displayed not too wide, and that is readability. What
    > the unixer could not get clear of is a distinction of concepts. Because
    > their fantastically hacked-up operating system operate by the principle
    > that lines should not be some 80 chars or else it will be truncated and
    > *silently* too, thus it became _necessarily_ their _habit_ and thought
    > that line truncation business is natural and a human duty. Unknown of
    > these setups, the unix geeks go by their presumption that all text
    > should be hard wrapped, as if parameters should be hard-coded.


    I've seen this argument before. There's at least one VERY good reason
    to hard-code linebreaks in text: to preserve a covert channel. It's
    really easy to structure plain text in such a way to include super
    sekret messages that can only be properly decoded when the original
    formatting of the text is preserved. Assuming that all of us are
    agreed that plain text is the correct lowest-common denominator in
    email and Usenet communications, it makes sense to allow for additional
    personal expression by way of enabling users to encode additional
    information in the formatting of their messages.

    So, while Mr. Lee (who is not alone) is apparently of the opinion that
    paragraphs should be formatted according to the transient size of the
    newsreader window, his preference destroys a channel of expression
    available to the putative author -- if free-flow paragraph structure is
    mandated by the messaging standards and conventions of the text
    messaging community.

    Personally, I think the status quo is fine. People who wish to insert
    line breaks where they wish in their paragraphs may do so, and others
    may rely (or not) on their software to format their messages.

    In the long term there are more pressing problems. Sould we, for
    instance, extend the plain text 'conventions', which are largely
    concerned with 7-bit ASCII messaging, and all the associated software
    applications to work with unidcode character sets? Simplicity is good
    and all that, but this is a multi-cultural, multi-language world.
    Locking out the non-English speaking population from Usenet or (worse)
    from manually interoperating with basic Internet protocols (for
    instance) seems rather short sighted.

    I do not mean to start a flame war here; I am just trying to point out
    the obvious. People like Mr. Lee, as well as many, many application
    deveolopers are well-meaning but misguided. They would unnecessarily
    complexify things that should be simple and simplify things that should
    be complex. I, for one, am continuing to think about these issues
    because I see no simple solutions and have no magic bullet to offer
    that would solve these perennial difficulties of prereference, clarity,
    and common sense.

    Perhaps one day we will converge on near optimal solutions to these and
    like issues; which will be coded and formalised in standards, and which
    will stand for the indefinate future.


    Regards,

    Steve
     
    Steve, Oct 19, 2005
    #1
    1. Advertising

  2. Steve

    Xah Lee Guest

    > Xah Lee, on Aug 22, 2:43 pm wrote:
    > Unix, RFC, and Line Truncation
    > http://xahlee.org/UnixResource_dir/writ/truncate_line.html


    Steve wrote:
    > I've seen this argument before. There's at least one VERY good reason
    > to hard-code linebreaks in text: to preserve a covert channel. It's
    > really easy to structure plain text in such a way to include super
    > sekret messages that can only be properly decoded when the original
    > formatting of the text is preserved. Assuming that all of us are
    > agreed that plain text is the correct lowest-common denominator in
    > email and Usenet communications, it makes sense to allow for additional
    > personal expression by way of enabling users to encode additional
    > information in the formatting of their messages.


    Rethink what you are saying. You'll see that what you propose as
    reasons for one, is actually for the other.

    Xah

    ∑ http://xahlee.org/
     
    Xah Lee, Oct 19, 2005
    #2
    1. Advertising

  3. "Xah Lee" <> wrote in message
    news:...

    > Rethink what you are saying. You'll see that what you propose as
    > reasons for one, is actually for the other.


    Nonsense. It is plain error to change what someone said and claim they
    said it, even if you think that what you are changing isn't important.

    DS
     
    David Schwartz, Oct 19, 2005
    #3
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Xah Lee

    Jargons of Info Tech industry

    Xah Lee, Aug 12, 2005, in forum: Java
    Replies:
    356
    Views:
    6,549
    noah bedford
    Oct 23, 2005
  2. Steve
    Replies:
    2
    Views:
    409
    David Schwartz
    Oct 19, 2005
  3. Xah Lee

    Jargons of Info Tech industry

    Xah Lee, Aug 12, 2005, in forum: Python
    Replies:
    385
    Views:
    4,810
    noah bedford
    Oct 23, 2005
  4. Xah Lee

    Jargons of Info Tech industry

    Xah Lee, Aug 12, 2005, in forum: C Programming
    Replies:
    347
    Views:
    4,305
    noah bedford
    Oct 23, 2005
  5. Steve

    Jargons of Info Tech industry

    Steve, Oct 19, 2005, in forum: C Programming
    Replies:
    2
    Views:
    347
    David Schwartz
    Oct 19, 2005
Loading...

Share This Page