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

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

I Don’t Make Mistakes. I Use C

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

Contents

  I Don’t Make Mistakes. I Use C visualforth@rocketmail.com - 2012-10-23 16:09 -0700
    Re: I Don’t Make Mistakes. I Use C Paul Rubin <no.email@nospam.invalid> - 2012-10-23 16:43 -0700
    Re: I Don’t Make Mistakes. I Use C jacko <jackokring@gmail.com> - 2012-10-23 16:50 -0700
      Re: I Don’t Make Mistakes. I Use C Paul Rubin <no.email@nospam.invalid> - 2012-10-23 18:58 -0700
        Re: I Don’t Make Mistakes. I Use C jacko <jackokring@gmail.com> - 2012-10-24 15:12 -0700
    Re: I Don’t Make Mistakes. I Use C "Elizabeth D. Rather" <erather@forth.com> - 2012-10-23 14:02 -1000
      Re: I Don’t Make Mistakes. I Use C Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-24 02:51 +0200
        Re: I Don’t Make Mistakes. I Use C Mark Wills <forthfreak@gmail.com> - 2012-10-24 04:23 -0700
      Re: I Don’t Make Mistakes. I Use C Paul Rubin <no.email@nospam.invalid> - 2012-10-23 19:20 -0700
      Re: I Don?t Make Mistakes. I Use C Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-10-24 05:04 -0500
        Re: I Don?t Make Mistakes. I Use C "Elizabeth D. Rather" <erather@forth.com> - 2012-10-24 08:04 -1000
          Re: I Don?t Make Mistakes. I Use C Paul Rubin <no.email@nospam.invalid> - 2012-10-24 13:11 -0700
            Re: I Don?t Make Mistakes. I Use C Pavel Klinkovsky <pavel.klinkovsky@gmail.com> - 2012-10-24 13:21 -0700
            Re: I Don?t Make Mistakes. I Use C Fritz Wuehler <fritz@spamexpire-201210.rodent.frell.theremailer.net> - 2012-10-25 20:00 +0200
              Re: I Don?t Make Mistakes. I Use C Paul Rubin <no.email@nospam.invalid> - 2012-10-25 11:30 -0700
                Re: I Don?t Make Mistakes. I Use C Anonymous <nobody@remailer.paranoici.org> - 2012-10-26 09:00 +0000
                  Re: I Don?t Make Mistakes. I Use C Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-10-26 05:01 -0500
                  Re: I Don?t Make Mistakes. I Use C Brad Eckert <hwfwguy@gmail.com> - 2012-10-26 08:46 -0700
              Re: I Don?t Make Mistakes. I Use C Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-10-25 23:05 -0500
                Re: I Don?t Make Mistakes. I Use C Anonymous <nobody@remailer.paranoici.org> - 2012-10-28 15:35 +0000
                  Re: I Don?t Make Mistakes. I Use C Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-10-28 12:06 -0500
                    Re: I Don?t Make Mistakes. I Use C Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-28 21:38 +0100
                      Re: I Don?t Make Mistakes. I Use C jacko <jackokring@gmail.com> - 2012-10-28 16:34 -0700
                    Re: I Don?t Make Mistakes. I Use C Anonymous <nobody@remailer.paranoici.org> - 2012-10-29 10:56 +0000
                      Re: I Don?t Make Mistakes. I Use C Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-10-29 06:11 -0500
                        Re: I Don?t Make Mistakes. I Use C rickman <gnuarm@gmail.com> - 2012-10-29 13:51 -0400
                          Re: I Don?t Make Mistakes. I Use C Anonymous <nobody@remailer.paranoici.org> - 2012-10-29 20:45 +0000
                            Re: I Don?t Make Mistakes. I Use C Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-10-30 04:20 -0500
                          Re: I Don?t Make Mistakes. I Use C Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-10-30 04:16 -0500
      Re: I Don’t Make Mistakes. I Use C rickman <gnuarm@gmail.com> - 2012-10-25 10:04 -0400
        Re: I Don’t Make Mistakes. I Use C Paul Rubin <no.email@nospam.invalid> - 2012-10-25 14:16 -0700
          Re: I Don’t Make Mistakes. I Use C "Elizabeth D. Rather" <erather@forth.com> - 2012-10-25 15:51 -1000
            Re: I Don’t Make Mistakes. I Use C Paul Rubin <no.email@nospam.invalid> - 2012-10-25 20:14 -0700
              Re: I Don?t Make Mistakes. I Use C Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-10-25 23:11 -0500
                Re: I Don?t Make Mistakes. I Use C Paul Rubin <no.email@nospam.invalid> - 2012-10-25 21:53 -0700
                  Re: I Don?t Make Mistakes. I Use C Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-10-26 01:27 -0500
                    Re: I Don?t Make Mistakes. I Use C Paul Rubin <no.email@nospam.invalid> - 2012-10-26 07:06 -0700
                      Re: I Don?t Make Mistakes. I Use C Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-10-26 11:34 -0500
                      Re: I Don?t Make Mistakes. I Use C Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-26 19:13 +0200
                        Re: I Don?t Make Mistakes. I Use C Alex McDonald <blog@rivadpm.com> - 2012-10-27 04:49 -0700
                  Re: I Don?t Make Mistakes. I Use C "Elizabeth D. Rather" <erather@forth.com> - 2012-10-25 21:20 -1000
              Re: I Don’t Make Mistakes. I Use C "Elizabeth D. Rather" <erather@forth.com> - 2012-10-25 21:23 -1000
                Re: I Don’t Make Mistakes. I Use C Paul Rubin <no.email@nospam.invalid> - 2012-10-26 00:53 -0700
            Re: I Don’t Make Mistakes. I Use C "Stanley Daniel de Liver" <notagoodone@invalid.org.invalid> - 2012-11-21 16:21 +0000
    Re: I Don't Make Mistakes. I Use C "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-24 06:55 -0400
      Re: I Don't Make Mistakes. I Use C "Elizabeth D. Rather" <erather@forth.com> - 2012-10-24 08:17 -1000
        Re: I Don't Make Mistakes. I Use C "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-25 00:23 -0400
          Re: I Don't Make Mistakes. I Use C Paul Rubin <no.email@nospam.invalid> - 2012-10-24 22:18 -0700
          Re: I Don't Make Mistakes. I Use C "Elizabeth D. Rather" <erather@forth.com> - 2012-10-24 21:47 -1000
            Re: I Don't Make Mistakes. I Use C Paul Rubin <no.email@nospam.invalid> - 2012-10-25 11:21 -0700
              Re: I Don't Make Mistakes. I Use C "Elizabeth D. Rather" <erather@forth.com> - 2012-10-25 08:43 -1000
                Re: I Don't Make Mistakes. I Use C Paul Rubin <no.email@nospam.invalid> - 2012-10-25 12:18 -0700
                Re: I Don't Make Mistakes. I Use C "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-26 19:55 -0400
                  Re: I Don't Make Mistakes. I Use C "Elizabeth D. Rather" <erather@forth.com> - 2012-10-26 17:38 -1000
              Re: I Don't Make Mistakes. I Use C Brad Eckert <hwfwguy@gmail.com> - 2012-10-26 09:07 -0700
            Re: I Don't Make Mistakes. I Use C "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-26 19:56 -0400
              Re: I Don't Make Mistakes. I Use C "Elizabeth D. Rather" <erather@forth.com> - 2012-10-26 17:47 -1000
                Re: I Don't Make Mistakes. I Use C Paul Rubin <no.email@nospam.invalid> - 2012-10-26 22:04 -0700
                  Re: I Don't Make Mistakes. I Use C visualforth@rocketmail.com - 2012-10-27 07:27 -0700
                    Re: I Don't Make Mistakes. I Use C Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-27 19:14 +0200
      Re: I Don't Make Mistakes. I Use C Brad Eckert <hwfwguy@gmail.com> - 2012-10-24 11:48 -0700
        Re: I Don't Make Mistakes. I Use C rickman <gnuarm@gmail.com> - 2012-10-25 19:14 -0400
    Re: I Don’t Make Mistakes. I Use C Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-10-24 10:41 -0700
      Re: I Don’t Make Mistakes. I Use C Pavel Klinkovsky <pavel.klinkovsky@gmail.com> - 2012-10-24 13:10 -0700
        Re: I Don’t Make Mistakes. I Use C "Elizabeth D. Rather" <erather@forth.com> - 2012-10-24 14:00 -1000
          Re: I Don’t Make Mistakes. I Use C Pavel Klinkovsky <pavel.klinkovsky@gmail.com> - 2012-10-24 23:54 -0700
        Re: I Don't Make Mistakes. I Use C "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-25 00:29 -0400
          Re: I Don't Make Mistakes. I Use C Paul Rubin <no.email@nospam.invalid> - 2012-10-24 22:25 -0700
            Re: I Don't Make Mistakes. I Use C Pavel Klinkovsky <pavel.klinkovsky@gmail.com> - 2012-10-24 23:57 -0700
          Re: I Don't Make Mistakes. I Use C Pavel Klinkovsky <pavel.klinkovsky@gmail.com> - 2012-10-25 00:11 -0700
      Re: I Don’t Make Mistakes. I Use C visualforth@rocketmail.com - 2012-10-24 16:14 -0700
        Re: I Don’t Make Mistakes. I Use C Paul Rubin <no.email@nospam.invalid> - 2012-10-24 17:16 -0700
          Re: I Don’t Make Mistakes. I Use C visualforth@rocketmail.com - 2012-10-24 17:47 -0700
        Re: I Don’t Make Mistakes. I Use C rickman <gnuarm@gmail.com> - 2012-10-25 10:17 -0400

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#16729 — Re: I Don?t Make Mistakes. I Use C

