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

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

Astronomy and programming languages

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

Contents

  Astronomy and programming languages anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-03 09:09 +0000
    Re: Astronomy and programming languages krishna.myneni@ccreweb.org - 2017-06-03 04:38 -0700
      Re: Astronomy and programming languages anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-03 13:45 +0000
        Re: Astronomy and programming languages krishna.myneni@ccreweb.org - 2017-06-03 08:46 -0700
        Re: Astronomy and programming languages "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-06-03 18:49 +0000
      Re: Astronomy and programming languages "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-06-03 18:48 +0000
        Re: Astronomy and programming languages krishna.myneni@ccreweb.org - 2017-06-03 13:33 -0700
          Re: Astronomy and programming languages "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-06-03 22:34 +0000
          Re: Astronomy and programming languages Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-04 03:05 -0500
    Re: Astronomy and programming languages krishna.myneni@ccreweb.org - 2017-06-03 05:58 -0700
      Re: Astronomy and programming languages krishna.myneni@ccreweb.org - 2017-06-03 06:01 -0700
      Re: Astronomy and programming languages anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-03 13:37 +0000
        Re: Astronomy and programming languages foxaudioresearch@gmail.com - 2017-06-03 07:28 -0700
          Re: Astronomy and programming languages anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-10 17:31 +0000
        Re: Astronomy and programming languages mhx@iae.nl - 2017-06-03 08:21 -0700
          Re: Astronomy and programming languages Julian Fondren <julian.fondren@gmail.com> - 2017-06-03 12:01 -0700
            Re: Astronomy and programming languages mhx@iae.nl - 2017-06-03 13:09 -0700
            Re: Astronomy and programming languages mhx@iae.nl - 2017-06-03 13:20 -0700
              Re: Astronomy and programming languages Brad Eckert <hwfwguy@gmail.com> - 2017-06-03 18:30 -0700
              Re: Astronomy and programming languages Brad Eckert <hwfwguy@gmail.com> - 2017-06-03 18:43 -0700
                Re: Astronomy and programming languages anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-10 17:52 +0000
              Re: Astronomy and programming languages Julian Fondren <julian.fondren@gmail.com> - 2017-06-03 19:15 -0700
                Re: Astronomy and programming languages mhx@iae.nl - 2017-06-04 00:19 -0700
              Re: Astronomy and programming languages anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-10 17:39 +0000
    Re: Astronomy and programming languages NN <november.nihal@gmail.com> - 2017-06-03 06:57 -0700
      Re: Astronomy and programming languages anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-03 14:48 +0000
        Re: Astronomy and programming languages NN <november.nihal@gmail.com> - 2017-06-03 11:12 -0700
          Re: Astronomy and programming languages Mark Wills <markwills1970@gmail.com> - 2017-06-06 06:28 -0700
            Re: Astronomy and programming languages minforth@arcor.de - 2017-06-06 06:56 -0700
            Re: Astronomy and programming languages "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-06-07 19:40 +0000
            Re: Astronomy and programming languages Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-08 05:10 -0500
              Re: Astronomy and programming languages Mark Wills <markwills1970@gmail.com> - 2017-06-08 04:28 -0700
                Re: Astronomy and programming languages Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-08 07:20 -0500
                Re: Astronomy and programming languages Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-09 04:08 -0500
                  Re: Astronomy and programming languages Mark Wills <markwills1970@gmail.com> - 2017-06-09 02:31 -0700
                    Re: Astronomy and programming languages Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-06-09 03:54 -0700
                      Re: Astronomy and programming languages Mark Wills <markwills1970@gmail.com> - 2017-06-09 05:00 -0700
                  Re: Astronomy and programming languages Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-06-09 04:03 -0700
                    Re: Astronomy and programming languages Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-09 08:37 -0500
                    Re: Astronomy and programming languages hughaguilar96@gmail.com - 2017-06-09 09:27 -0700
        Re: Astronomy and programming languages Cecil Bayona <cbayona@cbayona.com> - 2017-06-03 13:49 -0500
          Re: Astronomy and programming languages Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-04 03:11 -0500
            Re: Astronomy and programming languages Paul Rubin <no.email@nospam.invalid> - 2017-06-04 17:20 -0700
              Re: Astronomy and programming languages Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-07 03:10 -0500
                Re: Astronomy and programming languages "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-06-07 19:41 +0000
                  Re: Astronomy and programming languages anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-08 11:48 +0000
                    Re: Astronomy and programming languages "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-06-09 17:25 +0000
                Re: Astronomy and programming languages Paul Rubin <no.email@nospam.invalid> - 2017-06-10 00:31 -0700
                  Re: Astronomy and programming languages Melzzzzz <Melzzzzz@zzzzz.com> - 2017-06-10 08:18 +0000
                    Re: Astronomy and programming languages Paul Rubin <no.email@nospam.invalid> - 2017-06-16 00:23 -0700
                      Re: Astronomy and programming languages Melzzzzz <Melzzzzz@zzzzz.com> - 2017-06-16 07:40 +0000
                  Re: Astronomy and programming languages Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-11 02:21 -0500
                    Re: Astronomy and programming languages Brad Eckert <hwfwguy@gmail.com> - 2017-06-14 23:36 -0700
        Re: Astronomy and programming languages Cecil Bayona <cbayona@cbayona.com> - 2017-06-03 13:53 -0500
    Re: Astronomy and programming languages mhx@iae.nl - 2017-06-03 08:04 -0700
      Re: Astronomy and programming languages rickman <gnuarm@gmail.com> - 2017-06-03 11:29 -0400
      Re: Astronomy and programming languages krishna.myneni@ccreweb.org - 2017-06-03 08:55 -0700
    Re: Astronomy and programming languages Brad Eckert <hwfwguy@gmail.com> - 2017-06-03 09:57 -0700
      Re: Astronomy and programming languages Paul Rubin <no.email@nospam.invalid> - 2017-06-03 10:35 -0700
      Re: Astronomy and programming languages Lars Brinkhoff <lars.spam@nocrew.org> - 2017-06-03 19:44 +0200
    Re: Astronomy and programming languages Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-06-03 10:15 -0700
      Re: Astronomy and programming languages Mark Wills <markwills1970@gmail.com> - 2017-06-06 06:20 -0700
        Re: Astronomy and programming languages Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-06-06 07:13 -0700
          Re: Astronomy and programming languages minforth@arcor.de - 2017-06-06 08:21 -0700
            Re: Astronomy and programming languages Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-06-06 09:05 -0700
          Re: Astronomy and programming languages Paul Rubin <no.email@nospam.invalid> - 2017-06-06 23:49 -0700
            Re: Astronomy and programming languages Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-06-07 00:58 -0700
          Re: Astronomy and programming languages Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-06-07 16:05 -0400
            Re: Astronomy and programming languages "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-06-07 20:26 +0000
              Re: Astronomy and programming languages Mark Wills <markwills1970@gmail.com> - 2017-06-07 14:00 -0700
                Re: Astronomy and programming languages hughaguilar96@gmail.com - 2017-06-07 15:46 -0700
                Re: Astronomy and programming languages "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-06-07 23:06 +0000
                  Re: Astronomy and programming languages Mark Wills <markwills1970@gmail.com> - 2017-06-08 01:24 -0700
                    Re: Astronomy and programming languages "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-06-09 17:27 +0000
                Re: Astronomy and programming languages "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-06-07 23:08 +0000
                  Re: Astronomy and programming languages Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-06-07 22:26 -0700
                    Re: Astronomy and programming languages Mark Wills <markwills1970@gmail.com> - 2017-06-08 01:29 -0700
                    Re: Astronomy and programming languages Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-06-08 08:28 -0400
                      Re: Astronomy and programming languages Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-06-08 08:02 -0700
                  Re: Astronomy and programming languages Mark Wills <markwills1970@gmail.com> - 2017-06-08 01:26 -0700
                    Re: Astronomy and programming languages "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-06-09 17:30 +0000
                Re: Astronomy and programming languages Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-08 05:17 -0500
                  Re: Astronomy and programming languages Mark Wills <markwills1970@gmail.com> - 2017-06-08 04:37 -0700
                    Re: Astronomy and programming languages Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-08 07:28 -0500
                      Re: Astronomy and programming languages "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-06-09 17:33 +0000
              Re: Astronomy and programming languages anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-08 11:46 +0000
                Re: Astronomy and programming languages "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-06-09 17:35 +0000
                  Re: Astronomy and programming languages Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-10 02:18 -0500
                    Re: Astronomy and programming languages "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-06-10 07:54 +0000
                    Re: Astronomy and programming languages "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-06-10 08:00 +0000
                      Re: Astronomy and programming languages Melzzzzz <Melzzzzz@zzzzz.com> - 2017-06-10 08:38 +0000
                        Re: Astronomy and programming languages "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-06-11 17:53 +0000
                          Re: Astronomy and programming languages Melzzzzz <Melzzzzz@zzzzz.com> - 2017-06-11 18:03 +0000
                            Re: Astronomy and programming languages "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-06-11 18:17 +0000
                              Re: Astronomy and programming languages Melzzzzz <Melzzzzz@zzzzz.com> - 2017-06-11 18:23 +0000
                            Re: Astronomy and programming languages Alex <alex@rivadpm.com> - 2017-06-11 19:21 +0100
                              Re: Astronomy and programming languages Melzzzzz <Melzzzzz@zzzzz.com> - 2017-06-11 18:24 +0000
                                Re: Astronomy and programming languages Alex <alex@rivadpm.com> - 2017-06-11 19:28 +0100
                                  Re: Astronomy and programming languages Melzzzzz <Melzzzzz@zzzzz.com> - 2017-06-11 19:04 +0000
                                    Re: Astronomy and programming languages Alex <alex@rivadpm.com> - 2017-06-11 21:13 +0100
                                      Re: Astronomy and programming languages Alex <alex@rivadpm.com> - 2017-06-11 21:22 +0100
                                        Re: Astronomy and programming languages Melzzzzz <Melzzzzz@zzzzz.com> - 2017-06-12 03:11 +0000
                                          Re: Astronomy and programming languages anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-12 07:38 +0000
                                            Re: Astronomy and programming languages Melzzzzz <Melzzzzz@zzzzz.com> - 2017-06-12 08:13 +0000
                                              Re: Astronomy and programming languages Alex <alex@rivadpm.com> - 2017-06-12 11:22 +0100
                                          Re: Astronomy and programming languages Alex <alex@rivadpm.com> - 2017-06-12 11:48 +0100
                            Re: Astronomy and programming languages anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-12 13:58 +0000
                              Re: Astronomy and programming languages Melzzzzz <Melzzzzz@zzzzz.com> - 2017-06-13 02:19 +0000
                  Re: Astronomy and programming languages anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-10 13:16 +0000
                    Re: Astronomy and programming languages "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-06-11 17:53 +0000
              Re: Astronomy and programming languages Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-06-08 08:28 -0400
                Re: Astronomy and programming languages "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-06-09 17:38 +0000
    Re: Astronomy and programming languages Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-03 12:23 -0500
    Re: Astronomy and programming languages Paul Rubin <no.email@nospam.invalid> - 2017-06-03 10:27 -0700
    Re: Astronomy and programming languages "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-06-03 18:46 +0000
    Re: Astronomy and programming languages Julian Fondren <julian.fondren@gmail.com> - 2017-06-03 12:42 -0700
      Re: Astronomy and programming languages "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-06-03 22:24 +0000
        Re: Astronomy and programming languages Julian Fondren <julian.fondren@gmail.com> - 2017-06-03 15:34 -0700
          Re: Astronomy and programming languages "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-06-03 22:55 +0000
    Re: Astronomy and programming languages Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-06-10 10:27 -0700
    A Small Challenge (Re: Astronomy and programming languages) Joel Rees <joel.rees@gmail.com> - 2017-06-12 22:20 -0700
      Re: A Small Challenge (Re: Astronomy and programming languages) Paul Rubin <no.email@nospam.invalid> - 2017-06-12 22:52 -0700
      Re: A Small Challenge (Re: Astronomy and programming languages) Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-06-13 10:04 -0400
      Re: A Small Challenge (Re: Astronomy and programming languages) minforth@arcor.de - 2017-06-13 07:30 -0700
      Re: A Small Challenge (Re: Astronomy and programming languages) Cecil Bayona <cbayona@cbayona.com> - 2017-06-13 10:52 -0500

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

