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

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

Re: The Lisp Curse

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: The Lisp Curse arc <arc@vorsicht-bissig.delete-me.de> - 2011-08-24 11:12 +0000
    Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-08-24 17:12 -0400
      Re: The Lisp Curse arc <arc.deletethis@vorsicht-bissig.de> - 2011-09-01 00:18 +1200
        Re: The Lisp Curse Fritz Wuehler <fritz@spamexpire-201109.rodent.frell.theremailer.net> - 2011-09-01 12:11 +0200
          Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-09-01 19:51 -0400
            Re: The Lisp Curse Fritz Wuehler <fritz@spamexpire-201109.rodent.frell.theremailer.net> - 2011-09-07 02:39 +0200
              Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-09-09 07:36 -0400
        Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-09-01 19:42 -0400
          Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-09-02 04:58 -0700
            Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-09-02 22:08 -0400
              Re: The Lisp Curse "Elizabeth D. Rather" <erather@forth.com> - 2011-09-02 18:23 -1000
              Re: The Lisp Curse Paul Rubin <no.email@nospam.invalid> - 2011-09-03 01:14 -0700
              Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-09-03 03:31 -0700
                Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-09-04 06:58 -0400
                  Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-09-04 09:30 -0700
                    Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-09-05 20:25 -0400
                      Re: The Lisp Curse Paul Rubin <no.email@nospam.invalid> - 2011-09-06 00:52 -0700
                        Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-09-09 07:37 -0400
                          Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-09-09 05:02 -0700
                            Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-09-09 08:48 -0400
                              Re: The Lisp Curse coos haak <chforth@hccnet.nl> - 2011-09-09 20:36 +0200
                              Re: The Lisp Curse George Hubert <georgeahubert@yahoo.co.uk> - 2011-09-09 13:09 -0700
                                Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-09-12 06:17 -0400
                                  Re: The Lisp Curse Paul Rubin <no.email@nospam.invalid> - 2011-09-14 01:15 -0700
                      Re: The Lisp Curse stephenXXX@mpeforth.com (Stephen Pelc) - 2011-09-06 07:50 +0000
                        Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-09-06 05:22 -0700
                          Re: The Lisp Curse stephenXXX@mpeforth.com (Stephen Pelc) - 2011-09-06 13:28 +0000
                            Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-09-06 07:18 -0700
                      Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-09-06 05:58 -0700
                        Re: The Lisp Curse Keith H Duggar <duggar@alum.mit.edu> - 2011-09-06 07:37 -0700
                        Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-09-09 08:50 -0400
                          Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-09-09 07:05 -0700
                            Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-09-12 06:40 -0400
                              Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-09-12 04:36 -0700
                                Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-09-12 05:01 -0700
                                  Re: The Lisp Curse coos haak <chforth@hccnet.nl> - 2011-09-15 21:05 +0200
          Re: The Lisp Curse stephenXXX@mpeforth.com (Stephen Pelc) - 2011-09-02 12:58 +0000
            Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-09-02 22:10 -0400
              Re: The Lisp Curse stephenXXX@mpeforth.com (Stephen Pelc) - 2011-09-03 08:55 +0000
                Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-09-04 06:41 -0400
              Re: The Lisp Curse David Thompson <dave.thompson2@verizon.net> - 2011-09-09 01:28 -0400
                Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-09-09 07:37 -0400
          Re: The Lisp Curse arc <arc.deletethis@vorsicht-bissig.de> - 2011-09-05 01:27 +1200
            Re: The Lisp Curse BruceMcF <agila61@netscape.net> - 2011-09-04 14:25 -0700
            Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-09-05 20:23 -0400
              Re: The Lisp Curse "Elizabeth D. Rather" <erather@forth.com> - 2011-09-05 16:09 -1000
                Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-09-05 23:00 -0700
                  Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-09-09 07:47 -0400
                    Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-09-10 18:38 -0700
                      Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-09-12 06:38 -0400
                Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-09-09 07:39 -0400
                  Re: The Lisp Curse "Elizabeth D. Rather" <erather@forth.com> - 2011-09-09 08:32 -1000
                    Re: The Lisp Curse Richard Owlett <rowlett@pcnetinc.com> - 2011-09-09 15:24 -0500
              Re: The Lisp Curse Paul Rubin <no.email@nospam.invalid> - 2011-09-06 00:48 -0700
                Re: The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-09-06 03:25 -0500
                Re: The Lisp Curse John Passaniti <john.passaniti@gmail.com> - 2011-09-08 05:59 -0700
                  Re: The Lisp Curse anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-09-08 13:27 +0000
                    Re: The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-09-08 09:15 -0500
                      Re: The Lisp Curse anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-09-08 14:24 +0000
                        Re: The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-09-08 10:11 -0500
                          Re: The Lisp Curse anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-09-08 15:46 +0000
                            Re: The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-09-08 11:45 -0500
                          Re: The Lisp Curse Paul Rubin <no.email@nospam.invalid> - 2011-09-08 10:31 -0700
                            Re: The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-09-08 12:47 -0500
                              Re: The Lisp Curse Paul Rubin <no.email@nospam.invalid> - 2011-09-14 01:40 -0700
                    Re: The Lisp Curse John Passaniti <john.passaniti@gmail.com> - 2011-09-08 13:51 -0700
                      Re: The Lisp Curse Keith H Duggar <duggar@alum.mit.edu> - 2011-09-09 10:18 -0700
                        Re: The Lisp Curse mhx@iae.nl (Marcel Hendrix) - 2011-09-09 21:03 +0200
                          Re: The Lisp Curse Keith H Duggar <duggar@alum.mit.edu> - 2011-09-09 12:35 -0700
                            Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-09-09 13:38 -0700
                        Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-09-12 06:36 -0400
                          Re: The Lisp Curse Keith H Duggar <duggar@alum.mit.edu> - 2011-09-12 06:43 -0700
                            Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-09-19 09:38 -0400
                      Re: The Lisp Curse Keith H Duggar <duggar@alum.mit.edu> - 2011-09-09 10:30 -0700
                        Re: The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-09-10 03:45 -0500
                      Re: The Lisp Curse Albert van der Horst <albert@spenarnc.xs4all.nl> - 2011-09-10 08:23 +0000
                  Re: The Lisp Curse vandys@vsta.org - 2011-09-08 16:09 +0000
                    Re: The Lisp Curse John Passaniti <john.passaniti@gmail.com> - 2011-09-08 13:38 -0700
                  Re: The Lisp Curse John Passaniti <john.passaniti@gmail.com> - 2011-09-08 20:04 -0700
                    Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-09-09 07:45 -0400
                      Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-09-09 05:34 -0700
                        Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-09-09 09:49 -0400
                          Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-09-09 09:43 -0700
                            Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-09-12 06:35 -0400
                              Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-09-12 03:57 -0700
                                Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-09-19 09:38 -0400
                                  Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-09-19 07:29 -0700
                                    Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-09-21 18:46 -0400
                      Re: The Lisp Curse John Passaniti <john.passaniti@gmail.com> - 2011-09-11 19:58 -0700
                        Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-09-12 06:30 -0400
                          Re: The Lisp Curse "Elizabeth D. Rather" <erather@forth.com> - 2011-09-12 08:53 -1000
                            Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-09-19 09:38 -0400
                              Re: The Lisp Curse stephenXXX@mpeforth.com (Stephen Pelc) - 2011-09-19 13:57 +0000
                  Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-09-09 07:43 -0400
                    Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-09-09 04:57 -0700
                      Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-09-09 08:51 -0400
                    Re: The Lisp Curse John Passaniti <john.passaniti@gmail.com> - 2011-09-11 17:40 -0700
                      Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-09-11 22:03 -0700
                        Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-09-12 06:45 -0400
                          Re: The Lisp Curse John Passaniti <john.passaniti@gmail.com> - 2011-09-13 22:46 -0700
                            Re: The Lisp Curse Brad <hwfwguy@gmail.com> - 2011-09-14 09:56 -0700
                      Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-09-12 06:27 -0400
                        Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-09-12 03:38 -0700
                        Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-09-12 21:57 -0700
                          Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-09-19 09:41 -0400
                        Re: The Lisp Curse John Passaniti <john.passaniti@gmail.com> - 2011-09-13 21:32 -0700
                          Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-09-13 22:30 -0700
                          Re: The Lisp Curse Paul Rubin <no.email@nospam.invalid> - 2011-09-14 00:47 -0700
                            Re: The Lisp Curse John Passaniti <john.passaniti@gmail.com> - 2011-09-14 13:53 -0700
                              Re: The Lisp Curse Paul Rubin <no.email@nospam.invalid> - 2011-09-15 00:37 -0700
                                Re: The Lisp Curse John Passaniti <john.passaniti@gmail.com> - 2011-09-15 08:01 -0700
                                  Re: The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-09-15 10:40 -0500
                                  Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-09-19 09:52 -0400
                                Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-09-19 09:53 -0400
                          Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-09-19 09:46 -0400
                      Re: The Lisp Curse Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2011-09-12 20:49 +0100
                Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-09-09 07:46 -0400
                  Re: The Lisp Curse Paul Rubin <no.email@nospam.invalid> - 2011-09-14 02:10 -0700
                    Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-09-14 05:38 -0700
                      Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-09-19 09:39 -0400
                    Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-09-14 18:50 -0700
                      Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-09-15 03:44 -0700
                        Re: The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-09-15 06:12 -0500
                          Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-09-15 09:49 -0700
                            Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-09-16 02:20 -0700
                        Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-09-19 09:54 -0400
                          Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-09-19 14:32 -0700
                            Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-09-21 18:28 -0400
                      Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-09-15 03:50 -0700
                      Re: The Lisp Curse stephenXXX@mpeforth.com (Stephen Pelc) - 2011-09-15 12:58 +0000
                        Re: The Lisp Curse "Elizabeth D. Rather" <erather@forth.com> - 2011-09-15 09:16 -1000
                          Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-09-15 22:36 -0700
                      Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-09-19 09:54 -0400
            Re: The Lisp Curse Brad <hwfwguy@gmail.com> - 2011-09-06 09:17 -0700

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

