[Oberon] a module a page (keeps the mind sane)?
John R. Strohm
strohm at airmail.net
Sun Nov 4 08:52:25 CET 2018
Jörg said:
> I don‘t know whether NW or another person once really said „one page, one
> module“.
> I personally don‘t follow that guideline; I’m rather follower of Chris‘
> guideline „one page, one procedure“.
> It‘s anyhow difficult as the word „page“ is vaguely defined and heavily
> depends on the screen size, resolution and font used😀
>
> Whenever a procedure doesn‘t fit on one „page“ I try to split it. But I‘m
> not absolutely consequent on this guideline either. There are cases where
> a procedure is longer than a page. Cases that come to my mind where I
> break my own guideline:
> A) long CASE statement. But I try to at least fit one CASE on one page
> B) HW drivers, where speed is king and I don‘t want jumps an inner loop
I've been in this crazy racket, as student and then professional, since
about 1970.
In all of that time, close to half a century now, with the specific
exception of CASE statements implementing finite state machines parsing
things (source code files, event trace sequences), I've seen exactly one
procedure [*] that NEEDED to be more than one printed page (about 60 lines)
long. I've seen a LOT of run-on stream-of-consciousness procedures that
were a lot longer than 60 lines, and ALL of them could have been made a lot
simpler with some judicious refactoring. (One in particular was a HUGE
cut-and-paste mess, that I reduced DRAMATICALLY by undoing the cut-and-paste
and making about half a dozen short procedures for the common fragments.)
Elizabeth Rather and I agreed that FORTH was powerful and good, but we
disagreed on why. She was convinced it was the interactive nature. I
remain convinced that it is because it is NOT POSSIBLE in the typical FORTH
system to write a procedure longer than 16 lines x 64 characters. (Yes, the
language is extremely concise, compared to common languages, but the point
remains the same. FORTH *FORCES* modularization.) I also observe that I
saw long run-on stream-of-consciousness modules written by people using a
FORTH that allowed longer things.
[*] The module in question was actually a FORTRAN IV subroutine, from the
CDC 6600 STARTRK game. It was the photon torpedo handler. It had to set up
a loop, to handle firing either one or three torpedoes, around a loop that
simulated the torpedo flightpath, around setting up a stack to simulate
recursion and do 8-way connectivity, to detect nova chain reactions.
FORTRAN IV didn't support recursion, so the programmer had to fake it. I
suspect that it would have been a bit simpler in a language that supported
recursion.
--John R. Strohm
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
More information about the Oberon
mailing list