#60222 — Astronomy and programming languages

LWN has an article about the use Python in Science; it reports on a
talk given by an astronomer; the article is

https://lwn.net/Articles/724255/

(or, if you are not a subscriber, and don't want to wait until it
becomes available for guest readers,
<https://lwn.net/SubscriberLink/724255/f4d359c97e185889/>).

The talk itself (that I did not look at because of JavaScript) is at

https://www.youtube.com/watch?v=ZyjCqQEUa8o
https://speakerdeck.com/jakevdp/the-unexpected-effectiveness-of-python-in-science

The interesting thing for Forthers context is that Forth used to be
very strong in astronomy.  There is a section in the article titled
"Why Python?"  Some of the reasons mentioned there are an antithesis
to the positions many present as Forth philosophy: It is used
because:

* it works nicely with other languages such as C and Fortran, rather
  than doing everything yourself because you can do it better.

* it has a "battries included" philopsophy of providing all sorts of
  extras rather than minimalism that worries about kilobytes on a
  gigabyte machine.

* there is a huge number of third-party libraries that can be and are
  used, even though they are 'full of inefficient code to take care of
  all possible cases, etc.'

* You can publish the Python code, and another scientist can use it to
  reproduce your result (and check what you did to the data to get the
  result).  This requires a stronger level of portability than the
  concept of "programmer portability" or the attitude "you can do it
  on every system using carnal knowledge" that we can often see here.

So, while the positions that are often called the Forth philosophy
have their virtues in some contexts, they are probably a major
contributor for Forth's decline in astronomy.

Some want to make us believe that the reason for the lack of
popularity of Forth is the lack of a marketing campaign by a big
corporation, but if that was the case, astronomers would be
programming in PL/I, not Python.  Also, it's pretty hard to wean
programmers off their favourite language, and network effects make it
easy for a language to stay in a field where it is strong.  Forth
obviously dropped the ball in astronomy.

Anyway, my conclusions: The positions that are usually presented as
Forth philosophy are not beneficial in every case, so we should not
treat them as absolutes.  And some of the things that are often
maligned here, in particular, libraries, are actually helpful in many
cases.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2017: http://www.euroforth.org/ef17/

[toc] | [next] | [standalone]

#60223

On Saturday, June 3, 2017 at 5:35:30 AM UTC-5, Anton Ertl wrote:
> LWN has an article about the use Python in Science; it reports on a
> talk given by an astronomer; the article is
> 
> https://lwn.net/Articles/724255/
> 
> (or, if you are not a subscriber, and don't want to wait until it
> becomes available for guest readers,
> <https://lwn.net/SubscriberLink/724255/f4d359c97e185889/>).
> 
> The talk itself (that I did not look at because of JavaScript) is at
> 
> https://www.youtube.com/watch?v=ZyjCqQEUa8o
> https://speakerdeck.com/jakevdp/the-unexpected-effectiveness-of-python-in-science
> 
> The interesting thing for Forthers context is that Forth used to be
> very strong in astronomy.  There is a section in the article titled
> "Why Python?"  Some of the reasons mentioned there are an antithesis
> to the positions many present as Forth philosophy: It is used
> because:
> 
> * it works nicely with other languages such as C and Fortran, rather
>   than doing everything yourself because you can do it better.
> 
> * it has a "battries included" philopsophy of providing all sorts of
>   extras rather than minimalism that worries about kilobytes on a
>   gigabyte machine.
> 
> * there is a huge number of third-party libraries that can be and are
>   used, even though they are 'full of inefficient code to take care of
>   all possible cases, etc.'
> 
> * You can publish the Python code, and another scientist can use it to
>   reproduce your result (and check what you did to the data to get the
>   result).  This requires a stronger level of portability than the
>   concept of "programmer portability" or the attitude "you can do it
>   on every system using carnal knowledge" that we can often see here.
> 
> So, while the positions that are often called the Forth philosophy
> have their virtues in some contexts, they are probably a major
> contributor for Forth's decline in astronomy.
> 
> Some want to make us believe that the reason for the lack of
> popularity of Forth is the lack of a marketing campaign by a big
> corporation, but if that was the case, astronomers would be
> programming in PL/I, not Python.  Also, it's pretty hard to wean
> programmers off their favourite language, and network effects make it
> easy for a language to stay in a field where it is strong.  Forth
> obviously dropped the ball in astronomy.
> 
> Anyway, my conclusions: The positions that are usually presented as
> Forth philosophy are not beneficial in every case, so we should not
> treat them as absolutes.  And some of the things that are often
> maligned here, in particular, libraries, are actually helpful in many
> cases.
> 

Have you done any tests comparing the efficiency of Python code, compared to Forth source compiled by an optimizing compiler? I think Python derives much of its usability by providing a consistent library interface to efficient C and Fortran libraries. No one in the Python user community seems to care that the efficient numerical or other computing code which they use was not written in Python. I'm not sure that's what the Forth community should be striving towards. 

It's useful to provide a portable library interface in Forth, and providing portable Forth source libraries are important. But non-portable libraries, e.g. mixed Forth and assembler code, can also be very useful. Yes, the astronomy community left Forth behind, but I don't necessarily believe that's a fault of the Forth community. It's just that the needs and interests of the two communities overlapped for a brief time and then diverged. Nothing wrong with that. And I don't think we should be overly pessimistic about future use of Forth, either. We seem to be headed in the right direction by defining standards (which can be open to revision later) and writing code intended to be portable across Forth systems.

Krishna

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

#60230

krishna.myneni@ccreweb.org writes:
>Have you done any tests comparing the efficiency of Python code, compared t=
>o Forth source compiled by an optimizing compiler?

No, but I have no doubt that Forth beats Python by a good margin.

>I think Python derives m=
>uch of its usability by providing a consistent library interface to efficie=
>nt C and Fortran libraries. No one in the Python user community seems to ca=
>re that the efficient numerical or other computing code which they use was =
>not written in Python. I'm not sure that's what the Forth community should =
>be striving towards.=20

Should we reject using a library just because it is written in C or
Fortran?  Some in the Forth community suggest rejecting even libraries
written in Forth, because "full of inefficient code to take care of
all possible cases, etc.".  I, OTOH, think that if the library
satisfies the requirements, using it should certainly be considered,
whatever language it is written in.

>But non-portable libraries,=
> e.g. mixed Forth and assembler code, can also be very useful.

Sure.  My point was that being able to run code unaltered on several
Forth systems and when, e.g., installed in different directories has a
benefit that is not sufficiently appreciated here.

>Yes, the ast=
>ronomy community left Forth behind, but I don't necessarily believe that's =
>a fault of the Forth community. It's just that the needs and interests of t=
>he two communities overlapped for a brief time and then diverged. Nothing w=
>rong with that.

I think there is something wrong with that.  The "Forth philosophy" in
the form advocated by many here has painted Forth into a corner that
is much narrower than the language deserves.

>And I don't think we should be overly pessimistic about fut=
>ure use of Forth, either. We seem to be headed in the right direction by de=
>fining standards (which can be open to revision later) and writing code int=
>ended to be portable across Forth systems.

The problem I see that code portability is not valued much by many in
the community, including some standards committee members.

As for the future use of Forth, then well, if micorcontrollers with,
16KB ROM and 1KB RAM or thereabouts are the only place where we want
to use Forth, then we are right where we want to be.  If, OTOH, we
also want to see Forth used elsewhere, we have to be more flexible
wrt the philosophy.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2017: http://www.euroforth.org/ef17/

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

#60237

On Saturday, June 3, 2017 at 9:15:49 AM UTC-5, Anton Ertl wrote:
> krishna...org writes:
> >Have you done any tests comparing the efficiency of Python code, compared to Forth source compiled by an optimizing compiler?
> 
> No, but I have no doubt that Forth beats Python by a good margin.
> 
> >I think Python derives much of its usability by providing a consistent library interface to efficient C and Fortran libraries. No one in the Python user community seems to care that the efficient numerical or other computing code which they use wasnot written in Python. I'm not sure that's what the Forth community should be striving towards.
> 
> Should we reject using a library just because it is written in C or Fortran? 
 
Absolutely not. I never suggested that nor do I subscribe to that notion. But, in python, use of external libraries from C and Fortran, and maybe other compiled languages, is the norm rather than the exception. I don't believe use of Forth on the desktop should be based primarily on interfaces to code compiled from other languages -- such practice makes it difficult to debug library code at a fine-grained level from within the Forth environment. My preference is to use source code libraries, whenever possible.

> Some in the Forth community suggest rejecting even libraries written in Forth, because "full of inefficient code to take care of all possible cases, etc.".  I, OTOH, think that if the library satisfies the requirements, using it should certainly be considered, whatever language it is written in.

I agree with your sentiments on this. Forth purists don't impress me.

> >But non-portable libraries, e.g. mixed Forth and assembler code, can also be very useful.
> 
> Sure.  My point was that being able to run code unaltered on several Forth systems and when, e.g., installed in different directories has a benefit that is not sufficiently appreciated here.

I've always worked towards that. It's why I provide strict ANS Forth compatible versions of my kForth programs, whenever possible, and whenever time permits. For example:

ftp://ccreweb.org/software/gforth/
ftp://ccreweb.org/software/fsl/

> >Yes, the astronomy community left Forth behind, but I don't necessarily believe that's a fault of the Forth community. It's just that the needs and interests of the two communities overlapped for a brief time and then diverged. Nothing wrong with that.
 
> I think there is something wrong with that.  The "Forth philosophy" in the form advocated by many here has painted Forth into a corner that is much narrower than the language deserves.

I ignore those statements. As you know, I've been an advocate of Forth on the desktop here in c.l.f. The use of Forth for embedded controllers is just one application area, but the language has much more general applicability. I don't want to see the language evolve away from having a close and direct link with the hardware -- the ability to mix Forth and assembly code with ease is a non-negotiable feature of Forth for me. At the same time, I want to see standardized features which allow more exploratory programming. I first suggested standardizing TRAVERSE-WORDLIST here on c.l.f. some years ago, as a result of finding it to be a desired feature when we developed our portable modular programming framework for ANS Forth. I'm glad to see improvements in Forth 200x, such as the XCHARS wordset. These are all steps in the right direction for expanding the application space for Forth.
  
> >And I don't think we should be overly pessimistic about future use of Forth, either. We seem to be headed in the right direction by defining standards (which can be open to revision later) and writing code intended to be portable across Forth systems.
> 
> The problem I see that code portability is not valued much by many in the community, including some standards committee members.

Yes, there is resistance. We need to keep writing portable Forth code and libraries.

> As for the future use of Forth, then well, if micorcontrollers with, 16KB ROM and 1KB RAM or thereabouts are the only place where we want to use Forth, then we are right where we want to be.  If, OTOH, we also want to see Forth used elsewhere, we have to be more flexible wrt the philosophy.

I think the availability of applications, whether they use external libraries, or Forth source libraries, will adjust our philosophy.

Krishna

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

#60249

Anton Ertl wrote:

> > I think Python derives m=
> > uch of its usability by providing a consistent library interface to
> > efficie= nt C and Fortran libraries. No one in the Python user
> > community seems to ca= re that the efficient numerical or other
> > computing code which they use was = not written in Python. I'm not
> > sure that's what the Forth community should = be striving
> > towards.=20
> 
> Should we reject using a library just because it is written in C or
> Fortran?  Some in the Forth community suggest rejecting even libraries
> written in Forth, because "full of inefficient code to take care of
> all possible cases, etc.".  I, OTOH, think that if the library
> satisfies the requirements, using it should certainly be considered,
> whatever language it is written in.

Indeed.

-- 
Rudy Velthuis        http://www.rvelthuis.de

"Roses are #FF0000
 Violets are #0000FF
 All my base are belong to you!"
 -- Geek Valentine T-shirt at ThinkGeek

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

#60247

krishna.myneni@ccreweb.org wrote:

> On Saturday, June 3, 2017 at 5:35:30 AM UTC-5, Anton Ertl wrote:
> > LWN has an article about the use Python in Science; it reports on a
> > talk given by an astronomer; the article is
> > 
> > https://lwn.net/Articles/724255/
> > 
> > (or, if you are not a subscriber, and don't want to wait until it
> > becomes available for guest readers,
> > <https://lwn.net/SubscriberLink/724255/f4d359c97e185889/>).
> > 
> > The talk itself (that I did not look at because of JavaScript) is at
> > 
> > https://www.youtube.com/watch?v=ZyjCqQEUa8o
> >
https://speakerdeck.com/jakevdp/the-unexpected-effectiveness-of-python-in-science
> > 
> > The interesting thing for Forthers context is that Forth used to be
> > very strong in astronomy.  There is a section in the article titled
> > "Why Python?"  Some of the reasons mentioned there are an antithesis
> > to the positions many present as Forth philosophy: It is used
> > because:
> > 
> > * it works nicely with other languages such as C and Fortran, rather
> >   than doing everything yourself because you can do it better.
> > 
> > * it has a "battries included" philopsophy of providing all sorts of
> >   extras rather than minimalism that worries about kilobytes on a
> >   gigabyte machine.
> > 
> > * there is a huge number of third-party libraries that can be and
> > are   used, even though they are 'full of inefficient code to take
> > care of   all possible cases, etc.'
> > 
> > * You can publish the Python code, and another scientist can use it
> > to   reproduce your result (and check what you did to the data to
> > get the   result).  This requires a stronger level of portability
> > than the   concept of "programmer portability" or the attitude "you
> > can do it   on every system using carnal knowledge" that we can
> > often see here.
> > 
> > So, while the positions that are often called the Forth philosophy
> > have their virtues in some contexts, they are probably a major
> > contributor for Forth's decline in astronomy.
> > 
> > Some want to make us believe that the reason for the lack of
> > popularity of Forth is the lack of a marketing campaign by a big
> > corporation, but if that was the case, astronomers would be
> > programming in PL/I, not Python.  Also, it's pretty hard to wean
> > programmers off their favourite language, and network effects make
> > it easy for a language to stay in a field where it is strong.  Forth
> > obviously dropped the ball in astronomy.
> > 
> > Anyway, my conclusions: The positions that are usually presented as
> > Forth philosophy are not beneficial in every case, so we should not
> > treat them as absolutes.  And some of the things that are often
> > maligned here, in particular, libraries, are actually helpful in
> > many cases.
> > 
> 
> Have you done any tests comparing the efficiency of Python code,
> compared to Forth source compiled by an optimizing compiler?

Except on minimal systems, speed is overrated. Sure, in a critical
loop, it is important, but otherwise?

-- 
Rudy Velthuis        http://www.rvelthuis.de

"UNIX is simple. It just takes a genius to understand its 
 simplicity."-- Dennis Ritchie

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

#60257

On Saturday, June 3, 2017 at 1:48:15 PM UTC-5, Rudy Velthuis wrote:
> krishna...org wrote:
> 
...
> > Have you done any tests comparing the efficiency of Python code, compared to Forth source compiled by an optimizing compiler?

> Except on minimal systems, speed is overrated. Sure, in a critical loop, it is important, but otherwise?

It's about expanding the application space for Forth programs. There are at least a couple of application areas where speed is important: 1) intensive numerical computing, 2) large data set processing. Forth programmers could choose to do one of the following:

a) Use a highly-optimizing Forth compiler to write needed libraries.

b) Use a non-optimizing Forth compiler, but code the critical words in assembler.

c) Use a) or b) in conjunction with external C or Fortran compiled libraries, written for such uses.

