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

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

Scientific Computing and Forth

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

Contents

  Scientific Computing and Forth krishna.myneni@ccreweb.org - 2015-01-17 09:23 -0800
    Scientific Computing and Forth krishna.myneni@ccreweb.org - 2015-01-18 08:06 -0800
      Re: Scientific Computing and Forth Melzzzzz <mel@zzzzz.com> - 2015-01-23 16:52 +0100
        Re: Scientific Computing and Forth krishna.myneni@ccreweb.org - 2015-01-23 08:45 -0800
          Re: Scientific Computing and Forth krishna.myneni@ccreweb.org - 2015-01-23 08:51 -0800
          Re: Scientific Computing and Forth krishna.myneni@ccreweb.org - 2015-01-23 09:05 -0800
    Re: Scientific Computing and Forth krishna.myneni@ccreweb.org - 2015-01-22 19:58 -0800
      Re: Scientific Computing and Forth krishna.myneni@ccreweb.org - 2015-01-23 07:39 -0800
    Re: Scientific Computing and Forth Whammo <sidciavic@gmail.com> - 2015-01-25 00:15 -0800
      Re: Scientific Computing and Forth krishna.myneni@ccreweb.org - 2015-01-25 06:57 -0800
        Re: Scientific Computing and Forth Whammo <sidciavic@gmail.com> - 2015-01-25 20:10 -0800
          Re: Scientific Computing and Forth krishna.myneni@ccreweb.org - 2015-01-25 22:49 -0800
            Re: Scientific Computing and Forth Whammo <sidciavic@gmail.com> - 2015-01-26 01:23 -0800
              Re: Scientific Computing and Forth Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2015-01-26 10:36 +0000
              Re: Scientific Computing and Forth krishna.myneni@ccreweb.org - 2015-01-26 06:24 -0800
                Re: Scientific Computing and Forth beeflo <beeflobill@gmail.com> - 2015-01-26 11:33 -0800
                  Re: Scientific Computing and Forth krishna.myneni@ccreweb.org - 2015-01-26 15:49 -0800
                Re: Scientific Computing and Forth Whammo <sidciavic@gmail.com> - 2015-01-26 11:37 -0800
                  Re: Scientific Computing and Forth beeflo <beeflobill@gmail.com> - 2015-01-26 12:11 -0800
                    Re: Scientific Computing and Forth Whammo <sidciavic@gmail.com> - 2015-01-26 12:14 -0800
                      Re: Scientific Computing and Forth beeflo <beeflobill@gmail.com> - 2015-01-26 12:29 -0800
                  Re: Scientific Computing and Forth krishna.myneni@ccreweb.org - 2015-01-26 17:29 -0800
                    Re: Scientific Computing and Forth Whammo <sidciavic@gmail.com> - 2015-01-28 14:06 -0800
          Re: Scientific Computing and Forth "Elizabeth D. Rather" <erather@forth.com> - 2015-01-25 21:30 -1000
            Re: Scientific Computing and Forth krishna.myneni@ccreweb.org - 2015-01-26 05:28 -0800
              Re: Scientific Computing and Forth "Elizabeth D. Rather" <erather@forth.com> - 2015-01-26 11:06 -1000

Page 1 of 2  [1] 2  Next page →

#35866 — Scientific Computing and Forth

When I first read Skip Carter's assertion on the FSL page that Forth may be a strong contender for the replacement of Fortran, for the scientific community, I have to say that I was a bit incredulous. Over the years, however, I've come around to that idea, as I used Forth for various computing tasks. I believe the primary obstacle to extensive use of Forth for scientific computing has very, very little to do with the debate over standards. ANS Forth, with its flaws, is very well suited for scientific computing. The primary problem, as Skip Carter noted, and tried to remedy, was the lack of substantial libraries of numerical algorithms.

I ran into this problem the other day, as I wanted to write code to illustrate a calculation (for pedagogical purpose). I did not have access to a good two-dimensional integrator package in Forth. It would have taken some time to write and debug one in Forth. Instead, I found an existing package for R which would do what I needed, and, therefore, I implemented the program in R:

ftp://ccreweb.org/software/R/qm/h2plus.R

I would still like to have a version of this program in Forth.

Krishna

