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 3 of 7 — ← Prev page 1 2 [3] 4 5 6 7  Next page →

#60248

On 6/3/2017 9:48 AM, Anton Ertl wrote:
> NN <november.nihal@gmail.com> writes:
>> Can you elaborate on what you meant when you refer to positions many present as forth philosopy ? What are these positions and who is presenting these ?
> 
> Apparently the positions are not clear enough from the way I
> contrasted them with the reasons for using Python, so I'll make them
> more explicit here:
> 
> 1) C and other languages are evil or at least there is nothing of
>     value there, so we don't need to interface with them (except for
>     dealing with the OS).  We certainly don't need to interface with C
>     or Fortran libraries, see also 3).  (There is even a meme here that
>     rejects a feature with the (usually incorrect) argument that it
>     would make Forth more like C; e.g., some argued against number
>     prefixes such as $10 and #10 with that argument, even though $10
>     and #10 are not part of C).
> 
> 2) We must minimize everything at all costs.  Consuming a KB or an MB
>     for a convenience feature is against the Forth philosophy; whether
>     we have GBs of RAM to spare does not matter.
> 
> 3) Libraries are "full of inefficient code to take care of
>    all possible cases, etc."
> 
> 4) There is no need to standardize a feature if you can already do it
>     on some systems using carnal knowledge.  The value of the standard
>     is in programmer portability.  Loading programs unchanged is not
>     relevant to real programmers, and requiring to change some lines of
>     code in various places is the proper way to deal with moving code
>     between directories or computers.
> 
> As for who, I'll not put names here to protect the guilty.  Also,
> these positions are often held by multiple people, so picking out
> one would not be fair.
> 
> - anton
> 
Thank you for the above and your initial comment, it's something that 
needed to be said by someone that will not be ignored.

I believe that the Forth for embedded CPUs and desktop although related 
should be different beast. For embedded system lean an mean and close to 
the metal is the order of the day. For Desktop the same plus a 
collection libraries to get things done quickly.

And its also very important the language should be source compatible 
across multiple Forth systems. Right now many push the idea of 
programmer compatible, but not source compatible that ends killing the 
use of the language. Now when I'm going to write a program I have to 
consider which Forth system to use as its way too easy to write a 
program in one Forth and not run in another Forth. And I'm not talking 
about fancy extra features but Forth as defined by the ANS Standard will 
not run from one ANS Forth versus another ANS Forth that kind of 
nonsense will not fly if you want to make Forth popular again.

-- 
Cecil - k5nwa

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

#60271

Cecil Bayona <cbayona@cbayona.com> wrote:

> I believe that the Forth for embedded CPUs and desktop although
> related should be different beast. For embedded system lean an mean
> and close to the metal is the order of the day. For Desktop the same
> plus a collection libraries to get things done quickly.

C seems to be able to manage small systems and very large systems with
the same language; I don't see why Forth shouldn't be able to do the
same.

Andrew.

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

#60312

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
> C seems to be able to manage small systems and very large systems with
> the same language; I don't see why Forth shouldn't be able to do the
> same.

There's lots of legacy C code still being used and maintained on big
systems, but I've convinced myself that the main new uses of C, like
those of Forth, are on small systems.  As a large-server programmer I've
worked with lots of productive and successful programmers who arrived on
the scene later than we did.  They typically use languages like Ruby and
Javascript all day long, without ever having seen a line of C in their
life.

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

#60426

Paul Rubin <no.email@nospam.invalid> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>> C seems to be able to manage small systems and very large systems with
>> the same language; I don't see why Forth shouldn't be able to do the
>> same.
> 
> There's lots of legacy C code still being used and maintained on big
> systems, but I've convinced myself that the main new uses of C, like
> those of Forth, are on small systems.

Really?  Of course our mileage varies, but at my end of the large
server market I still see a lot of C being used.  Mind you, I tend to
put C++ in the same bucket as C, which some people don't.

> As a large-server programmer I've worked with lots of productive and
> successful programmers who arrived on the scene later than we did.
> They typically use languages like Ruby and Javascript all day long,
> without ever having seen a line of C in their life.

Well, it depends.  If you are writing pure server apps on top of a
database then yes, but if you're writing that database, not so much.

Andrew.

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

#60439

Andrew Haley wrote:

> Mind you, I tend to put C++ in the same bucket as C, which some people
> don't.

Especially C++ programmers don't. <g>

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

"The act of focusing our mightiest intellectual resources on the
 elusive goal of goto-less programs has helped us get our minds
 off all those really tough and possibly unresolvable problems
 and issues with which today's professional programmer would
 otherwise have to grapple." -- John Brown

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

#60464