Anton's primary complaint seems to be the resistance to both portable Forth source libraries, and resistance to portable interfaces for external libraries.

Krishna

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

#60260

krishna.myneni@ccreweb.org wrote:

> On Saturday, June 3, 2017 at 1:48:15 PM UTC-5, Rudy Velthuis wrote:
> > krishna...org wrote:
> > 
> ...
> > > Have you done any tests comparing the efficiency of Python code,
> > > compared to Forth source compiled by an optimizing compiler?
> 
> > Except on minimal systems, speed is overrated. Sure, in a critical
> > loop, it is important, but otherwise?
> 
> It's about expanding the application space for Forth programs. There
> are at least a couple of application areas where speed is important:

> 1) intensive numerical computing, 2) large data set processing.

As I said, in critical loops (which is usually what happens in
intensive numerical computing as well as in large data set processing),
speed is important.

If Python needs speed, it usually relies on algorithms written in C or
Fortran (e.g. in the NumPy or SciPy libraries for numerical computing)
or some other compiled language. This seems to be a no-no in the Forth
world.

-- 
Rudy Velthuis        http://www.rvelthuis.de

"Cholesterol is your natural defence against excessive 
 circulation of blood, which can carry venoms, poisons and other 
 toxins around your body." -- Michael Warner, in bpot

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

