Message-Id: <3020C047-00000001@shenzipc> From: firstname.lastname@example.org Date: Thu, 03 Aug 1995 08:25:42 edt Subject: Re: Deprecated Language Constructs To: "Daniel W. Connolly" <email@example.com> Cc: firstname.lastname@example.org >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.