Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #52246 > unrolled thread

Programming Style

Back to article view | Back to comp.lang.forth

Contents

  Programming Style rickman <gnuarm@gmail.com> - 2016-10-27 13:01 -0400
    Re: Programming Style Howerd <howerdo@yahoo.co.uk> - 2016-10-27 12:42 -0700
      Re: Programming Style rickman <gnuarm@gmail.com> - 2016-10-29 17:35 -0400
        Re: Programming Style Howerd <howerdo@yahoo.co.uk> - 2016-11-01 02:05 -0700
          Re: Programming Style luser droog <mijoryx@yahoo.com> - 2016-11-02 06:23 -0700
            Re: Programming Style Howerd <howerdo@yahoo.co.uk> - 2016-11-02 09:15 -0700
            Re: Programming Style hughaguilar96@gmail.com - 2016-11-02 12:15 -0700
              Re: Programming Style Howerd <howerdo@yahoo.co.uk> - 2016-11-03 06:40 -0700
                Re: Programming Style alex <alex@rivadpm.com> - 2016-11-03 22:28 +0000
    Re: Programming Style anotherreepca@gmail.com - 2016-11-05 23:01 -0700
      Re: Programming Style Bernd Paysan <bernd@net2o.de> - 2016-11-27 00:18 +0000

#52246 — Programming Style

As I am sure many here know I am only an occasional user of Forth.  I 
mostly use it to write test code for my hardware projects.  I don't 
deliver code to my customers so I am free to use any language I wish.

I find my coding style is heavily influenced by my heavy use of VHDL. 
Forth and VHDL are diametrically opposed in philosophies I think.  So 
I'm curious if my style is what other Forth programmers would use.

I do try to keep my definitions small, but I am not crazy about a huge 
proliferation of words.  Here is an example of one I am writing now.  I 
think it works, but am not able to test it from lack of hardware, so 
there may be bugs.  I'm just curious what people think of this style.


\ format and send write command with u1 as data and u2 as address, 
return error flag
\ TRUE is passed, FALSE is error
: WriteCmd ( u1 u2 -- flag )
     HEX OVER SWAP [char] W FormatCmd2
     DisplayComFlush ComSendStr ComReadEcho
     9 ScanReply <> IF THROW_COMM_WRITE_VERIFY THROW THEN
     TRUE DECIMAL ;


: ReadCmd ( u1 -- u2 ) \ format and send read command with u1 as address
     HEX DUP ReadCmdFmt
     ReadCmdSend
     OVER = IF DROP ELSE ReadVerErr THEN
     6 ScanReply
     DECIMAL
     ;

: VerReadLoop ( reg, n, sel -- )
     SelectCmd 0 DO I OVER WriteCmd DROP
         DUP ReadCmd 2DUP <> IF
             2DUP CR ."*** verify error *** read - " h.
             ."  : expected - " h. THEN
         DROP
     LOOP ;

The words ReadCmd sends a command to read hardware and gets a response 
which is left on the stack.  WriteCmd is similar, but verifies the 
command was received correctly and leaves a flag on the stack.

I'm not providing code for the lower words because they were written at 
a time when I didn't trust my system comms and added a *lot* of error 
checking code.  I found the problem in the hardware and some of the 
error checking got ripped out while other remains.  It is pretty 
inconsistent and ugly.  No time or need to fix it now as the test system 
is being used for the last time now.

-- 

Rick C

[toc] | [next] | [standalone]

#52252

