Path: csiph.com!news.fcku.it!aioe.org!.POSTED!not-for-mail
From: Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm>
Newsgroups: comp.lang.forth
Subject: Re: When forth PC with way faster OS?
Date: Fri, 1 Jan 2016 03:07:40 -0500
Organization: Aioe.org NNTP Server
Lines: 214
Message-ID: <20160101030740.5172d3cf@_>
References: <0b5cd7e4-64a8-4224-aaaf-31799f1f3d24@googlegroups.com>
NNTP-Posting-Host: n4wpt9zq8xR26Ttf9mo2BA.user.speranza.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Complaints-To: abuse@aioe.org
X-Notice: Filtered by postfilter v. 0.8.2
X-Newsreader: Claws Mail 3.13.1 (GTK+ 2.24.10; x86_64-unknown-linux-gnu)
Xref: csiph.com comp.lang.forth:44492

On Sat, 26 Dec 2015 14:36:45 -0800 (PST)
polymorph self <jackvanc3@gmail.com> wrote:

> http://colorforth.com/1percent.html

OMG!

Gavino, you actually linked to something that wasn't
judged by me to be a joke ...  Was this a Christmas
present for us?  Everyone should be happy with you!  
Even so, no one took you seriously enough to reply.
Maybe, they read the subject line.

So, let's review what either Charles Moore or perhaps
Jeff Fox said.

"[C] has elaborate sytnax [sic]. Rules that are supposed to
promote correctness, but merely create opportunity for error."

Let's ignore the spelling error.

The person who wrote this clearly has no understanding of
what syntax is for.  Syntax has nothing whatsoever to do
with code correctness or readability, although it helps.
Syntax is so that the parser can determine the what each
element of the code is used for.  Without syntax,
complicated interactions of language elements can't be
"understood" by the compiler.  By eliminating syntax,
as Forth does, means it is entirely up to the coder to
correctly code everything.  As we've seen with languages
which can detect coding mistakes by humans, humans make
plenty of coding errors for which they're completely
unaware.  Having fewer checks is far more likely to
result in more coding mistakes.

"[C] has considerable redundancy. This increases trivial
errors that can be detected. And program size."

I'm not sure what the author means by this.  There are
many ways to code the same thing in every language.

"[C's] strongly typed, with a bewildering variety of
types to keep straight. More errors."

C isn't strongly typed as compared to most high-level
languages.  It's considered to be very weak since it's
type system can be overridden via casts and allowed type
conversions.  C has far fewer types than most other
high-level languages.  Type systems are there to help
prevent programmers from making incorrect data conversions,
e.g., converting pointers to integers, using integers as
addresses, etc.  I.e., more errors are made without the
checks of type systems than with.

"As an infix language, [C] encourages nested parentheses.
Sometimes to a ludicrous extent. They must be counted and
balanced."

Forth, as an RPN language, must be converted to an unnatural
representation, one which people don't natively think with.
C uses standard algebraic representation taught in all math
classes.  Most people who became programmers are capable of
thinking that way.

"It's never clear how efficiently source will be translated
into machine language. Constructs are often chosen because
the programmer knows they're efficient. Subroutine calls are
expensive."

It's only unclear as to "how efficiently source will be
translated into machine language" if one accepts the
abstracted C model in the C specifications as taught by
those on comp.lang.c.  If one accepts that C is really
just a thin veneer over pointer based assembly language,
then these conversions are well understood and rather
straightforward.

The expense of subroutine calls has nothing to do with
the language in use and everything to do with the processor
instruction set.

"Because of the elaborate compiler, object libraries must
be maintained, distributed and linked. The only documentation
usually addresses this (apparantly [sic] difficult) procedure."

I'm ignoring that spelling error also.

C doesn't require one to use any of the C libraries.
In fact, you can do everything in C by just using C
and not using any libraries.  However, you may find
that at least one library include, only the one for
file operations (<stdio.h>), is far easier than pure C.
All of the other functionality in C library includes
is unneeded with proper program design.  However, it's
far more difficult and time consuming to not use them.

"Code is scattered in a vast heirarchy [sic] of files. You
can't find a definition unless you already know where it is."

Let's ignore that spelling error too.

This person needs to buy a good, C reference manual.

"Code is indented to indicate nesting. As code is edited
and processed, this cue is often lost or incorrect."

This affects the coding style of all languages.
This is sometimes true of Forth as well.  Of course,
with Forth, there is nothing to indicate nesting.

"Sometimes a line of code contains only a parenthesis,
or semicolon. This reduces the density of the code, and
the difficulty of reading it."

While the first sentence is true, the second is not.
The placement of code syntax on one line or another
has absolutely no effect on the density of compiled
C code.  Perhaps, the author is referring to the
visual density of the code, which has no worth.

"There's no documentation. Except for the ubiquitous
comments. These interrupt the code, further reducing
density, but rarely conveying useful insight."

How is this any better than Forth comments and
stack notation?  I.e., Forth and C are essentially
equivalent in regards to this ...

"Names tend to be hyphenated. This makes them unique
and displays their position in the heirarchy. The
significant portion of a name is hard to detect,
slow to read."

Let's ignore that same misspelling too.

C doesn't allow hyphens in names.  Did the author
mistake underscores for hyphens? ...  Clearly, the
author has an issue with one of the numerous naming
styles used by C, but I'm not sure which one.  I'm
not sure how Forth is any better.

"Constants, particularly fields within a word, are
named. Even if used, the name rarely provides enough
information about the function. And requires continual
cross-reference to the definition."

Clearly, the author has no real experience with C.
Most C programmers do not name "fields within a word,"
e.g., unions, but use logical-and with bit-masks.
The name of the bit-mask, implemented as a defined
value, provides the information the author is complaining
is missing.

"Preoccupation with contingencies. In a sense it's
admirable to consider all possibilities. But the
ones that never occur are never even tested. For
example, the only need for software reset is to
recover from software problems."

I have no idea what he rambling on about here ...
At best, this may be an issue with a particular
coder, and not the C language itself.

"Conditional compilation. More constants include
or exclude code for particular platforms. More
indentation. More difficulty fathoming which
code is relevant."

When conditional code is needed, just what is done
for Forth? ...

"Hooks for future enhancements, or abandoned features,
are abundant. This is useful only in understanding
the programmer's ambitions."

If it's not used, why does this concern the author?

"It is in a programmer's best interest to exaggerate
the complexity of his program."

This is not so for any programming language.  So, I
have to wonder how the author came to this conclusion.

"Another difficulty is the mindset that code must be
portable across platforms and compatible with earlier
versions of hardware/software."

The author got one correct.  This is a problem with
a large percentage of C programmers.  They simply fail
to accept the idea that 30% of C code is not portable 
and another 40% is only partially portable.  They
insist that code must be made portable even though
someone developing the code doesn't have access to
other platforms to verify code correctness.

FYI, another typo:
"Yes, I could write a better C program that those I've seen."

s/that/than/


Now, for my comment on the "1% of the code" issue.  I've
stated this in the past here.  The conclusion that code
density is still of importance in an era of cheap and
abundant memory is a fallacy.  It was important in the
days of expensive, small memories, i.e., the CISC era.
We are long past that time period.  Who cares how much
code is compiled for some C?  Who cares how small or
how dense code can be made?  These are old ideologies
no longer of any importance.


Rod Pemberton