On 10/25/12 6:53 PM, Paul Rubin wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>> Well, if pigs could fly ...  I don't believe for a moment that
>> programmers are anything like N x more productive than we were.  It
>> helps to have faster computer so we aren't waiting for things to
>> happen, but the complexity of the systems we use has increased which
>> soaks up a fair bit of that performance improvement.
>
> The faster and much more capacious computers doesn't just mean you're
> not waiting for things, it means you can use pre-existing tools that are
> overkill for the problem at hand just because it's convenient and you
> finish faster.  E.g. instead of spending N months implementing a
> database as part of the system, you'd spend an afternoon setting up an
> SQL server.  Instead of implementing custom message formats and
> communications layers you'd use AMQP or web services or whatever.
> Instead of intricately coded character-oriented screen UI's (I worked on
> those and it was painful) you'd serve some simple web pages and access
> them with browsers.  That doesn't even get to using languages that can
> juggle strings, nested structures, etc. natively, like anything
> reasonable today can.  The programs wouldn't fit in PDP-11's any more,
> but that's not relevant.

The problem is, you're judging Forth by the Standard. Every major 
implementation goes way beyond the standard. FORTH, Inc. has had an 
efficient database system since the 70's (significantly upgraded in the 
late 80's). Likewise existing communication services, using web services 
where appropriate. We have a vast arsenal of tools appropriate to the 
kinds of projects we do, and our customers have, on top of that, 
extensive libraries that are specific to their application domains.

A lot of the folks here are having fun implementing a simple, stripped 
down Forth because it's an interesting exercise. Folks who are serious 
about writing significant applications know where to find the 
professional-level Forth systems they need.

> I put up a url recently (definitely not scientific, but plausible)
> claiming software productivity doubles every 6 years:
>
>     http://people.cs.umass.edu/~yannis/law.html
>
> Look at some SPOJ problems ( http://www.spoj.pl/problems/classical/ )
> and think of how long it would take to do them in Forth compared to
> other possibilities.  This is more of the same.

I can't guess how long it would take to do any of those in any language, 
but I don't see anything there even remotely relevant to the kinds of 
work we do, so I'm not sure why we'd bother. But I seriously doubt it 
would take longer in Forth. A while back we were talking to a customer 
who complained that he couldn't possibly use Forth because we didn't 
have an FFT. We got it working in an hour.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

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

#16730

On 10/25/12 5:14 PM, Paul Rubin wrote:
> "Elizabeth D. Rather" <erather@forth.com> writes:
>> In one such project, the now-famous Saudi airport, the Forth team
>> completed in 18 months (27 man-years) a huge project on which 30
>> programmers had previously labored for 3 years (90 man-years), using
>> the most powerful programming tools available at the time, and
>> completed about 1/4 of the project with unacceptable timing
>> performance.
>
> Right, that was what, the 1980's?  The other stuff available at that
> time was terrible compared to what's around now, as were large
> organizations' development processes.  Of course Forth has gotten better
> too, but by as large a factor?  If Forth is 3x better than before and
> the other stuff is 50x better than before, the advantage has moved to
> the other side.

Unfortunately, there are no objective measures. Our customers, many of 
whom are using multiple languages and tool chains in various projects, 
still feel Forth has the edge in the projects in which they're using it.

>> the unsuccessful programming team... all were employees of a major
>> aerospace firm.
>
> That does sound like a recipe for bureaucracy and bloat.
>
>> The airport is currently advertising for Forth programmers, btw.
>
> Now THAT is interesting, and may be worth making a separate post about,
> in case some clf'er wants to apply.  (Assuming Forth Inc. doesn't
> already have the situation under control).

