home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / lang / forth / 3761 < prev    next >
Encoding:
Text File  |  1993-01-04  |  12.9 KB  |  291 lines
  1. Newsgroups: comp.lang.forth
  2. Path: sparky!uunet!starnine!mikeh
  3. From: mikeh@starnine.com (Mike Haas)
  4. Subject: Re: Documenting
  5. Message-ID: <C0CsnE.CrC@starnine.com>
  6. Sender: mikeh@starnine.com (Mike Haas)
  7. Date: Mon, 4 Jan 1993 23:45:13 GMT
  8. References: <C03sAB.MoB@starnine.com> <1992Dec31.112348.12448@sol.ctr.columbia.edu>
  9. Organization: StarNine Technologies, Inc.
  10. Lines: 279
  11.  
  12. In article <1992Dec31.112348.12448@sol.ctr.columbia.edu> penev@venezia.rockefeller.edu writes:
  13. >Mike Haas (mikeh@starnine.com) wrote:
  14. >
  15. >Do You need vertical format?    No
  16.  
  17. NEED? no, anyone can waste time seperating out assembly language
  18. instructions on one line with their eye.  'Course, you can do either
  19. in text files with no negative tradeoffs.  Trying vertical format
  20. with screens dooms you to flipping between many screens.
  21.  
  22. >Do You need indentation?    No
  23.  
  24. YES.  Any control structure should be indented.  Period.
  25. Putting IF and ELSE and THEN on the same line is silly and
  26. complicates reading source code tremendously.
  27.  
  28. >: 
  29. >: This is a side-effect of those ever-so-limiting 64 x 16 damn SCREENS!
  30. >: 
  31. >: In normal file-based environments (which all other languages are
  32. >: standardized on), you don't have to worry about packing as much
  33. >: into that tiny space as possible.
  34. >
  35. >You don't have to wory about about packing as much info in the screen
  36. >either. One screen can hold 5 to 12 words (subroutines). This is
  37. >enormous amount of info. The equivalent amount in C is more, that You
  38. >can fit even on today workstations' 17" screens. Consider the overhead
  39. >in C:
  40. >
  41. >procname(args) {
  42. >    variables declaration;
  43. >    body
  44. >}  
  45. >empty line
  46. >
  47. >You have four lines per entry, which cary basically no information.
  48.  
  49. What are we discussing, the pros & cons of screens vs. files or the
  50. overhead of different languages?
  51.  
  52. I hold that antthing that restricts you to looking a a specific block
  53. of text with no scrolling to look at CONTIGUOUS text is outdated
  54. and not defensible (except for standalone controller implementations).
  55.  
  56. >
  57. >: 
  58. >: In otherwords, with SCREENS, there is no way to create pretty,
  59. >: indented, clear code.  You either have to spread it over
  60. >
  61. >Look at _any_ 10 screens of FORTH, Inc.'s code and You can find 9 to
  62. >be pretty, clear, UNindented code. 
  63.  
  64. Code that is not indented is, to someone who is used to working
  65. with indented source code, always ugly.
  66.  
  67. >
  68. >: several screens (requiring constant flipping in an editor), or
  69. >: pack the hell out of each line (to get it all visible in one place).
  70.  
  71. >... or factor the words better.
  72.  
  73. Why should I have to rewrite my code just because of an antiquated
  74. display technology?
  75.  
  76. >
  77. >: 
  78. >: SCREENS only display 16 lines at a time.  More dark ages stuff which
  79. >: continues to cripple Forth's image.
  80. >: 
  81. >: Personally, I'll probably never work with SCREENS again, as I don't
  82. >: anticipate any more SBC projects.  That's fine with me, as Forth
  83. >
  84. >I have worked on i486/MSDOS and R3000/UNIX and find it much more
  85. >convinient to work with screens.
  86.  
  87. I suspect you have no choice.  Many forths do not support text files.
  88. Proponents of such systems always seem to be the same folks who
  89. argue for ancient stuff like screens.
  90.  
  91. >
  92. >: really does interface well with modern OS's (even some that aren't
  93. >: so modern), and I'm spoiled by working with standard text files
  94. >: for about 7 years now.  I can't imagine ever preferring SCREENS...
  95. >
  96. >There are things, that files are very unsuitable for. consider a
  97. >sextet index of a Monte Carlo Simulation Program:
  98.  
  99. Why are text files unsuitable for that?
  100.  
  101. Sscreens are unsuitable for their prime purpose... displaying source code.
  102. They are also inadequate for tracking source, with all those idiotic
  103. "load screens".
  104.  
  105. They are also incredibly wasteful... if you only enter one 1-line
  106. definition on a screen, you are wasting all the rest of the storage
  107. space, as screens must occupy 1024 characters, regardless of how
  108. much is white-space and what is not.  Just the remainder of whitespace
  109. on each line following the last non-white character is a waste.
  110.  
  111. All because of the inability to handle an "end-of-line" character!
  112. And what OS doesn't provide THAT?
  113.  
  114. >
  115. >
  116. >       420 \ Polymers - Main                                   PSP 22/11/92
  117. >       421 \   Polymers - local                                PSP  3/06/92
  118. >       422 \   Polymers - contd.                               PSP 30/05/92
  119. >       423 \ Energy discretization                             PSP  2/11/92
  120. >       424 \ Parameters of the polymer simulation              PSP 28/05/92
  121. >       425 \ Initial values of the parameters                  PSP  2/06/92
  122. >       426 \ Interaction - structures                          PSP  9/05/92
  123. >       427 \   Horizontal interaction                          PSP 28/05/92
  124. >       428 \   Vertical interaction                            PSP 28/05/92
  125. >       429 \   Location interactions                           PSP 15/04/92
  126. >       430 \   2D-Array calcualtions                           PSP 21/05/92
  127. >       431 \ T-dependent energies for the run                  PSP 29/05/92
  128. >       432 \ Polymer latice                                    PSP 17/04/92
  129. >       433 \   Neibours with cyclic boundary conditions        PSP 27/04/92
  130. >       434 \ Calculate energy index                            PSP 29/05/92
  131. >       435 \ Update sites                                      PSP 29/05/92
  132. >       436 \ Dynamics                                          PSP  5/06/92
  133. >       437 
  134. >       438 \ Tabulate all energy differences                   PSP 29/05/92
  135. >       439 \   Access energies and probabilities               PSP 29/05/92
  136. >       440 \   Build energy and probability                    PSP 29/05/92
  137. >       441 \   Horizontal connectivity                         PSP 26/04/92
  138. >       442 \   Vertical connectivity                           PSP 26/04/92
  139. >       443 \ 
  140. >       444 \ Cluster statistics - structures                   PSP 27/04/92
  141. >       445 \   Walk clusters                                   PSP 27/04/92
  142. >       446 \   Collect cluster lengths                         PSP 22/05/92
  143. >       447 \   Write cluster statistics to disk                PSP 22/05/92
  144. >       448 \ Concentration of monomers                         PSP 25/04/92
  145. >       449 
  146. >       450 \ Stat variables                                    PSP 21/05/92
  147. >       451 \   Definition of stat variables                    PSP 21/05/92
  148. >       452 \   Statistics                                      PSP 21/05/92
  149. >       453 \   Compute thermo-dynamic properties from stat     PSP 20/05/92
  150. >       454 
  151. >       455 
  152. >       456 \ Swapper                                           PSP 17/05/92
  153. >       457 \ Swapping interface                                PSP 17/05/92
  154. >       458 \ Change Lattice side and reboot                    PSP 14/05/92
  155. >       459 \ 96-bit data                                       PSP 22/05/92
  156. >       460 \ Statistical words                                 PSP 30/05/92
  157. >       461 \   Statistical words                               PSP 31/05/92
  158. >       462 \ Data base management                              PSP 20/05/92
  159. >       463 \ Additional operators                              PSP 21/05/92
  160. >       464 \ Invalid fields                                    PSP 24/05/92
  161. >       465 \ File of samples                                   PSP 21/05/92
  162. >       466 \ Thermodynamic quantilies                          PSP  3/11/92
  163. >       467 \ File of lengths                                   PSP 22/05/92
  164. >       468 \ File Density of states                            PSP  8/11/92
  165. >       469 \ Produce SAMPLES from TDQ                          PSP 20/05/92
  166. >       470 \ Convert SAMPLES Old > New                         PSP  3/06/92
  167. >       471 \ Locate L in the file                              PSP 21/05/92
  168. >       472 \ Produce Thermo Dynamic quantities from samples    PSP 24/05/92
  169. >       473 \ Avaraged statistics                               PSP  6/06/92
  170. >       474 \ Cumulant computation from samples                 PSP  6/06/92
  171. >       475 
  172. >       476 
  173. >       477 HEX \ Optimizing                                    PSP 23/04/92
  174. >       478 \ Internal registers                                PSP  5/05/92
  175. >       479 
  176. >
  177. >Try to have this with files. And talk about documentation afterwards.
  178.  
  179. Simple.  Each is in it's own file.  Clean, clear, and no waste of space.
  180. And if you want to import some support routines into another project,
  181. you simply call it by name without having to remember all those
  182. screen NUMBERS (y-e-c-c-h-h).  Just another place to make a mistake.
  183.  
  184. 'Course, maybe you LIKE having to specify a section of code both
  185. by NUMBER and then include a comment to explain what that number means.
  186. Me?  I like to just type in a descriptive filename.
  187.  
  188. I quit programming in hex code and front-panel switches when compilers
  189. became avaiilable, too.
  190.  
  191. >
  192. >: and I don't care how cool a Forth SCREEN editor you have... there are
  193. >: much better ones for text files.
  194. >: 
  195. >
  196. >This is not quite true. I've tried almost all of the editors on the PC
  197. >(pe2, e3, kedit, edit, professional editor (IBM), WINWORD) and emacs on UNIX.
  198.  
  199. Sorry.  Try a good editor with a gui... mouse operation, drag-select,
  200. cut copy paste, find & replace MULTIPLE FILES OPEN.
  201.  
  202. Check out text editors in a WINDOWING environment, like Mac or
  203. Amiga, Next, OS/2, even (yuk) Windows.  (Do you get the idea
  204. the world is changing without asking you?  Or the Forth community?)
  205.  
  206. >None is better for editing programs that the screen editor I use. The
  207. >reason is very simple. Even though the good editors have their
  208. >languages, not is a flexible as FORTH is. They are pretty narrow too.
  209. >On the contary one has the entire source of his editor in FORTH and
  210. >implements whatever functions he considers usefull. And one ends up
  211. >with a highly tuned to himself editor. 
  212.  
  213. Big deal.  Not as flexible?  You need to looka round a little more.
  214. SCREENS are not at all flexible.  They are fixed chunks of 1024
  215. characters that can't be printed, searched or in any OTHER way
  216. processed by the prolifera of OS utilities any system provides.
  217. Or third-party product like print spoolers, source control
  218. systems, etc. etc. etc.
  219.  
  220. Screens waste space and limit what you can see at one time (can't even
  221. look at two things together if they aren't on the same screen).
  222.  
  223. And customizability?  There are text editors that are 100%
  224. customizable.  You can add e-macs-style macros to make them feel
  225. like emacs, or vi, or ???  That's flexibility.  You can establish
  226. any keyboard paradigm for any editor, or dream up your own.
  227. Never has a Forth editor approached what is done in standard text
  228. file world.
  229.  
  230. The reason is simple.  Only Forth people write Forth editors.
  231. The rest of the computing universe provides products for text files.
  232. Therefore, there is a tremendous amount of creativity, ideas, and
  233. energy that goes into constantly providing better text-file
  234. processing tools.
  235.  
  236.  
  237. You can write macros in them, interface to other languages (ever hear
  238. of language-sensitive editors?... some might even have offered
  239. Forth interoperability IF Forth wasn't so wierd with SCREENS).
  240.  
  241. >
  242. >
  243. >: I hope I never again have to wind my way trough something like...
  244. >: 
  245. >: 5 LOAD 8 LOAD 23 LOAD 100 110 THRU 56 LOAD 13 LOAD etc. etc. etc
  246. >: 
  247. >
  248. >You can write extremely cryptic code in FORTH, as well as in almost
  249. >any languge. An usual load screen, though looks like:
  250. >
  251. > 0 ( Electives)   DECIMAL
  252. > 1 : <CREATE>   >IN 2@   SWAP 1024 * + ,  (CREATE) ;
  253. > 2    ' <CREATE> 'CREATE !     4 CONSTANT B/H  ( 0 if no  LOCATE)
  254. > 3 ( Aids) 12 LOAD  13 LOAD  14 LOAD 11 HELPS  10 LOAD  23 LOAD
  255. > 4 ( Disk retries   33 LOAD     6 LOAD)  2 LOAD
  256. > 5 ( 32-bit)  15 18 THRU   ( 21 23 THRU)  ( char)  19 LOAD
  257. > 6 ( L.C. Editor) 20 LOAD  ( UNIX Date & Time) 34 35 THRU
  258. > 7 ( Calendar)  31 LOAD   TODAY @ .DATE  ( Loops)  4 5 THRU
  259. > 8 ( Time)  32 LOAD   .(  Time )  @TIME .TIME
  260. > 9 : SYSTEM   11 DATED  ."  Time "  @TIME .TIME ;
  261. >10 : ONDISK   7 OFFSET @ -  HELPS ;     7 LOAD
  262. >11 ( Tasks)  24 25 THRU   \ Printer)  28 LOAD  ( Runner)  29 LOAD
  263. >12 ( Screen editor)  1 LOAD \TERM    222 LOAD
  264. >13 : HELP   SYSTEM ;    GILD
  265. >14 ( Terminal: ANSI)     ' ?CREATE 'CREATE !
  266. >15 \S   polyFORTH II Level 4      31 Jan 1992 
  267.  
  268. That's just beautiful.  Really gorgeous.  And you're trying
  269. to DEFEND THAT?  Load screens are laughable.  You don't
  270. realize it, but you might as well be arguing for piston-powered
  271. airplanes being better than jets.
  272.  
  273. >
  274. >
  275. >FORTH is a extremely democratic language. You can write _whatever_ You
  276. >want (and be responsible for this afterwards). I won't argue, that
  277. >screens is better or worse than files for everybody. I'll argue, that
  278. >it's beter for me.  And this is the beauty of FORTH - You can express
  279. >Your abstractions in code. FORTH is neither high level, nor low level.
  280. >It is of one particular level - _Your_ level.
  281.  
  282. The beauty of Forth has nothing to do with screens.  In fact, using
  283. text files removes so many headaches, that Forth actually improves
  284. as a managable language.
  285.  
  286. I always wonder how many proponents of screens have never tried
  287. a good file implemtation.
  288.  
  289. The fact that many still argue for screens is a statement as to 
  290. why Forth will never be accepted by the mainsteam.
  291.