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-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,57547e48b4c4d9b8 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-04-17 10:26:04 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!hammer.uoregon.edu!skates!not-for-mail From: Stephen Leake Newsgroups: comp.lang.ada Subject: Re: Ada programs depend on fonts (was: aunit?) Date: 17 Apr 2003 13:19:30 -0400 Organization: NASA Goddard Space Flight Center (skates.gsfc.nasa.gov) Message-ID: References: NNTP-Posting-Host: anarres.gsfc.nasa.gov Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: skates.gsfc.nasa.gov 1050600864 6525 128.183.235.92 (17 Apr 2003 17:34:24 GMT) X-Complaints-To: usenet@news.gsfc.nasa.gov NNTP-Posting-Date: 17 Apr 2003 17:34:24 GMT User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Xref: archiver1.google.com comp.lang.ada:36244 Date: 2003-04-17T17:34:24+00:00 List-Id: Georg Bauhaus writes: > Stephen Leake wrote: > : I accept ACT's definition of "good style". Because to do otherwise > : takes more time than it is worth. > > Hm. (For the same reason one could accept MSs definition of C++...) Touche :). > Why does it take less time to transform source code into ACT style > than to obey one or more definitions of good style? The point is for the entire Ada community to have exactly _one_ definition of good style, and _always_ use it. Then it is always faster to convert everything to that _one_ style, or to simply write in that style in the first place. > (After all, others might have good reasons for using a different > good style and that will likely lead to a bunch of programmers > grimly reformatting their sources :-) Yes, there are often "good reasons" for picking one style over another. But they are all swamped by the overwhelming advantage of simply using _one_ style. > But that is a matter of a source code _view_, see below, as in to > model-view-controller, or structure-and-form, or shape-and-content. Yes, you can use tools to present different views. > : Emacs, any fixed font. Of course :) > : > : In general, I would recommend adapting the display tools to agree with > : the "standard" definition of good style (as defined by ACT, in this case). > > There is some interesting evidence that looking at your program > in different shapes (for example on screen vs. carefully typeset) > will let you see things that you do not see if you look only at the on > screen version. (The same might be true of more prose like text: you > see orthographical mistakes in one form of the text that you have not > seen in the other.) Interesting. I don't have much experience with looking at code other than in Emacs (or equivalent), so I can't really comment. > I'm always annoyed by collegues relying on font colors, when they put /* > and */ and only these 4 characters around some larger portion of source > code. They say they can easily see that this part of the program is > ineffective, because it appears in a color for comments. That feature of Emacs has saved me many times when reading C code. I agree it's not good; that's one reason I use Ada :). > (At least Ada defeats this problem.) To me, this seems less likely > to happen if people don't make their programming depend so much on > font choice etc. No, the font choice is a reasonable fix for a bad language design combined with bad programming style. What alternate fix would you propose? Hmm, I guess you could require /* */ on each line; Emacs does that when you ask it to comment out a block. > :> (consider f (x) in most various circumstances.) Seen this way one > :> might argue that -gnaty is completely unaware of any > :> typographical tradition in mathematical typesetting. > : > : Ada source code is not meant to be typeset; that's what LaTeX is for. > > Depends. It might increase quality. Then, there is also Ada letters. > > :> It seems to be aware of typical font appearance in typical plain > :> text editors, > : > : Hmph. Emacs is _not_ a plain text editor :). I would say "fixed font > : in bitmapped displays". > > Emacs is a sophisticated plain text editor, aware of a number of > syntax rules for plain text. Editing Plain text, including editing program > text, is complicated and Emacs can help a lot knowing the syntax rules > of the plain text. (That implies syntax directed plain text navigation, > and there are a few Emacs major modes that are excellent in this respect.) > Ada source code is just plain text. No fancy formatting, > no fonts, no colors. I think we are trying to define the term "plain text"; you seem to be saying "fonts and colors is not plain text". Since Emacs can display Ada code using fonts and color, it is not a "plain text" editor. Another way to look at it; in the beginning, Emacs only worked with character cells; that's a good definition of "plain text". But with version 21, Emacs can deal with arbitrary bitmapped displays, so it really is no longer a "plain text" editor. > Ada compilers don't handle fonts and colors (note the omission of > formatting, because of front ends aware of indentation). That's true; Ada compilers do require "plain text" input. > A view of Ada source code might have fonts and colors, but should > programs be written in a way that is largely influenced by one view > of source code? I think not. I agree that the semantics of a program should not be determined by the view (one reason I don't like Python; indentation determines semantics!). But the user process of writing that code can benefit from a good view (fonts and colors). > :> on typical low res displays, > : > : 1280 by 1024; I don't think that counts as "low res". > > But it is low resolution, as long as the resolution isn't around > some 400 dpi. Ok; that's a meaningful definition. > What counts is the number of pixels per visible stretch, the shape > of pixels, and, if applicable, the resolution of a font. That does > not necessarily have anything to do with the number of pixels of a > device. Ok. > : picking a good fixed with font is critical. But I've done that. > > I hope it's not mission critical? :-) > > :> I wish one could ask -gnatyX to concentrate on those aspects of > :> source code which render Ada text ambigous to the human eye, like > :> using l near 1 (or using l at all. Isn't there a "k instead of i in > :> GNAT" policy?). > : > : Again a matter of good font choice; no excuse for using a font in > : which 1 (one) and l (letter ell) are confused. > > Well, I'd rather say, no excuse for making source code depend on > font choice. You have given hints in 2 paretheses, presumably because > you know that different news reading software might display 1 and l > differently? Exactly; I have zero control over your newsreader. But I have total control over the software development process used on my projects, and I can easily require a proper font. > Who is going to maintain the program text in which IDE using what > font? Yours in both respects? Yes. > Source code maintenance shouldn't be a matter of choosing good font > choice, should it? That's part of it, yes. Just as I have to specify what config managment tool to use, and what backup tool to use, I can specify what font makes the code readable. The font choice is less important, but in the same category of "things I have control over, and therefore should specify". -- -- Stephe