We're looking into it. :-)

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

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

#16731

"Elizabeth D. Rather" <erather@forth.com> writes:
> Unfortunately, there are no objective measures. Our customers, many of
> whom are using multiple languages and tool chains in various projects,
> still feel Forth has the edge in the projects in which they're using it.

That sounds reasonable.  I think Forth's strengths have never been in
the area of highly complex projects, even if you've done some successful
ones with it.  There are other areas where its advantages are still
relevant.

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

#17468

On Fri, 26 Oct 2012 01:51:33 -0000, Elizabeth D. Rather  
<erather@forth.com> wrote:

> On 10/25/12 11:16 AM, Paul Rubin wrote:
>> rickman <gnuarm@gmail.com> writes:
>>> If you can get the "smartest and most professional" programmers, I
>>> think nearly any language will do the job.
>>
>> "Smartest and most professional programmers" is a platitude anyway,
>> because of the bell curve.  They are out there but they are choosing
>> their own projects, running their own companies, etc.  And beyond that
>> layer, they're in academia, gathering up Fields medals, Nobel prizes,
>> and beyond even that routine Nobel Prize level, there's a guy at IAS
>> whose intellect has been compared in print to Isaac Newton's.
>
> Well, I did say "the smartest and most professional folks *you can  
> find*" :-) But I've been on projects staffed with the first <n> warm  
> bodies available at a low salary, as well as projects staffed with  
> hand-picked people, and I know for

<a fact
one person's experience
  that the 2nd kind gets the
> project done both quicker and cheaper, even though their salaries may be  
> much higher.


or it maybe that the projects that used s&mpfycf were better thought out  
in the first place.
[]

> In one such project, the now-famous Saudi airport, the Forth team  
> completed in 18 months (27 man-years) a huge project on which 30  
> programmers had previously labored for 3 years (90 man-years), using the  
> most powerful programming tools available at the time, and completed  
> about 1/4 of the project with unacceptable timing performance. Obviously  
> I know nothing of the skill level of the unsuccessful programming team,  
> but they all were employees of a major aerospace firm. The airport is  
> currently advertising for Forth programmers, btw.


This seems to be the zenith; not a routine example.


of course they require forth programmers, the system is written in that  
language; similarly C or COBOL or etc req those with the original skillset  
to maintain it.

> Cheers,
> Elizabeth
>


-- 
It's a money /life balance.

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

#16643 — Re: I Don't Make Mistakes. I Use C

<visualforth@rocketmail.com> wrote in message
news:e1c3e806-7d00-4d8c-92c2-b83d328057bc@googlegroups.com...
...

> I was recently at Design East in Boston. The show is changing
> with more of a slant towards software and hardware tools. I
> met with a number of companies like AdaCore and LDRA.
> One topic we always tend to talk about is the challenge of
> convincing C/C++ programmers that static and dynamic analysis
> tools are more than expensive tools or that Ada is more
> than a military programming language.
>
> One idea that came up a number of times in slightly different
> terms is that many programmers think other people make
> mistakes [...]

They do.  Everyone does.

> [...] but if they do then they can find and fix them [...]

That depends entirely on the circumstances.

a) Is the error immediately obvious?  E.g., crash, corrupt text, ...
b) Does the programmer understand what the code and data should be, or is
someone else confirming the results?  E.g., an accountant or an engineer ...
c) What type of testing is being done?  E.g., incremental as-you-go, static,
dynamic, ...
d) Is the program simple enough that the programmer understands it?
e) Is the error the result of some complex interaction of code changes by
multiple programmers?

Etc.

> [...] or they will be unimportant.

That can be either true or false or even change.  The error may be
unimportant for a decade, then it's not.  It depends on the circumstances,
e.g., the first virus ever to exploit the mistake, or the accountants
finally asked why a number was negative on the report, etc.

> The bottom line is "I don't make mistakes."

I think you misunderstood.  I doubt anyone was actually claiming they don't
make mistakes.  More likely, they know their company's process and believe
it's robust enough that few errors are made.

> Of course no one would admit to this.

If it's a major error, they could get fired.  But, more typically, they have
a process in place to detect errors, have users report errors, and to fix
errors as they are found.

> Anyone who has programmed knows that mistakes occur
> and that bugs can cause major problems.

They also know there are many different types of coding mistakes, not just
syntax errors.

> The problem with tools like C and C++ is that they are powerful
> but it is all too easy to shoot oneself in the foot...
...

> The cost of finding and fixings bugs has not really changed a lot.
> Figure a factor of ten in cost for each step software moves away
> from the programmer.
...

> The big difference is that it is now possible to significantly reduce
> the number of bugs in the field. It has to do more with using the
> right tools rather than whether you don't make mistakes because
> you will.
...

> So what about Ada?

You tell us.

> I know that few C/C++ programmers will switch but it is not as if
> I have not made the recommendation before (see C Programmers,
> Time To Try Ada [link]
...

> ... Ada is what I would pick over C or C++ for embedded projects.
>

Let's exclude the "without bugs" claim below.  Why?  Bugs are generally not
a consideration as to why you'd pick a language for an embedded environment.
The ability to generate code for the embedded environment is the primary
concern.  C and Forth are both well suited to that.  C++ is not, IMO.  Most
other languages aren't either.  So, other than supposedly fewer bugs, why
would you use Ada in an embedded environment?  What features does Ada have
which makes it good for embedded projects?  Pointers?  Good fit to the
machine model?  What features does it have that C and Forth don't have?
What features makes Ada better?

> Why? Because it is easier to write programs without bugs with Ada
> compared to C++ and definitely better than C.

1) Is Ada actually available for an embedded target?  (non-military)

2) Something must be substantially better than other solutions, and at a
lower cost point, to be adopted.  Ada may be - arguably - better at allowing
programmers to "write programs without bugs", but are the costs of hiring an
Ada programmer less than that of a C programmer?  No.  Forth?  No.  COBOL?
No.  Fortran?  No.  Lisp?  No.  Etc...