#60270

krishna.myneni@ccreweb.org wrote:
> On Saturday, June 3, 2017 at 1:48:15 PM UTC-5, Rudy Velthuis wrote:
>> krishna...org wrote:
>> 
> ...

>> > Have you done any tests comparing the efficiency of Python code,
>> > compared to Forth source compiled by an optimizing compiler?
> 
>> Except on minimal systems, speed is overrated. Sure, in a critical
>> loop, it is important, but otherwise?
> 
> It's about expanding the application space for Forth programs. There
> are at least a couple of application areas where speed is important:
> 1) intensive numerical computing, 2) large data set
> processing. Forth programmers could choose to do one of the
> following:
> 
> a) Use a highly-optimizing Forth compiler to write needed libraries.
> 
> b) Use a non-optimizing Forth compiler, but code the critical words
> in assembler.
> 
> c) Use a) or b) in conjunction with external C or Fortran compiled
> libraries, written for such uses.

I think that efficient code is important in most areas of computing.
Without it, we waste time and energy by making computers hotter and
therefore harder to cool, and therefore more expensive.  And we have
to wait for computers to do things.  Of course there has to be a
sensible trade-off: there's no point going to heroic lengths to
optimize a routine that will only be called once.  In many areas of
engineering there have been huge strides in efficiency, and we should
be doing that too.

