Re: Deprecated Language Constructs

>In message <9508012132.AA13077@sass027.sandia.gov>, Michael J Hannah
writes:
>>With this definition of the term, I do not understand the concern of
>>"breaking" existing documents.  If the concerns are valid, then _NO_
>>construct in the language that was at all widely used could _ever_
>>be deprecated.  Am I missing something?
>
>Nothing technical -- it's mostly a cultural thing. Backwards
>compatibility is a religion on the net and the web.
>
>And even in a production software environment, you can't really remove
>features, no matter how slowly or how much warning you give.
>
>Well... you _can_, but you'd better have a DARNED GOOD REASON.
>This brings us to...
>
>>The idea is to have such a better new way to do things that people
stop
>>using the old (deprecated) way for all newly created documents,
>
>I frankly don't see what's wrong with <ul>, <ol>, and <dl>. The users
>grok, the software groks, everything's hunky-dory. These are distinct
>communications idioms. In language design, orthogonality should only
>be taken so far. It's good language design to optimize for common
>idiomis -- especially in a document markup language, as oppose to 
>a programming language.

Good points above IMHO :-)

>Consider the cost of migrating from the current idioms to your
>proposed idioms: all that software has to get fixed (no big deal), we
>have to hammer out the spec, all those HTML introductions, books,
>tutorials, references, test suites, ... and finally: all those PEOPLE
>have to learn the new idiom. (Studies show it takes 3x as long
>to learn something if you know already know it in a contradicting
>form as if you're learning it fresh. "Can't teach an old dog new
>tricks," I guess.)

So whose migrating old stuff? Based on the definition of deprecation
which seems to have been agreed upon in this particular discussion, no
migration is needed.

>And for all that hassle, what do they get? As far as I can tell,
>exactly the same expressive power as they already had.
>
>Sorry, I just don't think it's worth the bother.
>

In defense of of mjhanna's proposal there are a number of more
expressive things that can be done with his lists, i.e. expanding and
contracting outlines, automatic updating of references to figures.

Received on Thursday, 3 August 1995 08:18:47 UTC