Most companies only measure two things: the immediate short-term cost of
something, and the timeliness of hourly workers.  That's it.  They don't
measure quality.  They don't measure performance.  They don't measure
intelligence.  The measure the immediate cost because it comes out of cash
flow and like most families have little or no savings to make expensive
purchases without financing.  Why they measure the timeliness of hourly
workers is beyond my comprehension.  I've seen companies fire skilled,
long-term, well trained employees simply because they were a few minutes
late to work.  It's impossible to replace such a person without incurring
large costs.  I.e., they'll choose the short term low cost solution over the
solution which is best for the company every time.  They'll lease a $1000
server for $5000 total if they can afford the monthly lease payment.
They'll hire 3 inexpensive C programmers to do the job of one expert
programmer in another language.  They'll fire the most intelligent employees
the company has because they currently have no work for them.  They'll keep
the cheap and "dumb" employees because they have work for them.

> Excerpt from "I Don't Make Mistakes. I Use C"
> Source: [link]

The second link at least lists some of the ways to reduce bugs for C.  You
didn't mention them in this thread and discounted them in your earlier
statements.

Also, were you quoting your own articles or someone else's?

> What about Forth ?

Forth should be far worse for bugs.  Interpreted Forth has no error checking
whatsoever.  I.e., few or no bugs will be detected.  If it's compiled Forth,
the errors which are detected is entirely up to the compiler author.  One
Forth compiler might detect everything whereas another won't check anything.
C compilers check for incompatible types and a fairly standard set of
various other common C coding errors.


Rod Pemberton

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

#16660 — Re: I Don't Make Mistakes. I Use C

On 10/24/12 12:55 AM, Rod Pemberton wrote:
...
>> What about Forth ?
>
> Forth should be far worse for bugs.  Interpreted Forth has no error checking
> whatsoever.  I.e., few or no bugs will be detected.  If it's compiled Forth,
> the errors which are detected is entirely up to the compiler author.  One
> Forth compiler might detect everything whereas another won't check anything.
> C compilers check for incompatible types and a fairly standard set of
> various other common C coding errors.

*Sigh* We've been down this road so often!

1. No Forth is "interpreted" in the classical sense (e.g. Basic). ITC 
Forth is compiled into addresses that can be processes very efficiently 
in a competently written implementation.

2. All Forths have some error checking, e.g. for undefined words, stack 
underflow at the user interface, etc. Some do more.

3. Forth is designed for intelligent programmers who prefer to assume 
responsibility for their work rather than relying on a "godlike" 
compiler to do their thinking for them.

4. Forth's extreme modularity makes it so much easier for programmers to 
test their work that Forth applications are at least as reliable as 
applications written in other languages.

5. No, Forth doesn't do type checking. It could, and programs such as 
StrongForth have tried it. StrongForth never caught on. Programmers want 
to get their work done: if type checking actually helped, Forth 
programmers would implement and use it.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

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

#16680 — Re: I Don't Make Mistakes. I Use C

"Elizabeth D. Rather" <erather@forth.com> wrote in message
news:arKdnVMSfeE6rRXNnZ2dnUVZ_s6dnZ2d@supernews.com...
> On 10/24/12 12:55 AM, Rod Pemberton wrote:
...

> >> What about Forth ?
> >
> > Forth should be far worse for bugs.  Interpreted Forth has no error
> > checking whatsoever.  I.e., few or no bugs will be detected.  If it's
> > compiled Forth, the errors which are detected is entirely up to the
> > compiler author.  One Forth compiler might detect everything
> > whereas another won't check anything.  C compilers check for
> > incompatible types and a fairly standard set of various other
> > common C coding errors.
>
> *Sigh* We've been down this road so often!
>
> 1. No Forth is "interpreted" in the classical sense (e.g. Basic). ITC
> Forth is compiled into addresses that can be processes very efficiently
> in a competently written implementation.
>

My Forth interpreter is ITC ...

> 2. All Forths have some error checking, e.g. for undefined words, stack
> underflow at the user interface, etc. Some do more.

Yes, but that's very trivial.  How does that detect any serious programming
mistakes?  (rhetorical)

> 3. Forth is designed for intelligent programmers who prefer to assume
> responsibility for their work rather than relying on a "godlike"
> compiler to do their thinking for them.

That was the entire point of "visualforth's" statment.  Even programmers who
"assume responsibility for their work", like experienced and skilled C
programmers using coding standards to prevent mistakes, still make mistakes.
He's claiming the language, it's syntax, it's design, is what prevents or
reduces coding errors.  That's why he suggested Ada.

> 4. Forth's extreme modularity makes it so much easier for programmers to
> test their work that Forth applications are at least as reliable as
> applications written in other languages.

It's easy to test as-you-go in C also.  It's called printf().  Even so,
"visualforth" is claiming that errors are still made in C.  That's true.
With fewer checks than C, I don't see how Forth can be any _less_
error prone than C.

> 5. No, Forth doesn't do type checking. It could, and programs such as
> StrongForth have tried it. StrongForth never caught on. Programmers want
> to get their work done: if type checking actually helped, Forth
> programmers would implement and use it.

C programmers didn't like the void types and pointers added to ANSI C.  They
didn't believe they were needed.  Some still don't.  However, the type
checking for them has caught numerous coding errors.  "Forth" seems to be in
the same state of denial that C was.


Rod Pemberton

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

#16687 — Re: I Don't Make Mistakes. I Use C

"Rod Pemberton" <do_not_have@notemailnotz.cnm> writes:
> It's easy to test as-you-go in C also.  It's called printf().

Really, thats not comparable, that's why debuggers like gdb exist.
Sometimes I think of Forth as a glorified scriptable debugger that
you can write your whole application in.

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

#16693 — Re: I Don't Make Mistakes. I Use C

On 10/24/12 6:23 PM, Rod Pemberton wrote:
> "Elizabeth D. Rather" <erather@forth.com> wrote in message
> news:arKdnVMSfeE6rRXNnZ2dnUVZ_s6dnZ2d@supernews.com...
>> On 10/24/12 12:55 AM, Rod Pemberton wrote:
> ...
>
>>>> What about Forth ?
>>>
>>> Forth should be far worse for bugs.  Interpreted Forth has no error
>>> checking whatsoever.  I.e., few or no bugs will be detected.  If it's
>>> compiled Forth, the errors which are detected is entirely up to the
>>> compiler author.  One Forth compiler might detect everything
>>> whereas another won't check anything.  C compilers check for
>>> incompatible types and a fairly standard set of various other
>>> common C coding errors.
>>
>> *Sigh* We've been down this road so often!
>>
>> 1. No Forth is "interpreted" in the classical sense (e.g. Basic). ITC
>> Forth is compiled into addresses that can be processes very efficiently
>> in a competently written implementation.
>
> My Forth interpreter is ITC ...