#5652

On Sep 9, 12:45 pm, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
wrote:
> "John Passaniti" <john.passan...@gmail.com> wrote in message
>
[snip]
>
> > In fact, in dynamic
> > languages like Lua, there are some errors that can only be
> > expressed at run-time.
>
> That is sufficient justification to not use such a language.  If you cannot
> do static code analysis, the code cannot be proven to not have run time
> errors.  Don't use it in any important situation.

<cough>.

Then don't use C.

"By a straightforward reduction to the halting problem it is possible
to prove that (for any Turing complete language) finding all possible
run-time errors in an arbitrary program (or more generally any kind of
violation of a specification on the final result of a program) is
undecidable: there is no mechanical method that can always answer
truthfully whether a given program may or may not exhibit runtime
errors." http://en.wikipedia.org/wiki/Static_program_analysis

From the Polyspace blurb (it's a C/C++ static analysis tool that's
debatably best in class)

"This approach is comprehensive and complete, because every failure
point in the code is identified as proven to fail, proven not to fail,
may never execute (dead code), or *unproven.*" (my emphasis)

In event driven applications, the job of static analysis becomes
harder still.

[snip]

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

#5656

"Alex McDonald" <blog@rivadpm.com> wrote in message
news:ce52886f-3fae-463f-8274-986b6d3a3c3e@m10g2000yqo.googlegroups.com...
> On Sep 9, 12:45 pm, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
> wrote:
> > "John Passaniti" <john.passan...@gmail.com> wrote in message
>
[snip]
>
> > > In fact, in dynamic
> > > languages like Lua, there are some errors that can only be
> > > expressed at run-time.
>
> > That is sufficient justification to not use such a language. If you
> > cannot do static code analysis, the code cannot be proven to
> > not have run time errors. Don't use it in any important situation.
>
> <cough>.
>
> Then don't use C.

Is that a SWAG?

> "By a straightforward reduction to the halting problem it is possible
> to prove that (for any Turing complete language) finding all possible
> run-time errors in an arbitrary program (or more generally any kind of
> violation of a specification on the final result of a program) is
> undecidable: there is no mechanical method that can always answer
> truthfully whether a given program may or may not exhibit runtime
> errors."
> http://en.wikipedia.org/wiki/Static_program_analysis

1) There is no such thing as a "Turing complete language".  All computing
platforms have limitations that a theoretical Turing machine does not have.
E.g., limited integer sizes, finite memory.  Does Turing compleness apply
completely with a restricted computing model?

2) The halting problem is based on a program which has the ability to run
forever, i.e., has an infinite loop.  Computer programs can be written to
always halt, i.e., exit all infinite loops or use only finite loops, and
terminate.  Does the halting problem and conclusions derived from it apply
then?

I'd think that both of those would restrict, perhaps even nullify, their
proof for general computing platforms and/or typical computer programs.
However, I'm not well versed in that area.