[toc] | [next] | [standalone]

#35883

If anyone is interested in working with me to port Steven Johnson's cubature code to ANS Forth, let me know. I don't have a lot of time to devote to this, but there's also no deadline -- it can be done over the course of a few months. 

http://ab-initio.mit.edu/wiki/index.php/Cubature

Krishna

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

#35972

On Sun, 18 Jan 2015 08:06:53 -0800 (PST)
krishna.myneni@ccreweb.org wrote:

> If anyone is interested in working with me to port Steven Johnson's
> cubature code to ANS Forth, let me know. I don't have a lot of time
> to devote to this, but there's also no deadline -- it can be done
> over the course of a few months. 
> 
> http://ab-initio.mit.edu/wiki/index.php/Cubature
> 
> Krishna

Why not just make wrapper, like it is done for R?

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

#35975

I assume you mean by wrapper an interface to the C code. Yes, it's possible to create a dynamically linked library from the C code and use an interface to make call the code. I can certainly do it in kForth, and Gforth and other Forth systems have a way to do it also. But it's not a portable approach for ANS Forth. A port of the cubature C code to Forth will be much more portable between Forth systems.

The larger issue is that external library interfaces are a poor approach in general for scientific computing. I believe this is the direction Python takes and I think it's the wrong approach. Modifying a library algorithm for a particular problem becomes a big pain with this approach. Why not just write one's code in Fortran or C to begin? Forth is quite capable of expressing the numerical algorithms, and there are a finite set of core algorithms that are needed for the majority of applications. We just haven't reached the threshold for native Forth numerical libraries to make it feasible for general purpose scientific computing.

Krishna

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

#35977

I mean external precompiled libraries are a poor approach, not source libraries.

KM

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

#35978

A perfect example to illustrate my preference for source libraries is provided by the following program:

ftp://ccreweb.org/software/kforth/examples/tpf.4th

This program required a slight variation of the adaptive step size ODE solver, runge4. If a precompiled only library was available, it would not have been useful. If a source library in C or Fortran was available, I could have made changes to it and rebuilt it, but it would have been a pain. Since we had the source library in Forth, it was easy to use the existing Forth module and add the required changes to my program.

Krishna

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

#35965

On Saturday, January 17, 2015 at 11:23:37 AM UTC-6, krishna...@ccreweb.org wrote:
...
> I ran into this problem the other day, as I wanted to write code to illustrate a calculation (for pedagogical purpose). I did not have access to a good two-dimensional integrator package in Forth. It would have taken some time to write and debug one in Forth. Instead, I found an existing package for R which would do what I needed, and, therefore, I implemented the program in R:
> 
> ftp://ccreweb.org/software/R/qm/h2plus.R
> 
> I would still like to have a version of this program in Forth.
> 
...

Interestingly, the paper at the link below computed the same thing as my program above, and there is a discrepancy in the third digit. For values of the parameters alpha = 1.24 and a = 2.00, my program gives an energy of 

   E = -0.586505

while, in the paper, they report an energy of E = -0.585050, for the same values of the parameters. Hmm... I've checked my program in a limiting case (a = 0), and it gives the correct answer to at least 7 digits.

The paper also uses much more complex trial wavefunctions to arrive at a more accurate energy. The calculations were done on a CRAY-YMP machine. I expect with a native code Forth compiler, and a port of the cubature package, the same calculations may be done on a desktop.

Krishna

--
The paper is, 

H. W. Jones and B. Etemadi, "Accurate ground-state calculations of H_{2}^{+} using basis sets of atom-centered Slater-type orbitals," Physical Review A, vol. 47, p. 3430 (1993).

http://journals.aps.org/pra/abstract/10.1103/PhysRevA.47.3430

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

#35971

It's clear that they have a typo in the Physical Review A paper. My program agrees to better than 6 digits with their published numbers for different "a" values, except for a=2. Their number, -0.585050, is different because they essentially mistyped the number -0.586505!

Krishna

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

#36006

The knowledge and effort required to mine library resources is comparable to that required to understand and code the problem directly.

 This is an example of the principle of "Conservation of Complexity".

 Chuck Moore

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

#36008