Andrew.

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

#60225

On Saturday, June 3, 2017 at 5:35:30 AM UTC-5, Anton Ertl wrote:
...
> The talk itself (that I did not look at because of JavaScript) is at
> 
> https://www.youtube.com/watch?v=ZyjCqQEUa8o
...

I watched the video with some amusement. The speaker has never collected data, nor apparently ever built any instruments which required programming. He has done data reduction, which admittedly, is probably what many astronomers and high-energy physicists do. So, he is talking only about one particular experience in science, which is mostly relevant to "big science". Data analysis and visualization are certainly important for science, but they are not the complete set of activities. And, as he states in the video, the reason python is effective for those tasks is that it can act as a "glue" for different tools: software libraries, and important data from different sources. Ok, that's fine. But, what if you need more than glue, or just a scripting language? What if you need a language capable of being used to write the original software components which are being glued together?

Krishna

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

#60226

On Saturday, June 3, 2017 at 7:58:58 AM UTC-5, krishna...@ccreweb.org wrote:
> On Saturday, June 3, 2017 at 5:35:30 AM UTC-5, Anton Ertl wrote:
> ...
> > The talk itself (that I did not look at because of JavaScript) is at
> > 
> > https://www.youtube.com/watch?v=ZyjCqQEUa8o
> ...
> 
> ... And, as he states in the video, the reason python is effective for those tasks is that it can act as a "glue" for different tools: software libraries, and important data from different sources. ...