So you must know that it's misleading to call it an interpreter.


>> 2. All Forths have some error checking, e.g. for undefined words, stack
>> underflow at the user interface, etc. Some do more.
>
> Yes, but that's very trivial.  How does that detect any serious programming
> mistakes?  (rhetorical)


Serious programming mistakes are logical errors. No compilers can check 
for that. Testing can.


>> 3. Forth is designed for intelligent programmers who prefer to assume
>> responsibility for their work rather than relying on a "godlike"
>> compiler to do their thinking for them.
>
> That was the entire point of "visualforth's" statment.  Even programmers who
> "assume responsibility for their work", like experienced and skilled C
> programmers using coding standards to prevent mistakes, still make mistakes.
> He's claiming the language, it's syntax, it's design, is what prevents or
> reduces coding errors.  That's why he suggested Ada.

Successful Forth programmers also use coding standards. They just don't 
expect a "god" compiler to enforce them. But no coding standards can 
prevent logical errors, which are the most common and most serious.


>> 4. Forth's extreme modularity makes it so much easier for programmers to
>> test their work that Forth applications are at least as reliable as
>> applications written in other languages.
>
> It's easy to test as-you-go in C also.  It's called printf().  Even so,
> "visualforth" is claiming that errors are still made in C.  That's true.
> With fewer checks than C, I don't see how Forth can be any _less_
> error prone than C.

You obviously haven't written any serious programs in Forth, or learned 
good Forth debugging techniques. printf() as a debugging tool is a 
horselaugh.


>> 5. No, Forth doesn't do type checking. It could, and programs such as
>> StrongForth have tried it. StrongForth never caught on. Programmers want
>> to get their work done: if type checking actually helped, Forth
>> programmers would implement and use it.
>
> C programmers didn't like the void types and pointers added to ANSI C.  They
> didn't believe they were needed.  Some still don't.  However, the type
> checking for them has caught numerous coding errors.  "Forth" seems to be in
> the same state of denial that C was.

If you set hurdles all over the place, some people will stumble over them.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

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

#16702 — Re: I Don't Make Mistakes. I Use C

"Elizabeth D. Rather" <erather@forth.com> writes:
>> My Forth interpreter is ITC ...
> So you must know that it's misleading to call it an interpreter.

Of course you know such implementations are usually described as having
a text interpreter and an address interpreter.  

> Serious programming mistakes are logical errors. No compilers can
> check for that. Testing can.

Compilers certainly do check for logical errors, sometimes quite
effectively.  Of course they can't check for ALL possible logical
errors, and the error checks constrain the user's programming style,
creating trade-offs.  It's a perennial topic of debate whether a given
trade-off is good or bad, but to say the checking doesn't catch (some)
actual logical errors is just silly.

> Successful Forth programmers also use coding standards. They just
> don't expect a "god" compiler to enforce them.

The compiler checks aren't god-like, they're just mechanisms.  Like the
warning buzzer in a car that alerts you if you turn off the motor with
the headlamps on.  Maybe a good thing, maybe bad, but fairly
straightforward either way.

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

#16704 — Re: I Don't Make Mistakes. I Use C

On 10/25/12 8:21 AM, Paul Rubin wrote:
> "Elizabeth D. Rather" <erather@forth.com> writes:
>>> My Forth interpreter is ITC ...
>> So you must know that it's misleading to call it an interpreter.
>
> Of course you know such implementations are usually described as having
> a text interpreter and an address interpreter.

Of course. Within the Forth community we understand these terms. In the 
wide world of computing, there's a different connotation. From Wikipedia:

"In computer science, an interpreter normally means a computer program 
that executes, i.e. performs, instructions written in a programming 
language. An interpreter may be a program that either

     1. executes the source code directly.

     2. translates source code into some efficient intermediate 
representation (code) and immediately executes this.

     3. explicitly executes stored precompiled code made by a compiler 
which is part of the interpreter system.

Early versions of the Lisp programming language and Dartmouth BASIC 
would be examples of type 1. Perl, Python, MATLAB, and Ruby are examples 
of type 2, while UCSD Pascal is an example of type 3.

Forth mostly fits #3, but I think the common understanding of 
"interpreter" is 1 or 2. Particularly when you say something like, 
"Interpreted Forth has no error checking whatsoever" (in this thread) or 
"Forth is slow, because it's interpreted" (a common statement from 
people with only a vague understanding of Forth) you're ignoring the 
reality of mainstream Forth technology. Even 70's ITC Forths had a very 
useful level of error checking (I don't consider type checking useful 
:-) and good implementations had excellent performance.

>> Serious programming mistakes are logical errors. No compilers can
>> check for that. Testing can.
>
> Compilers certainly do check for logical errors, sometimes quite
> effectively.  Of course they can't check for ALL possible logical
> errors, and the error checks constrain the user's programming style,
> creating trade-offs.  It's a perennial topic of debate whether a given
> trade-off is good or bad, but to say the checking doesn't catch (some)
> actual logical errors is just silly.

How does a compiler detect that the programmer wasn't thinking clearly 
about how to do this operation?

>> Successful Forth programmers also use coding standards. They just
>> don't expect a "god" compiler to enforce them.
>
> The compiler checks aren't god-like, they're just mechanisms.  Like the
> warning buzzer in a car that alerts you if you turn off the motor with
> the headlamps on.  Maybe a good thing, maybe bad, but fairly
> straightforward either way.

A good Forth implementation has a useful level of error checking. We 
just disagree on what constitutes "useful".

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

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

#16706 — Re: I Don't Make Mistakes. I Use C

"Elizabeth D. Rather" <erather@forth.com> writes:
> Forth mostly fits #3, but I think the common understanding of
> "interpreter" is 1 or 2.

No really, that's a rationalization that we hear on comp.lang.python all
the time too (CPython is a bytecode interpreter).  More commonly, an
interpreter is a program that loops over some representation of the user
program and executes the stuff in the representation.  E.g. CPython uses
bytecodes as the representation, a naive Lisp recursively evaluates
trees of cons cells in memory, and ITC has lists of addresses.
Something like Swift is an actual compiler.

> Particularly when you say something like, "Interpreted Forth has no
> error checking whatsoever" (in this thread) or "Forth is slow, because
> it's interpreted" (a common statement from people with only a vague
> understanding of Forth)