> From the Polyspace blurb (it's a C/C++ static analysis tool
> that's debatably best in class)

Astrée Static Analyzer
http://www.astree.ens.fr/
"Astrée is a static program analyzer aiming at proving the absence of Run
Time Errors (RTE) in programs written in the C programming language."

"In Nov. 2003, Astrée was able to prove completely automatically the absence
of any RTE in the primary flight control software of the Airbus A340
fly-by-wire system, a program of 132,000 lines of C analyzed in 1h20 on a
2.8 GHz 32-bit PC using 300 Mb of memory (and 50mn on a 64-bit AMD AthlonT
64 using 580 Mb of memory)."

"From Jan. 2004 on, Astrée was extended to analyze the electric flight
control codes then in development and test for the A380 series. The
operational application by Airbus France at the end of 2004 was just in time
before the A380 maiden flight on Wednesday, 27 April, 2005."

"In April 2008, Astrée was able to prove completely automatically the
absence of any RTE in a C version of the automatic docking software of the
Jules Vernes Automated Transfer Vehicle (ATV) enabling ESA to transport
payloads to the International Space Station [32]."


<cough>

It should be noted that for Astrée to perform it's static analysis it
eliminates recursion and dynamic memory allocation.  So, dynamic typing,
garbage collection, functional languages and languages like Erlang can't be
proven via their methods.


What's interesting is both Astrée and Polyspace use "abstract
interpretation", yet one claims they've proven no run-time errors ...


Rod Pemberton

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

#5667

On Sep 9, 2:49 pm, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
wrote:
> "Alex McDonald" <b...@rivadpm.com> wrote in message
>
> news:ce52886f-3fae-463f-8274-986b6d3a3c3e@m10g2000yqo.googlegroups.com...
>
>
>
>
>
>
>
>
>
> > On Sep 9, 12:45 pm, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
> > wrote:
> > > "John Passaniti" <john.passan...@gmail.com> wrote in message
>
> [snip]
>
> > > > In fact, in dynamic
> > > > languages like Lua, there are some errors that can only be
> > > > expressed at run-time.
>
> > > That is sufficient justification to not use such a language. If you
> > > cannot do static code analysis, the code cannot be proven to
> > > not have run time errors. Don't use it in any important situation.
>
> > <cough>.
>
> > Then don't use C.
>
> Is that a SWAG?

No, it's an observation that C has the same run-time issues as any
other language. See what follows.

>
> > "By a straightforward reduction to the halting problem it is possible
> > to prove that (for any Turing complete language) finding all possible
> > run-time errors in an arbitrary program (or more generally any kind of
> > violation of a specification on the final result of a program) is
> > undecidable: there is no mechanical method that can always answer
> > truthfully whether a given program may or may not exhibit runtime
> > errors."
> >http://en.wikipedia.org/wiki/Static_program_analysis
>
> 1) There is no such thing as a "Turing complete language".  All computing
> platforms have limitations that a theoretical Turing machine does not have.
> E.g., limited integer sizes, finite memory.  Does Turing compleness apply
> completely with a restricted computing model?

Man, give up with the "There's no such thing yada yada yada...".
AFAUK, and you're (yet again) wrong.

>
> 2) The halting problem is based on a program which has the ability to run
> forever, i.e., has an infinite loop.  Computer programs can be written to
> always halt, i.e., exit all infinite loops or use only finite loops, and
> terminate.  Does the halting problem and conclusions derived from it apply
> then?
>
> I'd think that both of those would restrict, perhaps even nullify, their
> proof for general computing platforms and/or typical computer programs.
> However, I'm not well versed in that area.

An understatement.

>
> > From the Polyspace blurb (it's a C/C++ static analysis tool
> > that's debatably best in class)
>
> Astrée Static Analyzerhttp://www.astree.ens.fr/
> "Astrée is a static program analyzer aiming at proving the absence of Run
> Time Errors (RTE) in programs written in the C programming language."
>
> "In Nov. 2003, Astrée was able to prove completely automatically the absence
> of any RTE in the primary flight control software of the Airbus A340
> fly-by-wire system, a program of 132,000 lines of C analyzed in 1h20 on a
> 2.8 GHz 32-bit PC using 300 Mb of memory (and 50mn on a 64-bit AMD AthlonT
> 64 using 580 Mb of memory)."
>
> "From Jan. 2004 on, Astrée was extended to analyze the electric flight
> control codes then in development and test for the A380 series. The
> operational application by Airbus France at the end of 2004 was just in time
> before the A380 maiden flight on Wednesday, 27 April, 2005."
>
> "In April 2008, Astrée was able to prove completely automatically the
> absence of any RTE in a C version of the automatic docking software of the
> Jules Vernes Automated Transfer Vehicle (ATV) enabling ESA to transport
> payloads to the International Space Station [32]."

Cool product.

>
> <cough>
>
> It should be noted that for Astrée to perform it's static analysis it
> eliminates recursion and dynamic memory allocation.  So, dynamic typing,
> garbage collection, functional languages and languages like Erlang can't be
> proven via their methods.

Yet some of these dynamically typed, garbage collected, functional
languages can generate C. These generated programs should (if they
avoid malloc and recursion) be amenable to analysis by Astrée, since
they are of equivalent "power" and Turing completeness, yes?

>
> What's interesting is both Astrée and Polyspace use "abstract
> interpretation", yet one claims they've proven no run-time errors ...

For a sub-domain of C. Therefore any language that has the same
restricted characteristics is amenable to the same analysis, since one
Turing complete language can always be expressed in another. The
reason that run-time errors occur -- and can't be statically analysed
-- is that it's not possible to prove for any *arbitrary program*, as
stated in the wikipedia article I quoted; the same statement is on the
Astrée web page you quote btw. Hence the restriction on recursion and
dynamic memory allocation.

>
> Rod Pemberton

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

#5708

"Alex McDonald" <blog@rivadpm.com> wrote in message
news:a32768b2-f939-4b42-af28-d729f575b990@br5g2000vbb.googlegroups.com...
> On Sep 9, 2:49 pm, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
> wrote:
> > "Alex McDonald" <b...@rivadpm.com> wrote in message
> >
news:ce52886f-3fae-463f-8274-986b6d3a3c3e@m10g2000yqo.googlegroups.com...
>
> > > "By a straightforward reduction to the halting problem it is possible
> > > to prove that (for any Turing complete language) finding all possible
> > > run-time errors in an arbitrary program (or more generally any kind of
> > > violation of a specification on the final result of a program) is
> > > undecidable: there is no mechanical method that can always answer
> > > truthfully whether a given program may or may not exhibit runtime
> > > errors."
> > >http://en.wikipedia.org/wiki/Static_program_analysis
>
> > 1) There is no such thing as a "Turing complete language". All computing
> > platforms have limitations that a theoretical Turing machine does not
> > have. E.g., limited integer sizes, finite memory. Does Turing compleness
> > apply completely with a restricted computing model?
>
> > 2) The halting problem is based on a program which has the ability to
> > run forever, i.e., has an infinite loop. Computer programs can be
written
> > to always halt, i.e., exit all infinite loops or use only finite loops,
and
> > terminate. Does the halting problem and conclusions derived from it
> > apply then?
>
> > I'd think that both of those would restrict, perhaps even nullify, their
> > proof for general computing platforms and/or typical computer programs.
> > However, I'm not well versed in that area.
>

The proof, from what I read, applies to an infinite class of programs as a
whole.  That's important, since both you and I can code a loop, that gets
input, computes a sum, and will always terminate.  It's an "arbitrary
program".  It's provable that it will terminate.  So, it's not undecidable
for that specific, but arbitrary program.  You must keep the proof in
context of it's contraints.

> Yet some of these dynamically typed, garbage collected, functional
> languages can generate C. These generated programs should (if they
> avoid malloc and recursion) be amenable to analysis by Astrée, since
> they are of equivalent "power" and Turing completeness, yes?

