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

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

how do forthers control compexity and make easy user interfaces?

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

Contents

  how do forthers control compexity and make easy user interfaces? the_gavino_himself <visphatesjava@gmail.com> - 2013-12-25 21:54 -0800
    Re: how do forthers control compexity and make easy user interfaces? Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2013-12-26 10:16 +0000
      How to specify complex code? mhx@iae.nl - 2013-12-26 02:52 -0800
        Re: How to specify complex code? ForthFreak <forthfreak@gmail.com> - 2013-12-26 03:45 -0800
          Re: How to specify complex code? mhx@iae.nl - 2013-12-26 05:20 -0800
        Re: How to specify complex code? Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2013-12-26 22:34 +0000
          Re: How to specify complex code? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2013-12-27 01:07 -0500
            Re: How to specify complex code? Mark Wills <markrobertwills@yahoo.co.uk> - 2013-12-27 02:20 -0800
            Re: How to specify complex code? Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2013-12-27 12:27 +0000
      Re: how do forthers control compexity and make easy user interfaces? Richard Owlett <rowlett@pcnetinc.com> - 2013-12-26 06:54 -0600
        Re: how do forthers control compexity and make easy user interfaces? Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2013-12-26 22:37 +0000
      Re: how do forthers control compexity and make easy user interfaces? Spam@ControlQ.com - 2013-12-27 17:13 -0500
      Re: how do forthers control compexity and make easy user interfaces? the_gavino_himself <visphatesjava@gmail.com> - 2013-12-31 17:34 -0800
    Re: how do forthers control compexity and make easy user interfaces? Richard Owlett <rowlett@pcnetinc.com> - 2013-12-26 06:52 -0600
      Re: how do forthers control compexity and make easy user interfaces? the_gavino_himself <visphatesjava@gmail.com> - 2013-12-31 17:42 -0800

#27445 — how do forthers control compexity and make easy user interfaces?

two problem I have a tuff time with

[toc] | [next] | [standalone]

#27447

the_gavino_himself wrote:

> two problem I have a tuff time with

The complexity and user interface problems are two that really should be 
resolved long before you start coding. I deal with Industrial Control 
Systems and have used quite a bit of the Forth Philosophy which actually 
seems to have come from the mathematical philosophy of George Polya (see 
"How to Solve It" by George Polya published in 1945).

From getting the true goals of the customer I usually perform a Task 
Analysis first, to ensure that I know all the sequence of actions that the 
User and the Systems is going to have to perform. As my systems ar often 
Safety Critical I will run a HAZOP analysis at this stage and adjust the 
resultant task plan and re-analyse both the task plan and HAZOP. It is here 
that you make your first decompositions of the problem space and begin to 
see the natural structure of the resultant system.

I write descriptive documents for the system (functional specifications etc) 
and when the custoimer agrees I proceed with further decomposition of the 
system following the naturally emerging stucture.

When it come to the software portion I begin at the higher level (user 
visible functions) and write the glossary commentary for the words that are 
natural language in the problem domain, attaching those comments to each of 
those words of the Application Specific Language. I write no code at this 
level, just the comments for each word I decide will make sense in 
fulfilling the functions. Eventually I descend the levels of abstraction 
towards meeting words that look like they would appear in a standard Forth. 
All through this activity there are regular reviews to ensure that the whole 
intent of the system is coherent, meets with the customer requirements for 
function and has notes relating to the related fault actions (time-out 
periods, mis-entered data etc).

When I am close to approaching the level of words in a Standard Forth I can 
then start fleshing out the words with code, starting at the bottom and 
working up the levels. I functionally test immediately after coding. Reviews 
continue of this code and ther begins formal inspections, functional tests 
and limitations testing as the system builds from the bottom. These reviews 
ensure that the coded implentation performs the requirements (comments) as 
specified. When you get to the top you should have the whole system, no 
matter how complex it started, written and able to perform as it should. 

When I was developing one application in view of the client it came to a 
point that the client started to see new opportunities he could explore as 
the Application Specific Language was familiar to him already. That was a 
system I sealed at a level just below his ASL and allowed him the freedom to 
generate his own new functionality (not a safety critical application). Most 
of teh other applications get sealed into the system and there are no user 
changeable elements.