"No error checking whatsoever" is certainly bogus.  "Slow" is relative
to compiled code and I don't think an ITC Forth can avoid a substantial
speed disadvantage compared to compiled Forth or C.

> Even 70's ITC Forths had a very useful level of error checking (I
> don't consider type checking useful :-) and good implementations had
> excellent performance.

From what I can tell, they did have excellent performance compared to
other interpreted languages of the era, such as BASIC.  I don't see how
they could have approached the performance of competitive compiled code
even from that era (I guess that means Fortran etc.)

> How does a compiler detect that the programmer wasn't thinking clearly
> about how to do this operation?

Unclarity of thought often results in a type error that the compiler can
catch.  A trivial C example: you have a data structure with the address
of a float, and that slot containing the address itself has an address,
that might be held in some variable:

   float **p;  // p is a pointer to a pointer to a float

Now if you get confused about the data layout, you might dereference p
expecting to get the float directly, when in fact you have to
dereference it again:

   float x = *p;  // ERROR

the compiler spots that dereferencing p once gets you another pointer,
not a float, and tells you what went wrong.

> A good Forth implementation has a useful level of error checking. We
> just disagree on what constitutes "useful".

C programmers say things like that all the time too ;-). 

http://www.altdevblogaday.com/2011/12/24/static-code-analysis/
is by a well-known C programmer who recently saw the light ;-).

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

#16751 — Re: I Don't Make Mistakes. I Use C

"Elizabeth D. Rather" <erather@forth.com> wrote in message
news:F7CdnfKu9NzOFRTNnZ2dnUVZ_rOdnZ2d@supernews.com...
> On 10/25/12 8:21 AM, Paul Rubin wrote:
> > "Elizabeth D. Rather" <erather@forth.com> writes:
> > > [Rod Pemberton wrote:]
...

[You are snipping one too many reply authors above...]
[4 indents below matches 3 above]

> >>> My Forth interpreter is ITC ...
> >> So you must know that it's misleading to call it an interpreter.
> >
> > Of course you know such implementations are usually described as having
> > a text interpreter and an address interpreter.
>
> Of course. Within the Forth community we understand these terms. In the
> wide world of computing, there's a different connotation. From Wikipedia:
>
> "In computer science, an interpreter normally means a computer program
> that executes, i.e. performs, instructions written in a programming
> language. An interpreter may be a program that either
>
>      1. executes the source code directly.
>
>      2. translates source code into some efficient intermediate
> representation (code) and immediately executes this.
>
>      3. explicitly executes stored precompiled code made by a compiler
> which is part of the interpreter system.
>
> Early versions of the Lisp programming language and Dartmouth BASIC
> would be examples of type 1. Perl, Python, MATLAB, and Ruby are examples
> of type 2, while UCSD Pascal is an example of type 3.
>

I'll take it this reply to Paul...
is what you meant earlier in reply to me (Rod) about Forth not actually
being an interpreter, i.e., two interpreters...

Paul mentioned the two classic Forth interpreters above.  Mine has both.
Even so, my Forth is ITC.  ITC is the method used by inner/address
interpreter, not the outer/text interpreter.

> Forth mostly fits #3, but I think the common understanding of
> "interpreter" is 1 or 2. Particularly when you say something like,
> "Interpreted Forth has no error checking whatsoever" (in this thread) or
> "Forth is slow, because it's interpreted" (a common statement from
> people with only a vague understanding of Forth) you're ignoring the
> reality of mainstream Forth technology. Even 70's ITC Forths had a very
> useful level of error checking (I don't consider type checking useful
> :-) and good implementations had excellent performance.
>

I said those things, not Paul ...  although he responded similarly,
if someone thought he was me.

All interpreters are slow, as compared to compiled code.  This has nothing
to do with Forth.  All interpreters re-implement the processor, in one way
or another, in software.  It's technically impossible for an interpreter to
be as fast has the native hardware.

What error checking does interpreted Forth have?  At best, it's trivial
things that you've already mentioned, e.g., stack under/overflow.  Does it
do anything important?  E.g., what checks does it do to prevent any integer
on the stack from being used as an xt?  E.g., what does it do to ensure only
correct return values on the return stack are used by EXIT/SEMIS?  E.g.,
what does it do to ensure ALLOT points the dictionary pointer to a valid
location?  (You know full well that ALLOT in an interpreted Forth is just
"DP +!" ...  I.e., no checking on DP's value.)  I.e., there are many ways to
"abuse" interpreted Forth's sufficiently that they'll crash or produce
incorrect data or corrupted data.  Sequencing of Forth words is another such
issue.  E.g., some Forth require using ALLOT _prior to_ storing a value into
the dictionary, versus immediately after storing a value.  Nothing else
should be writing to the dictionary.  Some such issues are probably
environment specific.  But, I bet if I were to start to attack various
Forths, that I'd find many such issues are common across multiple platforms.

> >> Serious programming mistakes are logical errors. No compilers can
> >> check for that. Testing can.
> >
> > Compilers certainly do check for logical errors, sometimes quite
> > effectively.  Of course they can't check for ALL possible logical
> > errors, and the error checks constrain the user's programming style,
> > creating trade-offs.  It's a perennial topic of debate whether a given
> > trade-off is good or bad, but to say the checking doesn't catch (some)
> > actual logical errors is just silly.
>
> How does a compiler detect that the programmer wasn't thinking clearly
> about how to do this operation?
>

Since Paul said that, I'll let him respond to it.

> >> Successful Forth programmers also use coding standards. They just
> >> don't expect a "god" compiler to enforce them.
> >
> > The compiler checks aren't god-like, they're just mechanisms.  Like the
> > warning buzzer in a car that alerts you if you turn off the motor with
> > the headlamps on.  Maybe a good thing, maybe bad, but fairly
> > straightforward either way.
>
> A good Forth implementation has a useful level of error checking. We
> just disagree on what constitutes "useful".
>

We?  Which "we" ... ?  You two are confusing me.

I don't think you realized Paul responded to you, and you responded to him
without realizing it wasn't me.  That may have something to do with you
snipping me as one of the people you replied to.  :-)  Paul didn't indicate,
if he realized it, that you were replying to him thinking it was me.


Rod Pemberton

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

#16758 — Re: I Don't Make Mistakes. I Use C

On 10/26/12 1:55 PM, Rod Pemberton wrote:
> "Elizabeth D. Rather" <erather@forth.com> wrote in message
...
> What error checking does interpreted Forth have?  At best, it's trivial
> things that you've already mentioned, e.g., stack under/overflow.  Does it
> do anything important?  E.g., what checks does it do to prevent any integer
> on the stack from being used as an xt?  E.g., what does it do to ensure only
> correct return values on the return stack are used by EXIT/SEMIS?