On Thursday, 27 October 2016 19:01:36 UTC+2, rickman  wrote:
> As I am sure many here know I am only an occasional user of Forth.  I 
> mostly use it to write test code for my hardware projects.  I don't 
> deliver code to my customers so I am free to use any language I wish.
> 
> I find my coding style is heavily influenced by my heavy use of VHDL. 
> Forth and VHDL are diametrically opposed in philosophies I think.  So 
> I'm curious if my style is what other Forth programmers would use.
> 
> I do try to keep my definitions small, but I am not crazy about a huge 
> proliferation of words.  Here is an example of one I am writing now.  I 
> think it works, but am not able to test it from lack of hardware, so 
> there may be bugs.  I'm just curious what people think of this style.
> 
> 
> \ format and send write command with u1 as data and u2 as address, 
> return error flag
> \ TRUE is passed, FALSE is error
> : WriteCmd ( u1 u2 -- flag )
>      HEX OVER SWAP [char] W FormatCmd2
>      DisplayComFlush ComSendStr ComReadEcho
>      9 ScanReply <> IF THROW_COMM_WRITE_VERIFY THROW THEN
>      TRUE DECIMAL ;
> 
> 
> : ReadCmd ( u1 -- u2 ) \ format and send read command with u1 as address
>      HEX DUP ReadCmdFmt
>      ReadCmdSend
>      OVER = IF DROP ELSE ReadVerErr THEN
>      6 ScanReply
>      DECIMAL
>      ;
> 
> : VerReadLoop ( reg, n, sel -- )
>      SelectCmd 0 DO I OVER WriteCmd DROP
>          DUP ReadCmd 2DUP <> IF
>              2DUP CR ."*** verify error *** read - " h.
>              ."  : expected - " h. THEN
>          DROP
>      LOOP ;
> 
> The words ReadCmd sends a command to read hardware and gets a response 
> which is left on the stack.  WriteCmd is similar, but verifies the 
> command was received correctly and leaves a flag on the stack.
> 
> I'm not providing code for the lower words because they were written at 
> a time when I didn't trust my system comms and added a *lot* of error 
> checking code.  I found the problem in the hardware and some of the 
> error checking got ripped out while other remains.  It is pretty 
> inconsistent and ugly.  No time or need to fix it now as the test system 
> is being used for the last time now.
> 
> -- 
> 
> Rick C

Hi Rick,

Your code looks a lot like any of my code - the important thing is that you have defined the two interface words that you can test independently, then a test loop that calls them. 

The fact that you re-wrote your first version is also very Forth-like ;-)

My style of Forth is very user-centric - give the user what they need to talk to the hardware - then improve it until you run out of time or get bored...

Testing hardware like this is amazingly more productive that the usual C/Eclipse/IDE style where you spend so much time constructing a test harness that you have forgotten what you were trying to test. Well I have forgotten it, anyways.

Best regards,
Howerd

[toc] | [prev] | [next] | [standalone]

#52292

On 10/27/2016 3:42 PM, Howerd wrote:
> On Thursday, 27 October 2016 19:01:36 UTC+2, rickman  wrote:
>> As I am sure many here know I am only an occasional user of Forth.  I
>> mostly use it to write test code for my hardware projects.  I don't
>> deliver code to my customers so I am free to use any language I wish.
>>
>> I find my coding style is heavily influenced by my heavy use of VHDL.
>> Forth and VHDL are diametrically opposed in philosophies I think.  So
>> I'm curious if my style is what other Forth programmers would use.
>>
>> I do try to keep my definitions small, but I am not crazy about a huge
>> proliferation of words.  Here is an example of one I am writing now.  I
>> think it works, but am not able to test it from lack of hardware, so
>> there may be bugs.  I'm just curious what people think of this style.
>>
>>
>> \ format and send write command with u1 as data and u2 as address,
>> return error flag
>> \ TRUE is passed, FALSE is error
>> : WriteCmd ( u1 u2 -- flag )
>>      HEX OVER SWAP [char] W FormatCmd2
>>      DisplayComFlush ComSendStr ComReadEcho
>>      9 ScanReply <> IF THROW_COMM_WRITE_VERIFY THROW THEN
>>      TRUE DECIMAL ;
>>
>>
>> : ReadCmd ( u1 -- u2 ) \ format and send read command with u1 as address
>>      HEX DUP ReadCmdFmt
>>      ReadCmdSend
>>      OVER = IF DROP ELSE ReadVerErr THEN
>>      6 ScanReply
>>      DECIMAL
>>      ;
>>
>> : VerReadLoop ( reg, n, sel -- )
>>      SelectCmd 0 DO I OVER WriteCmd DROP
>>          DUP ReadCmd 2DUP <> IF
>>              2DUP CR ."*** verify error *** read - " h.
>>              ."  : expected - " h. THEN
>>          DROP
>>      LOOP ;
>>
>> The words ReadCmd sends a command to read hardware and gets a response
>> which is left on the stack.  WriteCmd is similar, but verifies the
>> command was received correctly and leaves a flag on the stack.
>>
>> I'm not providing code for the lower words because they were written at
>> a time when I didn't trust my system comms and added a *lot* of error
>> checking code.  I found the problem in the hardware and some of the
>> error checking got ripped out while other remains.  It is pretty
>> inconsistent and ugly.  No time or need to fix it now as the test system
>> is being used for the last time now.
>>
>> --
>>
>> Rick C
>
> Hi Rick,
>
> Your code looks a lot like any of my code - the important thing is that you have defined the two interface words that you can test independently, then a test loop that calls them.
>
> The fact that you re-wrote your first version is also very Forth-like ;-)
>
> My style of Forth is very user-centric - give the user what they need to talk to the hardware - then improve it until you run out of time or get bored...
>
> Testing hardware like this is amazingly more productive that the usual C/Eclipse/IDE style where you spend so much time constructing a test harness that you have forgotten what you were trying to test. Well I have forgotten it, anyways.
>
> Best regards,
> Howerd

