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

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

When forth PC with way faster OS?

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

Contents

  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

#44364 — When forth PC with way faster OS?

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

[toc] | [next] | [standalone]

#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

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

#44494

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

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

#44512

On Fri, 1 Jan 2016 04:57:09 -0800 (PST)
Howerd <howerdo@yahoo.co.uk> wrote:

> On Friday, 1 January 2016 08:07:27 UTC, Rod Pemberton  wrote:

> > Who cares how much code is compiled for some C?  
> > Who cares how small or how dense code can be made?
>
> Me. 

Ok.

> > 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.

Well, IMO, the purpose of source code is to tell the machine what
you want it to do for you.  That, of course, means "talking" to it
in a way it understands, i.e., "speaking" it's language.


Rod Pemberton

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

#44523

On Friday, January 1, 2016 at 2:07:27 AM UTC-6, Rod Pemberton
wrote:
> 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.

I read all of that ultratechnology stuff years ago.  It
abbreviates to "Forth is good" without a lot of information
lost.

> 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.

Sure, outside of embedded computing, RAM has completely outgrown
concerns about code size.  But humans haven't.  Heartbleed is a
recent example of that.  Here are some slides about LibreSSL,
OpenBSD's fork of OpenSSL:

http://www.openbsd.org/papers/bsdcan14-libressl/mgp00001.html


On Friday, January 1, 2016 at 4:41:43 PM UTC-6, Rod Pemberton wrote:
> Well, IMO, the purpose of source code is to tell the machine what
> you want it to do for you.  That, of course, means "talking" to it
> in a way it understands, i.e., "speaking" it's language.

Ehh.  A rock at rest is just a rock.  A rock in motion is a
deadly projectile.  When the machine is the only consume of
code, the code is at rest.  It works as well it does and people
deal with that.  As soon as you want the code to change, you
have to bring in a programmer - even, the same programmer that
wrote it in the first place - and that programmer is now a
second audience for the code.


-- Julian

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

#44647

On Friday, January 1, 2016 at 5:41:43 PM UTC-5, Rod Pemberton wrote:
> Well, IMO, the purpose of source code is to tell the machine what
> you want it to do for you.  That, of course, means "talking" to it
> in a way it understands, i.e., "speaking" it's language.

Are you kidding?

We live in times of super computers.
Computers - and even microprocessors - should understand my language, not vice versa!

Cheers,
Dirk.

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

#44663

On Thursday, January 7, 2016 at 12:54:35 AM UTC-5, visua...@rocketmail.com wrote:
> Are you kidding?
> 
> We live in times of super computers.
> Computers - and even microprocessors - should understand my language, not vice versa!
> 
> Cheers,
> Dirk.
This is just silliness.

Computers only understand ONE "language", that being the set of bit patterns
that comprise the instructions the CPU can perform. A computer "language" needs to know how to translate the programmer's text into the sequence of 
CPU instructions that the CPU needs to perform to carry out the intended 
behavior. To claim that just because CPUs are faster now and can access more 
memory than ever before, they should magically know and understand every 
language is ludicrous. That is simply not how it works.

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

#44665

On Thursday, January 7, 2016 at 8:19:22 AM UTC-5, Chris Curl wrote:
> On Thursday, January 7, 2016 at 12:54:35 AM UTC-5, visua...@rocketmail.com wrote:
> > Are you kidding?
> > 
> > We live in times of super computers.
> > Computers - and even microprocessors - should understand my language, not vice versa!
> > 
> > Cheers,
> > Dirk.
> This is just silliness.
> 
> Computers only understand ONE "language", that being the set of bit patterns
> that comprise the instructions the CPU can perform. A computer "language" needs to know how to translate the programmer's text into the sequence of 
> CPU instructions that the CPU needs to perform to carry out the intended 
> behavior. To claim that just because CPUs are faster now and can access more 
> memory than ever before, they should magically know and understand every 
> language is ludicrous. That is simply not how it works.

I am really sorry about that misunderstanding of my contribution.

I wrote "Computers - and even microprocessors - should understand my language", but I did not write that a CPU should understand my language. 

I assumed that everybody knows that it is state of the art that there is a compiler - or IDE in case of microprocessors - between my language and the CPU, compiler and/or IDE being part of this computer. The CPU I did not mention, the CPU is hidden inside the system.

That's why I am using Forth. I do not need to worry about the set of bit patterns that comprise the instructions the CPU can perform.

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

#44666

On Thursday, January 7, 2016 at 1:52:53 PM UTC-5, visua...@rocketmail.com wrote:
> I am really sorry about that misunderstanding of my contribution.
> 
> I wrote "Computers - and even microprocessors - should understand my language", but I did not write that a CPU should understand my language. 
> 
> I assumed that everybody knows that it is state of the art that there is a compiler - or IDE in case of microprocessors - between my language and the CPU, compiler and/or IDE being part of this computer. The CPU I did not mention, the CPU is hidden inside the system.
> 
> That's why I am using Forth. I do not need to worry about the set of bit patterns that comprise the instructions the CPU can perform.

I understand your point. I probably over-reacted. It's all good.