So, to control complexity and make user interfaces easier you have to start 
outside the software with the rest of the system and make sure that you have 
understood the cusomer needs well enough. Then decompose the problem space 
from the complex problem to a set of much smaller ones. Solving lots of 
smaller, simpler problems is easier than trying to get your head around a 
much more complex one.

With that, Merry Christmas Gavino. May you get to grips with writing some 
code soon. You can always try a small problem out and post your efforts for 
helpful commentary.

-- 
********************************************************************
Paul E. Bennett IEng MIET.....<email://Paul_E.Bennett@topmail.co.uk>
Forth based HIDECS Consultancy.............<http://www.hidecs.co.uk>
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-510979
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************

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

#27448 — How to specify complex code?

On Thursday, December 26, 2013 11:16:15 AM UTC+1, Paul E Bennett wrote:
how do forthers control compexity and make easy user interfaces?

> The complexity and user interface problems are two that really should be 
> resolved long before you start coding. I deal with Industrial Control 
> Systems and have used quite a bit of the Forth Philosophy which actually 
> seems to have come from the mathematical philosophy of George Polya (see 
> "How to Solve It" by George Polya published in 1945).
[..]
> When it come to the software portion I begin at the higher level (user 
> visible functions) and write the glossary commentary for the words that are 
> natural language in the problem domain, attaching those comments to each of 
> those words of the Application Specific Language. I write no code at this 
> level, just the comments for each word I decide will make sense in 
> fulfilling the functions. 
[..]

You make it all sound so easy and natural :-)

I guess that *after* the specification phase one may find out 
that the Forth, or the hardware it runs on, or the I/O drivers, or
a special combination of the above, ..., cannot meet [real-time] 
specifications. How do you handle this? You may need to compute /
simulate during decomposition which of several alternative
(implementation) branches should be chosen?

Another problem is parallel task execution (does it fit your framework 
at all?). The given problem may become so complex that it is not 
feasible (or efficient) to think through all possible states. This 
becomes even worse if code branches into libraries that are not 
specified correctly, incompletely, not at all, or not in source?

Another problem I can think of: say there is a constraint on power 
dissipation for the computing hardware, or worse, a constraint on 
battery-life for the whole (portable, medical, application)? I am
sure you encounter such problems very frequently?

A nice contractual obligation I read recently: "The design should 
be proven and run reliable for 10 years (250 FIT). The hardware 
(they mean the processor -mhx) must be state-of-the-art.

-marcel

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

#27452 — Re: How to specify complex code?

On Thursday, 26 December 2013 10:52:45 UTC, m...@iae.nl  wrote:
> On Thursday, December 26, 2013 11:16:15 AM UTC+1, Paul E Bennett wrote:
> 
> how do forthers control compexity and make easy user interfaces?
> 
> 
> 
> > The complexity and user interface problems are two that really should be 
> 
> > resolved long before you start coding. I deal with Industrial Control 
> 
> > Systems and have used quite a bit of the Forth Philosophy which actually 
> 
> > seems to have come from the mathematical philosophy of George Polya (see 
> 
> > "How to Solve It" by George Polya published in 1945).
> 
> [..]
> 
> > When it come to the software portion I begin at the higher level (user 
> 
> > visible functions) and write the glossary commentary for the words that are 
> 
> > natural language in the problem domain, attaching those comments to each of 
> 
> > those words of the Application Specific Language. I write no code at this 
> 
> > level, just the comments for each word I decide will make sense in 
> 
> > fulfilling the functions. 
> 
> [..]
> 
> 
> 
> You make it all sound so easy and natural :-)
> 
> 
> 
> I guess that *after* the specification phase one may find out 
> 
> that the Forth, or the hardware it runs on, or the I/O drivers, or
> 
> a special combination of the above, ..., cannot meet [real-time] 
> 
> specifications. How do you handle this? You may need to compute /
> 
> simulate during decomposition which of several alternative
> 
> (implementation) branches should be chosen?
> 
> 
> 
> Another problem is parallel task execution (does it fit your framework 
> 
> at all?). The given problem may become so complex that it is not 
> 
> feasible (or efficient) to think through all possible states. This 
> 
> becomes even worse if code branches into libraries that are not 
> 
> specified correctly, incompletely, not at all, or not in source?
> 
> 
> 
> Another problem I can think of: say there is a constraint on power 
> 
> dissipation for the computing hardware, or worse, a constraint on 
> 
> battery-life for the whole (portable, medical, application)? I am
> 
> sure you encounter such problems very frequently?
> 
> 
> 
> A nice contractual obligation I read recently: "The design should 
> 
> be proven and run reliable for 10 years (250 FIT). The hardware 
> 
> (they mean the processor -mhx) must be state-of-the-art.
> 
> 
> 
> -marcel