This was prompted by a problem with the test fixture for the boards I 
build (or have built for me actually).  I went up to the contract 
assembler yesterday and ran some of the test code and found the problem. 
  The most likely candidate for problems is always the 
electro-mechanical parts.  The test code created a repetitive pattern on 
the signals of interest so I could follow the path which led back to the 
FPGA.  So the culprit seemed to be the FPGA.  Replacing that required 
flashing the new part and this hasn't been done in some six years, which 
means there's always a chance I didn't have the right version (I've lost 
two computers in that time).  I verify showed the existing FPGA contents 
matched the file I had, so we were good to go.

The assembly folks replaced the part, I reprogrammed it and we were able 
to continue to test boards.  :)

The test guy was interested in what I was using so I tried explaining 
Forth to him.  He had used C and C++ but didn't seem to have a great 
perspective on it all as he was asking me if I was doing "Windows" 
programming.  So I showed him how easy it was to define new words, but 
I'm not sure it sunk in.

-- 

Rick C

[toc] | [prev] | [next] | [standalone]

#52374

On Saturday, 29 October 2016 23:35:08 UTC+2, rickman  wrote:
> On 10/27/2016 3:42 PM, Howerd wrote:
> > On Thursday, 27 October 2016 19:01:36 UTC+2, rickman  wrote:
> >> As I am sure many here know I am only an occasional user of Forth.  I
> >> mostly use it to write test code for my hardware projects.  I don't
> >> deliver code to my customers so I am free to use any language I wish.
> >>
> >> I find my coding style is heavily influenced by my heavy use of VHDL.
> >> Forth and VHDL are diametrically opposed in philosophies I think.  So
> >> I'm curious if my style is what other Forth programmers would use.
> >>
> >> I do try to keep my definitions small, but I am not crazy about a huge
> >> proliferation of words.  Here is an example of one I am writing now.  I
> >> think it works, but am not able to test it from lack of hardware, so
> >> there may be bugs.  I'm just curious what people think of this style.
> >>
> >>
> >> \ format and send write command with u1 as data and u2 as address,
> >> return error flag
> >> \ TRUE is passed, FALSE is error
> >> : WriteCmd ( u1 u2 -- flag )
> >>      HEX OVER SWAP [char] W FormatCmd2
> >>      DisplayComFlush ComSendStr ComReadEcho
> >>      9 ScanReply <> IF THROW_COMM_WRITE_VERIFY THROW THEN
> >>      TRUE DECIMAL ;
> >>
> >>
> >> : ReadCmd ( u1 -- u2 ) \ format and send read command with u1 as address
> >>      HEX DUP ReadCmdFmt
> >>      ReadCmdSend
> >>      OVER = IF DROP ELSE ReadVerErr THEN
> >>      6 ScanReply
> >>      DECIMAL
> >>      ;
> >>
> >> : VerReadLoop ( reg, n, sel -- )
> >>      SelectCmd 0 DO I OVER WriteCmd DROP
> >>          DUP ReadCmd 2DUP <> IF
> >>              2DUP CR ."*** verify error *** read - " h.
> >>              ."  : expected - " h. THEN
> >>          DROP
> >>      LOOP ;
> >>
> >> The words ReadCmd sends a command to read hardware and gets a response
> >> which is left on the stack.  WriteCmd is similar, but verifies the
> >> command was received correctly and leaves a flag on the stack.
> >>
> >> I'm not providing code for the lower words because they were written at
> >> a time when I didn't trust my system comms and added a *lot* of error
> >> checking code.  I found the problem in the hardware and some of the
> >> error checking got ripped out while other remains.  It is pretty
> >> inconsistent and ugly.  No time or need to fix it now as the test system
> >> is being used for the last time now.
> >>
> >> --
> >>
> >> Rick C
> >
> > Hi Rick,
> >
> > Your code looks a lot like any of my code - the important thing is that you have defined the two interface words that you can test independently, then a test loop that calls them.
> >
> > The fact that you re-wrote your first version is also very Forth-like ;-)
> >
> > My style of Forth is very user-centric - give the user what they need to talk to the hardware - then improve it until you run out of time or get bored...
> >
> > Testing hardware like this is amazingly more productive that the usual C/Eclipse/IDE style where you spend so much time constructing a test harness that you have forgotten what you were trying to test. Well I have forgotten it, anyways.
> >
> > Best regards,
> > Howerd
> 
> This was prompted by a problem with the test fixture for the boards I 
> build (or have built for me actually).  I went up to the contract 
> assembler yesterday and ran some of the test code and found the problem. 
>   The most likely candidate for problems is always the 
> electro-mechanical parts.  The test code created a repetitive pattern on 
> the signals of interest so I could follow the path which led back to the 
> FPGA.  So the culprit seemed to be the FPGA.  Replacing that required 
> flashing the new part and this hasn't been done in some six years, which 
> means there's always a chance I didn't have the right version (I've lost 
> two computers in that time).  I verify showed the existing FPGA contents 
> matched the file I had, so we were good to go.
> 
> The assembly folks replaced the part, I reprogrammed it and we were able 
> to continue to test boards.  :)
> 
> The test guy was interested in what I was using so I tried explaining 
> Forth to him.  He had used C and C++ but didn't seem to have a great 
> perspective on it all as he was asking me if I was doing "Windows" 
> programming.  So I showed him how easy it was to define new words, but 
> I'm not sure it sunk in.
> 
> -- 
> 
> Rick C