The thing is that, if you think about it, a "computer" is really just 
the CPU and whatever peripherals are included. In that state, the only 
thing it knows is the machine language of the CPU. That is really all 
a computer is.

EVERYTHING else, including the operating system, is just software, which 
needs to get loaded onto the computer somehow. And it is the software that 
provides all the extra functionality that you are saying should be there.

But I know that you already know all this.

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

#44667

On Thursday, January 7, 2016 at 5:03:30 PM UTC-5, Chris Curl wrote:
> On Thursday, January 7, 2016 at 1:52:53 PM UTC-5, visua...@rocketmail.com wrote:
> > I am really sorry about that misunderstanding of my contribution.
> > 
> > I wrote "Computers - and even microprocessors - should understand my language", but I did not write that a CPU should understand my language. 
> > 
> > I assumed that everybody knows that it is state of the art that there is a compiler - or IDE in case of microprocessors - between my language and the CPU, compiler and/or IDE being part of this computer. The CPU I did not mention, the CPU is hidden inside the system.
> > 
> > That's why I am using Forth. I do not need to worry about the set of bit patterns that comprise the instructions the CPU can perform.
> 
> I understand your point. I probably over-reacted. It's all good.
> 
> The thing is that, if you think about it, a "computer" is really just 
> the CPU and whatever peripherals are included. In that state, the only 
> thing it knows is the machine language of the CPU. That is really all 
> a computer is.
> 
> EVERYTHING else, including the operating system, is just software, which 
> needs to get loaded onto the computer somehow. And it is the software that 
> provides all the extra functionality that you are saying should be there.
> 
> But I know that you already know all this.

Thanks, Chris!
We have different points of view, but in the end we understand each other.
That's great!
Be the Forth with you!
DB.

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

#44759

visualforth@rocketmail.com wrote:
> ...
> We live in times of super computers.
> Computers - and even microprocessors - should understand my language, not vice versa!
>
> Cheers,
> Dirk.

Computers are like babies.  No matter what language you speak to them they demand
constant attention.

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

#44771

On Monday, January 11, 2016 at 7:04:20 AM UTC-5, HAA wrote:
> visualforth.com wrote:
> > ...
> > We live in times of super computers.
> > Computers - and even microprocessors - should understand my language, not vice versa!
> >
> > Cheers,
> > Dirk.
> 
> Computers are like babies.  No matter what language you speak to them they demand
> constant attention.

That's why I like to have a computer with ForthOS, to enable me to add a beep when my computer has done it's chores - not possible with another OS up to now.
That helps avoid constant attention.

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

#44668

On Friday, January 1, 2016 at 12:07:27 AM UTC-8, Rod Pemberton wrote:
> On Sat, 26 Dec 2015 14:36:45 -0800 (PST)
> polymorph self <jackvanc3@gmail.com> wrote:
> 

> "[C] has elaborate sytnax [sic]. Rules that are supposed to
> promote correctness, but merely create opportunity for error."
> 
> Let's ignore the spelling error.

  Really?

> 
> 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.

  You actually agree with him here. He doesn't say it ensures correctness,
 he says it is supposed to promote it. This is, 'helps correctness'.

> Syntax is so that the parser can determine the what each
> element of the code is used for.

 The coder already determines this. 

> 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.

 Yes, the coder serves the C compiler. It is always up to
the coder to correctly code everything in any language.
Syntax or none. If the coder doesn't understand the problem,
the compiler doesn't notice or care.
 With forth the compiler serves the coder.

> 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.

 The solution isn't smarter compilers, it is methodological.
Forth is an integrated language and methodology.
 
>  Having fewer checks is far more likely to
> result in more coding mistakes.

 Coding mistakes are not a result of a lack of checks.
They're a result of incorrect code.

> 
> "[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.

 He is of course referring to efficient object code and
tricking the compiler into it's production.
 He is comparing C to forth. It is disingenuous to 
compare C to other languages.

> 
> "[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.

Again, He is comparing C to forth. 
 C creates problems and then one must work around them.

> 
> "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.

 This is fallacy. RPN is a natural, native and standard way to
interact with stacks. All people who became programmers are capable of
thinking this 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.

Not all people who became programmers are capable of
thinking this way.

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

 There is an implied, 'all else being equal' and spare us the
hyperbole. 

> 
> "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.

 It was almost funny the first time.

> 
> 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.

 So you actually agree.

> 
> "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.

 Now it's just sad.

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

  If you can't refute, accuse ignorance.
 Learn to use commas! 

> 
> "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.

 Again, He is comparing C to forth. 
Everything is nested so why indicate?

> 
> "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.

 It is disingenuous to assert he meant object code density.
Less worth, if lines of code is equal to 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 ...

 Stack notation is a universal and useful simplistic abstraction.
 Comments are arbitrary and can presume something not already known.


 
> "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.

Fallacies Here!


> 
> "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.

 Again, assuming you know forth, this is disingenuous.

> 
> "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.
> 

You're admitting ignorance here, but dismissing 
it with fallacies.


> "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? ...

 Who's saying it's needed? But one can vector execution.


> 
> "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?

 You're not even trying now.