There's no getting around putting in significant time and effort to work out any non-trivial problem, whether one uses library code or not. It's equally true in physics as in software. The library code in that case might be a derived equation. One can use it without insight. In working out the H2+ problem for myself, I purposefully avoided looking at the long history of past work on trial wavefunctions for H2+, so that I could think through the problem myself. I had several false starts, as I didn't use continuous wavefunctions at first, which did not work as expected at all. I learned a valuable lesson. The variational principle has some requirements for continuous wavefunctions. Other trial functions which I thought should do better based on physical reasoning turned out to give poorer (less accurate) answers. Then, I was forced to look back at my reasoning and find the flaws. It was a worthwhile exercise. Now, having gone through the exercise myself, I can comprehend much more easily some 60 years or so of past work.

Reusable source library code is useful. It's not always necessary to reinvent the wheel, because one often cannot become an expert at every aspect of a problem (multidimensional numerical integration, in my example). But, when something doesn't work as expected, one needs to be able to drill down into the problem.

Krishna

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

#36025

 I think Mr. Moore's assertion says more about the complexity of understanding and adapting general-purpose library code to a specific application than coding specific-case words to a specified application.
 The emphasis being the understanding of the problem. If you understand the problem and are a competent forth programmer, the coding of the solution is trivial as opposed to the essential understanding of the problem.
 As for the demagoguery of 'wheel reinvention', one wheel is not every wheel.
An appropriate wheel for one surface is not appropriate for another.
 This, as I understand it, is a philosophy of forth. One can use the forth programming language any way one wants. But there is more to it than forth words.

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

#36027

On Sunday, January 25, 2015 at 10:10:40 PM UTC-6, Whammo wrote:
> I think Mr. Moore's assertion says more about the complexity of understanding and adapting general-purpose library code to a specific application than coding specific-case words to a specified application.
>  The emphasis being the understanding of the problem. If you understand the problem and are a competent forth programmer, the coding of the solution is trivial as opposed to the essential understanding of the problem.
>  As for the demagoguery of 'wheel reinvention', one wheel is not every wheel.
> An appropriate wheel for one surface is not appropriate for another.
>  This, as I understand it, is a philosophy of forth. One can use the forth programming language any way one wants. But there is more to it than forth words.

Please feel free to enlighten us with your examples of devising non-trivial special purpose wheels in an area in which you had little or no expertise, and in which existing open source libraries existed which would also do the job. It doesn't matter what programming language you are using.

Also, loose talk about conservation of computational complexity is not at all convincing. Can you reference a mathematical proof of conservation of computational complexity? Is there an agreed upon definition of computational complexity? If neither of these exists, it doesn't matter what Chuck Moore or anyone else proclaims about conservation of computational complexity.


Krishna

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

#36030

 The extraordinary claim of the need of forth scientific math libraries is what requires extraordinary proof.
 I also think you're missing the point. I would not, nor would I recommend,   code/coding something beyond my/ones understanding.
 If the idea of conservation of complexity is outside of your experience and in need of proof, then an acceptance of needless complexity would seem likely.
 To someone that knows what they're doing forth is simple and easy. If it is complex and difficult, then it is not forth that is lacking.

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

#36031

Whammo wrote:

>  The extraordinary claim of the need of forth scientific math libraries is
>  what requires extraordinary proof.
>  I also think you're missing the point. I would not, nor would I
>  recommend,   code/coding something beyond my/ones understanding. If the
>  idea of conservation of complexity is outside of your experience and in
>  need of proof, then an acceptance of needless complexity would seem
>  likely. To someone that knows what they're doing forth is simple and
>  easy. If it is complex and difficult, then it is not forth that is
>  lacking.

I never find myself wanting to conserve complexity. I much prefer the notion 
that until you can reduce a problem to a simple statement of its essence you 
do not really understand the problem.

I have been re-visiting my development procedures with a view to further 
encourage the reduction of cyclomatic complexity at the requirements 
specification level. This is all aimed at ensuring requirements are Clear, 
Concise, Correct, Coherent, Complete and Confirm-able.

-- 
********************************************************************
Paul E. Bennett IEng MIET.....<email://Paul_E.Bennett@topmail.co.uk>
Forth based HIDECS Consultancy.............<http://www.hidecs.co.uk>
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-510979
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************

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

#36039