Hi Rick,

Your story reflects my experience too : many times I have worked with people, done something whizzy in Forth, and been surprised by the lack of interest. 

My explanation is that human beings are much more like Captain Kirk than Mr. Spock - The Vulcan is always mystified by the seemingly irrational choices made by his human friends...

Maybe it is also because there are different types of people, some of whom (like myself) see Forth and are immediately hooked for life, in spite of enormous peer pressure to the contrary (at least in a work environment), and some can work with Forth for years and never really get the point.
Just one of life's more intriguing mysteries...

My most recent fun exploit with Forth was a few months ago when I was working for a major Smart Meter company, together with some really bright colleagues. I was assigned the task of converting a somewhat large requirements document (actually three of them, with two of them as HTML files embedded in the third file) into C format headers and script files. Rather than do this manually for the five test cases I was given, I decided to parse the document and produce the output files automatically for all 400+ test cases, using Forth, of course.
I produced the five test cases, early, and gave them to my colleague, who then asked what I was using - he was quite curious. I showed him my SwiftForth program in action - I forget the exact words that he used, but he was totally amazed that it was possible to do this in just a couple of days.
So another fun experience in Forth - thanks Chuck :-)

Best regards,
Howerd

[toc] | [prev] | [next] | [standalone]

#52398

On Tuesday, November 1, 2016 at 4:05:55 AM UTC-5, Howerd wrote:

