Re: Ada programs depend on fonts (was: aunit?)

[Stephen Leake <Stephe.Leake@nasa.gov>]

Georg Bauhaus <sb463ba@d2-hrz.uni-duisburg.de> writes:

> Stephen Leake <Stephe.Leake@nasa.gov> 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