Yes.  How do you intend to avoid malloc and recursion in such languages?  In
C, one can code without them ...  For such languages, one must redesign the
syntax of the language, or do an awkward rewrite the language's C backend
...

> > What's interesting is both Astrée and Polyspace use "abstract
> > interpretation", yet one claims they've proven no run-time errors ...
>
> For a sub-domain of C.

It might not be the sub-domain that is tested by Astrée, but all of C
reduces to a small sub-domain of C.  E.g.,
http://www.cs.berkeley.edu/~necula/cil/index.html


Rod Pemberton

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

#5715

On Sep 12, 11:35 am, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
wrote:
> "Alex McDonald" <b...@rivadpm.com> wrote in message
>
> news:a32768b2-f939-4b42-af28-d729f575b990@br5g2000vbb.googlegroups.com...> On Sep 9, 2:49 pm, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
> > wrote:
> > > "Alex McDonald" <b...@rivadpm.com> wrote in message
>
> news:ce52886f-3fae-463f-8274-986b6d3a3c3e@m10g2000yqo.googlegroups.com...
>
>
>
>
>
>
>
>
>
>
>
> > > > "By a straightforward reduction to the halting problem it is possible
> > > > to prove that (for any Turing complete language) finding all possible
> > > > run-time errors in an arbitrary program (or more generally any kind of
> > > > violation of a specification on the final result of a program) is
> > > > undecidable: there is no mechanical method that can always answer
> > > > truthfully whether a given program may or may not exhibit runtime
> > > > errors."
> > > >http://en.wikipedia.org/wiki/Static_program_analysis
>
> > > 1) There is no such thing as a "Turing complete language". All computing
> > > platforms have limitations that a theoretical Turing machine does not
> > > have. E.g., limited integer sizes, finite memory. Does Turing compleness
> > > apply completely with a restricted computing model?
>
> > > 2) The halting problem is based on a program which has the ability to
> > > run forever, i.e., has an infinite loop. Computer programs can be
> written
> > > to always halt, i.e., exit all infinite loops or use only finite loops,
> and
> > > terminate. Does the halting problem and conclusions derived from it
> > > apply then?
>
> > > I'd think that both of those would restrict, perhaps even nullify, their
> > > proof for general computing platforms and/or typical computer programs.
> > > However, I'm not well versed in that area.
>
> The proof, from what I read, applies to an infinite class of programs as a
> whole.  That's important, since both you and I can code a loop, that gets
> input, computes a sum, and will always terminate.  It's an "arbitrary
> program".  It's provable that it will terminate.  

See http://en.wikipedia.org/wiki/Termination_analysis

"There is, however, no general procedure for determining whether an
expression involving looping instructions will halt, even when humans
are tasked with the inspection. The theoretical reason for this is the
undecidability of the Halting Problem: *there cannot exist some
algorithm which determines whether any given program stops after
finitely many computation steps*. [my emphasis]

"In practice one fails to show termination (or non-termination)
because every algorithm works with a finite set of methods being able
to extract relevant information out of a given program. A method might
look at how variables change with respect to some loop condition
(possibly showing termination for that loop), other methods might try
to transform the program's calculation to some mathematical construct
and work on that, possibly getting information about the termination
behaviour out of some properties of this mathematical model. But
because each method is only able to "see" some specific reasons for
(non)termination, even through combination of such methods one cannot
cover all possible reasons for (non)termination."


> So, it's not undecidable
> for that specific, but arbitrary program.  You must keep the proof in
> context of it's contraints.

No proof is possible. See above. We may be talking past each other
here, since I'm using much more rigourous language than you. But that
rigour is appropriate, since we're discussing Turing completeness, not
the weather.

>
> > Yet some of these dynamically typed, garbage collected, functional
> > languages can generate C. These generated programs should (if they
> > avoid malloc and recursion) be amenable to analysis by Astr e, since
> > they are of equivalent "power" and Turing completeness, yes?
>
> Yes.  How do you intend to avoid malloc and recursion in such languages?  In
> C, one can code without them ...  For such languages, one must redesign the
> syntax of the language, or do an awkward rewrite the language's C backend
> ...

So? If an awkward rewrite is possible (something I am not claiming is
possible in all cases, btw), and the C that is generated does not use
recursion or malloc, then the programs are equivalent.

Since C -> machine instructions and langX -> machine instructions...

At the language level of analysis, Lisp and its ilk are much more
amenable to analysis than C, since the mathematical formalism and the
language itself are very closely related, and there are fewer "here
there be dragons" in their specifications than exist in C.

>
> > > What's interesting is both Astr e and Polyspace use "abstract
> > > interpretation", yet one claims they've proven no run-time errors ...
>
> > For a sub-domain of C.
>
> It might not be the sub-domain that is tested by Astr e, but all of C
> reduces to a small sub-domain of C.  E.g.,http://www.cs.berkeley.edu/~necula/cil/index.html
>
> Rod Pemberton

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

#5927

"Alex McDonald" <blog@rivadpm.com> wrote in message
news:2af32584-0f13-4a32-beae-766e478e536c@h6g2000vbc.googlegroups.com...
> On Sep 12, 11:35 am, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
> wrote:
> > "Alex McDonald" <b...@rivadpm.com> wrote in message
> >
news:a32768b2-f939-4b42-af28-d729f575b990@br5g2000vbb.googlegroups.com...

> > So, it's not undecidable
> > for that specific, but arbitrary program. You must keep the proof in
> > context of it's contraints.
>
> No proof is possible. See above. We may be talking past each other
> here, since I'm using much more rigourous language than you. But that
> rigour is appropriate, since we're discussing Turing completeness, not
> the weather.

No, we weren't discussing Turing completeness.  You threw out Turing
completeness as justification for a situation where it clearly does not
apply.

> > > Yet some of these dynamically typed, garbage collected, functional
> > > languages can generate C. These generated programs should (if they
> > > avoid malloc and recursion) be amenable to analysis by Astr e, since
> > > they are of equivalent "power" and Turing completeness, yes?
>
> > Yes. How do you intend to avoid malloc and recursion in such languages?
> > In C, one can code without them ... For such languages, one must
> > redesign the syntax of the language, or do an awkward rewrite the
> > language's C backend ...
>
> So? If an awkward rewrite is possible (something I am not claiming is
> possible in all cases, btw), and the C that is generated does not use
> recursion or malloc, then the programs are equivalent.
>

But, without malloc and recursion, they won't be dynamic languages anymore
...   Are you confused?

> Since C -> machine instructions and langX -> machine instructions...
...

> At the language level of analysis, Lisp and its ilk are much more
> amenable to analysis than C, since the mathematical formalism and the
> language itself are very closely related, and there are fewer "here
> there be dragons" in their specifications than exist in C.

And, just how does that justify Ada being used instead of Lisp?  Or, C being
used instead of Forth?  etc  What is your point here?