Often, constraints applied by the client are arbitrary, and when pressed, they will sometimes not have an answer as to why a particular constraint exists, providing an ideal opportunity to negotiate the requirement/constraint away. This forms a large part of my day-job these days; reading client specifications and raising clarifications, exceptions, and deviations.

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

#27455 — Re: How to specify complex code?

On Thursday, December 26, 2013 12:45:12 PM UTC+1, ForthFreak wrote:
> On Thursday, 26 December 2013 10:52:45 UTC, m...@iae.nl  wrote:
> > On Thursday, December 26, 2013 11:16:15 AM UTC+1, Paul E Bennett wrote:
> > how do forthers control compexity and make easy user interfaces?
> 
> > > The complexity and user interface problems are two that really should be 
> > > resolved long before you start coding. I deal with Industrial Control 
> > > Systems and have used quite a bit of the Forth Philosophy which actually 
> > > seems to have come from the mathematical philosophy of George Polya (see 
> > > "How to Solve It" by George Polya published in 1945).
[..]
> Often, constraints applied by the client are arbitrary, and when pressed, 
> they will sometimes not have an answer as to why a particular constraint 
> exists, providing an ideal opportunity to negotiate the equirement/constraint
> away. This forms a large part of my day-job these days; reading client 
> specifications and raising clarifications, exceptions, and deviations.

Of course. But the technical problems I listed are real. 
What do you do in those cases?

-marcel

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

#27465 — Re: How to specify complex code?

mhx@iae.nl wrote:

> On Thursday, December 26, 2013 11:16:15 AM UTC+1, Paul E Bennett wrote:
> how do forthers control compexity and make easy user interfaces?
> 
>> The complexity and user interface problems are two that really should be
>> resolved long before you start coding. I deal with Industrial Control
>> Systems and have used quite a bit of the Forth Philosophy which actually
>> seems to have come from the mathematical philosophy of George Polya (see
>> "How to Solve It" by George Polya published in 1945).
> [..]
>> When it come to the software portion I begin at the higher level (user
>> visible functions) and write the glossary commentary for the words that
>> are natural language in the problem domain, attaching those comments to
>> each of those words of the Application Specific Language. I write no code
>> at this level, just the comments for each word I decide will make sense
>> in fulfilling the functions.
> [..]
> 
> You make it all sound so easy and natural :-)

It was just a brief (glossed over) account of the general process.
 
> I guess that *after* the specification phase one may find out
> that the Forth, or the hardware it runs on, or the I/O drivers, or
> a special combination of the above, ..., cannot meet [real-time]
> specifications. How do you handle this? You may need to compute /
> simulate during decomposition which of several alternative
> (implementation) branches should be chosen?

I quite often do the software bits first, using software prototypes and just 
generally having a play with some ideas in order to resolve issues and 
improve the technical specification from which to build the system. Some 
decisions about whether a function ends up in hardware or software ar made 
quite a way into the development schedule. Having some quite fast Forth 
processors to hand is helpful in the playtime sessions and you can get to 
know how some activities will be represented at the machine level.
 
> Another problem is parallel task execution (does it fit your framework
> at all?). The given problem may become so complex that it is not
> feasible (or efficient) to think through all possible states. This
> becomes even worse if code branches into libraries that are not
> specified correctly, incompletely, not at all, or not in source?

Issues that you should be dealing with early in the design. Th idea is to 
simplify the problem space so that the implemntation can be constructed of 
simple, very understandable, elements in cooperation. You can also limit the 
effect of some states with proper partitioning and bounding of the system. 
For me, some of the simplification is using more simpler processors than one 
very complex processor.
 
> Another problem I can think of: say there is a constraint on power
> dissipation for the computing hardware, or worse, a constraint on
> battery-life for the whole (portable, medical, application)? I am
> sure you encounter such problems very frequently?

