waynekn@tekig5.UUCP (Wayne Knapp) (09/04/85)
{{{{{{{{{{{{{munch}}}}}}}}}}}} Brodie's ideas are for the birds. (from the book Thinking Forth) I for one think writing my code in 1k blocks is stupid. I really can't believe that variable lenghts files promote bad code. So does anyone else feel the same. Has anyone written a screen editor that avoids the 1k blocks? If so and it is in the public domain, I would really like a copy. About Brodie's ideas. His views about dictionarys - Not only Forth, what about lisp, smalltalk prolog. Not a new idea. About editors - completely all wet About control strutures - I have to wonder if Brodie has ever really written any code. I've never seen block strutured code as badly written as his examples. I suggest that if you want to read the book "Thinking Forth", that you should check it out from a libarary. Don't waste any money on it. The book starts out fine, but by the middle of the book Brodie gone over the deep end. Parts of the book read like they were written by a mad man, or at least by someone who hasn't done any real programming. By the way, I do think Forth is neat.
toma@tekchips.UUCP (Tom Almy) (09/05/85)
In article <216@tekig5.UUCP> waynekn@tekig5.UUCP (Wayne Knapp) writes: > >I for one think writing my code in 1k blocks is stupid. Well, I can think of a few good points (but not many): 1. Absolute portability -- does your system delimit lines with a CR, LF, CR-LF pair, or ?? 2. Ease of implementation on simple systems. I can put a complete Forth environment in an 2764 EPROM. To add an ASCII stream file system would probably double the size (figuring increased Editor size as well). 3. The limited number of lines promotes writing of small definitions which are much easier to understand and debug. A standard text editor allows writing terribly huge definitions. Do you want to see a "C" program that has a case statement that is 20 pages long? Drop by, I've got one (I didn't write it, though). >Has anyone written a screen editor that avoids the 1k blocks? If so and it >is in the public domain, I would really like a copy. > Before I started with Forth, I used STOIC. It has the Forth block structure, but for loading purposes treats the blocks like a character stream. A file system is built on top of this, and a TECO-like (sorry) editor is provided. This is public domain, and I could send it to you. Also, MMS-Forth (for IBM-PCs and TRS-80s) has a screen editor called "NOTEPAD" which scrolls over screen boundries. Since it deals with normal Forth screens you still have 64 character files. There are also simple modifications you can make to your Forth system to redirect the console to a file of text. I have done that on most of my outside (of Tektronix) Forths I have implemented in the past four years to appease people that just don't want to fool with screens. You use any arbitrary text editor under the DOS, and then run Forth to load it. Personnally, this is too much like a batch environment for my taste. >About Brodie's ideas. > > His views about dictionarys - Not only Forth, what about lisp, smalltalk > prolog. Not a new idea. Well, only LISP is older than Forth. Nobody gives LISP the credit it deserves anyway (speaking as a former LISP hacker). > > About editors - completely all wet > AMEN! >I suggest that if you want to read the book "Thinking Forth", that you should >check it out from a libarary. Don't waste any money on it. The book starts >out fine, but by the middle of the book Brodie gone over the deep end. Well I think that it is a fine book, even for non-Forth programmers. But it needs to be read as one reads the editorial pages in a newspaper. The book is very SUBJECTIVE and OPINIONATED. But then he admits that in the Preface. My biggest gripe is his hatred of "objects" (pages 89-92), not recognizing their importance in writing correct, understandable code. He is concerned with an imagined lack of control, and his use of the klutzy IBM/PC BIOS as an example was inappropriate. >By the way, I do think Forth is neat. Me too. Tom Almy
rb@ccivax.UUCP (rex ballard) (09/21/85)
> Brodie's ideas are for the birds. (from the book Thinking Forth) I for one > think writing my code in 1k blocks is stupid. >I really can't believe that variable length files promote bad code. Is it possible you have never seen some of the 'C' programming nightmeres or assembler atrocities that come with variable length files? Variable length files let programmers get into some really bad habits like 200 lines between an 'if' and an 'else'! Add to that some loops, some cases, and some 'do forever' loops, and you can have a masterpiece in GIGO. The first version I used had 512 byte block (32x16) screens. Most of my current work is in 'C', but I still have a very 'screen oriented' dialect. I have actually recommended a 'FORTH for C programmers' seminar, just in the hopes that some good habits would rub off. I can't say I'm fanatically fond of 'screens' either, but given that a series of very small definitions can be written in just a few lines each, it is not that hard to live with. It might be nice to have a choice of format's though. One trick that does work is to define newlines, linefeeds... as :;, but it adds to your dictionary space and execution time if you let them appear inside definitions (makes beautification difficult). One option I have worked with was a CP/M version that would let you 'Save' your last definition or the text of the commands entered since the last 'Save', whichever came last, similar to a 'history' command. This meant that you could try various definitions, and when you got a good one, 'Save' it. It involved redefining the line enter definition to CMOVE TIP into a block. You could go back later and add the documentation. I normally avoid getting involved in FORTH discussions, because FORTH people tend to get a little too religeous. Just mention words like subroutine threaded code (very fast on a 6809), or 'infix preprocessor' or even 'object oriented vocabularies', or even binary format files, and you can be called a heritic and a FIG meeting. Still, forth entails a lot of very powerful concepts - many, thanks to Brodie - that are the basic foundations of any fourth generation language (reading 'Forth meets Smalltalk' shows just how close they really are). One very powerful concept is that you can't mainain it if you can't see it. These statements of heresy and all other opinions expressed have nothing in any way to do with Computer Consoles Inc. or it's employees.