"Rudy Velthuis" <newsgroups@rvelthuis.de> writes:
>Andrew Haley wrote:
>
>> Mind you, I tend to put C++ in the same bucket as C, which some people
>> don't.
>
>Especially C++ programmers don't.

My impression is that the C++ programmers who are maintaining gcc see
C in the same bucket as C++, to C's detriment.

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

#60512

Anton Ertl wrote:

> "Rudy Velthuis" <newsgroups@rvelthuis.de> writes:
> > Andrew Haley wrote:
> > 
> >> Mind you, I tend to put C++ in the same bucket as C, which some
> people >> don't.
> > 
> > Especially C++ programmers don't.
> 
> My impression is that the C++ programmers who are maintaining gcc see
> C in the same bucket as C++, to C's detriment.

Dunno. I don't use GCC a lot, so I can't comment on that.

ISTM that C zealots and C++ zealots are different people. They insist
on the differences and have different standards they go by (and many
adhere to them very strictly).

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

"Acceptance without proof is the fundamental characteristic of
 Western religion, rejection without proof is the fundamental
 characteristic of Western science."
 -- Gary Zukav

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

#60546

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
> Really?  Of course our mileage varies, but at my end of the large
> server market I still see a lot of C being used.  Mind you, I tend to
> put C++ in the same bucket as C, which some people don't.

Well I specifically meant regular C, whether or not C++ is in the same
"bucket".  FWIW I find C++ to be a totally different programming
experience from C, but that's possibly subjective.

> Well, it depends.  If you are writing pure server apps on top of a
> database then yes, but if you're writing that database, not so much.

Sure, writing databases is a specialized area.  And while the older ones
like MySQL are written in C, some of the newer ones (e.g. Riak, written
in Erlang) are not.

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

#60549

On 2017-06-10, Paul Rubin <no.email@nospam.invalid> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>> Really?  Of course our mileage varies, but at my end of the large
>> server market I still see a lot of C being used.  Mind you, I tend to
>> put C++ in the same bucket as C, which some people don't.
>
> Well I specifically meant regular C, whether or not C++ is in the same
> "bucket".  FWIW I find C++ to be a totally different programming
> experience from C, but that's possibly subjective.

Agreed, C++, when used like C++, is very different from C.

>
>> Well, it depends.  If you are writing pure server apps on top of a
>> database then yes, but if you're writing that database, not so much.
>
> Sure, writing databases is a specialized area.  And while the older ones
> like MySQL are written in C, some of the newer ones (e.g. Riak, written
> in Erlang) are not.

Interesting choice for language ;) I just tried yaws. It perform rather
bad (12k reqs/sec) in comparison to eg rwasa (written in assembler) that
achieves maximum through output (around 60k reqs/sec) on my machine. I
have nonblocking/event based  io lib written in C++ that I used for
Haskell. It achieves maximum with single thread.  Haskell sockets in
combination with green threads achieve around third of that. But if I
use MVars/Channels to pass around data  (and threads) in Haskell, that
has pretty high overhead alone. Erlang can only be worse ;p

-- 
press any key to continue or any other to quit...

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

#60803

Melzzzzz <Melzzzzz@zzzzz.com> writes:
>>  Riak, written in Erlang)
> Interesting choice for language ;) I just tried yaws. It perform rather
> bad (12k reqs/sec) 

Riak is supposed to be a high availability near-unkillable distributed
db, not a throughput monster.  Network delays alone (because the data
is replicated etc.) prevent that.

> But if I use MVars/Channels to pass around data (and threads) in
> Haskell, that has pretty high overhead alone. Erlang can only be worse