Yes. There are plenty of small low power processors, that collectively 
arranged as a system can often prove more powrful functionally than one 
mega-fast processor and use much less power overall. Again, an aspect that 
can be determined quite easily up-front in the structuring of the system.

> A nice contractual obligation I read recently: "The design should
> be proven and run reliable for 10 years (250 FIT). The hardware
> (they mean the processor -mhx) must be state-of-the-art.

That is why I always say the first Review you do is on the customer's 
requirements specification to ensure that it is:- Clear, Concise, Correct, 
Consistent, Confirmed and Testable. If it does not meet those criteria you 
need to get the ambiguities resolved before proceeding much further into the 
design.

-- 
********************************************************************
Paul E. Bennett IEng MIET.....<email://Paul_E.Bennett@topmail.co.uk>
Forth based HIDECS Consultancy.............<http://www.hidecs.co.uk>
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-510979
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************

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

#27469 — Re: How to specify complex code?

On Thu, 26 Dec 2013 17:34:17 -0500, Paul E Bennett  
<Paul_E.Bennett@topmail.co.uk> wrote:

> [snip]
>
> That is why I always say the first Review you do is on the customer's
> requirements specification to ensure that it is:- Clear, Concise,
> Correct, Consistent, Confirmed and Testable. If it does not meet those
> criteria you need to get the ambiguities resolved before proceeding much
> further into the design.

With one exception, I agree.

It's obvious to me that what you labeled as the first review should
actually be the second review.  The first review should be to check
that the business's employees have made sure their spell checkers
have been enabled, since it's clear yours wasn't:

  compexity -> complexity
  ar -> are
  implemntation -> implementation
  powrful -> powerful

I think those are enough to say you failed to satisfy four of your
stated requirements: "Clear," "Correct," "Concise," and "Confirmed".

Yes?  Or, is there a problem with your 'e' and perhaps 'l' key?  ;-)


Rod Pemberton

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

#27471 — Re: How to specify complex code?

On Friday, December 27, 2013 6:07:34 AM UTC, Rod Pemberton wrote:
> Yes?  Or, is there a problem with your 'e' and perhaps 'l' key?  ;-)

That's what mulled wine does to a man :-)

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

#27475 — Re: How to specify complex code?

Rod Pemberton wrote:

> On Thu, 26 Dec 2013 17:34:17 -0500, Paul E Bennett
> <Paul_E.Bennett@topmail.co.uk> wrote:
> 
>> [snip]
>>
>> That is why I always say the first Review you do is on the customer's
>> requirements specification to ensure that it is:- Clear, Concise,
>> Correct, Consistent, Confirmed and Testable. If it does not meet those
>> criteria you need to get the ambiguities resolved before proceeding much
>> further into the design.
> 
> With one exception, I agree.
> 
> It's obvious to me that what you labeled as the first review should
> actually be the second review.  The first review should be to check
> that the business's employees have made sure their spell checkers
> have been enabled, since it's clear yours wasn't:
> 
>   compexity -> complexity
>   ar -> are
>   implemntation -> implementation
>   powrful -> powerful
> 
> I think those are enough to say you failed to satisfy four of your
> stated requirements: "Clear," "Correct," "Concise," and "Confirmed".
> 
> Yes?  Or, is there a problem with your 'e' and perhaps 'l' key?  ;-)
> 
> 
> Rod Pemberton

The drive was long, the hour was late and the keyboard does misbehave a bit 
when it is a bit cold. You are right that I should probably have read my 
text and corrected the message before posting. Then, I am human and as 
fallable as the next man. Project reviews, however, are always a multi-
person task. 

-- 
********************************************************************
Paul E. Bennett IEng MIET.....<email://Paul_E.Bennett@topmail.co.uk>
Forth based HIDECS Consultancy.............<http://www.hidecs.co.uk>
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-510979
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************

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

#27454

Paul Bennett wrote an excellent outline of problem solving in 
general with an example from programming.

Thank you.

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

#27466

Richard Owlett wrote:

> Paul Bennett wrote an excellent outline of problem solving in
> general with an example from programming.
> 
> Thank you.