Rod Pemberton

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

#5940

On Sep 19, 2:38 pm, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
wrote:
> "Alex McDonald" <b...@rivadpm.com> wrote in message
>
> news:2af32584-0f13-4a32-beae-766e478e536c@h6g2000vbc.googlegroups.com...> On Sep 12, 11:35 am, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
> > wrote:
> > > "Alex McDonald" <b...@rivadpm.com> wrote in message
>
> news:a32768b2-f939-4b42-af28-d729f575b990@br5g2000vbb.googlegroups.com...
>
> > > So, it's not undecidable
> > > for that specific, but arbitrary program. You must keep the proof in
> > > context of it's contraints.
>
> > No proof is possible. See above. We may be talking past each other
> > here, since I'm using much more rigourous language than you. But that
> > rigour is appropriate, since we're discussing Turing completeness, not
> > the weather.
>
> No, we weren't discussing Turing completeness.  You threw out Turing
> completeness as justification for a situation where it clearly does not
> apply.
>
> > > > Yet some of these dynamically typed, garbage collected, functional
> > > > languages can generate C. These generated programs should (if they
> > > > avoid malloc and recursion) be amenable to analysis by Astr e, since
> > > > they are of equivalent "power" and Turing completeness, yes?
>
> > > Yes. How do you intend to avoid malloc and recursion in such languages?
> > > In C, one can code without them ... For such languages, one must
> > > redesign the syntax of the language, or do an awkward rewrite the
> > > language's C backend ...
>
> > So? If an awkward rewrite is possible (something I am not claiming is
> > possible in all cases, btw), and the C that is generated does not use
> > recursion or malloc, then the programs are equivalent.
>
> But, without malloc and recursion, they won't be dynamic languages anymore
> ...   Are you confused?
>
> > Since C -> machine instructions and langX -> machine instructions...
>
> ...
>
> > At the language level of analysis, Lisp and its ilk are much more
> > amenable to analysis than C, since the mathematical formalism and the
> > language itself are very closely related, and there are fewer "here
> > there be dragons" in their specifications than exist in C.
>
> And, just how does that justify Ada being used instead of Lisp?  Or, C being
> used instead of Forth?  etc  What is your point here?
>
> Rod Pemberton

This ridiculous snipping makes things impossible. I'm with Stephen on
this one. "Trolley", "your" and "off".

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

#6013

"Alex McDonald" <blog@rivadpm.com> wrote in message
news:f28426e1-52b3-402b-907c-7f8846a3c0cd@u19g2000vbm.googlegroups.com...
>
> This ridiculous snipping makes things impossible.
>

What ridiculous snipping?  I left all relevant context and substantially
more after your inane complaints ...

You do know that Usenet posts are restricted by both size and for some
servers the amount quoted material, yes?

Standard Usenet courtesy is to *remove* non-relevant context.  As I stated
previously, if something was removed that you wished to discuss, it's up to
you to put it back in or respond to the appropriate message.

All prior posts should be available in your Usenet reader, if not there is
Google Groups which has the content but formats awkwardly.  You'll need to
enable indenting for GG.

> I'm with Stephen on this one. "Trolley", "your" and "off".
>

First, that was somewhere else.  Second, I was responding to you, so I guess
you're also "'Trolley', 'your', and 'off'".

Third, Stephen primarily posts *COMMERCIAL* *SPAM* which is either on
MPE or VFX and is explicitly *OFF-TOPIC* ...  I don't complain about it
since he seems to be a rather nice guy, doesn't post alot, is knowledgeable,
and since Ms. Rather does the same from time to time.

Fourth, this is *not* a moderated Usenet group.  Topicality is explicitly a
function of *all* people here.  If you don't like what I say, your options
are to leave, filter, or ignore.  Harassment of me is futile.


Rod Pemberton

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

#5702

On Sep 9, 7:45 am, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
wrote:
> > And on top of all this you would be missing out on all
> > the other features of Lua ... such as interactivity.
>
> BASIC has interactivity.  Interactivity is nice but of no real value.

Yes, because you favor a language that doesn't offer interactivity,
and so the process of creating software for you doesn't exploit that
feature.  So yes, it has no real value... to you.  But why exactly are
the limitations you impose on yourself by choosing C the same
limitations others should choose?

This is a common pattern for you.  Whenever your notion of a "god"
language can't do something, you declare that something has no value.
Sour grapes.

> > In fact, in dynamic
> > languages like Lua, there are some errors that can only be
> > expressed at run-time.
>
> That is sufficient justification to not use such a language.  If you
> cannot do static code analysis, the code cannot be proven to not have
> run time errors.  Don't use it in any important situation.

This is a very old debate that goes beyond our discussion here.  The
answer is that both static typing and dynamic typing have their place,
and both present a different set of advantages and disadvantages.
Static typing only catches specific classes of errors that have to do
with type.  Every other class of errors is still alive and well in
statically typed languages.  That means that both statically and
dynamically typed languages both require testing to be part of the
development process.  If you're relying on static typing to somehow
"prove" that your program is correct, then you've failed right there.

> > So yes, if you're a masochist, you are certainly free to
> > implement a language only in terms of library function calls.
>
> You do not need to be a masochist.
>
> C is straighforward and logical, if you use it that way.  You
> just need to learn C and structured programming concepts.

No, actually it has nothing to do with learning C and structured
programming.  What you are actually advocating is that one limits
themselves to what C provides.  And convenient for you, since you
don't seem to understand much beyond the simple batch-compiled
imperative procedural world of C, you're happy living within those
limitations.  Hey, whatever works for you.

> > And if Rod still
> > has trouble believing this, he is free to prove his point by taking
> > his work in creating a Forth and not making a whole new language,
> > but instead expressing Forth as a bunch of library function calls.
>
> Why would I do that?

Because it would prove your point.  If you created a language that had
the same expressive power of Forth but was implemented just in terms
of C function calls and text-substitution macros, then you could point
to that as an illustration of your point.  Thing is that I don't even
require a working code.  You can make your point by taking some non-
trivial Forth code and then expressing that same code in a theoretical
set of C functions.  That is, you believe that it isn't necessary to
invent new syntax to express a language; that you can do it entirely
with C function calls.  So put your claim to the test, and let's see
what you come up with.

Again, it doesn't have to run.  But you do have to explain what the
abstractions do.

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

#5707

"John Passaniti" <john.passaniti@gmail.com> wrote in message
news:ba8c08a3-93aa-4f41-ad0f-126535041b8a@c29g2000yqd.googlegroups.com...
> On Sep 9, 7:45 am, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
> wrote:
> > JP wrote:
>
> > > such as interactivity.
>
> But why exactly are the limitations you impose on yourself by choosing C
> the same limitations others should choose?

IIRC, there are five different interpreted C's.  Maybe it's three ...
Limitation eliminated.

> This is a common pattern for you.  Whenever your notion of a "god"
> language can't do something, you declare that something has no value.
> Sour grapes.