> 
> "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.

He also seems to be critical of programmers.
It's called introspection. You should try it
sometime.

> 
> "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



 Very short-sighted, dismissive and greedy.
 Computing is an extension of the mind of man.
 And a mind is a terrible thing to waste.

 Kevin Lee Reno

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

#44670

Whammo wrote:

> > 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
> 
> 
> 
>  Very short-sighted, dismissive and greedy.
>  Computing is an extension of the mind of man.
>  And a mind is a terrible thing to waste.
> 
>  Kevin Lee Reno

I agree that it is terrible to waste one's mind by programming
in a weak, low-level, toy language.  Programs can be created
more quickly when a powerful, high-level language is used.

I agree that it is advantageous to have compact code.
How much Forth code does it take to do this?


Ruby:

"snab:HTROfcEHTdYOTi.EGAUGNALj".swapcase.split(/[BCDIJ]/).
  map(&:reverse).join " "
 ===>
"ANS Forth: the toy language."

-- 
Africans gang-rape and clitorectomize Finnish girl; government arrests Finn
whom they accuse of complaining:
conservative-headlines.com/2009/03/another-european-awaits-extradition-for-hate-speech

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

#44672

On Thursday, January 7, 2016 at 5:03:57 PM UTC-8, WJ wrote:
> Whammo wrote:
> 
> > > 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
> > 
> > 
> > 
> >  Very short-sighted, dismissive and greedy.
> >  Computing is an extension of the mind of man.
> >  And a mind is a terrible thing to waste.
> > 
> >  Kevin Lee Reno
> 
> I agree that it is terrible to waste one's mind by programming
> in a weak, low-level, toy language.  Programs can be created
> more quickly when a powerful, high-level language is used.
> 
> I agree that it is advantageous to have compact code.
> How much Forth code does it take to do this?
> 
> 
> Ruby:
> 
> "snab:HTROfcEHTdYOTi.EGAUGNALj".swapcase.split(/[BCDIJ]/).
>   map(&:reverse).join " "
>  ===>
> "ANS Forth: the toy language."

   Such a small fraction of your object code, as to defy comparison. 

 

 You can't make a man understand that which he has a vested interest in not understanding


 

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

#44675

On Thursday, January 7, 2016 at 5:04:30 PM UTC-7, Whammo wrote:
> On Friday, January 1, 2016 at 12:07:27 AM UTC-8, Rod Pemberton wrote:
> > 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.
> 
>  The solution isn't smarter compilers, it is methodological.
> Forth is an integrated language and methodology.
>  
> >  Having fewer checks is far more likely to
> > result in more coding mistakes.
> 
>  Coding mistakes are not a result of a lack of checks.
> They're a result of incorrect code.

I agree with most of what you said --- the two quotes above are particularly good points --- people want computers to be "smart," but computers can't actually think, so if the human isn't thinking then nobody is.

Rod is just a troll, here to promote C --- he is also a stalker --- I recommend that you not respond to him.

I generally read anything that Charles Moore writes, as he is the inventor of Forth --- I don't take everything he says as gospel though --- Forth is really all about thinking for yourself (I'm sure Charles Moore would agree too, as he doesn't seem to be collecting sycophants; he just does what he wants to do).

Finding quotes from Charles Moore that "prove" me to be wrong about Forth in every way is pretty easy to do, but I don't care --- people find quotes in the Bible to "prove" almost any agenda, but I don't care about that either --- I'm not really into following anybody.

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

#44693

On Thu, 7 Jan 2016 20:58:16 -0800 (PST)
hughaguilar96@gmail.com wrote:

> Rod is just a troll, here to promote C
> --- he is also a stalker ---
> I recommend that you not respond to him.

Ignore me?  Pfft... I'm not the one who rants.
People who rant get ignored or filtered.  It's
why Bernd has been keeping a low profile.  No
one was responding to him after he went off on
a bunch of rants.  It's why Alex left.  It's
partly why Passiniti left, but his record was
about as long as yours. It's why you should
leave.  Please, get a clue.

Hugh claims to be a taxi driver.  Look up "serial
killer" and "taxi driver" some time.  It seems
to be an ongoing correlation, almost a trend ...

Well, I'd like to call you a serial killer, but
you failed to kill Ms. Rather despite incessant,
verbally abusive rants, and failed even after
openly wishing her dead.  She was attacked and
nearly killed when you did so.  How sick, twisted,
and cruel is that?  It's almost beyond comprehension
that you're not locked up for something.  If you're
not a failure at being a serial killer, then you're
most definitely a sociopath.

BTW, there are another 70 lines from where that
came from on other messed up stuff you've said here.

So, when I politely ignore an obnoxious, ignorant,
trollish ghost of Passiniti, like Blammo or
whatever, maybe you should at least consider not
inciting things further.  It's not like you have
much to say on the topic of Forth anyway, and no
one here agrees with what you do say, not Forth
experts, not Forth novices, not Forth programmers,
not C programmers, not spammers like Gavino, not
AI masters like Mentifex, and not even rickman who
has no basis for being here either.


Rod Pemberton

[toc] | [prev] | [standalone]

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

csiph-web