I was under the impression programming is really a form of problem solving. 
I just find Forth helps me solve those problems simply and effectively (no 
matter what the end application language may be).

-- 
********************************************************************
Paul E. Bennett IEng MIET.....<email://Paul_E.Bennett@topmail.co.uk>
Forth based HIDECS Consultancy.............<http://www.hidecs.co.uk>
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-510979
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************

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

#27481

On Thu, 26 Dec 2013, Paul E Bennett wrote:

> Date: Thu, 26 Dec 2013 10:16:15 +0000
> From: Paul E Bennett <Paul_E.Bennett@topmail.co.uk>
> Newsgroups: comp.lang.forth
> Subject: Re: how do forthers control compexity and make easy user interfaces?
> 
> the_gavino_himself wrote:
>
>> two problem I have a tuff time with
>
> The complexity and user interface problems are two that really should be
> resolved long before you start coding. I deal with Industrial Control
> Systems and have used quite a bit of the Forth Philosophy which actually
> seems to have come from the mathematical philosophy of George Polya (see
> "How to Solve It" by George Polya published in 1945).
>
> From getting the true goals of the customer I usually perform a Task
> Analysis first, to ensure that I know all the sequence of actions that the
> User and the Systems is going to have to perform. As my systems ar often
> Safety Critical I will run a HAZOP analysis at this stage and adjust the
> resultant task plan and re-analyse both the task plan and HAZOP. It is here
> that you make your first decompositions of the problem space and begin to
> see the natural structure of the resultant system.
>
> I write descriptive documents for the system (functional specifications etc)
> and when the custoimer agrees I proceed with further decomposition of the
> system following the naturally emerging stucture.
>
> When it come to the software portion I begin at the higher level (user
> visible functions) and write the glossary commentary for the words that are
> natural language in the problem domain, attaching those comments to each of
> those words of the Application Specific Language. I write no code at this
> level, just the comments for each word I decide will make sense in
> fulfilling the functions. Eventually I descend the levels of abstraction
> towards meeting words that look like they would appear in a standard Forth.
> All through this activity there are regular reviews to ensure that the whole
> intent of the system is coherent, meets with the customer requirements for
> function and has notes relating to the related fault actions (time-out
> periods, mis-entered data etc).
>
> When I am close to approaching the level of words in a Standard Forth I can
> then start fleshing out the words with code, starting at the bottom and
> working up the levels. I functionally test immediately after coding. Reviews
> continue of this code and ther begins formal inspections, functional tests
> and limitations testing as the system builds from the bottom. These reviews
> ensure that the coded implentation performs the requirements (comments) as
> specified. When you get to the top you should have the whole system, no
> matter how complex it started, written and able to perform as it should.
>
> When I was developing one application in view of the client it came to a
> point that the client started to see new opportunities he could explore as
> the Application Specific Language was familiar to him already. That was a
> system I sealed at a level just below his ASL and allowed him the freedom to
> generate his own new functionality (not a safety critical application). Most
> of teh other applications get sealed into the system and there are no user
> changeable elements.
>
> So, to control complexity and make user interfaces easier you have to start
> outside the software with the rest of the system and make sure that you have
> understood the cusomer needs well enough. Then decompose the problem space
> from the complex problem to a set of much smaller ones. Solving lots of
> smaller, simpler problems is easier than trying to get your head around a
> much more complex one.
>
> With that, Merry Christmas Gavino. May you get to grips with writing some
> code soon. You can always try a small problem out and post your efforts for
> helpful commentary.

A very generous reply, I hope the OP took the time to read, and indeed 
study it closely.  You are a mensch, Mr. Bennett, and a gentleman.

Cheers,
Rob Sciuk

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

#27569