> Your story reflects my experience too : many times I have worked with people, done something whizzy in Forth, and been surprised by the lack of interest. 
> 

I respectfully suggest that you may be inappropriately extrapolating
from a "lack of response" to "lack of interest". For example, I felt
similarly after posting an idea for a new control structure for
PostScript. A few months later, somebody /had/ taken idea in a
formidably impressive new direction.

https://groups.google.com/d/topic/comp.lang.postscript/3gP89-WCRdY/discussion

Interest may take some time to accrue.

[toc] | [prev] | [next] | [standalone]

#52402

On Wednesday, 2 November 2016 14:23:13 UTC+1, luser droog  wrote:
> On Tuesday, November 1, 2016 at 4:05:55 AM UTC-5, Howerd wrote:
> 
> > Your story reflects my experience too : many times I have worked with people, done something whizzy in Forth, and been surprised by the lack of interest. 
> > 
> 
> I respectfully suggest that you may be inappropriately extrapolating
> from a "lack of response" to "lack of interest". For example, I felt
> similarly after posting an idea for a new control structure for
> PostScript. A few months later, somebody /had/ taken idea in a
> formidably impressive new direction.
> 
> https://groups.google.com/d/topic/comp.lang.postscript/3gP89-WCRdY/discussion
> 
> Interest may take some time to accrue.

Hi luser,

You are probably correct :-)
My cynicism is increasing with age...

Best regards,
Howerd

[toc] | [prev] | [next] | [standalone]

#52406

On Wednesday, November 2, 2016 at 6:23:13 AM UTC-7, luser droog wrote:
> On Tuesday, November 1, 2016 at 4:05:55 AM UTC-5, Howerd wrote:
> 
> > Your story reflects my experience too : many times I have worked with people, done something whizzy in Forth, and been surprised by the lack of interest. 
> > 
> 
> I respectfully suggest that you may be inappropriately extrapolating
> from a "lack of response" to "lack of interest". For example, I felt
> similarly after posting an idea for a new control structure for
> PostScript. A few months later, somebody /had/ taken idea in a
> formidably impressive new direction.
> 
> https://groups.google.com/d/topic/comp.lang.postscript/3gP89-WCRdY/discussion
> 
> Interest may take some time to accrue.

What happens in practice is that a negative response is instantaneous. It only takes seconds for a troll to say that your code "sucks" and is "crap" etc., and it requires no mental effort, or even sobriety.

A positive response takes time to build up, and it takes mental effort because the person has to acquire an understanding of what your code does. By the time that the person has invested all of this mental effort, he has also built up a desire for 100% of the credit --- also, if the person is using this code on the job, then the code has become proprietary to his employer so he can't discuss it publicly without getting in trouble from his boss --- so, for the most part, a positive response will never happen and only a flood of negative responses will occur.

[toc] | [prev] | [next] | [standalone]

#52411