I think GHC and Erlang are roughly comparable for that.  If you don't
have too much actual shared data between threads, you might try STM
in Haksell and see if it helps (it's much worse than mvars when there is
high contention).  With Erlang you can use ETS and there's no actual
interprocess communication most of the time (it's faked by the library).

You also shouldn't compare GHC or Erlang message passing to a single
threaded C++ program.  GHC and Erlang both can use all your cpu's cores.

> That is because when I write C++ program, rarely I need to worry about
> performance. When I write Haskell all the time I have to rewrite
> program several times in order to achieve the same ...

Idiomatic Haskell will usually beat Ruby, Python, etc. but will be
slower than C++ unless you optimize a lot (see Alioth shootout).

How often do you care?  A rather beefy server stack these days costs a
few hundred dollars a month.  Unless you're running a huge service like
Google, it will usually be cheaper to add a few more servers than pay
for the added development/debugging time and bug consequences from using
something like C++.

If you're really trying to compute something fast nowadays, you wouldn't
use C++ any more either, of course.  You'd use CUDA or even Verilog:

  https://www.ovh.ie/dedicated_servers/gpu/
  https://www.runabove.com/FPGAaaS.xml
  https://www.runabove.com/labs/FPGAAccelize/

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

#60805

On 2017-06-16, Paul Rubin <no.email@nospam.invalid> wrote:
> Melzzzzz <Melzzzzz@zzzzz.com> writes:

>> But if I use MVars/Channels to pass around data (and threads) in
>> Haskell, that has pretty high overhead alone. Erlang can only be worse
>
> I think GHC and Erlang are roughly comparable for that.  If you don't
> have too much actual shared data between threads, you might try STM
> in Haksell and see if it helps (it's much worse than mvars when there is
> high contention).  With Erlang you can use ETS and there's no actual
> interprocess communication most of the time (it's faked by the library).

Tried STM and MVars, overhead is same, that is, I have half troughoutput
when handling IO in one thread and processing in worker threads,
rather then separately in each thread.

>
> You also shouldn't compare GHC or Erlang message passing to a single
> threaded C++ program.  GHC and Erlang both can use all your cpu's cores.

I think I will perform message passing in C++. I think that overhead is
mainly because of GC.

>
>> That is because when I write C++ program, rarely I need to worry about
>> performance. When I write Haskell all the time I have to rewrite
>> program several times in order to achieve the same ...
>
> Idiomatic Haskell will usually beat Ruby, Python, etc. but will be
> slower than C++ unless you optimize a lot (see Alioth shootout).

Heh, Ruby and Python are dead slow.
>
> How often do you care?  A rather beefy server stack these days costs a
> few hundred dollars a month.  Unless you're running a huge service like
> Google, it will usually be cheaper to add a few more servers than pay
> for the added development/debugging time and bug consequences from using
> something like C++.

To me it is easy to do C++, but I do Haskell in free time. 
>
> If you're really trying to compute something fast nowadays, you wouldn't
> use C++ any more either, of course.  You'd use CUDA or even Verilog:
>
>   https://www.ovh.ie/dedicated_servers/gpu/
>   https://www.runabove.com/FPGAaaS.xml
>   https://www.runabove.com/labs/FPGAAccelize/

Well, I hadn't these kind of computations in mind.

-- 
press any key to continue or any other to quit...

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

#60600

Paul Rubin <no.email@nospam.invalid> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>> Really?  Of course our mileage varies, but at my end of the large
>> server market I still see a lot of C being used.  Mind you, I tend to
>> put C++ in the same bucket as C, which some people don't.
> 
> Well I specifically meant regular C, whether or not C++ is in the same
> "bucket".  FWIW I find C++ to be a totally different programming
> experience from C, but that's possibly subjective.

OK.  I reckon that C++ is C in drag.  :-)

>> Well, it depends.  If you are writing pure server apps on top of a
>> database then yes, but if you're writing that database, not so much.
> 
> Sure, writing databases is a specialized area.

All areas of programming are specialized.

Andrew.

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

#60772

To some people, C++ is C with better namespace management.

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

#60250

On 6/3/2017 9:48 AM, Anton Ertl wrote:
> NN <november.nihal@gmail.com> writes:
>> Can you elaborate on what you meant when you refer to positions many present as forth philosopy ? What are these positions and who is presenting these ?
> 
> Apparently the positions are not clear enough from the way I
> contrasted them with the reasons for using Python, so I'll make them
> more explicit here:
> 
> 1) C and other languages are evil or at least there is nothing of
>     value there, so we don't need to interface with them (except for
>     dealing with the OS).  We certainly don't need to interface with C
>     or Fortran libraries, see also 3).  (There is even a meme here that
>     rejects a feature with the (usually incorrect) argument that it
>     would make Forth more like C; e.g., some argued against number
>     prefixes such as $10 and #10 with that argument, even though $10
>     and #10 are not part of C).
> 
> 2) We must minimize everything at all costs.  Consuming a KB or an MB
>     for a convenience feature is against the Forth philosophy; whether
>     we have GBs of RAM to spare does not matter.
> 
> 3) Libraries are "full of inefficient code to take care of
>    all possible cases, etc."
> 
> 4) There is no need to standardize a feature if you can already do it
>     on some systems using carnal knowledge.  The value of the standard
>     is in programmer portability.  Loading programs unchanged is not
>     relevant to real programmers, and requiring to change some lines of
>     code in various places is the proper way to deal with moving code
>     between directories or computers.
> 
> As for who, I'll not put names here to protect the guilty.  Also,
> these positions are often held by multiple people, so picking out
> one would not be fair.
> 
> - anton
> 
Thank you for the above and your initial comment, it's something that 
needed to be said by someone that will not be ignored. Hopefully this 
gets through my email program mangled the original post.

I believe that the Forth for embedded CPUs and desktop although related 
should be different beast. For embedded system lean an mean and close to 
the metal is the order of the day. For Desktop the same plus a 
collection libraries to get things done quickly.