On Thursday, December 26, 2013 2:16:15 AM UTC-8, Paul E Bennett wrote:
> the_gavino_himself wrote:
> 
> 
> 
> > two problem I have a tuff time with
> 
> 
> 
> The complexity and user interface problems are two that really should be 
> 
> resolved long before you start coding. I deal with Industrial Control 
> 
> Systems and have used quite a bit of the Forth Philosophy which actually 
> 
> seems to have come from the mathematical philosophy of George Polya (see 
> 
> "How to Solve It" by George Polya published in 1945).
> 
> 
> 
> From getting the true goals of the customer I usually perform a Task 
> 
> Analysis first, to ensure that I know all the sequence of actions that the 
> 
> User and the Systems is going to have to perform. As my systems ar often 
> 
> Safety Critical I will run a HAZOP analysis at this stage and adjust the 
> 
> resultant task plan and re-analyse both the task plan and HAZOP. It is here 
> 
> that you make your first decompositions of the problem space and begin to 
> 
> see the natural structure of the resultant system.
> 
> 
> 
> I write descriptive documents for the system (functional specifications etc) 
> 
> and when the custoimer agrees I proceed with further decomposition of the 
> 
> system following the naturally emerging stucture.
> 
> 
> 
> When it come to the software portion I begin at the higher level (user 
> 
> visible functions) and write the glossary commentary for the words that are 
> 
> natural language in the problem domain, attaching those comments to each of 
> 
> those words of the Application Specific Language. I write no code at this 
> 
> level, just the comments for each word I decide will make sense in 
> 
> fulfilling the functions. Eventually I descend the levels of abstraction 
> 
> towards meeting words that look like they would appear in a standard Forth. 
> 
> All through this activity there are regular reviews to ensure that the whole 
> 
> intent of the system is coherent, meets with the customer requirements for 
> 
> function and has notes relating to the related fault actions (time-out 
> 
> periods, mis-entered data etc).
> 
> 
> 
> When I am close to approaching the level of words in a Standard Forth I can 
> 
> then start fleshing out the words with code, starting at the bottom and 
> 
> working up the levels. I functionally test immediately after coding. Reviews 
> 
> continue of this code and ther begins formal inspections, functional tests 
> 
> and limitations testing as the system builds from the bottom. These reviews 
> 
> ensure that the coded implentation performs the requirements (comments) as 
> 
> specified. When you get to the top you should have the whole system, no 
> 
> matter how complex it started, written and able to perform as it should. 
> 
> 
> 
> When I was developing one application in view of the client it came to a 
> 
> point that the client started to see new opportunities he could explore as 
> 
> the Application Specific Language was familiar to him already. That was a 
> 
> system I sealed at a level just below his ASL and allowed him the freedom to 
> 
> generate his own new functionality (not a safety critical application). Most 
> 
> of teh other applications get sealed into the system and there are no user 
> 
> changeable elements.
> 
> 
> 
> So, to control complexity and make user interfaces easier you have to start 
> 
> outside the software with the rest of the system and make sure that you have 
> 
> understood the cusomer needs well enough. Then decompose the problem space 
> 
> from the complex problem to a set of much smaller ones. Solving lots of 
> 
> smaller, simpler problems is easier than trying to get your head around a 
> 
> much more complex one.
> 
> 
> 
> With that, Merry Christmas Gavino. May you get to grips with writing some 
> 
> code soon. You can always try a small problem out and post your efforts for 
> 
> helpful commentary.
> 
> 
> 
> -- 
> 
> ********************************************************************
> 
> Paul E. Bennett IEng MIET.....<email://Paul_E.Bennett@topmail.co.uk>
> 
> Forth based HIDECS Consultancy.............<http://www.hidecs.co.uk>
> 
> Mob: +44 (0)7811-639972
> 
> Tel: +44 (0)1235-510979
> 
> Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
> 
> ********************************************************************


thank you; interesting stuff here

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

#27453

the_gavino_himself wrote:
> two problem I have a tuff time with
>

First:
Learn to write coherently.
Second:
Learn to write grammatically.
Third:
Learn to spell.
FORTH:
Put above into practice.

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

#27570

On Thursday, December 26, 2013 4:52:12 AM UTC-8, Richard Owlett wrote:
> the_gavino_himself wrote:
> 
> > two problem I have a tuff time with
> 
> >
> 
> 
> 
> First:
> 
> Learn to write coherently.
> 
> Second:
> 
> Learn to write grammatically.
> 
> Third:
> 
> Learn to spell.
> 
> FORTH:
> 
> Put above into practice.


I know love is behind your hen pecking :)
I know the above, and am a published author, but I am sometimes jarred and it's late when I post here :)
You can learn some economics by listening to John Allison, Tom Woods, and Peter Schiff on youtube. Enjoy!

[toc] | [prev] | [standalone]

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

csiph-web