From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,6487f59679c615d8 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.68.231.2 with SMTP id tc2mr775197pbc.8.1336613580842; Wed, 09 May 2012 18:33:00 -0700 (PDT) MIME-Version: 1.0 Path: pr3ni8170pbb.0!nntp.google.com!news2.google.com!goblin3!goblin.stu.neva.ru!nntp-feed.chiark.greenend.org.uk!ewrotcd!reality.xs3.de!news.jacob-sparre.dk!munin.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Ada Reference Manual 2012 in info format Date: Wed, 9 May 2012 20:32:53 -0500 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <82aa1ud0l3.fsf@stephe-leake.org> <20120509131736.63c924c8@vostro> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: munin.nbi.dk 1336613578 6617 69.95.181.76 (10 May 2012 01:32:58 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Thu, 10 May 2012 01:32:58 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Date: 2012-05-09T20:32:53-05:00 List-Id: "Oliver Kleinke" wrote in message news:20120509131736.63c924c8@vostro... > Am Thu, 3 May 2012 18:25:53 -0500 >> If you do spend time making an alternative version of the Standard, I >> strongly recommend that you do so by modifying the ARM_Formatter >> tool. That way, you can convert future versions of the Standard to >> your format easily (if it is a by-hand conversion, it will become >> obsolete far quicker than you realize and then you'll either have to >> do it all again or forget it). And that would also allow the >> alternate version to be used on the Rationale and other standards >> documents, if that is appropriate someday. (That's what Stephen Leake >> did with the "info" version.) >> > you have to realize that design and looks do have a function beyond > fancy, usability for example. I think you derailed the conversation for > your own purpose of defending the RM from change. "malware-laden ads", > "run god-knows-what on your computer", "Start Menu in Windows 8" -- > these are cheesy strawman arguments and it sounds like you are accusing > Jerrid that this is what he has in mind. Well, let me defend myself simply by saying 95% of change is bad. At best, it wastes your time and energies, and much of the time is worse than that, by preventing you from doing valuable things at all. The above supposedly "straw-men" are just examples of that. I'd never say that *all* change is bad (I get lots of use out of GPS and cell phone devices, neither of which [practically] existed when I was in college), but would argue that proving the value of change is on those that would try to make it -- my default position is that it is bad. Feel free to prove to me otherwise. As far as usablity goes, I've already said that I'd like to upgrade the navigation facilities of the RM. If someone has suggestions for doing that, I'd love to see them, especially if they can be relatively easily added to the existing tools. But beyond that, I think you will find it very difficult to "modernize" the RM without damaging its usability, because so many things are constrained -- you can't change the fonts significantly (as these are significant in the understanding), you can't change the format much (damaging to examples and other "preformatted" layout), and you can't separate it into smaller chunks (because there is too much interrelationships between adjacent text, much of it makes no sense by itself). To really make the RM more "usable", you'd have to start over with the organization of the contents, and that's neither practical (way too much work) nor possible (it would no longer reflect the Standard, which is kinda the point). ... > Providing a modern HTML version does not exclude the possibility to > provide a more 'compatible' version, so don't be so obstinate. :-) I'd much rather avoid a fork if at all possible, in large part because people use the RM to determine "the rules" and ultimately to reports to both the ARG and to implementers. If there are RM versions out there that make that difficult, then that's harmful. (And I'd rather that Google searches land on the "official" RM, which makes it best that there aren't competing versions out there.) Note that I have absolutely no objections to putting the RM into *other* formats (as Stephen did for "info"), because that just makes Ada more adaptable -- which is not a bad thing. Randy.