And its also very important the language should be source compatible 
across multiple Forth systems. Right now many push the idea of 
programmer compatible, but not source compatible that ends killing the 
use of the language. Now when I'm going to write a program I have to 
consider which Forth system to use as its way too easy to write a 
program in one Forth and not run in another Forth. And I'm not talking 
about fancy extra features but Forth as defined by the ANS Standard will 
not run from one ANS Forth versus another ANS Forth that kind of 
nonsense will not fly if you want to make Forth popular again.

-- 
Cecil - k5nwa

-- 
Cecil - k5nwa

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

#60233

On Saturday, June 3, 2017 at 12:35:30 PM UTC+2, 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
[..] 
> 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.

I am sure it is all about libraries. The present-day
engineering students can't, and won't, program. They
don't even know how to use Matlab. In my experience,
the reason that they gear towards Python is:
  1. It is free (of cost). You would be surprised to know
how important this is in even very big companies, but it
is also important when you want to learn a language to
impress your boss.
  2. Extremely well documented (a Python Primer for Dummies has
800 pages at least, and it answers all werty's questions).
  3. One can learn to *start* doing something extremely impressive
with a minimal investment of time and money.

-marcel

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

#60236

mhx@iae.nl wrote on 6/3/2017 11:04 AM:
> On Saturday, June 3, 2017 at 12:35:30 PM UTC+2, 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
> [..]
>> 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.
>
> I am sure it is all about libraries. The present-day
> engineering students can't, and won't, program. They
> don't even know how to use Matlab. In my experience,
> the reason that they gear towards Python is:
>   1. It is free (of cost). You would be surprised to know
> how important this is in even very big companies, but it
> is also important when you want to learn a language to
> impress your boss.
>   2. Extremely well documented (a Python Primer for Dummies has
> 800 pages at least, and it answers all werty's questions).
>   3. One can learn to *start* doing something extremely impressive
> with a minimal investment of time and money.

I'm not sure if you are denigrating or promoting python?

I can tell you the "free" issue cuts a lot of corners in a company.  If IT 
doesn't have the machines locked down, it is a whole lot easier to run a 
free program than a paid for program simply because you can't run a program 
you can't buy.

I had *exactly* that experience in a company once.  I had $2,000 budgeted in 
the program so I could use MPE Forth to debug my hardware without involving 
the software people.  It was a company with a lot of infighting and the 
HW/SW divide was as wide as it could get.  When it came time to spend the 
money one of the program managers sat down in the road and wouldn't allow 
the purchase.

That was far from the most ineffective thing the company ever did.

-- 

Rick C

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

#60238

On Saturday, June 3, 2017 at 10:04:51 AM UTC-5, m...@iae.nl wrote:
...
> I am sure it is all about libraries. The present-day
> engineering students can't, and won't, program. They
> don't even know how to use Matlab. ...

Next you're going to mention LabView, and I'm going to lose it ...

Krishna

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

#60239

On Saturday, June 3, 2017 at 3:35:30 AM UTC-7, Anton Ertl wrote:
> There is a section in the article titled "Why Python?"  

Why isn't the elephant in the room mentioned? Python has a built-in interpreter. If you want to know something, drill down with the interpreter now instead of wading through reams of documentation (or uncommented source code).

Although PyPy has a JIT compiler, it doesn't have the browser giants (like Google and MS) behind it the way that JavaScript does. It seems to me that JS is the new Forth. You get really good JIT results and an interpreter.

That's not to say that Forth is dead. It's a very productive tool and a great language for building languages. JS will always look like JS. Forth is an artisan language where simplicity of form is the foundation. Minimization of complexity is the game, a game that pays dividends. It just takes time for those dividends to show up. 

The biggest problem Forth faces is that of networking. It doesn't have a standard means of pulling in external libraries. There are all kinds of proprietary means, depending on the OS. One way to solve this is to build a Forth on JS and let the browser be the OS. Can a Forth compile to JS and load that JS? How dangerous does the browser let you be?

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

#60243

Brad Eckert <hwfwguy@gmail.com> writes:
> It seems to me that JS is the new Forth. You get really good JIT
> results and an interpreter. ... That's not to say that Forth is
> dead. It's a very productive tool and a great language for building
> languages. JS will always look like JS. Forth is an artisan language
> where simplicity of form is the foundation.

Nobody remembers Lisp...

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

#60244

Brad Eckert wrote:
> Can a Forth compile to JS and load that JS?

It could.  You can always build a string, and call the JS eval function.
If you use asm.js (or wasm) you can get quite good code generation.

But indirect threading also works fine, and then you don't have to jump
through those hoops.

> How dangerous does the browser let you be?

Not very dangerous at all.

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

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

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

csiph-web