Writing operators vs. writing procedures 
Author Message
 Writing operators vs. writing procedures

First of all, hello everybody, I've been lurking the last few days
and I see names of old friends and acquaintances.  I've been so busy
for the last year that I haven't had time for the net.

Mike Haas has been making points about being held to a 16-line
size for colon definitions.  For my own part, I spent most of my Forth
years on an S-100 machine with fig-Forth, and I learned to work very
comfortably within the confines of a screen-based paradigm.  Nowadays
I code in Forth under Unix and MS-DOS, and I use a file-based system.  I've
carried my coding style (short routines) into the new environments.

I think it's a matter of programmers getting used to features, and indeed,
misfeatures of their programming environments.  "He never had feature x,
so he couldn't see the need for it; then he got feature x, and he couldn't
work without it."  I felt that the 16-line maximum convenient size was limiting,
but now I'm glad for the rigor of thought that it imposed.

Anyway, I feel that the real issue here is that extensible languages
suggest a different programming approach: the programmer first creates
an extension to the language to effectively talk about the problem at hand,
and then uses that extension to implement a solution.

I tend to write tiny snippets of code which resemble operators more than
procedures.  These operators become a rich toolbox with which to code the
higher levels.  Of course, at some point one has to write procedures, and
I am always looking for runs of code in the procedures which can be turned
into operators -- no different from normal factoring of code.

Encouraging beginning Forth programmers to try and code operators, not
procedures, has proved be an effective way to transition C/Pascal/fortran
programmers into good Forth coding habits.

--
Marc de Groot (KG6KF) San Francisco |

UUCP: ..!uunet!hoptoad!noe!marc     |          cents for your paradigm."



Mon, 11 Sep 1995 04:28:48 GMT  
 Writing operators vs. writing procedures

Hi, Marc, long time no chat.  Hope I see ya at Worldcon!  Anyway, back
to the topic at hand.

[due to the size constraints of BLOCKS in early Forth systems]

Quote:
>I tend to write tiny snippets of code which resemble operators more than
>procedures.  These operators become a rich toolbox with which to code the
>higher levels.  Of course, at some point one has to write procedures, and
>I am always looking for runs of code in the procedures which can be turned
>into operators -- no different from normal factoring of code.
>Encouraging beginning Forth programmers to try and code operators, not
>procedures, has proved be an effective way to transition C/Pascal/Fortran
>programmers into good Forth coding habits.

This is a good point (and one that is often raised by proponents of
BLOCKs, rather than stream files).  And it's one that I basically agree
with.  Forth programs *should* be written by creating small operators to
extend the language, and the final program should be written in this
"new language".  And the constraints of blocks to tend to help newbies
discover the power of many small, short definitions.

OTOT, there are times when stuff just ain't gonna fit on a block.
Especially tables of data and such.  Or large assembly routines.  Such
things can be spread across several blocks, but this is often a PITA.

And the "right" size for a procedure or function or word or whatever is
just that, the "right size."  There's no other real criteria.  If the
right size for a particular function happens to be 17 lines, well, there
it is.  Three lines may *usually* be the right size in Forth, but if it
ain't, you're stuck.  :-)

On the third tentacle, blocks are useful for many things that are hard
to do with stream files, e.g. simple virtual memory management.  I've
done things with blocks that would be a royal PITA with stream files.
Not impossible, just a PITA.

Which is why I advocate having both.  Streams are the mainstream
paradigm, and are useful for many things that blocks are not useful for,
but blocks definitely have their uses as well.

OC, if stream files are available, newbies are likely to use them, and
less likely to learn elegant Forth coding styles (styles that are often
useful in other languages as well, as Marc pointed out).  But they're
just too darn useful for an experienced programmer for me to be willing
to give them up.  So, perhaps, education is the only answer.  Get more
books like "Thinking Forth" out there--books not about the gritty
details of programming in Forth, but the *style* of Forth.
--
Chris Waters    | the insane don't | "Pfui!"  -- Nero Wolfe



Tue, 12 Sep 1995 04:00:39 GMT  
 
 [ 2 post ] 

 Relevant Pages 

1. 'Write attribute vs Write procedure.

2. Automate Writing Stored Procedure

3. self-booting pmode program written in assembler written in sh

4. LORAX -- new Red Hat installation procedure written in Python

5. REXX procedures to write Excel files?

6. Clarification: read/write slow, and TCPSocket and sys{read,write}

7. read/write slow, and TCPSocket and sys{read,write}

8. FST Write procedure

9. Accessing the source code of (self written) procedures?

10. PLT scheme - writing a procedure with state?

11. Using write procedure with a string parameter.

12. Problem with microprocessor read/write procedure

 

 
Powered by phpBB® Forum Software