Those are all faults that will show up very quickly in testing. No point 
in complicating your compiler trying to detect them.

> E.g.,
> what does it do to ensure ALLOT points the dictionary pointer to a valid
> location?  (You know full well that ALLOT in an interpreted Forth is just
> "DP +!" ...  I.e., no checking on DP's value.)

That's actually something that many Forth compilers check for. It's 
really quite easy. An ALLOT that's no more than DP +! is a pretty sorry 
implementation.

> I.e., there are many ways to
> "abuse" interpreted Forth's sufficiently that they'll crash or produce
> incorrect data or corrupted data.  Sequencing of Forth words is another such
> issue.  E.g., some Forth require using ALLOT _prior to_ storing a value into
> the dictionary, versus immediately after storing a value.  Nothing else
> should be writing to the dictionary.  Some such issues are probably
> environment specific.  But, I bet if I were to start to attack various
> Forths, that I'd find many such issues are common across multiple platforms.

So long as you follow the rule that you should ALLOT first, you'll be fine.

...
>>
>> A good Forth implementation has a useful level of error checking. We
>> just disagree on what constitutes "useful".
>>
>
> We?  Which "we" ... ?  You two are confusing me.

You: Rod, and I disagree on what constitutes useful error checking.

> I don't think you realized Paul responded to you, and you responded to him
> without realizing it wasn't me.  That may have something to do with you
> snipping me as one of the people you replied to.  :-)  Paul didn't indicate,
> if he realized it, that you were replying to him thinking it was me.

I am quite clear as to who said what in this thread.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

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

#16738 — Re: I Don't Make Mistakes. I Use C

On Thursday, October 25, 2012 11:21:47 AM UTC-7, Paul Rubin wrote:
> 
> Compilers certainly do check for logical errors, sometimes quite
> effectively.  Of course they can't check for ALL possible logical
> errors, and the error checks constrain the user's programming style,
> creating trade-offs.  It's a perennial topic of debate whether a given
> trade-off is good or bad, but to say the checking doesn't catch (some)
> actual logical errors is just silly.

Maybe static checking should be the domain of the editor. Consider Visual Studio's editor, which hilights errors in realtime. Edit time is the best time to tell you when you're doing something corny, so you can immediately fix it.

An editor should be able to verify stack comments (excepting yeahbuts like use of words with variable stack effects) and actually parse the source files so it can let you navigate the cross reference structure. Basically an editor with a built-in Forth. Possibly a heavily instrumented Forth that performs run time type checks as well.

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

#16752 — Re: I Don't Make Mistakes. I Use C

"Elizabeth D. Rather" <erather@forth.com> wrote in message
news:8fSdnSe9ZpDgcxXNnZ2dnUVZ_oCdnZ2d@supernews.com...
> On 10/24/12 6:23 PM, Rod Pemberton wrote:
> > "Elizabeth D. Rather" <erather@forth.com> wrote in message
> > news:arKdnVMSfeE6rRXNnZ2dnUVZ_s6dnZ2d@supernews.com...
> >> On 10/24/12 12:55 AM, Rod Pemberton wrote:
> >> > [visualforth wrote]
...

> >>>> What about Forth ?
> >>>
> >>> Forth should be far worse for bugs.  Interpreted Forth has no error
> >>> checking whatsoever.  I.e., few or no bugs will be detected.  If it's
> >>> compiled Forth, the errors which are detected is entirely up to the
> >>> compiler author.  One Forth compiler might detect everything
> >>> whereas another won't check anything.  C compilers check for
> >>> incompatible types and a fairly standard set of various other
> >>> common C coding errors.
> >>
> >> *Sigh* We've been down this road so often!
> >>
> >> 1. No Forth is "interpreted" in the classical sense (e.g. Basic). ITC
> >> Forth is compiled into addresses that can be processes very efficiently
> >> in a competently written implementation.
> >
> > My Forth interpreter is ITC ...
>
>
> So you must know that it's misleading to call it an interpreter.
>

What ... ?  What ever do you mean?

An interperter is a program which doesn't use compiled code to execute the
program.  Most are characterized by a loop which is used to interpret
program data and decide what language routines to execute.  There are four
widely known types interpreters: DTC, ITC, STC, TTC.  STC is the exception
to the standard characteristics.  It's a form of assembly or machine code.
Most classic Basic's are TTC intepreters, which are typically called
"bytecode" interpreters by those unfamiliar with other types of
interpreters.

> >> 2. All Forths have some error checking, e.g. for undefined words, stack
> >> underflow at the user interface, etc. Some do more.
> >
> > Yes, but that's very trivial.  How does that detect any serious
> > programming mistakes?  (rhetorical)
>
> Serious programming mistakes are logical errors. No compilers can check
> for that. Testing can.
>

Did you mean "logic"?  Or, did you actually mean "logical"...?

As for logic errors, let's say one person programs a block of code.  It does
exactly what he/she was told to have it do.  So, it's all correct logic
wise.  Now, let's say another person is required to write a block of code
that interacts with the original.  What he/she coded is entirely correct
logic wise too.  So, it too does exactly what he/she was told to have it do.
However, the combination of the two results in an error, i.e., an unforeseen
incompatibility.  It's clearly an error.  Was that a logic error?

> >> 4. Forth's extreme modularity makes it so much easier for programmers
> >> to test their work that Forth applications are at least as reliable as
> >> applications written in other languages.
> >
> > It's easy to test as-you-go in C also.  It's called printf().  Even so,
> > "visualforth" is claiming that errors are still made in C.  That's true.
> > With fewer checks than C, I don't see how Forth can be any _less_
> > error prone than C.
>
> You obviously haven't written any serious programs in Forth, or
> learned good Forth debugging techniques. printf() as a debugging
> tool is a horselaugh.

You mean I shouldn't be using .S to debug my Forth ... ?  Fine, I'll go back
to using . (dot) ...  ;-)

If I should be using .S , how is that any different?

Actually, I used . (dot) and now use .S with XDUMP, which is a "primitive"
in C.  XDUMP is like an enhanced version of DUMP but it also displays the
dictionary header of a word.


Rod Pemberton

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

#16759 — Re: I Don't Make Mistakes. I Use C

