ntg-context - mailing list for ConTeXt users
 help / color / mirror / Atom feed
From: "Thomas A. Schmitz" <thomas.schmitz@uni-bonn.de>
To: mailing list for ConTeXt users <ntg-context@ntg.nl>
Subject: Re: nomarking function in MKIV
Date: Fri, 2 Jul 2010 10:18:23 +0200	[thread overview]
Message-ID: <9DD0392C-7665-44E2-A007-FB39EF7614BD@uni-bonn.de> (raw)
In-Reply-To: <201007012059.27547.alan.braslau@cea.fr>


On Jul 1, 2010, at 8:59 PM, Alan BRASLAU wrote:

> This is a very good answer.
> 
> Now, think about robustness. So called sloppy writing
> can easily happen in a very big project, or more likely
> by an inexperienced user. ConTeXt is pretty good in handling
> this, but not perfect. How many times have we tried options
> that do not exist and which are simply ignored in silence.
> 
> Now try:
>  \input knuth
>  \starttext
>  What about this?
>  \stoptext
> 
> Sometimes our errors, ignored in silence, end up having
> strange side effects that are long to debug. I came across
> this, for example, using by mistake \cite{reference}
> rather then \cite[reference].
> 
> Back to robustness, I once wrote a very big system used to run
> expriments. It *had* to be robust. Luckly, to insure this,
> I had a collegue who was very good in doing every thing wrong.
> For example, if the program asked "how many cycles" to run,
> he was capable of typing "yes". Why not?
> The program still had to handle this correctly.
> Should be the same for typesetting.
> 
> I hope that you all *never* make mistakes.
> Remember, *real* unix users only use cat;
> All other text editors are for "sissys".


Hope this isn't too long and not too off-topic...

It all depends on what you call "robustness." I'm a classicist, not a computer scientist or programmer, so  I view software only from a user's perspective. But here's what I think about this: a system is robust when it behaves in a predictable and consistent manner. Maybe it's because I have begun writing some of my stuff in xml, or maybe it's because I'm an anal-retentive guy by nature, but I find the tree image of documents compelling: everything has to be part of a branch. And I read the examples you provide as proving me right: if a program asks "how many cycles?" and the user input is "yes," the only consistent and predictable behavior is throwing an error and reporting it to the user - "integer number expected" or some such. Processing "yes" will not allow the user to learn how to do this right. Everything else ("The program still had to handle this correctly") is just going to leave the user at the mercy of what someone somewhere defined for her/him. 

Moreover: maybe as a classicist, I find it natural to look at documents in the perspective of the "longue durée" - after all, we handle stuff that has been around for several millennia. Which means I see my TeX or whatever file not primarily as an instruction to typeset stuff in a certain way, but as a container  to preserve information. Which means: ideally, I want my documents so well-structured that someone in the year 3010 will be able to extract the same information from them. The better they are structured, the more they respect a consistent model, the better the chances that this will happen. Again, I would argue that this means an example like
somestuff
\starttext
morestuff
\stoptext
just should be flagged as invalid because it makes it difficult to parse this document for the information it contains.

Lastly, Hraban has given a very good analogy when he pointed to the difference between the old-style html with its convenient, but sloppy syntax à la stuff<p>, whereas x(ht)ml is more strict with <p>stuff</p>. The old way was convenient when you saw your document merely as a set of instructions for a browser to display your stuff. But in today's world, you have to see that your document may be viewed and processed in hundreds of ways: in a web browser on a computer, on a cell phone, an e-reader, a tablet, etc. Which means you should think of your document as structured information, not as instructions for a certain device. Again, the better the document is structured, the more independent and reliable its transmission will be.

So: I find the new \startchapter ... \stopchapter code much superior to the old way of organizing chapters. And I would argue that a program which discourages and flags incorrect input (like what you describe in your examples) is much superior to a program which somehow processes this input. This has nothing to do with using cat as an editor (btw: cat is for sissys, REAL programmers use a magnetized needle and a steady hand), but is a matter of organizing information in the best way.

Thomas
___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________


  reply	other threads:[~2010-07-02  8:18 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-29 16:14 John Devereux
2010-06-29 17:33 ` Peter Münster
2010-06-29 21:03   ` John Devereux
2010-06-30  8:19   ` Alan BRASLAU
2010-06-30  9:03     ` Peter Münster
2010-06-30 10:03       ` nomarking function in MKIV (selector) Alan BRASLAU
2010-06-30 22:35     ` nomarking function in MKIV Wolfgang Schuster
2010-07-01  8:16       ` Alan BRASLAU
2010-07-01  8:30         ` Wolfgang Schuster
2010-07-01  9:23         ` Peter Münster
2010-07-01  9:44           ` Alan BRASLAU
2010-07-01  9:55             ` luigi scarso
2010-07-01 10:00             ` Thomas A. Schmitz
2010-07-01 10:23               ` luigi scarso
2010-07-01 18:59               ` Alan BRASLAU
2010-07-02  8:18                 ` Thomas A. Schmitz [this message]
2010-07-02  9:18                   ` luigi scarso
2010-07-02 11:07                   ` Alan BRASLAU
2010-07-01 10:11             ` Henning Hraban Ramm

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9DD0392C-7665-44E2-A007-FB39EF7614BD@uni-bonn.de \
    --to=thomas.schmitz@uni-bonn.de \
    --cc=ntg-context@ntg.nl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).