On Wednesday, 2 November 2016 20:15:41 UTC+1, hughag...@gmail.com  wrote:
> On Wednesday, November 2, 2016 at 6:23:13 AM UTC-7, luser droog wrote:
> > On Tuesday, November 1, 2016 at 4:05:55 AM UTC-5, Howerd wrote:
> > 
> > > Your story reflects my experience too : many times I have worked with people, done something whizzy in Forth, and been surprised by the lack of interest. 
> > > 
> > 
> > I respectfully suggest that you may be inappropriately extrapolating
> > from a "lack of response" to "lack of interest". For example, I felt
> > similarly after posting an idea for a new control structure for
> > PostScript. A few months later, somebody /had/ taken idea in a
> > formidably impressive new direction.
> > 
> > https://groups.google.com/d/topic/comp.lang.postscript/3gP89-WCRdY/discussion
> > 
> > Interest may take some time to accrue.
> 
> What happens in practice is that a negative response is instantaneous. It only takes seconds for a troll to say that your code "sucks" and is "crap" etc., and it requires no mental effort, or even sobriety.
> 
> A positive response takes time to build up, and it takes mental effort because the person has to acquire an understanding of what your code does. By the time that the person has invested all of this mental effort, he has also built up a desire for 100% of the credit --- also, if the person is using this code on the job, then the code has become proprietary to his employer so he can't discuss it publicly without getting in trouble from his boss --- so, for the most part, a positive response will never happen and only a flood of negative responses will occur.

Hi Hugh,

You are making several points here, some of which I agree with :

1. > A positive response takes time to build up, and it takes mental effort because 
> the person has to acquire an understanding of what your code does.
I agree.

2. > By the time that the person has invested all of this mental effort, he has also 
> built up a desire for 100% of the credit
Not sure about this - some people are happy to give credit where credit is due.
 
3. > if the person is using this code on the job, then the code has become 
> proprietary to his employer so he can't discuss it publicly without getting in 
> trouble from his boss
This is certainly the case for production code.

4. > so, for the most part, a positive response will never happen and only a flood of
> negative responses will occur
I saw the phrase "cultural vandalism" applied to the conspiracy theory that the Apollo moon landings were fake, and there is a subset of the population who like nonsensical theories like that because they support their negative world view.
I think this also applies to software concepts that go against a person's viewpoint - it is often easier to attack than to investigate what the truth actually is.

Best regards,
Howerd

[toc] | [prev] | [next] | [standalone]

#52423

On 03/11/16 13:40, Howerd wrote:
> On Wednesday, 2 November 2016 20:15:41 UTC+1, hughag...@gmail.com  wrote:

>
> 2. > By the time that the person has invested all of this mental effort, he has also
>> built up a desire for 100% of the credit
> Not sure about this - some people are happy to give credit where credit is due.

Most, in my experience.

>
> 3. > if the person is using this code on the job, then the code has become
>> proprietary to his employer so he can't discuss it publicly without getting in
>> trouble from his boss
> This is certainly the case for production code.

Many companies (mine included) contribute huge amounts of code (and 
time, and money) into supporting open source initiatives. An example; 
OpenStack.

-- 
Alex

[toc] | [prev] | [next] | [standalone]

#52455

I find myself struggling to decide between writing factors for reusability and writing factors for clarity (here read "sanity"). One of the advantages of factoring I see listed a lot is smaller code size due to reuse, but at the same time I can see that making a word too general makes it a huge pain to write and debug. How does one make the decision? It seems to me that it's usually better to favor clarity in higher-level words, and that usually works, except when dealing with low-level string stuff that involves iterating through them (there's just sooo many things on the stack to deal with...).

[toc] | [prev] | [next] | [standalone]

#52884

Am Sat, 05 Nov 2016 23:01:38 -0700 schrieb anotherreepca:

> I find myself struggling to decide between writing factors for
> reusability and writing factors for clarity (here read "sanity"). One of
> the advantages of factoring I see listed a lot is smaller code size due
> to reuse, but at the same time I can see that making a word too general
> makes it a huge pain to write and debug. How does one make the decision?
> It seems to me that it's usually better to favor clarity in higher-level
> words, and that usually works, except when dealing with low-level string
> stuff that involves iterating through them (there's just sooo many
> things on the stack to deal with...).

Download Thinking Forth if you need some longer text.  Here just a few 
words:

Don't overgeneralize. Factors are potentially reusable, they don't have 
to be reusable for cases you don't yet know.  If you have a word that's 
only reusable by making changes to it, you'll probably end up with a 
common factor and the uncommon parts.

Factoring for clarity is a good goal.  Reusability may just come on its 
own.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.forth

csiph-web