That should have been " ... import data from different sources".

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

#60228

krishna.myneni@ccreweb.org writes:
>And, as he states in the video, the r=
>eason python is effective for those tasks is that it can act as a "glue" fo=
>r different tools: software libraries, and important data from different so=
>urces. Ok, that's fine. But, what if you need more than glue, or just a scr=
>ipting language? What if you need a language capable of being used to write=
> the original software components which are being glued together?

Python can also do that.  Or, if the performance of Python is
insufficient for the task at hand, they will reach for C, C++, or
Fortran.

Why not Forth?  Python has features for interfacing with C and
ABI-compatible languages, but not for interfacing with Forth.  Why
not?  Are there any Forth libraries that are worth interfacing to?

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2017: http://www.euroforth.org/ef17/

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

#60231

> 
> Why not Forth?  Python has features for interfacing with C and
> ABI-compatible languages, but not for interfacing with Forth.  Why
> not?  Are there any Forth libraries that are worth interfacing to?
> 
> - anton
> -- 
> M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
> comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
>      New standard: http://www.forth200x.org/forth200x.html
>    EuroForth 2017: http://www.euroforth.org/ef17/

Maybe GForth should be available as a library for Python that can be used to write things that are not easy or possible in Python.  The interface could be text strings in and out.  Is that a crazy idea?

