celarier@reed.bitnet (Stuart Celarier,<None>,2369490,2369386) (10/16/90)
After resisting putting my two cents in, I finally cave in to the pressure. I completely agree that bad design is bad design, regardless of what form it takes. But that is not the central issue, it merely refutes those who like the 'discipline' that blocks forces on them. The main issue in coding is appearance, in its many guises such as readability. To be as revolutionary as the early 1960s, code is written for the machine, it is written for the user. Code is worth nothing if you can not read it and modify it. In either block or file format, Forth code can be made readable. However, most projects I have worked on in Forth, execution time optimization always requires some hefty amount of assembly code to be written -- and here the simplicity comes in, since it is so easy to exchange a colon definition for a code definition. Assembly language does NOT fit well in blocks! The syntax of assembly languages is vertical (except on a few parallel processors...), and few calls take fewer than 16 instructions (i.e., 16 lines). The result is an editing nightmare! When writing assembly language routines I like to have one instruction per line, group related instructions into a stanza (not split across block boundaries), and unlimited amount of space to comment what is really going on, since assembly language can be so arcane. I've seen a number of Forth system sources which were impossible to read for this reason; they crammed three or five instructions on a line, and performed amazing trickery without the slightest hint of what's being done. At one job, we kept track of the amount of time spent when writing assembly code that was spent just getting the code, which spanned several screens, to look right. That is, what was the overhead of using blocks when writing assembly code. For three programmers, the average was nearly 3/4 of the total time was spent formatting. Doesn't this distract from the task at hand? And at what point in the project development are you optimizing colon definitions into assembly language? Why, at the very end, just before release, when you can't afford to waste time. I would be happy always working with files, but if I can't someone had better address the writing assembly language in blocks. One idea, never fully implemented around these parts, is to change the editor to have 'rubber screens', letting it worry about the screen boundaries when you tell it to -- namely when writing assembly code, a table, or any other entity which doesn't really fit in 16 lines -- and behaving as a block editor the rest of the time. Think of it as a different user interface to your current block editor. May your colon alway function properly. Stuart Celarier celarier@reed.edu