On Monday, January 26, 2015 at 3:23:41 AM UTC-6, Whammo wrote:
> The extraordinary claim of the need of forth scientific math libraries is what requires extraordinary proof.

Here, I have given a specific example of an application not written in Forth due to the lack of existing Forth code. The existence of the Forth Scientific Library is an expression of the need for numerical libraries. Programming languages which are used for scientific computation, Fortran, C, computing environments such as Mathematica, Matlab, and R, provide access to a vast number of library functions generally considered useful in scientific computing. 

You seem to be implying that libraries of Forth code are, in general, not necessary, and that each instance of a computational requirement should be coded separately. Or, perhaps you are restricting that to only numerical libraries?

>  I also think you're missing the point. I would not, nor would I recommend,   code/coding something beyond my/ones understanding.

Then, it seems to me that what you are saying is, if a programmer is unable to code an application from an in-depth knowledge of every computational requirement of the application, despite the existence of external code for areas which are tangential to the problem at hand, he/she should stop development to become a subject matter expert in that area, or, presumably just abandon the project altogether, because it is not the "Forth way" to try and make use of existing code.

>  If the idea of conservation of complexity is outside of your experience and in need of proof, then an acceptance of needless complexity would seem likely.

I believe I do understand the difference between science and pseudo-science. But, I'll admit that my knowledge of computer science is spotty, and there may exist a quantifiable definition of computational complexity. If not, any talk of conservation of such a quantity does not fall in the domain of science.

>  To someone that knows what they're doing forth is simple and easy. If it is complex and difficult, then it is not forth that is lacking.

I don't know how that's germane to this discussion. The problem at hand is not about difficulty in coding with the Forth language. It's about the lack of code in Forth to perform a specific type of computation, code which already exists in another language.

Krishna

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

#36046

On Monday, January 26, 2015 at 7:24:26 AM UTC-7, krishna...@ccreweb.org wrote:
> On Monday, January 26, 2015 at 3:23:41 AM UTC-6, Whammo wrote:
> > The extraordinary claim of the need of forth scientific math libraries is what requires extraordinary proof.
> 
> Here, I have given a specific example of an application not written in Forth due to the lack of existing Forth code. The existence of the Forth Scientific Library is an expression of the need for numerical libraries. Programming languages which are used for scientific computation, Fortran, C, computing environments such as Mathematica, Matlab, and R, provide access to a vast number of library functions generally considered useful in scientific computing. 
> 
> You seem to be implying that libraries of Forth code are, in general, not necessary, and that each instance of a computational requirement should be coded separately. Or, perhaps you are restricting that to only numerical libraries?
> 
> >  I also think you're missing the point. I would not, nor would I recommend,   code/coding something beyond my/ones understanding.
> 
> Then, it seems to me that what you are saying is, if a programmer is unable to code an application from an in-depth knowledge of every computational requirement of the application, despite the existence of external code for areas which are tangential to the problem at hand, he/she should stop development to become a subject matter expert in that area, or, presumably just abandon the project altogether, because it is not the "Forth way" to try and make use of existing code.
> 
> >  If the idea of conservation of complexity is outside of your experience and in need of proof, then an acceptance of needless complexity would seem likely.
> 
> I believe I do understand the difference between science and pseudo-science. But, I'll admit that my knowledge of computer science is spotty, and there may exist a quantifiable definition of computational complexity. If not, any talk of conservation of such a quantity does not fall in the domain of science.
> 
> >  To someone that knows what they're doing forth is simple and easy. If it is complex and difficult, then it is not forth that is lacking.
> 
> I don't know how that's germane to this discussion. The problem at hand is not about difficulty in coding with the Forth language. It's about the lack of code in Forth to perform a specific type of computation, code which already exists in another language.
> 
> Krishna

I'll stick my neck out here.....

I believe language choice is best handled with a pragmatic thought process.  When people deal with it objectively, it seems the discussion becomes circular and by the end of it, the consensus is some relative thing, like "all languages are irrelevant and programmer skill is THE variable that make programs good or bad". (Since I've never reached infinite programming perfection, I can't refute the claim that programmer skill makes the language good.)

Such conclusions always leaves me feeling a bit deflated, and I feel the language I'm frustrated with still sucks!