On 10/26/12 1:56 PM, Rod Pemberton wrote:
> "Elizabeth D. Rather" <erather@forth.com> wrote in message
...
>>> Yes, but that's very trivial.  How does that detect any serious
>>> programming mistakes?  (rhetorical)
>>
>> Serious programming mistakes are logical errors. No compilers can check
>> for that. Testing can.
>>
>
> Did you mean "logic"?  Or, did you actually mean "logical"...?
>
> As for logic errors, let's say one person programs a block of code.  It does
> exactly what he/she was told to have it do.  So, it's all correct logic
> wise.  Now, let's say another person is required to write a block of code
> that interacts with the original.  What he/she coded is entirely correct
> logic wise too.  So, it too does exactly what he/she was told to have it do.
> However, the combination of the two results in an error, i.e., an unforeseen
> incompatibility.  It's clearly an error.  Was that a logic error?

More to the point, is it something a compiler can detect?

>>>> 4. Forth's extreme modularity makes it so much easier for programmers
>>>> to test their work that Forth applications are at least as reliable as
>>>> applications written in other languages.
>>>
>>> It's easy to test as-you-go in C also.  It's called printf().  Even so,
>>> "visualforth" is claiming that errors are still made in C.  That's true.
>>> With fewer checks than C, I don't see how Forth can be any _less_
>>> error prone than C.
>>
>> You obviously haven't written any serious programs in Forth, or
>> learned good Forth debugging techniques. printf() as a debugging
>> tool is a horselaugh.
>
> You mean I shouldn't be using .S to debug my Forth ... ?  Fine, I'll go back
> to using . (dot) ...  ;-)
>
> If I should be using .S , how is that any different?
>
> Actually, I used . (dot) and now use .S with XDUMP, which is a "primitive"
> in C.  XDUMP is like an enhanced version of DUMP but it also displays the
> dictionary header of a word.

The point is that the whole strategy of developing and testing in Forth 
(including but not limited to the use of . .S DUMP and other 
diagnostics) is what makes the process so efficient and productive, and 
Forth code so reliable.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

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

#16760 — Re: I Don't Make Mistakes. I Use C

"Elizabeth D. Rather" <erather@forth.com> writes:
>> As for logic errors, let's say one person programs a block of code.  It does
>> exactly what he/she was told to have it do.  So, it's all correct logic
>> wise.  Now, let's say another person is required to write a block of code
>> that interacts with the original.  What he/she coded is entirely correct
>> logic wise too.  So, it too does exactly what he/she was told to have it do.
>> However, the combination of the two results in an error, i.e., an unforeseen
>> incompatibility.  It's clearly an error.  Was that a logic error?
>
> More to the point, is it something a compiler can detect?

It absolutely is, some of the time.  E.g., person A was told to write a
module with interface X, and person B was told to write a client for A's
module, using interface Y, where X is not equal to Y.  Lots of
mismatches of this sort are routinely caught by compilers.

More generally, a logic error is what happens when the programmer
believes two contradictory things and codes both beliefs into the
program (maybe at separate times).  Type errors are an obvious example
of this: over here xyz is an int, and over there it is a float.

Fancier compilers can spot contradictory beliefs in deeper ways:

  http://stanford.edu/~engler/deviant-sosp-01.pdf 

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

#16762 — Re: I Don't Make Mistakes. I Use C

On Saturday, October 27, 2012 1:04:20 AM UTC-4, Paul Rubin wrote:
> "Elizabeth D. Rather" <forth.com> writes: 
> > More to the point, is it something a compiler can detect? 
It absolutely is, some of the time. E.g., person A was told to write a module with interface X, and person B was told to write a client for A's module, using interface Y, where X is not equal to Y. Lots of mismatches of this sort are routinely caught by compilers. 

Using Forth you would get the error message

Y 
^
Error(-13): Y is undefined 
X 
^
Error(-13): X is undefined 

or something like that. Isn't that enough? 

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

#16772 — Re: I Don't Make Mistakes. I Use C

visualforth@rocketmail.com wrote:

> On Saturday, October 27, 2012 1:04:20 AM UTC-4, Paul Rubin wrote:
>> "Elizabeth D. Rather" <forth.com> writes:
>> > More to the point, is it something a compiler can detect?
> It absolutely is, some of the time. E.g., person A was told to write a
> module with interface X, and person B was told to write a client for
> A's module, using interface Y, where X is not equal to Y. Lots of
> mismatches of this sort are routinely caught by compilers.
> 
> Using Forth you would get the error message
> 
> Y
> ^
> Error(-13): Y is undefined
> X
> ^
> Error(-13): X is undefined
> 
> or something like that. Isn't that enough?

What he presumable means is that you say "the function will see a string 
on the stack, specified by address and length, and person A writes

: type ( len addr -- ) { addr } 0 ?DO addr i + c@ emit LOOP ;

and person B assumes that of course it's ( addr len -- ) and tries

s" foo" type

which then crashes, instead of printing a type error.

The reason why this doesn't matter much in Forth is that Forth 
programmers acutally test their functions.  They don't just compile and 
are happy when that is done without error messages - it usually is, the 
real work starts after it compiles.

When I interface with external libraries or such, I generate my bindings 
with Swig (automatic), and then I start testing the words I use.  And 
then it goes "boom", "boom", "boom", because these C functions are 
mostly untested.  They compiled, yes.  Without error.  That's it.

Examples I had seen with the simple OpenGL terminal (using GL Shader 
Language) of Gforth for Android:

* The glUniformf variants (passing a float directly instead of a pointer 
as with glUniformfv) doesn't work with AMD/ATI's driver, and it doesn't 
report an error.  The value passed is simply always 0.

* The function mix(color1, color2, alpha), which should translate to 
color1*alpha+color2*(1-alpha) doesn't on my Defy+, there it maps to 
color1*alpha+color2.  WTF?  Didn't they test it?

* The array index in the GLSL works for static indices on Huawei's cheap 
phone, but not for variable indices (variables as index is the only 
meaningful reason to use an array).  Neither does this print an error 
message.  It obviously was simply untested - the test case apparently 
only had a static index.  Maybe the Khronos group should publish a 
comprehensive test suit for their standards.

IMHO it's a good thing that in Forth the compiler tells you almost 
nothing about the quality of your program.  Only simple typos are 
reported.  This means you *absolutely must* test it.  Because otherwise, 
it will definitely not work.  And there, Forth provides a lot of means 
to test without much effort.  If the compiler lulls you in false 
confidence about the quality of the program, you forget testing.  You 
still have to do it.  The type errors are minor compared to the logical 
errors.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

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

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

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

csiph-web