B

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

#60574

foxaudioresearch@gmail.com writes:
>> 
>> Why not Forth?  Python has features for interfacing with C and
>> ABI-compatible languages, but not for interfacing with Forth.  Why
>> not?  Are there any Forth libraries that are worth interfacing to?
...
>Maybe GForth should be available as a library for Python that can be used to write things that are not easy or possible in Python.  The interface could be text strings in and out.  Is that a crazy idea?

Not particularly.  The "strings in and out" idea has been used in some
distributed Forth applications, and it certainly can be used for
interfacing to Python; it would allow having Python and Forth in
separate processes, which would very much reduce the headaches that
interfacing between a managaed language like Python and a low-level
language like Forth has when it's done in the same process.  The
disadvantage is that communication would be more expensive than
passing pointers to some structures in memory in the same process.

But anyway, my question was why a Python user would want to use such a
Gforth library for Python rather than the established C framework.
Does Forth have any killer libraries or other features to offer to a
Python programmer?

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2017: http://www.euroforth.org/ef17/

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

#60235

On Saturday, June 3, 2017 at 3:45:20 PM UTC+2, Anton Ertl wrote:
> krishna.myneni@ccreweb.org writes:
> >And, as he states in the video, the r=
> >eason python is effective for those tasks is that it can act as a "glue" fo=
> >r different tools: software libraries, and important data from different so=
> >urces. Ok, that's fine. But, what if you need more than glue, or just a scr=
> >ipting language? What if you need a language capable of being used to write=
> > the original software components which are being glued together?
> 
> Python can also do that.  Or, if the performance of Python is
> insufficient for the task at hand, they will reach for C, C++, or
> Fortran.
> 
> Why not Forth?  Python has features for interfacing with C and
> ABI-compatible languages, but not for interfacing with Forth.  Why
> not?  Are there any Forth libraries that are worth interfacing to?

I would say the most important asset of Forth is its interpreter.
However, the interpreter should be able to call all these great
(foreign) libraries that are already available. And that mechanism 
is not standard :-)  We can't even open a arbitrary text file in a 
standard way.

-marcel

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

#60251

On Saturday, June 3, 2017 at 10:21:03 AM UTC-5, m...@iae.nl wrote:
> I would say the most important asset of Forth is its interpreter.
> However, the interpreter should be able to call all these great
> (foreign) libraries that are already available. And that mechanism
> is not standard :-)