To be pragmatic, as I understand it, you've got to have a goal.  So, the key question to ask relative to your goal is "what benefits and losses do I get from using this (pick any) language"?  (To be pedantic, I think that pragmatism is only a good philosophy if you have good higher goals to which your lesser goals align.  But, that has nothing to do with choosing a language.)

I could guess at your goal, but I'm confident I'd not do it justice.  But, I assume want to use forth because you've heard that it is an awesome language that leads to really great software.  I do believe that claim (I'm still investigating so I'm not 100% sure), but I don't think it is the "forth language" that makes it so.  It's the forth methodology.

What you gain from using the forth methodology (with skill) is efficient, succinct, flexible, and understandable software.  And the language is designed around that methodology.  In other words, if you map a program from language X into forth, I do not think there will by *any* value added.

Now, before the trolls descend upon me, yes, I hereby declare that I do believe that you can write great software in other languages. But not to take away from other languages, I think forth is really good for this.

Because I said that forth is good for efficient, succinct, flexible, and understandable software, I don't mean to imply that *your* goals align with those ideals.  Your goal might be to bang out computations using techniques you've already learned.  Then the only relevant virtue I've listed here is efficiency (in time).  All the other listed virtues are nice and irrelevant.

My conclusion....you can draw your own.  But you have my take on it.


Good luck,
Andrew Bettilyon

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

#36061

On Monday, January 26, 2015 at 1:33:06 PM UTC-6, beeflo wrote:
> On Monday, January 26, 2015 at 7:24:26 AM UTC-7, krishna...@ccreweb.org wrote:
> > On Monday, January 26, 2015 at 3:23:41 AM UTC-6, Whammo wrote:
> > > The extraordinary claim of the need of forth scientific math libraries is what requires extraordinary proof.
> > 
> > Here, I have given a specific example of an application not written in Forth due to the lack of existing Forth code. The existence of the Forth Scientific Library is an expression of the need for numerical libraries. Programming languages which are used for scientific computation, Fortran, C, computing environments such as Mathematica, Matlab, and R, provide access to a vast number of library functions generally considered useful in scientific computing. 
> > 
> > You seem to be implying that libraries of Forth code are, in general, not necessary, and that each instance of a computational requirement should be coded separately. Or, perhaps you are restricting that to only numerical libraries?
> > 
> > >  I also think you're missing the point. I would not, nor would I recommend,   code/coding something beyond my/ones understanding.
> > 
> > Then, it seems to me that what you are saying is, if a programmer is unable to code an application from an in-depth knowledge of every computational requirement of the application, despite the existence of external code for areas which are tangential to the problem at hand, he/she should stop development to become a subject matter expert in that area, or, presumably just abandon the project altogether, because it is not the "Forth way" to try and make use of existing code.
> > 
> > >  If the idea of conservation of complexity is outside of your experience and in need of proof, then an acceptance of needless complexity would seem likely.
> > 
> > I believe I do understand the difference between science and pseudo-science. But, I'll admit that my knowledge of computer science is spotty, and there may exist a quantifiable definition of computational complexity. If not, any talk of conservation of such a quantity does not fall in the domain of science.
> > 
> > >  To someone that knows what they're doing forth is simple and easy. If it is complex and difficult, then it is not forth that is lacking.
> > 
> > I don't know how that's germane to this discussion. The problem at hand is not about difficulty in coding with the Forth language. It's about the lack of code in Forth to perform a specific type of computation, code which already exists in another language.
> > 
> > Krishna
> 
> I'll stick my neck out here.....
> 

Don't worry. We are not here to lop it off. A scratch might not be out of the question, though :-)

> I believe language choice is best handled with a pragmatic thought process.  When people deal with it objectively, it seems the discussion becomes circular and by the end of it, the consensus is some relative thing, like "all languages are irrelevant and programmer skill is THE variable that make programs good or bad". (Since I've never reached infinite programming perfection, I can't refute the claim that programmer skill makes the language good.)
> 
> Such conclusions always leaves me feeling a bit deflated, and I feel the language I'm frustrated with still sucks!
> 

The discussion here is not about choosing a good language for the computation task I discussed in my original posting. It's about the prerequisites for performing that task in Forth.

