Re: Forth philosophy

From	"Rod Pemberton" <dont_use_email@xnothavet.cqm>
Newsgroups	comp.lang.forth
Subject	Re: Forth philosophy
Date	2014-06-11 19:30 -0400
Organization	Aioe.org NNTP Server
Message-ID	<op.xhbcxxrw6zenlw@localhost> (permalink)
References	<d6a1ccca-1a5b-4fdf-be24-6ee6029d557c@googlegroups.com>

Show all headers | View raw

On Tue, 10 Jun 2014 16:23:25 -0400, OneArb <o1neeno1@gmail.com> wrote:

> I have been puzzled about Forth and a sideline supporter.
>
> While trying to use objects, I ran into,  performance questions, the
> inability to create granular objects, maintenance complexity.
>
> My quest for a solution led to Forth.
>
> 1) How would I explain, in the most compact way, the benefit of
> breaking down a program into words that do little ?

In Forth, there is a benefit because Forth has no syntax errors or
compiler warnings.  There is nothing to tell you about incorrectness.
I.e., you can only detect errors in Forth by thoroughly testing every
bit of code you coded, which is easiest if they are small pieces.
There is nothing to warn you about boundary cases, integer overflow,
unused code, or the mis-use of an integer as an address.

Also, reducing everything to the simplest concept also interferes
with developing and testing of more complex ideas.  The ability to
grasp the entire problem or implementation at once can be obfuscated
by using small pieces.  It's much better to see the entire problem,
in one place, at once, not a whole bunch of jumbled little pieces
that have to be put together, correctly.

> 2) What would be ways to apply Forth way of thinking to other languages ?
>

I've answered this one in the past.  There is minimal benefit in other
languages.

E.g., breaking C down into a bunch of small procedures which do little
to nothing per procedure call results in a huge mess of nested procedure
calls.  This adds call overhead.  The prolog(ue) or epilog(ue) of a
procedure adds a half-dozen or more instructions each.  Most of the
overhead can be optimized away, but not all of it.  You'd have to use
a bunch of special compiler features to inlign many of the procedures
to reduce the effect of the extra, unneeded nesting that resulted from
"factoring" in C.  So, applying Forth's "factoring" concept to C would
hinder C.  In C, testing a procedure is easy, but testing small pieces
of code as separate procedures which call each other is time consuming.

Of course, I'm not a fan of "Bottom's Up" design, but "Top Down".
I've seen all sorts of bad code with "Bottom's Up" programmers in C.
Forth is inherently a "Bottom's Up" language.

> 3) Was there ever an attempt to host / embed Forth within another  
> compiler ?
>

I'm not sure about within another compiler, but minimal Forths have
been implemented in a wide variety of projects: MUDs, Bitcoin
scripting etc.

Ms. Rather mentioned code density.  Increased code density is fine when it
has a purpose.  It's not an advantage in it's own right.  There must be a
reason for using it.  Otherwise, it doesn't provide any advantage.  You
have to be careful when people tout things as facts or rules without them
explaining why it is a fact or rule.  I.e., people forget about the
reasons and the constraints.

For CISC processors, code density reduced the amount of memory needed when
computer memory was expensive.  The same is true of Forth.  Interpreted
Forths have a higher code density which reduced the need for memory on
early machines that only had a few KB of memory.

However, code density for a modern Forth means that Forth is interpreted.
Interpreters are slow.  They re-implement a processor in software, when
a processor in hardware is already available to you.  So, a high code
density today usually means slower.

IMO, compiled Forths won't see much if any increase in code density
after compilation.  And, if they do, their more compact code is likely
to result in a slower implementation.  In part, the increase in code
density comes in exchange for a less efficient algorithm.  In part,
the increase in code density comes in exchange for shorter, but less
efficient processor instructions.  When code is compiled, code density
is only important if memory is expensive or constrained, which it isn't
in modern machines.  Shorter machine instructions, today, do less work
with MISC, RISC, and RISC-like post-CISC CISC instruction sets.  Speed
is about doing the most work per time unit.  I.e., code density is of
no value to compiled Forth.

Rod Pemberton

Thread

Forth philosophy OneArb <o1neeno1@gmail.com> - 2014-06-10 13:23 -0700
  Re: Forth philosophy Roger Levy <roger.levy@gmail.com> - 2014-06-10 14:45 -0700
  Re: Forth philosophy Elizabeth D Rather <erather@forth.com> - 2014-06-10 12:51 -1000
    Re: Forth philosophy hughaguilar96@yahoo.com - 2014-06-10 16:14 -0700
  Re: Forth philosophy Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2014-06-11 10:03 +0100
    Re: Forth philosophy visualforth@rocketmail.com - 2014-06-11 11:11 -0700
      Re: Forth philosophy Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2014-06-11 21:57 +0100
  Re: Forth philosophy "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-06-11 19:30 -0400
    Re: Forth philosophy "Elizabeth D. Rather" <erather@forth.com> - 2014-06-11 14:26 -1000
      Re: Forth philosophy rickman <gnuarm@gmail.com> - 2014-06-12 00:24 -0400
        Re: Forth philosophy "Elizabeth D. Rather" <erather@forth.com> - 2014-06-11 18:58 -1000
          Re: Forth philosophy "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-06-12 07:33 -0400
            Re: Forth philosophy AKK <akk@nospam.org> - 2014-06-12 20:39 +0200
              Re: Forth philosophy "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-06-12 23:15 -0400
              Re: Forth philosophy anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-06-13 17:29 +0000
                Re: Forth philosophy AKK <akk@nospam.org> - 2014-06-14 12:26 +0200
                Re: Forth philosophy anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-06-14 10:59 +0000
                Re: Forth philosophy Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-06-14 07:39 -0500
                Optimizing C compilers vs. assembly language for Forth interpreters (was: Forth philosophy) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-06-14 14:40 +0000
                Re: Optimizing C compilers vs. assembly language for Forth interpreters Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-06-14 11:25 -0500
                Re: Optimizing C compilers vs. assembly language for Forth interpreters Bernd Paysan <bernd.paysan@gmx.de> - 2014-06-15 23:55 +0200
                Re: Forth philosophy albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-06-14 19:45 +0000
                Re: Forth philosophy Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-06-15 13:18 -0500
                Re: Forth philosophy AKK <akk@nospam.org> - 2014-06-16 21:14 +0200
                Re: Forth philosophy Bernd Paysan <bernd.paysan@gmx.de> - 2014-06-16 22:41 +0200
                Re: Forth philosophy AKK <akk@nospam.org> - 2014-06-17 13:32 +0200
                Re: Forth philosophy Bernd Paysan <bernd.paysan@gmx.de> - 2014-06-17 15:02 +0200
                Re: Forth philosophy mhx@iae.nl - 2014-06-16 13:41 -0700
        Re: Forth philosophy "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-06-12 07:33 -0400
        Re: Forth philosophy barrym95838@yahoo.com - 2014-06-13 21:48 -0700
          Re: Forth philosophy "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-06-14 01:01 -0400
      Re: Forth philosophy Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-06-12 03:02 -0500
      Re: Forth philosophy albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-06-12 10:43 +0000
      Re: Forth philosophy "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-06-12 07:32 -0400

csiph-web