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

Groups > comp.lang.forth > #44494

Re: When forth PC with way faster OS?

Show all headers | View raw

On Friday, 1 January 2016 08:07:27 UTC, Rod Pemberton  wrote:
> On Sat, 26 Dec 2015 14:36:45 -0800 (PST)
> polymorph self <jackva....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

Hi Rod,

Happy New Year to you and all on clf :-)

> Who cares how much code is compiled for some C?  
> Who cares how small or how dense code can be made? 
Me. 
> These are old ideologies no longer of any importance. 
With all due respect, I don't agree.
<rant>
The purpose of human-readable source code is to be read and understood by humans. The more there is, the more work this requires, and the more possibilities there are for bugs to hide undetected.

I have just finished a contract working on a classical embedded ARM based control system with around 400 files, mostly 1 or 2 Kbytes each, so about 1Mbyte of code. 
Some bugs were quite hard to find, but most were easy, the source folders and files had mostly sensible names, and you could search the entire code base in a matter of seconds.

Compare this with the latest fashion, of embedded systems based on a Raspberry Pi (or other ARM) running Linux - I compare the chaos caused by this approach to to the types of OOP paradigm that caused so much damage in the 1990's and 2000's. 

The code base is maybe 1000 x bigger - around 1 GBytes. 
Plus everything is built on shifting sand - every time you reboot, or update something a bug may appear or disappear.
But the real killer is that there are some bugs that it is unfeasible to fix.
OK so you have a single chip ARM that has 10 times the processing power and 100 times the storage of my first PC, but due to the explosion in complexity it is just not possible to write programs that work reliably, let alone boot in less that 30 seconds. 

Not that I have anything against the Raspberry Pi (a great educational tool), or even OOP (when you use the right type of Objects and Orient them correctly), but computers need human beings to understand what is going on, and to do this less really is more.

</rant>

Best regards,
Howerd

Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

When forth PC with way faster OS? polymorph self <jackvanc3@gmail.com> - 2015-12-26 14:36 -0800
  Re: When forth PC with way faster OS? Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-01-01 03:07 -0500
    Re: When forth PC with way faster OS? Howerd <howerdo@yahoo.co.uk> - 2016-01-01 04:57 -0800
      Re: When forth PC with way faster OS? Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-01-01 17:41 -0500
        Re: When forth PC with way faster OS? Julian Fondren <julian.fondren@gmail.com> - 2016-01-02 02:46 -0800
        Re: When forth PC with way faster OS? visualforth@rocketmail.com - 2016-01-06 21:54 -0800
          Re: When forth PC with way faster OS? Chris Curl <ccurl609@gmail.com> - 2016-01-07 05:19 -0800
            Re: When forth PC with way faster OS? visualforth@rocketmail.com - 2016-01-07 10:52 -0800
              Re: When forth PC with way faster OS? Chris Curl <ccurl609@gmail.com> - 2016-01-07 14:03 -0800
                Re: When forth PC with way faster OS? visualforth@rocketmail.com - 2016-01-07 14:28 -0800
          Re: When forth PC with way faster OS? "HAA" <someone@microsoft.com> - 2016-01-11 23:04 +1100
            Re: When forth PC with way faster OS? visualforth@rocketmail.com - 2016-01-11 18:28 -0800
    Re: When forth PC with way faster OS? Whammo <sidciavic@gmail.com> - 2016-01-07 16:04 -0800
      Re: When forth PC with way faster OS? "WJ" <w_a_x_man@yahoo.com> - 2016-01-08 01:01 +0000
        Re: When forth PC with way faster OS? Whammo <sidciavic@gmail.com> - 2016-01-07 18:41 -0800
      Re: When forth PC with way faster OS? hughaguilar96@gmail.com - 2016-01-07 20:58 -0800
        Re: When forth PC with way faster OS? Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-01-08 10:20 -0500

csiph-web