See above.  I can locate them for you if need be.

> > C is straighforward and logical, if you use it that way. You
> > just need to learn C and structured programming concepts.
>
> No, actually it has nothing to do with learning C and structured
> programming.  What you are actually advocating is that one limits
> themselves to what C provides.
>

(Wow.  You have missed a large part the discussion ...)

I've already covered the issue that most of these "new" languages are coded
in C.  That being the situation, those "new" languages are also "limited to
what C provides".  So, you're entire argument is flawed or a strawman, if
that language was coded in C.

> If you created a language that had
> the same expressive power of Forth but was implemented
> just in terms of C function calls and text-substitution macros,
> then you could point to that as an illustration of your point.
>

There are numerous Forth's in C already.  Take Gforth.  What's wrong with it
proving "your best but incorrect representation of my point" point?

> You can make your point by taking some non-
> trivial Forth code and then expressing that same code
> in a theoretical set of C functions.

My Forth-to-C converter does that already.  Actually, it does that for two
forms of Forth code in C (410 lines).  The first converts directly
parameterless C functions.  The second converts to C that can be interpreted
by my ITC interpreter in C.  But, let's ignore that ...  You will anyway.

So, let's take Rob Chapman's Timbre.  What's wrong with it proving "my"
point?


Rod Pemberton

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

#5721

On 9/12/11 12:30 AM, Rod Pemberton wrote:
> "John Passaniti"<john.passaniti@gmail.com>  wrote in message
> news:ba8c08a3-93aa-4f41-ad0f-126535041b8a@c29g2000yqd.googlegroups.com...
>> On Sep 9, 7:45 am, "Rod Pemberton"<do_not_h...@noavailemail.cmm>
>> wrote:
>>> JP wrote:
>>
>>>> such as interactivity.
>>
>> But why exactly are the limitations you impose on yourself by choosing C
>> the same limitations others should choose?
>
> IIRC, there are five different interpreted C's.  Maybe it's three ...
> Limitation eliminated.

I have seen one such.  The notion that it is interactive in the sense 
that Forth is, is laughable.  I suspect you have little or no real 
experience developing real-world applications in Forth.  Most Forth 
newbies work in a programming style close to what they're accustomed to 
in other languages, and therefor fail to appreciate the full power of 
interactive development.

Not to mention that the Forths with full optimizing compilers are just 
as interactive as ITC Forths, which in any case aren't "interpreted" in 
the conventional sense of the term.

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]

#5928

"Elizabeth D. Rather" <erather@forth.com> wrote in message
news:fYqdnVfKCfG0yPPTnZ2dnUVZ_rOdnZ2d@supernews.com...
> On 9/12/11 12:30 AM, Rod Pemberton wrote:
> > "John Passaniti"<john.passaniti@gmail.com>  wrote in message
> >
news:ba8c08a3-93aa-4f41-ad0f-126535041b8a@c29g2000yqd.googlegroups.com...
> >> On Sep 9, 7:45 am, "Rod Pemberton"<do_not_h...@noavailemail.cmm>
> >> wrote:
> >>> JP wrote:
> >>
> >>>> such as interactivity.
> >>
> >> But why exactly are the limitations you impose on yourself by choosing
> >> C the same limitations others should choose?
> >
> > IIRC, there are five different interpreted C's.  Maybe it's three ...
> > Limitation eliminated.
>
> I have seen one such.  The notion that it is interactive in the sense
> that Forth is, is laughable.  I suspect you have little or no real
> experience developing real-world applications in Forth.

True, so?

> Most Forth newbies work in a programming style close to what
> they're accustomed to in other languages, and therefor fail to
> appreciate the full power of interactive development.

I loved the interactiveness of interpreted BASIC my C64 decades ago.  I've
also programmed in interpreted BASIC on industrial equipment.  Interactivity
is nice but of no real value.  Compilers compile quickly.  If you need to
test something quickly, you can compile a small snip instead of the entire
application.


Rod Pemberton

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

#5938

On Mon, 19 Sep 2011 09:38:50 -0400, "Rod Pemberton"
<do_not_have@noavailemail.cmm> wrote:

>I loved the interactiveness of interpreted BASIC my C64 decades ago.  I've
>also programmed in interpreted BASIC on industrial equipment.  Interactivity
>is nice but of no real value.  Compilers compile quickly.  If you need to
>test something quickly, you can compile a small snip instead of the entire
>application.

"Trolley", "your" and "off". The real point of interactivity is not
for testing but for debugging. Just because *you* have not experienced
the need or benefit does not make the benefits unreal.

Stephen

-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

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

#5644

"John Passaniti" <john.passaniti@gmail.com> wrote in message
news:14d1e29c-5e8d-49bb-ace8-ed97b5bcde52@o9g2000vbo.googlegroups.com...
>
> No rational person
> thinks the reason why a large number of languages are implemented
> in C is because C is particularly suited for implementing languages.
> C is used because it's there (on most reasonable platforms) and
> because it's just high enough in level over assembly language that
> you have some expectation of portability for most of the code.
> That's it.

I'm exceptionally rational and I've already disproved that argument.  Go
back an reread.  It's in three (3) different posts in this thread.  Look for
Forth and ubiquitous.

> Rod refuses to believe that programming languages (which bundles
> together paradigms, facilities, semantics, and syntax) matter.  And
> that's because he takes a ridiculous reductionist view that only
> considers the end (an instruction stream executed by the processor)
> and doesn't consider how the programmer got there.

That is what is fundamental.  But, in a powerful language like C, it's easy
to "get there".  Maybe that's the understanding that you're missing?

> Anyone who has
> spent time working in multiple programming languages-- and especially
> multiple fundamentally different programming languages-- knows that
> everything Rod dismisses has a profound effect on how the programmer
> thinks and eventually solves the problem.

Please stop discounting my experience as a form of insult.  I've told you
previously that I've used over a dozen major languages.

> Rod's bizarre notion is
> that because each of these languages can be implemented in C,
> then these languages have no value--

History has proven this to be true ...  I've already stated so repeatedly
and mentioned various proofs.

> Rod's bizarre notion is that because each of these languages
> can be implemented in C, then these languages have no value
> -- you could just code in C and call out to libraries and try to
> hide much of the syntactic horror with C's crude text-substitution
> macros.  Even more bizarre is that if Rod
> really believed that,

I've explained repeatedly that I'm coding an interpreter (ITC), not a
Forth-to-C translator.  I already have a simple Forth-to-C translator.  It's
only 410 lines of C.  It needs definitions for the base wordset and code for
the primitives.  These will come from the interpreter, or earlier versions
of it.

> [...] you might think he
> wouldn't be implementing a
> Forth in C.

As mentioned previously, to you I believe, it's a side project from a C
compiler.

> Instead, if he really believes that language doesn't
> matter, he should instead be creating a set of libraries for C

I'm still acquiring resources for that project.  It's on hold.  I've got too
many active projects.

