Programming Environments

This part of the discussion is still superficially still about language design, but it is really about programming environments (PEs), and the responses which worry about editing and viewing heavily indented programs show how poor many PEs are.

I have used a programming language that uses indentation to show blocks (Occam) and found it very easy to cope with because it came with a purpose-built "folding" editor.

Nested blocks could be folded away into a one-line comment, so that it was easy to view the top-level structure of a complete program. If I wanted to work on a folded block, it could be unfolded in situ, so I could see the surrounding program as well (e.g. for a simple block), or it could be unfolded separately (e.g. for a function) so that the number of nested indentations could be temporarily set back to zero. The editor could also automatically change the level of indentation of folded blocks if I inserted or deleted a surrounding block.

When I stopped using Occam, I found going back to a normal editor very painful, as I had become used to using the editor facilities to simplify everyday tasks like indenting and/or commenting chunks of code, and to unfold and so view related but distant pieces of code in a single screenful of text. Last time I looked, the only folding editor commonly available was a mode of emacs, which did not have the full set of facilities to make it a useful tool.

J.C.Highfield also wrote (below) about using Occam. (Scott Stanchfield) responded to Charles Fiterman

Although I kind of agree, I think we run into _lots_ of trouble when different editors use different tab stops, and different people use different tabs in their style, and people use "expand" with a different tabstop than they should.

My co-worker and I have been working on the same code. She uses emacs, I use softedit. When she tabs, it gets expanded to 8 chars. Mine are set at 4. On the screen when she's editing, all looks fine. When I start editing something she was editing, things look very wrong.

On the other hand, I used to program on a mainframe, using ISPF as a user interface. The display panels that we programmed used an indentation- sensitive IF-THEN-ELSE structure. It was nice because it kept the panel logic shorter, and forced a particular style. (Can't say I really liked that style, though, but it _was_ consistent.)

On the mainframe, tabs were a non-issue. On UNIX, I think they could cause tons of grief. replied to Scott

Occam uses two spaces as a unit of indentation, and uses the indentation to show the block structure. This gets around the problem of differing tab sizes.

Using indentation instead of block start and finish markers seems to cut down the amount of incorrectly structured program particularly for novices, but all that indentation can make the programs very hard to read on a small screen unless you have some technique of handling the extreme program 'width'. Printing out the program also suffers these problems.

Occam programming systems usually get around this with folding editors, where a 'fold' contains code which inherits the indentation of the fold. When you enter a fold you see the code it contains starting in column 1. This is works OK for programming. However, I have never seen a good solution for printing out these programs. You either print them out as a 'flat' file, where all the folds are expanded and so the text runs off the right side of the page (or wraps around) or you use a fancy fold-aware listing program that prints out the contents of the folds after the code containing them - equivalent in some ways to printing functions after the code that calls them but in my experience much harder to read.

I like Occam and folding editors, but I don't think I will be encouraging the use of significant indentation in major programming languages until I see a good way of handling the printout problem.

I don't see why programs should be any more heavily indented if it indicates the block structure than if it doesn't. Rather, I think that Occam allows the user to write better scoped, and thus more heavily nested programs (e.g. a function definition can contain other function definitions) and that the PE allows the programmer to manage the nesting sensibly, so it isn't until you come to print them that you realise what you have done. Personally, I rather like the implications: that you can more easily use the facilities of the language to manage complexity in a proper PE. Perhaps if Occam also had classes or modules to help control scope it would be even better to program in and easier to print out. (Solution Technology) responded to J.C.Highfield

I found style of programming can affect the amount of indentation. I actually try to limit the amount of nesting so that I don't indent across the page. If it is getting that deep maybe there should be another class to handle the details. I also use what I call chained ifs. that correspond to "case/switch" statements.
if ...
else if ...
else if ...
This minimizes the amount of indentation by considering it as one control structure.

cg@Myrias.AB.CA responded to Charles' first post

[indented blocks] may be easier on the eye, but I see some problems with trying to do that, especially in C (or C++ as in the example). First, I could no longer use the convention of putting temporary (e.g. debugging prints) code at column 1 in the middle of normally indented stuff. I would have to have some other convention, such as an added comment, for finding such things. The non-indented stuff is very easy to see.
I do this too - I had to use an extra comment in Occam

I had initially thought that multi-line macros would be a problem, but since they are actually only one logical line, I think they would be OK.

I personally go out of my way to avoid lines that don't fit in a standard 80-column window, so I sometimes outdent long strings constants. This would be messed up, too.
No, on-screen this is not a problem in a folding editor

Long expressions in general become more of a problem. Artificial rules such as requiring extra parentheses in them are destined to cause problems for users, automatic pretty-printers, etc.
You need an escape mechanism to indicate when a statement has overflowed onto the next line; Occam manages, although it is unpleasant to parse - see a discussion about semicolons and newlines for more information.

Tabs (Richard A. O'Keefe) replied to Scott (Scott Stanchfield) writes:
On the mainframe, tabs were a non-issue. On UNIX, I think they could cause tons of grief.

Only if people muddle up and confuse three quite distinct things:

The right answer is to use whatever _command_ you want for indentation and whatever _indentation level_ you want, but leave the interpretation of _tab characters_ strictly alone.

Charles Fiterman ( responded to Richard O'Keefe

[Don't confuse 8 char Unix tab stops with indentation levels.]
I agree absolutely. But would like to say that the TAB in data is really a misplaced compression algorithm. If you want to compress data use compress, or gzip, or ARC. Never put TAB characters in data, and programs are data.

BTW psychological experiment show that the most readable tab value for programs is 3. However other values 1..8 are not bad. That right a tab size of one in a program is not bad. Zero is very bad. So if you are worried about some deeply indented code not having space you can use a tab size of 1 and still be quite readable. (Paul Long) wrote (Richard A. O'Keefe) writes:
to what columns should the TAB format effector move?
UNIX convention here is absolutely consistent: multiples of 8. Anything else violates UNIX conventions, the expectations of a lot of tools and a great many people, and good manners.
I've never heard of a "UNIX convention" for tabbing. Many devices and software tools default to 8 columns, but I assume this harkens back to FORTRAN, Teletype consoles, or even typewriter tab stops (was 8 columns an inch somewhere?). None of the UNIX projects I've worked on standardized on 8-column tabbing. The only project that did was a VMS project.

BTW, there was a study (Miaria, Richard J., et al. 1983. "Program Indentation and Comprehensibility." _Communications of the ACM_ 26, no. 11 (November): 861-67) that showed that the optimal indentation for comprehension is 2 to 4 columns. The worst is no indentation (of course) and the next worst is 6 columns. I don't know how 8-column indentation ranks.

The study also found that, despite the empirical data, many people felt that 6-column indentation was easier to use. I assume they felt that it is more aesthetically pleasing to look at. There is an analogous situation with monitor brightness. Another study has shown that people prefer their monitors brighter than what is optimal for visual acuity.

and the moderator added

Every Unix screen editor I have ever used, dating back to about 1977, used 8 character tab stops. Some printer drivers I wrote then also had 8 char stops. The convention that a 0x9 in a text file means logically skip ahead to the next multiple of 8 spaces needn't have any connection to how you lay out your code nor what your editor does with the tab key.