> To be pragmatic, as I understand it, you've got to have a goal.  So, the key question to ask relative to your goal is "what benefits and losses do I get from using this (pick any) language"?  (To be pedantic, I think that pragmatism is only a good philosophy if you have good higher goals to which your lesser goals align.  But, that has nothing to do with choosing a language.)
> 
> I could guess at your goal, but I'm confident I'd not do it justice.  But, I assume want to use forth because you've heard that it is an awesome language that leads to really great software.  I do believe that claim (I'm still investigating so I'm not 100% sure), but I don't think it is the "forth language" that makes it so.  It's the forth methodology.
> 

My goal at present is rather limited: port the h2plus.R program to Forth. It's a reasonable question to ask, why would you want to do this when you have a working version in R. My reply to that consists of the following points:

1) R provides a nice integrated environment with a lot of library functions, via interfaces to code written in other languages; however, it is very slow. The portions of the program written as R functions are slow compared to compiled code in other languages. So, there is an efficiency gain to be had in porting the application to another language such as Forth.

2) Testing and debugging in R is much better than running an executable built from Fortran or C, because it provides an interactive environment. The Forth environment provides at least the same level of interactivity for testing and debugging.

3) I would like to integrate the h2plus code with other computational code I have already developed in Forth.

For the moment, I would say 1) is the big concern.

And, yes, I have heard that Forth is an awesome language. Having used it for over 30 years, I find that to be true :-) But, I tend to dismiss the objectively unverifiable statements which people tend to make in this newsgroup.

> What you gain from using the forth methodology (with skill) is efficient, succinct, flexible, and understandable software.  And the language is designed around that methodology.  In other words, if you map a program from language X into forth, I do not think there will by *any* value added.
> 

Not true in general! See point 2) above. The presence of an interactive environment is of tremendous added value.


> Now, before the trolls descend upon me, yes, I hereby declare that I do believe that you can write great software in other languages. But not to take away from other languages, I think forth is really good for this.
> 
> Because I said that forth is good for efficient, succinct, flexible, and understandable software, I don't mean to imply that *your* goals align with those ideals.  Your goal might be to bang out computations using techniques you've already learned.  Then the only relevant virtue I've listed here is efficiency (in time).  All the other listed virtues are nice and irrelevant.
> 

Efficiency and interactivity.

> My conclusion....you can draw your own.  But you have my take on it.
> 
> 
> Good luck,
> Andrew Bettilyon

Thanks for your input.

Krishna

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

#36047

 Then why use the forth programming language? If you're going to dilute it's strengths, repudiate it's principles and equate it to other programming languages, what are you actually advocating?
 Forth is not just a programming language. It's an intellectual paradigm that is consistent with observed reality.

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

#36051

On Monday, January 26, 2015 at 12:37:36 PM UTC-7, Whammo wrote:
> Then why use the forth programming language? If you're going to dilute it's strengths, repudiate it's principles and equate it to other programming languages, what are you actually advocating?
>  Forth is not just a programming language. It's an intellectual paradigm that is consistent with observed reality.

Why use forth? Ummm, because "forth is good for efficient, succinct, flexible, and understandable software".

If that isn't extolling forth, then I don't know how.

If I didn't exhaustively praise forth to your satisfaction, then please refer to Thinking Forth by Leo Brodie with the idea that I ditto that whole thing. (At least I think I do because I've only skimmed it.)

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

#36053

On Monday, January 26, 2015 at 12:11:48 PM UTC-8, beeflo wrote:
> On Monday, January 26, 2015 at 12:37:36 PM UTC-7, Whammo wrote:
> > Then why use the forth programming language? If you're going to dilute it's strengths, repudiate it's principles and equate it to other programming languages, what are you actually advocating?
> >  Forth is not just a programming language. It's an intellectual paradigm that is consistent with observed reality.
> 
> Why use forth? Ummm, because "forth is good for efficient, succinct, flexible, and understandable software".
> 
> If that isn't extolling forth, then I don't know how.
> 
> If I didn't exhaustively praise forth to your satisfaction, then please refer to Thinking Forth by Leo Brodie with the idea that I ditto that whole thing. (At least I think I do because I've only skimmed it.)

 Yeah, this was not directed to you. Apologies.

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web