> [...] then show us all how much better his [C] libraries are
> than using Forth.

Funny ...

> Language matters.  It shapes how one thinks about problems, and it
> provides facilities that drive how solutions are framed.  People who
> only spend time in one language or who have never introspected on the
> process they use to write code don't understand this.  The rest of us
> do.

Over a dozen languages later, my conclusion is C is the 'God-like'
language.  How does my conclusion fit into your illogical argument?
Why do you continue to discount my experience?

You've argued this _exact_ same thing before, BTW.  Do you recollect?


Rod Pemberton

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

#5650

On Sep 9, 12:43 pm, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
wrote:

[snip]

>
> Over a dozen languages later, my conclusion is C is the 'God-like'
> language.  How does my conclusion fit into your illogical argument?
> Why do you continue to discount my experience?
>

Thanks for concluding the sermon on CLF in your role as the High
Priest in the Church of C. What next; voices telling you that you must
take the word and witness on comp.lang.ruby, or that the heathens that
practice the black arts of Lisp must be eternally punished for using C
to build their machines of evil?

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

#5655

"Alex McDonald" <blog@rivadpm.com> wrote in message
news:e3a3b65d-c9b0-4139-b54c-ed14d36610e1@g32g2000pri.googlegroups.com...
> On Sep 9, 12:43 pm, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
> wrote:
>
> [snip]
>
> >
> > Over a dozen languages later, my conclusion is C is the 'God-like'
> > language. How does my conclusion fit into your illogical argument?
> > Why do you continue to discount my experience?
>
> Thanks for concluding the sermon on CLF in your role as the High
> Priest in the Church of C. What next; voices telling you that you must
> take the word and witness on comp.lang.ruby, or that the heathens that
> practice the black arts of Lisp must be eternally punished for using C
> to build their machines of evil?
>

You made the illogical claim.
You avoided answering the question.
You attempted to demean or belittle by implying insanity.

Whatever...

What's the emoticon for roll-eyes or thumb-nose?


Rod Pemberton

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

#5701

On Sep 9, 7:43 am, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
wrote:
> I'm exceptionally rational and I've already disproved that argument.  
> Go back an reread.  It's in three (3) different posts in this thread.  
> Look for Forth and ubiquitous.

You suffer from confusing your ability to state and defend your
opinions with the ability to disprove arguments.  At best, you've
disproved arguments to your satisfaction, which as a threshold is a
pretty low bar to cross.

> > Anyone who has spent time working in multiple programming
> > languages-- and especially multiple fundamentally different
> > programming languages-- knows that everything Rod dismisses has a
> > profound effect on how the programmer thinks and eventually
> > solves the problem.
>
> Please stop discounting my experience as a form of insult.  I've told
> you previously that I've used over a dozen major languages.

I discount your experience because your own words suggest your
experience doesn't run very deep.  Using "over a dozen major
languages" by itself says absolutely nothing more than you know the
syntax of those languages.  Nothing you have written demonstrates to
me that you know how to *think* in those languages, or that you
understand how the paradigms and facilities provided by those
languages fundamentally affects solutions implemented.  You could know
*hundreds* of languages, but if the extent of that knowledge is mostly
just knowing the syntax, then you don't really know those languages.
There is more to programming than just syntax, and your own words
suggest you haven't come to level of understanding.

This is periodically demonstrated in this newsgroup when a programmer
familiar with another language (such as C) tries to learn Forth.  What
sometimes happens is the programmer doesn't take the time to
understand what is different about Forth and will just literally
translate code from the language they are familiar with into Forth.
The result is usually poor.  You see very non-Forth things like an
over-use of variables (instead of effectively using the stack) and
other issues.  It's what happens when the programmer isn't thinking in
terms of how to effectively use Forth, but is merely just trying to
translate another language (which made a different set of trade-offs)
to Forth.

Forth isn't unique in this regard.  I've seen people try to take a
procedural style in Lisp, with the result being demonstrably less
elegant than embracing a functional style.  I've seen people who
didn't understand closures write callback functions in Javascript that
used explicit methods to retain context, which is just horrible.  And
right now at work, I'm cleaning up a code base implemented in C# where
the programmer didn't really understand object orientation, which led
to some hideously unmaintainable code that doesn't effectively use the
language.

The point is that languages aren't just syntax.  Languages bundle
together syntax, semantics, facilities, paradigms, idioms, and
styles.  And these all have very big effects on how programmers come
up with solutions.  The fact that you apparently don't believe that is
what leads me to disregard your experience.

> > Rod's bizarre notion is
> > that because each of these languages can be implemented
> > in C, then these languages have no value--
>
> History has proven this to be true ...  I've already stated so
> repeatedly and mentioned various proofs.

At best, what you have shown is that given enough time and effort, one
can approximate paradigms and facilities of other languages in C.  And
that's not surprising, because the same argument could be made about
*any* Turing-complete language.  The part you seem to have a very hard
time understanding is that just because one *can* do something in C
doesn't mean that one *should*.  You could pound a nail into a board
with a handsaw; it's a functional solution and gets the job done.  But
is it the best?

That's the problem with your ridiculous reductionism.  It completely
disregards an objective evaluation of the solution itself, and only
considers the end result.  Why exactly are you afraid of an objective
evaluation of the solution?  What fear lurks in you about seeing an
algorithm expressed more clearly, succinctly, elegantly, or
efficiently in a different language?

The same argument you make is often brought up here in
comp.lang.forth.  When I've talked about various paradigms and
facilities available in other languages, some here counter by saying
that one could build up the same in Forth and then be able to use
those language features.  But what they (and you) don't talk about is
that before one can use those language features, they have to build
them up first.  That takes non-zero time, and it's time that you're
spending not solving the problem, but building the infrastructure to
solve the problem.  It's much like the old Steve Martin joke about how
to make a million dollars-- you first get a million dollars.  You're
skipping over the details.  And you do that because once one starts
diving into the details about the time and effort (and thus, expense),
you see it simply isn't cost effective.  Picking a language that
already has what you need means you are solving the problem
immediately.

> Over a dozen languages later, my conclusion is C is the 'God-like'
> language.  How does my conclusion fit into your illogical argument?
> Why do you continue to discount my experience?

I continue to discount your experience because my own experience
directly contradicts yours.  I've worked as some flavor of software
developer for the past 25 years, and in that time, I've used a wide
variety of programming languages in my work.  Early on, my interest in
studying programming languages was driven by the naive notion of
finding some "god" language that was universal.  That is, I thought
that if I searched enough, I could find one language that could
replace every other language.  But a funny thing happened along the
way.  I quickly found out that some languages resulted in very
different kinds of solutions that were often more elegant and
objectively better.  And thinking about this some more, I came to
understand this is because programming languages can have a profound
effect on how one thinks.  And I have proved that fact to myself many
times over the years by looking at and objectively evaluating how the
various languages I've used have resulted in very different solutions.

