chris@mimsy.UUCP (Chris Torek) (02/27/89)
[discussion redirected to comp.misc] >In article <234@jarthur.UUCP> wilkins@jarthur.UUCP (Mark Wilkins) writes: >>... Ever try writing 10,000 line program that works in Applesoft BASIC? >>THAT will make you a believer. In article <1348@ubu.warwick.UUCP> mirk@warwick.UUCP (Mike Taylor) writes: >Hmmm ... A few years ago BASIC was all I had, structured programming >was a closed book to me, and yet I seemed to get by without any of the >sorts of problems that Structured Programming is supposed to alleviate. >I will admit I never wrote a 10000-line BASIC program, but I certainly >got into the 1000s .... But looking at it objectively, I never had as >much difficulty debugging my huge, sprawling unstructured BASIC programs >as I do now debugging my huge, sprawling, but structured, C programs. >(Only 1/2 a :-) When it comes to debugging, BASIC has two big advantages over C: First, it is interpreted (usually). You can use `printf-style' debugging quite freely. C systems usually force you to recompile everything with a special `debug' flag, and run under a special debugger, and even then the debugger often does not match the language, so that you cannot print or set variables properly. Second, BASIC is a much simpler language: there are not as many ways for you to hang yourself. The rope is simply too short. Despite the near-necessities missing from most BASICs---local variables, for instance---it is possible to write large programs in them. I once (in 1979 or 1980, I suppose) wrote a Z80 assembler in TRS-80 Model I Level II BASIC. The line count was certainly greater than 1000. The system I used was to keep a large sheet of paper covered with entry points and variable use. In fact, I still have that paper (curious what one finds in the desk drawers under the H19): ... 10200 - Line input & parsing ... 11200 - O1$: "BC" RP <- 0, "DE" RP <- 1, "HL" RP <- 2, "AF" RP <- 3, "IX" 4, "IY" 5, else -1 ... 12100 - Label table search, FI = `subscr' for label (*not* mod 25) ... 12400 - write 1 disk record, C bytes ... (many of these comments now seem unutterably cryptic; but some of it comes back to me now). The input, output, and labels were all stored on floppy disk. This was necessary as the assembler itself used most of the available RAM (48 kB, minus the sizes of the various patches needed to use lowercase, fix the keyboard, and so forth---about 35 or 40 k left, I think). The assembler was a conventional two-pass job, and ran at the blinding speed of 15 lines per minute. Per pass. I used to start it assembling, then go eat lunch or something. I did add a `buzz' assembler directive that made use of the cassette recorder relay to alert me when the assembly was done. But somehow I never got around to rewriting the assembler in assembly.... -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
dg@lakart.UUCP (David Goodenough) (02/28/89)
From article <16129@mimsy.UUCP>, by chris@mimsy.UUCP (Chris Torek): > In article <1348@ubu.warwick.UUCP> mirk@warwick.UUCP (Mike Taylor) writes: >>Hmmm ... A few years ago BASIC was all I had, structured programming >>was a closed book to me, and yet I seemed to get by without any of the >>sorts of problems that Structured Programming is supposed to alleviate. >>I will admit I never wrote a 10000-line BASIC program, but I certainly >>got into the 1000s .... But looking at it objectively, I never had as >>much difficulty debugging my huge, sprawling unstructured BASIC programs >>as I do now debugging my huge, sprawling, but structured, C programs. >>(Only 1/2 a :-) > > Despite the near-necessities missing from most BASICs---local > variables, for instance---it is possible to write large programs in > them. I once (in 1979 or 1980, I suppose) wrote a Z80 assembler in > TRS-80 Model I Level II BASIC. The line count was certainly greater > than 1000. The system I used was to keep a large sheet of paper > covered with entry points and variable use. In fact, I still have that > paper (curious what one finds in the desk drawers under the H19): > ... > 10200 - Line input & parsing > ... > 11200 - O1$: "BC" RP <- 0, "DE" RP <- 1, "HL" RP <- 2, > "AF" RP <- 3, "IX" 4, "IY" 5, else -1 > ... > 12100 - Label table search, FI = `subscr' for label (*not* mod 25) > ... > 12400 - write 1 disk record, C bytes > ... > (many of these comments now seem unutterably cryptic; but some of it > comes back to me now). In a book that has basic programs for the TRS80, the author makes the following comment (not verbatim, but the meaning is the same) "You do not need a structured programming language (like PASCAL) to write structured programs. You need discipline: write all your subroutines, give them entry and exit points and conditions and variable, comment your loops, and if's ....." Is there any _REAL_ difference between: while (a < 25) { ..... } AND: 100 REM start "while A < 25" loop 110 if A >= 25 then goto 200 120 ..... 190 goto 110 200 REM exit "while A < 25" loop Local variables are perhaps the hardest problem to solve, but careful variable name chosing goes a long way. Recursion, I will admit, is a problem. But it _CAN_ be done, you just need to do a lot of legwork in software, and your stack space is only as big as you make it. -- dg@lakart.UUCP - David Goodenough +---+ IHS | +-+-+ ....... !harvard!xait!lakart!dg +-+-+ | AKA: dg%lakart.uucp@xait.xerox.com +---+
desnoyer@Apple.COM (Peter Desnoyers) (03/03/89)
In article <447@lakart.UUCP> dg@lakart.UUCP (David Goodenough) writes: >Is there any _REAL_ difference between: > > while (a < 25) > { > ..... > } >AND: >100 REM start "while A < 25" loop >110 if A >= 25 then goto 200 >120 ..... >190 goto 110 >200 REM exit "while A < 25" loop > What about this: ; start "while A < 25" loop L.16: CMP A,#25 JGE L.17 ... JMP L.16 ; end of "while A < 25" loop L.17: ... which you have to agree is equivalent to this :-) /* start "while A < 25" loop */ /* L.16 */ C325 /* CMP A, #25 */ F70030 /* JGE L.17 */ ... F00010 /* JMP L.16 */ /* end of "while A < 25" loop */ /* L.17 */ It is possible to write large, well-documented programs in BASIC, and to debug and maintain them. It is also possible to ride a moped on a race course. In both cases you are using a tool for a purpose which it was not designed for, expending a lot of effort to do that, and taking longer to finish the job. Peter Desnoyers
paul@deadpup.UUCP (paul) (03/03/89)
In article <26640@apple.Apple.COM>, desnoyer@Apple.COM (Peter Desnoyers) writes: > It is possible to write large, well-documented programs in BASIC, and > to debug and maintain them. It is also possible to ride a moped on a > race course. In both cases you are using a tool for a purpose which it > was not designed for, expending a lot of effort to do that, and > taking longer to finish the job. Speaking from the point of view of someone who spent entirely too many years writing applications in BASIC on the TRS-80 series, yeh! One had to exercise _extream_ care in variable naming. In addition, several necessary speed/memory optimizations worked against propper commenting, and for that matter readable programs. This necessitated voluminous documentation external to the source. But FORTRAN ate too much memory, and assembler took to long to write, so BASIC was the most appropriate of the available languages. Now, having matured to "real machines," I most certainly wouldn't give up C for BASIC. Paul J. Mech oucsace.cs.OHIOU.EDU!deadpup!paul uiucuxc!oucs!oucsace!deadpup!paul
jv@mh.nl (Johan Vromans) (03/05/89)
In article <447@lakart.UUCP> dg@lakart.UUCP (David Goodenough) writes: >Is there any _REAL_ difference between: > > while (a < 25) > { > ..... > } >AND: >100 REM start "while A < 25" loop >110 if A >= 25 then goto 200 >120 ..... >190 goto 110 >200 REM exit "while A < 25" loop > YES. The main difference is that in the BASIC program the "descriptive comments" and the program semantics are not related. You may change the semantics, or the comment, or both, depending on discipline and haste. (Is your boss pushing you? Don't change comments - it only takes more time.) BUT it helps to have comments like the one shown above when trying to figure out program semantics. If they are consistent. -- Johan Vromans jv@mh.nl via european backbone (mcvax) Multihouse [A-Za-z ]* [NB]V uucp: ..!mcvax!mh.nl!jv Gouda - The Netherlands phone: +31 1820 62944