gforth, iForth, SwiftForth, and VFX all have "use libsomething.so" and
"call this function by name that takes this N arguments from the
stack", and "here's some way to associate Forth with a callback for a
C library that takes N arguments".

There are some commonalities: iForth and VFX have a shared
higher-level FFI (Extern:), and then VFX and SwiftForth share
SwiftForth's FFI (Library Function:).

There are some differences: iForth's lower-level FFI with dynlink.frt
has a LIBRARY-FIND that returns a constant that you then need to pass
separately to FOREIGN , so creating a wrapper is a two-step process:

  s" curl_easy_init" libcurl library-find throw constant c-curl_easy_init

and then:

  : curl_easy_init ( -- handle )  0 c-curl_easy_init foreign ;

whereas this is a one-step process elsewhere.  And this FOREIGN always
returns 1 argument, so you need to DROP after calling a void function,
whereas other FFI handle that for you.

So a universal Forth FFI-to-C doesn't seem far off, something that
just compiles with zero overhead to an FFI that the given Forth
already supports. Although the Extern: and Function: interfaces both
parse out parameter lists, it's just to get the number of arguments to
pass. The gap is in advanced ways of getting constants; that you can
defer to the build system.

>  We can't even open a arbitrary text file in a
> standard way.

On POSIX if OPEN-FILE is a thin wrapper over open() or fopen(), then
you're at the standard met by most other languages. Do you mean that
there isn't a 'search order' for files, that OPEN-FILE doesn't look
for a file several locations before giving up?

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

#60254

On Saturday, June 3, 2017 at 9:01:10 PM UTC+2, Julian Fondren wrote:
[..]
> There are some differences: iForth's lower-level FFI with dynlink.frt
> has a LIBRARY-FIND that returns a constant that you then need to pass
> separately to FOREIGN , so creating a wrapper is a two-step process:
> 
>   s" curl_easy_init" libcurl library-find throw constant c-curl_easy_init
> 
> and then:
> 
>   : curl_easy_init ( -- handle )  0 c-curl_easy_init foreign ;
> 
> whereas this is a one-step process elsewhere.  And this FOREIGN always
> returns 1 argument, so you need to DROP after calling a void function,
> whereas other FFI handle that for you.

Are you sure? That looks a bit 2014-ish (still supported as 
one of the layers course). 

Nowadays we prefer Hanno's dynlibs.frt:

WINDOWS? [IF] 	Library: SDL.dll
		Library: openGL32.dll
		Library: glu32.dll
		Library: glew32.dll
       [ELSE]	Library: libSDL_image.so
	 	Library: libSDL.so
       		Library: libGL.so
		Library: libGLU.so
		Library: libGLEW.so
       [THEN]

AliasedExtern: sdl-init	int SDL_Init ( int flags );
AliasedExtern: sdl-quit void SDL_Quit ( void );
AliasedExtern: sdl-geterror int SDL_GetError ( void );
AliasedExtern: sdl-getvideoinfo int  SDL_GetVideoInfo ( void );
AliasedExtern: sdl-set-video-mode int  SDL_SetVideoMode	( int width, int height, int bpp, int flags );

etc. (spaced parameter lists are my private preference).

-marcel

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

#60256

On Saturday, June 3, 2017 at 9:01:10 PM UTC+2, Julian Fondren wrote:
[..]
> >  We can't even open a arbitrary text file in a
> > standard way.
> 
> On POSIX if OPEN-FILE is a thin wrapper over open() or fopen(), then
> you're at the standard met by most other languages. Do you mean that
> there isn't a 'search order' for files, that OPEN-FILE doesn't look
> for a file several locations before giving up?

There is that, but we also can't reliably specify a pathname (which 
characters, which slashes or other separators (:, ~), relative or 
absolute, case-sensitive or not ...).
An included file does not know how to get its support files, even 
if they are in the same directory.

File names and paths, plus the FFI, and we would be all set to go.

-marcel

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

#60262

On Saturday, June 3, 2017 at 1:20:06 PM UTC-7, m...@iae.nl wrote:> 
> There is that, but we also can't reliably specify a pathname (which 
> characters, which slashes or other separators (:, ~), relative or 
> absolute, case-sensitive or not ...).
> An included file does not know how to get its support files, even 
> if they are in the same directory.
> 

Yes, there's that. Abstracting out the OS dependencies flies in the face of Forth's simplicity, which is its whole value proposition. But, things have to change. Somewhere along the line, in the last few years and under our very noses, Google killed the OS as a business model. Besides the obvious repercussions for Redheads and fruit companies, there will be an increasing need for Forth code to be OS-agnostic.

Just as the VM became virtual, so must the OS.

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

#60263

On Saturday, June 3, 2017 at 1:20:06 PM UTC-7, m...@iae.nl wrote:
> 
> There is that, but we also can't reliably specify a pathname 

There's also the question of who "We" is/are. The established Forth vendors are obligated to not break code. There is little incentive to promote "new code" because "old code" is a huge economic engine that many parties rely upon.

If you want to work out the OS agnostification and put it out there, I'd be happy to consider it. Besides, it's in the interests of parties who place inclusiveness above exclusiveness (for whatever well deserved reasons) to lead Forth into the future, because that's the future.

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

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

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

csiph-web