The end result is that I gave up looking for a "god" language years
ago.  I see that as fundamentally wrong and limiting.  By putting the
language ahead of the problem, you force the solution of that problem
to be in terms of what the language provides.  And it means that you
need to create the infrastructure when that language is lacking.  Far
better is to start with the problem and then pick the language that
best supports finding a solution.

So yes, I discount your experience because I see nothing from you that
suggests that you have introspected about the process of creating
software and have any depth or maturity when it comes to understanding
how programming languages shape and limit solutions.  But don't worry,
you're in good company here in comp.lang.forth.  There are lots of
people who have never when staring at their screens have never
questioned how the language they are using is limiting them.  It's
more than just a fun philosophical question.  It's where the Dunning-
Kruger effect comes in.

> You've argued this _exact_ same thing before, BTW.  Do you recollect?

Yes, I recollect that you refuse to put forward the effort needed to
understand my points.  So I repeat them in hopes that at some point,
intellectual curiosity will push you away from your comfort zone and
start to consider what I and others are telling you.  Until that
happens, then I fearlessly predict that you'll keep spouting the same
nonsense, and I and others will repeatedly tell you that you're wrong.

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

#5703

On Sep 11, 6:40 pm, John Passaniti <john.passan...@gmail.com> wrote:
> On Sep 9, 7:43 am, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
> wrote:
> > Please stop discounting my experience as a form of insult.  I've told
> > you previously that I've used over a dozen major languages.
>
> I discount your experience because your own words suggest your
> experience doesn't run very deep.  Using "over a dozen major
> languages" by itself says absolutely nothing more than you know the
> syntax of those languages.  Nothing you have written demonstrates to
> me that you know how to *think* in those languages, or that you
> understand how the paradigms and facilities provided by those
> languages fundamentally affects solutions implemented.  You could know
> *hundreds* of languages, but if the extent of that knowledge is mostly
> just knowing the syntax, then you don't really know those languages.
> There is more to programming than just syntax, and your own words
> suggest you haven't come to level of understanding.

Note to Rod --- Passaniti has *never* posted Forth code on
comp.lang.forth in all of the years that he has been trolling here.
There is no evidence to indicate that he knows any language other than
Perl (which, strangely enough, he has posted on comp.lang.forth).

Rod --- write some code and post it --- that is what I do (see my
novice package). There is no other way to be a programmer than to
program --- that is my proverb!

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

#5714

"Hugh Aguilar" <hughaguilar96@yahoo.com> wrote in message
news:b19e3c17-3c17-4f4f-8755-2ef4f6a17be5@s42g2000prb.googlegroups.com...
>
> Note to Rod --- Passaniti has *never* posted Forth code on
> comp.lang.forth in all of the years that he has been trolling here.
>

Oh, I don't doubt that.  The most hostile, self-assured, and arrogant of any
group rarely do, be it here or c.l.c, etc.  Unfortunately, they are always
windbags, not experienced people.  They don't post their own code because
they fear that criticism of their code, or the solution in JP's case, would
knock them off their almighty perch.  They'd be proven wrong, or it'd be
proven that they don't actually program, or don't program well.  E.g., two
"experts" on c.l.c don't actually program in C.  They write (bad) books on
C and argue the C specification.

I haven't posted Forth here, but I've posted a bit of C and assembly to
other groups.  Most of my code is either personal or corporate.  I may
release a bunch of my personal code some time in the far future.

> There is no evidence to indicate that he knows any language other than
> Perl (which, strangely enough, he has posted on comp.lang.forth).

Just posting Perl doesn't prove that either ...  (See how he likes his
argument applied to his vacant skillset.)

Someone with his name and experiences similar to info he posted has a
Linkedin page ...  One paragraph summarizes his skills.  There is zero
mention of his programming language skillset.  ISTM, that that page mostly
lists what the companies he worked for do, and not what he did for them, or
what he learned from them.  I seriously hope that's not the basis for his
resume.  When he does mention "develop software," it seems to be in a
management sense or support sense, and not in a programming one.  One
could confuse decades old experience, due to his wording, for actual
programming experience.


Rod Pemberton

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

#5739

On Sep 12, 6:45 am, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
wrote:
> Someone with his name and experiences similar to info he posted has a
> Linkedin page ...  One paragraph summarizes his skills.  There is zero
> mention of his programming language skillset.  

Correct.  That information is on my resume.  LinkedIn is not a resume,
it's a professional networking system and there people care more about
what you do, not how you do it.  So the noise of the various
programming languages I know and use isn't relevant there.  If I was
actively looking for a job, I might consider adding it.  But since I'm
not, I prefer to keep it simple and keep it to the resume.

To find my resume requires nothing more than knowing how to use
Google.  But to save you the effort:

http://japanisshinto.com/stuff/resume/john-passaniti-resume.pdf

That resume is from when I was last looking for work (December 2009).
It doesn't include what I currently do.  Maybe I'll update it.

> ISTM, that that page mostly lists what the companies he worked for
> do, and not what he did for them, or what he learned from them.  

Correct.  That is because it's LinkedIn, and not a resume.  As for
what I learned from the companies I've worked for, that's not
something I would put in a resume.  That's something that comes out
during an interview, and I'm more than happy to talk about the various
lessons learned from employers, and both the successes and mistakes
I've made.

> I seriously hope that's not the basis for his resume.  

Correct.  It isn't.  And because the best advice I've had when writing
a resume is to not make it too long, I decided to omit the various
random projects I've worked on as an independent consultant and some
non-software work experience I had years ago.  If you're curious about
those, I'd be happy to detail them in private email.

> When he does mention "develop software," it seems to be in a
> management sense or support sense, and not in a programming one.  
> One could confuse decades old experience, due to his wording,
> for actual programming experience.

Nope.  Although I've managed others in the past (and currently manage
one other programmer), I have never had a pure management role.  It's
a very small part of what I do, and I gladly defer as much of it as I
can to people in actual management.  I've never been offered such a
pure-management role because I've explicitly told my employers that
I'm not at all interested in that.  I have been offered in the past
pure design roles where I would design but not implement systems.
I've rejected those as well.  And yes, I rejected those even though
there was the promise of a higher salary.  Money isn't everything.
Job satisfaction and security matter far more to me at age 46 than
working in a role that would bore me to tears.

I enjoy designing audio systems, enjoy implementing them, enjoy the
industry I work in, enjoy coming up with new innovations, enjoy the
cross-pollination of ideas from other industries, and enjoy the sense
of accomplishment from taking products from concept to implementation
to manufacturing to finally sitting on a shipping dock headed for
customers.  And what especially gives me a kick is when I'm standing
at a concert or in a recording studio and seeing musicians running
their instruments through the digital signal processors I've written
code for, or sitting in an auditorium listening to power amplification
systems I wrote code for fill the space with sound.

I fully expect you'll read my resume and come up with more bullshit
assumptions about my past and current work.  You seem unable to help
yourself.

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

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

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

csiph-web