Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #40779 > unrolled thread
| Started by | rickman <gnuarm@gmail.com> |
|---|---|
| First post | 2015-07-24 12:19 -0400 |
| Last post | 2015-11-30 02:55 -0500 |
| Articles | 20 on this page of 178 — 30 participants |
Back to article view | Back to comp.lang.forth
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: Which scripting for embedded automation? rickman <gnuarm@gmail.com> - 2015-07-24 12:19 -0400
Re: Which scripting for embedded automation? Paul Rubin <no.email@nospam.invalid> - 2015-07-24 10:15 -0700
Re: Which scripting for embedded automation? foxaudioresearch@gmail.com - 2015-07-24 10:32 -0700
Re: Which scripting for embedded automation? "WJ" <w_a_x_man@yahoo.com> - 2015-07-24 23:06 +0000
Re: Which scripting for embedded automation? Don Y <this@is.not.me.com> - 2015-07-24 17:00 -0700
Re: Which scripting for embedded automation? rickman <gnuarm@gmail.com> - 2015-07-24 20:52 -0400
Re: Which scripting for embedded automation? Mark Wills <markwills1970@gmail.com> - 2015-07-25 01:28 -0700
Re: Which scripting for embedded automation? josv@planet.nl - 2015-07-25 07:15 -0700
Re: Which scripting for embedded automation? rickman <gnuarm@gmail.com> - 2015-07-25 10:19 -0400
Re: Which scripting for embedded automation? Paul Rubin <no.email@nospam.invalid> - 2015-07-25 10:26 -0700
Re: Which scripting for embedded automation? Mark Wills <markwills1970@gmail.com> - 2015-07-27 00:42 -0700
Re: Which scripting for embedded automation? "Elizabeth D. Rather" <erather@forth.com> - 2015-07-26 22:07 -1000
Re: Which scripting for embedded automation? Mark Wills <markwills1970@gmail.com> - 2015-07-27 01:44 -0700
Re: Which scripting for embedded automation? foxaudioresearch@gmail.com - 2015-07-27 05:57 -0700
Re: Which scripting for embedded automation? "Alex McDonald" <blog@rivadpm.com> - 2015-07-27 14:02 +0100
Re: Which scripting for embedded automation? foxaudioresearch@gmail.com - 2015-07-27 08:41 -0700
Re: Which scripting for embedded automation? Julian Fondren <julian.fondren@gmail.com> - 2015-07-27 08:36 -0700
Re: Which scripting for embedded automation? rickman <gnuarm@gmail.com> - 2015-07-25 10:20 -0400
Re: Which scripting for embedded automation? glidedog@gmail.com - 2015-07-26 04:01 -0700
Re: Which scripting for embedded automation? "Alex McDonald" <blog@rivadpm.com> - 2015-07-26 18:53 +0100
Re: Which scripting for embedded automation? Paul Rubin <no.email@nospam.invalid> - 2015-07-26 11:18 -0700
Re: Which scripting for embedded automation? "Alex McDonald" <blog@rivadpm.com> - 2015-07-26 20:25 +0100
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-27 07:36 +0000
Re: Which scripting for embedded automation? Paul Rubin <no.email@nospam.invalid> - 2015-07-27 01:12 -0700
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-27 10:02 +0000
Re: Which scripting for embedded automation? "Alex McDonald" <blog@rivadpm.com> - 2015-07-27 13:44 +0100
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-27 15:15 +0000
Re: Which scripting for embedded automation? glidedog@gmail.com - 2015-07-27 04:52 -0700
Re: Which scripting for embedded automation? "Alex McDonald" <blog@rivadpm.com> - 2015-07-27 14:01 +0100
Re: Which scripting for embedded automation? glidedog@gmail.com - 2015-07-27 06:16 -0700
Re: Which scripting for embedded automation? "Alex McDonald" <blog@rivadpm.com> - 2015-07-27 14:33 +0100
Re: Which scripting for embedded automation? "Alex McDonald" <blog@rivadpm.com> - 2015-07-27 14:34 +0100
Re: Which scripting for embedded automation? Paul Rubin <no.email@nospam.invalid> - 2015-07-27 10:47 -0700
Re: Which scripting for embedded automation? "Elizabeth D. Rather" <erather@forth.com> - 2015-07-27 08:12 -1000
Re: Which scripting for embedded automation? Paul Rubin <no.email@nospam.invalid> - 2015-07-27 11:24 -0700
Re: Which scripting for embedded automation? "Elizabeth D. Rather" <erather@forth.com> - 2015-07-27 08:41 -1000
Re: Which scripting for embedded automation? Paul Rubin <no.email@nospam.invalid> - 2015-07-27 12:49 -0700
Re: Which scripting for embedded automation? Julian Fondren <julian.fondren@gmail.com> - 2015-07-27 14:38 -0700
Re: Which scripting for embedded automation? "Elizabeth D. Rather" <erather@forth.com> - 2015-07-27 12:02 -1000
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-07-27 11:16 -0700
Re: Which scripting for embedded automation? "Alex McDonald" <blog@rivadpm.com> - 2015-07-27 20:11 +0100
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-27 13:50 +0000
Re: Which scripting for embedded automation? glidedog@gmail.com - 2015-07-27 08:56 -0700
Re: Which scripting for embedded automation? Doug Hoffman <glidedog@gmail.com> - 2015-08-09 09:32 -0400
Re: Which scripting for embedded automation? "Elizabeth D. Rather" <erather@forth.com> - 2015-08-09 16:30 -1000
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-08-09 22:56 -0700
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-10 08:53 +0000
Re: Which scripting for embedded automation? "Elizabeth D. Rather" <erather@forth.com> - 2015-08-10 08:28 -1000
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-11 15:17 +0000
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-08-10 14:14 -0700
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-08-10 16:29 -0700
Re: Which scripting for embedded automation? Mark Wills <markwills1970@gmail.com> - 2015-08-11 01:44 -0700
Re: Which scripting for embedded automation? "Alex McDonald" <blog@rivadpm.com> - 2015-08-11 11:09 +0100
Re: Which scripting for embedded automation? rickman <gnuarm@gmail.com> - 2015-08-11 11:03 -0400
Re: Which scripting for embedded automation? Mark Wills <markwills1970@gmail.com> - 2015-08-11 08:08 -0700
Re: Which scripting for embedded automation? "Alex McDonald" <blog@rivadpm.com> - 2015-08-11 17:21 +0100
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-08-11 22:05 -0700
Re: Which scripting for embedded automation? Mark Wills <markwills1970@gmail.com> - 2015-08-12 05:50 -0700
Re: Which scripting for embedded automation? "Alex McDonald" <blog@rivadpm.com> - 2015-08-12 18:02 +0100
Re: Which scripting for embedded automation? Mark Wills <markwills1970@gmail.com> - 2015-08-12 05:51 -0700
Re: Which scripting for embedded automation? mhx@iae.nl - 2015-08-12 10:18 -0700
Re: Which scripting for embedded automation? mhx@iae.nl - 2015-08-13 10:37 -0700
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-14 12:13 +0000
Re: Which scripting for embedded automation? Bernd Paysan <bernd.paysan@gmx.de> - 2015-08-14 21:30 +0200
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-08-14 13:05 -0700
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-15 16:57 +0000
Re: Which scripting for embedded automation? Bernd Paysan <bernd.paysan@gmx.de> - 2015-08-16 00:12 +0200
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-16 09:44 +0000
Re: Which scripting for embedded automation? Bernd Paysan <bernd.paysan@gmx.de> - 2015-08-17 00:06 +0200
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-18 09:13 +0000
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-08-18 09:02 -0700
Re: Which scripting for embedded automation? "Alex McDonald" <blog@rivadpm.com> - 2015-08-19 00:02 +0100
Re: Which scripting for embedded automation? "Elizabeth D. Rather" <erather@forth.com> - 2015-08-18 14:20 -1000
Re: Which scripting for embedded automation? Bernd Paysan <bernd.paysan@gmx.de> - 2015-08-19 03:12 +0200
Re: Which scripting for embedded automation? mhx@iae.nl - 2015-08-14 13:09 -0700
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-08-14 13:43 -0700
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-15 17:10 +0000
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-08-12 21:16 -0700
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-08-12 21:31 -0700
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-08-12 21:39 -0700
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-08-13 13:43 -0700
Re: Which scripting for embedded automation? "Alex McDonald" <blog@rivadpm.com> - 2015-08-13 10:55 +0100
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-08-14 12:06 -0700
Re: Which scripting for embedded automation? Alex McDonald <blog@rivadpm.com> - 2015-08-14 18:33 -0700
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-08-15 19:33 -0700
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-08-23 16:59 -0700
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-08-13 15:52 -0700
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-10 08:43 +0000
Re: Which scripting for embedded automation? glidedog@gmail.com - 2015-07-27 06:04 -0700
Re: Which scripting for embedded automation? Julian Fondren <ayrnieu@gmail.com> - 2015-07-26 13:49 -0700
Re: Which scripting for embedded automation? "Elizabeth D. Rather" <erather@forth.com> - 2015-07-26 14:56 -1000
Re: Which scripting for embedded automation? rickman <gnuarm@gmail.com> - 2015-07-26 14:20 -0400
Re: Which scripting for embedded automation? Paul Rubin <no.email@nospam.invalid> - 2015-07-26 17:29 -0700
Re: Which scripting for embedded automation? "WJ" <w_a_x_man@yahoo.com> - 2015-08-10 22:52 +0000
Re: Which scripting for embedded automation? "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-26 17:11 -0400
Re: Which scripting for embedded automation? "Alex McDonald" <blog@rivadpm.com> - 2015-07-26 22:38 +0100
Re: Which scripting for embedded automation? "Elizabeth D. Rather" <erather@forth.com> - 2015-07-26 15:07 -1000
Re: Which scripting for embedded automation? "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-26 21:26 -0400
Re: Which scripting for embedded automation? "Elizabeth D. Rather" <erather@forth.com> - 2015-07-26 16:49 -1000
Re: Which scripting for embedded automation? "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-27 01:30 -0400
Re: Which scripting for embedded automation? "Elizabeth D. Rather" <erather@forth.com> - 2015-07-26 22:19 -1000
Re: Which scripting for embedded automation? "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-27 19:31 -0400
Re: Which scripting for embedded automation? Julian Fondren <julian.fondren@gmail.com> - 2015-07-27 16:44 -0700
Re: Which scripting for embedded automation? "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-27 20:32 -0400
Re: Which scripting for embedded automation? Bernd Linsel <bl1@gmx.com> - 2015-07-28 18:57 +0200
Re: Which scripting for embedded automation? "Elizabeth D. Rather" <erather@forth.com> - 2015-07-27 22:03 -1000
Re: Which scripting for embedded automation? stephen@mpeforth.com (Stephen Pelc) - 2015-07-27 09:12 +0000
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-07-27 11:02 -0700
Re: Which scripting for embedded automation? rickman <gnuarm@gmail.com> - 2015-07-27 14:14 -0400
Re: Which scripting for embedded automation? "Alex McDonald" <blog@rivadpm.com> - 2015-07-27 20:17 +0100
Re: Which scripting for embedded automation? "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-27 19:33 -0400
Re: Which scripting for embedded automation? "Elizabeth D. Rather" <erather@forth.com> - 2015-07-27 22:05 -1000
Re: Which scripting for embedded automation? "Alex McDonald" <blog@rivadpm.com> - 2015-07-28 12:47 +0100
Re: Which scripting for embedded automation? "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-28 23:52 -0400
Re: Which scripting for embedded automation? awegel@arcor.de (Alexander Wegel) - 2015-07-29 12:24 +0200
Re: Which scripting for embedded automation? "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-27 19:32 -0400
Re: Which scripting for embedded automation? Bernd Linsel <bl1@gmx.com> - 2015-07-28 19:22 +0200
Re: Which scripting for embedded automation? Walter Banks <walter@bytecraft.com> - 2015-07-28 15:46 -0400
Re: Which scripting for embedded automation? "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-28 23:47 -0400
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-29 07:22 +0000
Re: Which scripting for embedded automation? Paul Rubin <no.email@nospam.invalid> - 2015-07-29 00:48 -0700
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-29 10:15 +0000
Re: Which scripting for embedded automation? Paul Rubin <no.email@nospam.invalid> - 2015-07-31 11:34 -0700
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-04 09:21 +0000
Re: Which scripting for embedded automation? Walter Banks <walter@bytecraft.com> - 2015-07-29 13:27 -0400
Re: Which scripting for embedded automation? "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-29 18:53 -0400
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-30 12:40 +0000
Re: Which scripting for embedded automation? "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-30 22:15 -0400
Re: Which scripting for embedded automation? Paul Rubin <no.email@nospam.invalid> - 2015-07-30 21:51 -0700
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-31 10:32 +0000
Re: Which scripting for embedded automation? David Thompson <dave.thompson2@verizon.net> - 2015-08-16 02:31 -0400
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-16 09:53 +0000
Re: Which scripting for embedded automation? Bernd Linsel <bl1@gmx.com> - 2015-07-29 17:50 +0200
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-30 13:14 +0000
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-29 10:28 +0000
Re: Which scripting for embedded automation? Bernd Linsel <bl1@gmx.com> - 2015-07-29 18:24 +0200
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-29 17:09 +0000
Re: Which scripting for embedded automation? Bernd Linsel <bl1@gmx.com> - 2015-07-30 02:01 +0200
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-07-29 17:58 -0700
Re: Which scripting for embedded automation? "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-30 21:26 -0400
Re: Which scripting for embedded automation? Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-07-31 00:06 -0700
Re: Which scripting for embedded automation? Hannu Vuolasaho <vuokkosetae@gmail.com> - 2015-07-31 13:35 +0300
Re: Which scripting for embedded automation? Mikael Nordman <oh2aun@gmail.com> - 2015-08-01 01:12 -0700
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-07-31 15:05 -0700
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-30 12:03 +0000
Re: Which scripting for embedded automation? Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2015-11-02 16:29 +0100
Re: Which scripting for embedded automation? Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2015-11-02 16:58 +0100
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-02 15:43 +0000
Re: Which scripting for embedded automation? Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2015-11-02 18:24 +0100
Re: Which scripting for embedded automation? Bernd Paysan <bernd.paysan@gmx.de> - 2015-11-02 20:09 +0100
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-03 12:07 +0000
Re: Which scripting for embedded automation? Bernd Paysan <bernd.paysan@gmx.de> - 2015-11-03 22:22 +0100
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-04 09:47 +0000
Re: Which scripting for embedded automation? Bernd Paysan <bernd.paysan@gmx.de> - 2015-11-04 14:59 +0100
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-04 14:13 +0000
Re: Which scripting for embedded automation? Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-11-02 20:29 +0000
Re: Which scripting for embedded automation? Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2015-11-05 12:02 +0100
Re: Which scripting for embedded automation? Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2015-11-05 15:57 +0100
Re: Which scripting for embedded automation? Walter Banks <walter@bytecraft.com> - 2015-07-28 15:32 -0400
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-07-29 16:35 -0700
Re: Which scripting for embedded automation? Walter Banks <walter@bytecraft.com> - 2015-08-01 22:50 -0400
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-08-01 20:06 -0700
Re: Which scripting for embedded automation? humptydumpty <ouatubi@gmail.com> - 2015-07-26 22:56 -0700
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-27 07:32 +0000
Re: Which scripting for embedded automation? humptydumpty <ouatubi@gmail.com> - 2015-07-27 01:46 -0700
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-27 07:54 +0000
Re: Which scripting for embedded automation? humptydumpty <ouatubi@gmail.com> - 2015-07-27 22:42 -0700
Re: Which scripting for embedded automation? glidedog@gmail.com - 2015-07-28 02:38 -0700
Re: Which scripting for embedded automation? humptydumpty <ouatubi@gmail.com> - 2015-07-28 05:28 -0700
Re: Which scripting for embedded automation? glidedog@gmail.com - 2015-07-28 05:41 -0700
Re: Which scripting for embedded automation? humptydumpty <ouatubi@gmail.com> - 2015-07-28 05:49 -0700
Re: Which scripting for embedded automation? rickman <gnuarm@gmail.com> - 2015-07-28 14:14 -0400
Re: Which scripting for embedded automation? "Elizabeth D. Rather" <erather@forth.com> - 2015-07-28 07:38 -1000
Re: Which scripting for embedded automation? glidedog@gmail.com - 2015-07-28 13:37 -0700
Re: Which scripting for embedded automation? "WJ" <w_a_x_man@yahoo.com> - 2015-11-28 18:06 +0000
Re: Which scripting for embedded automation? rickman <gnuarm@gmail.com> - 2015-11-29 02:45 -0500
Re: Which scripting for embedded automation? Paul Rubin <no.email@nospam.invalid> - 2015-11-29 23:02 -0800
Re: Which scripting for embedded automation? rickman <gnuarm@gmail.com> - 2015-11-30 02:55 -0500
Page 1 of 9 [1] 2 3 4 5 6 7 8 9 Next page →
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-07-24 12:19 -0400 |
| Subject | Re: Which scripting for embedded automation? |
| Message-ID | <motoev$eeu$1@dont-email.me> |
On 7/24/2015 1:00 AM, Paul Rubin wrote: > abhishekkumardwivedi@gmail.com writes: >> like data transfer,etc. And there is need of some logic to parse >> received content. Perl, python, lua or simple shell scripting .. which >> one? There will be branch and loop operations, better to have more >> ready tools for network operations... Parser and LAN are the key here. > > I'd suggest Python of the ones you mention, assuming you have enough ram > (a Raspberry pi would be more than plenty). I use it all the time > myself. Or if you want something really different and interesting, look > at Erlang. > > Perl is old-school by now, and shell scripts too inflexible. Lua is > very elegantly implemented and compact but it lacks Python's creature > comforts. Forth is likely to be too low level for this sort of > programming. It's virtue is being able to run in very small memory > space, like under 10K of code space and a few hundred ram bytes in an > MCU. But it makes programming very low level and painstaking, almost > like assembler. I find your analysis of Forth to be very naive. Much the same as other languages like C, Forth provides a basic capability with more advanced capabilities provided through libraries. Suggesting that Forth is only useful where the entire development system needs to reside in 10 KB of code is a red herring. This capability comes with limitations and so is only used where it is a significant advantage. Otherwise Forth can be used to advantage in the same environments where you would use C, Python or any others. It typically comes with exactly the sort of capabilities needed for this project. A parser is built in with full capability of being used in the application and most Forths running under an OS support networking. Referring to Forth as being "like assembler" just shows how little you understand the language and appreciate its features. -- Rick
[toc] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-07-24 10:15 -0700 |
| Message-ID | <87lhe5sciz.fsf@jester.gateway.sonic.net> |
| In reply to | #40779 |
rickman <gnuarm@gmail.com> writes: [Ok, replying to your crosspost even though my own earlier post was only on comp.arch.embedded where the original question was. The question regards scripting home automation stuff on an embedded Linux system]. >> Forth is likely to be too low level for this sort of programming. >> It's virtue is being able to run in very small memory space, like >> under 10K of code space and a few hundred ram bytes in an MCU. > I find your analysis of Forth to be very naive. Much the same as > other languages like C, Forth provides a basic capability with more > advanced capabilities provided through libraries. Sure, I'd consider C to also be low level though. I'd have to add that Forth doesn't have nearly as many available libraries, because of the smaller userbase, but I think partly from a minimalist "do everything yourself" spirit in Forth culture. > Suggesting that Forth is only useful where the entire development > system needs to reside in 10 KB of code is a red herring. I didn't mean to suggest a 10K maximum. I meant Forth had the capability of running in such small space and that this is IMHO a big achievement and advantage that it has, but it dictated a lot of Forth's design decisions. Historically Forth was most successful in the era of 16-bit systems with up to 64k ram, or maybe on MSDOS PC's with up to 640k. Once you have tens of MB available the tradeoffs in scripting become a lot different. Other Forth advantages include pauseless operation (necessary for real-time programs), higher cpu efficiency than Python even in simple interpreters, and very high efficiency (comparable to C) if you use an optimizing compiler. But, in the context of scripting, these are usually not important. Python burns more machine resources, but in return it takes care of a lot of issues for you that you'd have to spend your own time looking after in Forth or C. > Otherwise Forth can be used to advantage in the same environments > where you would use C, Python or any others. I didn't say anything about C and I'd consider it comparable to Forth in most regards. C would IMHO be a poor choice of scripting language in this situation too. Have you actually used Python? It's not anything like C or Forth. Lumping Python with C seems to miss the distinction. If you haven't actually used both, then making comparisons between them isn't convincing. > It typically comes with exactly the sort of capabilities needed for > this project. A parser is built in with full capability of being used > in the application and most Forths running under an OS support > networking. If the OP has control over the network protocol then using the Forth parser can be a simple and efficient solution, especially if the network devices are all trusted. If there are devices speaking protocols like XML (some home automation stuff is like that) then Forth starts to be painful. I don't know if a Forth TLS stack even exists. > Referring to Forth as being "like assembler" just shows how little you > understand the language and appreciate its features. I understand Forth pretty well at a technical level, though I'm not a very fluent user in terms of being used to the idioms it takes to use it productively.
[toc] | [prev] | [next] | [standalone]
| From | foxaudioresearch@gmail.com |
|---|---|
| Date | 2015-07-24 10:32 -0700 |
| Message-ID | <49250263-911c-4ccb-8856-d0a6afc5e441@googlegroups.com> |
| In reply to | #40782 |
I believe the Forth solution would be a new DSL for the problem (s) at hand. So it's hard to evaluate it since it does not exist yet. This is always a strange discussion for Forth since it can create a new language and in fact out the box is not very useful until properly extended. Will it include re-entrant string functions and regex ? It could. But who knows until it's coded. My 2 cents BF
[toc] | [prev] | [next] | [standalone]
| From | "WJ" <w_a_x_man@yahoo.com> |
|---|---|
| Date | 2015-07-24 23:06 +0000 |
| Message-ID | <mougdl$b1d$1@dont-email.me> |
| In reply to | #40782 |
Paul Rubin wrote:
> > Otherwise Forth can be used to advantage in the same environments
> > where you would use C, Python or any others.
>
> I didn't say anything about C and I'd consider it comparable to Forth in
> most regards. C would IMHO be a poor choice of scripting language in
> this situation too.
>
> Have you actually used Python? It's not anything like C or Forth.
> Lumping Python with C seems to miss the distinction. If you haven't
> actually used both, then making comparisons between them isn't
> convincing.
It's obvious that the reason that he is recommending Forth
over all other languages is that he knows no language that
is higher-level than Forth. And he finds it too difficult
to learn another language.
If a hammer is the only tool that you have, then you use
a hammer for everything.
How would these tasks be done with a hammer?
Using Gauche Scheme:
Write a function that accepts a vector (1-dimensional array) of
16-bit numbers and replaces each number with its difference
from the average.
(use gauche.uvector)
(use gauche.collection)
(define (relativize vec)
(let ((avg (round->exact (/ (fold + 0 vec) (s16vector-length vec)))))
(s16vector-sub! vec avg)))
(define my-vec (s16vector 0 1 2 3 4 5 6 7 8 9))
(relativize my-vec)
my-vec
===>
#s16(-4 -3 -2 -1 0 1 2 3 4 5)
Take a string that contains numbers separated by semicolons or
commas and convert it to a list of numbers.
(map string->number (string-split "2,3.14;5.8,9" #/[,;]/))
===>
(2 3.14 5.8 9)
--
The report card by the American Society of Civil Engineers showed the national
infrastructure a single grade above failure, a step from declining to the point
where everyday things simply stop working the way people expect them to. ---
washingtonpost.com/local/trafficandcommuting/us-infrastructure-gets-d-in-annual-report/2013/03/19/c48cb010-900b-11e2-9cfd-36d6c9b5d7ad_story.html
[toc] | [prev] | [next] | [standalone]
| From | Don Y <this@is.not.me.com> |
|---|---|
| Date | 2015-07-24 17:00 -0700 |
| Message-ID | <moujig$4kn$1@speranza.aioe.org> |
| In reply to | #40789 |
On 7/24/2015 4:06 PM, WJ wrote: > It's obvious that the reason that he is recommending Forth > over all other languages is that he knows no language that > is higher-level than Forth. And he finds it too difficult > to learn another language. > > If a hammer is the only tool that you have, then you use > a hammer for everything. > > How would these tasks be done with a hammer? > > Using Gauche Scheme: > > Write a function that accepts a vector (1-dimensional array) of > 16-bit numbers and replaces each number with its difference > from the average. > > (use gauche.uvector) > (use gauche.collection) > > (define (relativize vec) > (let ((avg (round->exact (/ (fold + 0 vec) (s16vector-length vec))))) > (s16vector-sub! vec avg))) > > (define my-vec (s16vector 0 1 2 3 4 5 6 7 8 9)) > (relativize my-vec) > my-vec > ===> > #s16(-4 -3 -2 -1 0 1 2 3 4 5) > > > Take a string that contains numbers separated by semicolons or > commas and convert it to a list of numbers. > > (map string->number (string-split "2,3.14;5.8,9" #/[,;]/)) > ===> > (2 3.14 5.8 9) What role would these have in the scripting of an automation system? IME, tasks in that domain tend to be more procedural oriented.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-07-24 20:52 -0400 |
| Message-ID | <moumgt$rhv$1@dont-email.me> |
| In reply to | #40791 |
On 7/24/2015 8:00 PM, Don Y wrote: > On 7/24/2015 4:06 PM, WJ wrote: > >> It's obvious that the reason that he is recommending Forth >> over all other languages is that he knows no language that >> is higher-level than Forth. And he finds it too difficult >> to learn another language. >> >> If a hammer is the only tool that you have, then you use >> a hammer for everything. >> >> How would these tasks be done with a hammer? >> >> Using Gauche Scheme: >> >> Write a function that accepts a vector (1-dimensional array) of >> 16-bit numbers and replaces each number with its difference >> from the average. >> >> (use gauche.uvector) >> (use gauche.collection) >> >> (define (relativize vec) >> (let ((avg (round->exact (/ (fold + 0 vec) (s16vector-length vec))))) >> (s16vector-sub! vec avg))) >> >> (define my-vec (s16vector 0 1 2 3 4 5 6 7 8 9)) >> (relativize my-vec) >> my-vec >> ===> >> #s16(-4 -3 -2 -1 0 1 2 3 4 5) >> >> >> Take a string that contains numbers separated by semicolons or >> commas and convert it to a list of numbers. >> >> (map string->number (string-split "2,3.14;5.8,9" #/[,;]/)) >> ===> >> (2 3.14 5.8 9) > > What role would these have in the scripting of an automation system? > IME, tasks in that domain tend to be more procedural oriented. WJ is an odd sort. You won't find that he is much of a conversationalist. Rather he communicates in terms of code for any manner of interesting, even if irrelevant, examples. Just one of the many odd birds flitting about in the Forth newsgroup. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2015-07-25 01:28 -0700 |
| Message-ID | <8f8f8dd6-efca-4f3e-ac18-ed28bce7524c@googlegroups.com> |
| In reply to | #40792 |
On Saturday, 25 July 2015 01:52:11 UTC+1, rickman wrote: > On 7/24/2015 8:00 PM, Don Y wrote: > > On 7/24/2015 4:06 PM, WJ wrote: > > > >> It's obvious that the reason that he is recommending Forth > >> over all other languages is that he knows no language that > >> is higher-level than Forth. And he finds it too difficult > >> to learn another language. > >> > >> If a hammer is the only tool that you have, then you use > >> a hammer for everything. > >> > >> How would these tasks be done with a hammer? > >> > >> Using Gauche Scheme: > >> > >> Write a function that accepts a vector (1-dimensional array) of > >> 16-bit numbers and replaces each number with its difference > >> from the average. > >> > >> (use gauche.uvector) > >> (use gauche.collection) > >> > >> (define (relativize vec) > >> (let ((avg (round->exact (/ (fold + 0 vec) (s16vector-length vec))))) > >> (s16vector-sub! vec avg))) > >> > >> (define my-vec (s16vector 0 1 2 3 4 5 6 7 8 9)) > >> (relativize my-vec) > >> my-vec > >> ===> > >> #s16(-4 -3 -2 -1 0 1 2 3 4 5) > >> > >> > >> Take a string that contains numbers separated by semicolons or > >> commas and convert it to a list of numbers. > >> > >> (map string->number (string-split "2,3.14;5.8,9" #/[,;]/)) > >> ===> > >> (2 3.14 5.8 9) > > > > What role would these have in the scripting of an automation system? > > IME, tasks in that domain tend to be more procedural oriented. > > WJ is an odd sort. You won't find that he is much of a > conversationalist. Rather he communicates in terms of code for any > manner of interesting, even if irrelevant, examples. > > Just one of the many odd birds flitting about in the Forth newsgroup. > > -- > > Rick He may be an odd sort, but his point is spot on. For *embedded scripting* I wouldn't go near Forth in a bazillion years. Okay, if the *embedded* machine I was using had like, 1K of RAM, then yes, Forth. Otherwise, no way. Look, if you are doing scripting, then you are doing things like: * Pinging IP addresses (e.g. a gateway) and changing routing tables on the fly depending on whether a particular interface is up or not. * Reading through log files, looking for the certain occurrence of strings (error codes/strings, other filenames etc.) * Deleting log or error files * Moving log or error files * Rotating log or error files depending on their age * Searching for files of a given type, or date range, and moving them, or zipping them, or deleting them. Forth has *no* standard way to do any of these things. You'd even have to write your own string array handler FFS. Forget enumerating a disk directory, getting a list of all the files in a structure, with their creation dates, modification dates, filtering by type, sorting by date, looking for duplicate file names (so that you can delete the older versions) etc. Are you kidding me? You want Perl, PHP, and Python. Any of those will take you everywhere you want to go. Forth is next to useless for this sort of thing, unless you have a rack of libraries that you have personally built up over the years. Because, you know, this is Forth, right, and we don't use each other's libraries in the Forth world, because everyone else's code sucks, right? We can *all* do *much* better jobs by ourselves, re-inventing the wheel over and over and over again. Using Forth for this kind of thing would be like setting out to build a house with a hammer and a screwdriver. Someone says "hey, where's the cement mixer?" and you hold up the hammer and the screwdriver and say "we're gonna build our own! It's gonna be the best cement mixer EVER!" Don't get me started! I don't even have a cat that I can kick ;-) Next-door neighbour... he has a cat...
[toc] | [prev] | [next] | [standalone]
| From | josv@planet.nl |
|---|---|
| Date | 2015-07-25 07:15 -0700 |
| Message-ID | <3677f1ee-b1d8-4c92-82a8-de3d9d0bec48@googlegroups.com> |
| In reply to | #40796 |
Hi Mark, Forth took me everywhere where I wanted to go when I wrote my server controller. Especially itools.frt which I did not write myself, but found thanks to: https://groups.google.com/forum/?fromgroups#!forum/comp.lang.forth was very useful. Jos On Saturday, 25 July 2015 10:28:02 UTC+2 Mark Wills wrote: > On Saturday, 25 July 2015 01:52:11 UTC+1, rickman wrote: > > On 7/24/2015 8:00 PM, Don Y wrote: > > > On 7/24/2015 4:06 PM, WJ wrote: > > > > > >> It's obvious that the reason that he is recommending Forth > > >> over all other languages is that he knows no language that > > >> is higher-level than Forth. And he finds it too difficult > > >> to learn another language. > > >> > > >> If a hammer is the only tool that you have, then you use > > >> a hammer for everything. > > >> > > >> How would these tasks be done with a hammer? > > >> > > >> Using Gauche Scheme: > > >> > > >> Write a function that accepts a vector (1-dimensional array) of > > >> 16-bit numbers and replaces each number with its difference > > >> from the average. > > >> > > >> (use gauche.uvector) > > >> (use gauche.collection) > > >> > > >> (define (relativize vec) > > >> (let ((avg (round->exact (/ (fold + 0 vec) (s16vector-length vec))))) > > >> (s16vector-sub! vec avg))) > > >> > > >> (define my-vec (s16vector 0 1 2 3 4 5 6 7 8 9)) > > >> (relativize my-vec) > > >> my-vec > > >> ===> > > >> #s16(-4 -3 -2 -1 0 1 2 3 4 5) > > >> > > >> > > >> Take a string that contains numbers separated by semicolons or > > >> commas and convert it to a list of numbers. > > >> > > >> (map string->number (string-split "2,3.14;5.8,9" #/[,;]/)) > > >> ===> > > >> (2 3.14 5.8 9) > > > > > > What role would these have in the scripting of an automation system? > > > IME, tasks in that domain tend to be more procedural oriented. > > > > WJ is an odd sort. You won't find that he is much of a > > conversationalist. Rather he communicates in terms of code for any > > manner of interesting, even if irrelevant, examples. > > > > Just one of the many odd birds flitting about in the Forth newsgroup. > > > > -- > > > > Rick > > He may be an odd sort, but his point is spot on. For *embedded scripting* > I wouldn't go near Forth in a bazillion years. Okay, if the *embedded* > machine I was using had like, 1K of RAM, then yes, Forth. Otherwise, no > way. > > Look, if you are doing scripting, then you are doing things like: > > * Pinging IP addresses (e.g. a gateway) and changing routing tables on > the fly depending on whether a particular interface is up or not. > * Reading through log files, looking for the certain occurrence of strings > (error codes/strings, other filenames etc.) > * Deleting log or error files > * Moving log or error files > * Rotating log or error files depending on their age > * Searching for files of a given type, or date range, and moving them, > or zipping them, or deleting them. > > Forth has *no* standard way to do any of these things. You'd even have > to write your own string array handler FFS. Forget enumerating a disk > directory, getting a list of all the files in a structure, with their > creation dates, modification dates, filtering by type, sorting by date, > looking for duplicate file names (so that you can delete the older > versions) etc. > > Are you kidding me? > > You want Perl, PHP, and Python. Any of those will take you everywhere > you want to go. > > Forth is next to useless for this sort of thing, unless you have a rack > of libraries that you have personally built up over the years. Because, > you know, this is Forth, right, and we don't use each other's libraries > in the Forth world, because everyone else's code sucks, right? We can > *all* do *much* better jobs by ourselves, re-inventing the wheel over > and over and over again. > > Using Forth for this kind of thing would be like setting out to build a > house with a hammer and a screwdriver. Someone says "hey, where's the > cement mixer?" and you hold up the hammer and the screwdriver and say > "we're gonna build our own! It's gonna be the best cement mixer EVER!" > > Don't get me started! I don't even have a cat that I can kick ;-) > > Next-door neighbour... he has a cat...
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-07-25 10:19 -0400 |
| Message-ID | <mp05qi$t9i$1@dont-email.me> |
| In reply to | #40796 |
On 7/25/2015 4:28 AM, Mark Wills wrote: > On Saturday, 25 July 2015 01:52:11 UTC+1, rickman wrote: >> On 7/24/2015 8:00 PM, Don Y wrote: >>> On 7/24/2015 4:06 PM, WJ wrote: >>> >>>> It's obvious that the reason that he is recommending Forth >>>> over all other languages is that he knows no language that >>>> is higher-level than Forth. And he finds it too difficult >>>> to learn another language. >>>> >>>> If a hammer is the only tool that you have, then you use >>>> a hammer for everything. >>>> >>>> How would these tasks be done with a hammer? >>>> >>>> Using Gauche Scheme: >>>> >>>> Write a function that accepts a vector (1-dimensional array) of >>>> 16-bit numbers and replaces each number with its difference >>>> from the average. >>>> >>>> (use gauche.uvector) >>>> (use gauche.collection) >>>> >>>> (define (relativize vec) >>>> (let ((avg (round->exact (/ (fold + 0 vec) (s16vector-length vec))))) >>>> (s16vector-sub! vec avg))) >>>> >>>> (define my-vec (s16vector 0 1 2 3 4 5 6 7 8 9)) >>>> (relativize my-vec) >>>> my-vec >>>> ===> >>>> #s16(-4 -3 -2 -1 0 1 2 3 4 5) >>>> >>>> >>>> Take a string that contains numbers separated by semicolons or >>>> commas and convert it to a list of numbers. >>>> >>>> (map string->number (string-split "2,3.14;5.8,9" #/[,;]/)) >>>> ===> >>>> (2 3.14 5.8 9) >>> >>> What role would these have in the scripting of an automation system? >>> IME, tasks in that domain tend to be more procedural oriented. >> >> WJ is an odd sort. You won't find that he is much of a >> conversationalist. Rather he communicates in terms of code for any >> manner of interesting, even if irrelevant, examples. >> >> Just one of the many odd birds flitting about in the Forth newsgroup. >> >> -- >> >> Rick > > He may be an odd sort, but his point is spot on. For *embedded scripting* > I wouldn't go near Forth in a bazillion years. Okay, if the *embedded* > machine I was using had like, 1K of RAM, then yes, Forth. Otherwise, no > way. > > Look, if you are doing scripting, then you are doing things like: > > * Pinging IP addresses (e.g. a gateway) and changing routing tables on > the fly depending on whether a particular interface is up or not. > * Reading through log files, looking for the certain occurrence of strings > (error codes/strings, other filenames etc.) > * Deleting log or error files > * Moving log or error files > * Rotating log or error files depending on their age > * Searching for files of a given type, or date range, and moving them, > or zipping them, or deleting them. > > Forth has *no* standard way to do any of these things. You'd even have > to write your own string array handler FFS. Forget enumerating a disk > directory, getting a list of all the files in a structure, with their > creation dates, modification dates, filtering by type, sorting by date, > looking for duplicate file names (so that you can delete the older > versions) etc. > > Are you kidding me? No, but you are kidding me. It is clear that you have virtually no experience with Forth. Does a language need a "standard" way to do everything you want to do? No, none of the things you mention are in the Forth "standard" and yet, many apps have been written that do exactly these things. In fact, most are a part of the Forth systems that you would use. But if you check the OP's requirements, he didn't mention any of these. "such as scan and ping other devices, string like data transfer,etc. And there is need of some logic to parse received content." > You want Perl, PHP, and Python. Any of those will take you everywhere > you want to go. > > Forth is next to useless for this sort of thing, unless you have a rack > of libraries that you have personally built up over the years. Because, > you know, this is Forth, right, and we don't use each other's libraries > in the Forth world, because everyone else's code sucks, right? We can > *all* do *much* better jobs by ourselves, re-inventing the wheel over > and over and over again. > > Using Forth for this kind of thing would be like setting out to build a > house with a hammer and a screwdriver. Someone says "hey, where's the > cement mixer?" and you hold up the hammer and the screwdriver and say > "we're gonna build our own! It's gonna be the best cement mixer EVER!" > > Don't get me started! I don't even have a cat that I can kick ;-) > > Next-door neighbour... he has a cat... Wow! You clearly have some issues with programming languages. Perhaps you should put down the keyboard and walk away? -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-07-25 10:26 -0700 |
| Message-ID | <87mvykqhcf.fsf@jester.gateway.sonic.net> |
| In reply to | #40798 |
rickman <gnuarm@gmail.com> writes: >> Look, if you are doing scripting, then you are doing things like: >> * Pinging IP addresses (e.g. a gateway) and changing routing tables.. >> * Rotating log or error files depending on their age... >> * Searching for files of a given type, or date range, and moving them, >> or zipping them, or deleting them. >> Forth has *no* standard way to do any of these things. > No, but you are kidding me. It is clear that you have virtually no > experience with Forth. Based on Mark's earlier posts going back for years, he is an accomplished Forth user and implementer. > Does a language need a "standard" way to do everything you want to do? It helps if there's at least a documented way in a given implementation. > No, none of the things you mention are in the Forth "standard" and > yet, many apps have been written that do exactly these things. In > fact, most are a part of the Forth systems that you would use. There's probably some way in gforth to do those things, but looking at http://www.complang.tuwien.ac.at/forth/gforth/Docs-html/ for example, I don't how to get the timestamp (last modification time) of a file. There might be some library in the distro somewhere for it, but otherwise it means using the C interface. > But if you check the OP's requirements, he didn't mention any of > these. It's a reasonable basic premise that a networked automation controller should write logs of what it's been doing. I haven't heard of any reasonable logging system in Forth. Logging is a surprisingly complicated problem and there are lots of competing solutions in other languages, that all have their good points and drawbacks. But the basic requirements are: - multiple concurrent tasks in the application have to be able to emit log messages simultaneously, and these messages get written to the same log without getting garbled - logging should be asynchronous from the application, so if your task logs a message it shouldn't have to wait for the log i/o before it can keep running - log messages can at times be emitted faster than the log output device can keep up with, so there has to be some buffering - you need strategies for when there is too much stuff to buffer, for when the disk gets full, etc - you want to be able to log to disk files and also over the network, maybe simultaneously - for logging on disk, you want to automatically rotate log files every so often and/or when they reach a specified size - you need precise control of the log format so you can satisfy the formatting requirements of whatever is consuming the logs (that might some analytics tool not written by you, or it might even be another organization) - etc. etc. etc. The docs for the Python standard logging module are here: https://docs.python.org/3/library/logging.html That system is clumsy to use and I'd call it "unpythonic" (not a good example of idiomatic Python) and I suspect it's patterned after a Java package, but it does most or all of the stuff above, and the stuff is not useless bloat. It really does become necessary from time to time, so that module replaced earlier, simpler ones that were missing needed functionality. And no it's not always better to start with something simple and implement what you need as you go along. Your program is may want to use 3rd party modules that themselves have to log stuff, so you want a standardized logging interface that implements everything up front, and whose availability the different module authors can rely on. > "such as scan and ping other devices, string like data > transfer,etc. And there is need of some logic to parse received > content." Yes, that sounds like a big pain in Forth. For example, lots of home devices (think of your DSL router, but these days even things like refrigerators) have built-in web servers that show UI's meant to be used by humans rather than programs. So if you want to automate those devices, your script has to scrape the HTML and interact with it. There's a nice Python library that I use all the time for that: http://www.crummy.com/software/BeautifulSoup/bs4/doc/ I can't even imagine what a hassle it would be to do that in Forth. As an issue not even mentioned, an automation system probably wants to communicate with several targets concurrently, so some kind of multitasking is helpful, or else you need asynchronous i/o facilities and callback pain. I think Gforth now has preemptive multitasking using Posix threads, but it's not currently documented. You might have to deal with the traditional hazards of low level threaded programming. Python has multiple concurrency approaches that provide a reasonable level of safety, and Erlang is even better (independent lighweight processes that communicate by message passing). > Wow! You clearly have some issues with programming languages. > Perhaps you should put down the keyboard and walk away? I'm not trying to insult you since I know you're a strong implementer in some areas, but I suspect you haven't done a lot of internet programming. It's not like MCU programming where you're in control of everything. There's much more interoperating with external services written by other people and whose crufty requirements you have to deal with, more weird formats to parse, concurrency is required rather often, for non-stop systems you need code upgrade and failover mechanisms (Erlang again has the best story for this: you can upgrade your app without interrupting its existing network connections), etc. Forth (and for similar reason C) work nicely when the data fits naturally into cells (machine words). For variable sized data like strings, Forth has some features that can be used with a bit of headache. For more complicated data like HTML documents that are manipulated as tree structure, you're really better off with a garbage collected language. You might give Python a try sometime. There's lots of intro material: https://wiki.python.org/moin/BeginnersGuide/Programmers I got started with the official tutorial, current version here: https://docs.python.org/3/tutorial/index.html You might want to look at section 3 (intro to the language) first. The earlier sections are stuff like invocation instructions. Here is a set of Forth solutions for the first 25 Euler problems: http://www.fourtheye.org/cgi-bin/language.pl?language=forth The same guy also did solutions in various other languages, so you can compare their complexity: http://www.fourtheye.org/projecteulertable.html (his Python solutions are a bit clunky in my opinion, and warning, some of them might only work in Python 2 since in Python 3 they changed some stuff). Here are Haskell solutions: https://wiki.haskell.org/Euler_problems Lots of the time it should be able to write Python code that's fairly similar to the Haskell code.
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2015-07-27 00:42 -0700 |
| Message-ID | <11b0bc66-8c1e-44b8-9399-09cd32714e06@googlegroups.com> |
| In reply to | #40798 |
On Saturday, 25 July 2015 15:19:28 UTC+1, rickman wrote: > On 7/25/2015 4:28 AM, Mark Wills wrote: > > On Saturday, 25 July 2015 01:52:11 UTC+1, rickman wrote: > >> On 7/24/2015 8:00 PM, Don Y wrote: > >>> On 7/24/2015 4:06 PM, WJ wrote: > >>> > >>>> It's obvious that the reason that he is recommending Forth > >>>> over all other languages is that he knows no language that > >>>> is higher-level than Forth. And he finds it too difficult > >>>> to learn another language. > >>>> > >>>> If a hammer is the only tool that you have, then you use > >>>> a hammer for everything. > >>>> > >>>> How would these tasks be done with a hammer? > >>>> > >>>> Using Gauche Scheme: > >>>> > >>>> Write a function that accepts a vector (1-dimensional array) of > >>>> 16-bit numbers and replaces each number with its difference > >>>> from the average. > >>>> > >>>> (use gauche.uvector) > >>>> (use gauche.collection) > >>>> > >>>> (define (relativize vec) > >>>> (let ((avg (round->exact (/ (fold + 0 vec) (s16vector-length vec))))) > >>>> (s16vector-sub! vec avg))) > >>>> > >>>> (define my-vec (s16vector 0 1 2 3 4 5 6 7 8 9)) > >>>> (relativize my-vec) > >>>> my-vec > >>>> ===> > >>>> #s16(-4 -3 -2 -1 0 1 2 3 4 5) > >>>> > >>>> > >>>> Take a string that contains numbers separated by semicolons or > >>>> commas and convert it to a list of numbers. > >>>> > >>>> (map string->number (string-split "2,3.14;5.8,9" #/[,;]/)) > >>>> ===> > >>>> (2 3.14 5.8 9) > >>> > >>> What role would these have in the scripting of an automation system? > >>> IME, tasks in that domain tend to be more procedural oriented. > >> > >> WJ is an odd sort. You won't find that he is much of a > >> conversationalist. Rather he communicates in terms of code for any > >> manner of interesting, even if irrelevant, examples. > >> > >> Just one of the many odd birds flitting about in the Forth newsgroup. > >> > >> -- > >> > >> Rick > > > > He may be an odd sort, but his point is spot on. For *embedded scripting* > > I wouldn't go near Forth in a bazillion years. Okay, if the *embedded* > > machine I was using had like, 1K of RAM, then yes, Forth. Otherwise, no > > way. > > > > Look, if you are doing scripting, then you are doing things like: > > > > * Pinging IP addresses (e.g. a gateway) and changing routing tables on > > the fly depending on whether a particular interface is up or not. > > * Reading through log files, looking for the certain occurrence of strings > > (error codes/strings, other filenames etc.) > > * Deleting log or error files > > * Moving log or error files > > * Rotating log or error files depending on their age > > * Searching for files of a given type, or date range, and moving them, > > or zipping them, or deleting them. > > > > Forth has *no* standard way to do any of these things. You'd even have > > to write your own string array handler FFS. Forget enumerating a disk > > directory, getting a list of all the files in a structure, with their > > creation dates, modification dates, filtering by type, sorting by date, > > looking for duplicate file names (so that you can delete the older > > versions) etc. > > > > Are you kidding me? > > No, but you are kidding me. It is clear that you have virtually no > experience with Forth. Does a language need a "standard" way to do > everything you want to do? No, none of the things you mention are in > the Forth "standard" and yet, many apps have been written that do > exactly these things. I'll call you on that. Citations please. > In fact, most are a part of the Forth systems > that you would use. But if you check the OP's requirements, he didn't > mention any of these. "such as scan and ping other devices, string like > data transfer,etc. And there is need of some logic to parse received > content." > > > > You want Perl, PHP, and Python. Any of those will take you everywhere > > you want to go. > > > > Forth is next to useless for this sort of thing, unless you have a rack > > of libraries that you have personally built up over the years. Because, > > you know, this is Forth, right, and we don't use each other's libraries > > in the Forth world, because everyone else's code sucks, right? We can > > *all* do *much* better jobs by ourselves, re-inventing the wheel over > > and over and over again. > > > > Using Forth for this kind of thing would be like setting out to build a > > house with a hammer and a screwdriver. Someone says "hey, where's the > > cement mixer?" and you hold up the hammer and the screwdriver and say > > "we're gonna build our own! It's gonna be the best cement mixer EVER!" > > > > Don't get me started! I don't even have a cat that I can kick ;-) > > > > Next-door neighbour... he has a cat... > > Wow! You clearly have some issues with programming languages. Perhaps > you should put down the keyboard and walk away? > > -- > > Rick
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-07-26 22:07 -1000 |
| Message-ID | <VNKdnWE8Lt1YeyjInZ2dnUU7-TednZ2d@supernews.com> |
| In reply to | #40819 |
On 7/26/15 9:42 PM, Mark Wills wrote: > On Saturday, 25 July 2015 15:19:28 UTC+1, rickman wrote: >> On 7/25/2015 4:28 AM, Mark Wills wrote: >>> On Saturday, 25 July 2015 01:52:11 UTC+1, rickman wrote: >>>> On 7/24/2015 8:00 PM, Don Y wrote: >>>>> On 7/24/2015 4:06 PM, WJ wrote: >>>>> >>>>>> It's obvious that the reason that he is recommending Forth >>>>>> over all other languages is that he knows no language that >>>>>> is higher-level than Forth. And he finds it too difficult >>>>>> to learn another language. >>>>>> >>>>>> If a hammer is the only tool that you have, then you use >>>>>> a hammer for everything. >>>>>> >>>>>> How would these tasks be done with a hammer? >>>>>> >>>>>> Using Gauche Scheme: >>>>>> >>>>>> Write a function that accepts a vector (1-dimensional array) of >>>>>> 16-bit numbers and replaces each number with its difference >>>>>> from the average. >>>>>> >>>>>> (use gauche.uvector) >>>>>> (use gauche.collection) >>>>>> >>>>>> (define (relativize vec) >>>>>> (let ((avg (round->exact (/ (fold + 0 vec) (s16vector-length vec))))) >>>>>> (s16vector-sub! vec avg))) >>>>>> >>>>>> (define my-vec (s16vector 0 1 2 3 4 5 6 7 8 9)) >>>>>> (relativize my-vec) >>>>>> my-vec >>>>>> ===> >>>>>> #s16(-4 -3 -2 -1 0 1 2 3 4 5) >>>>>> >>>>>> >>>>>> Take a string that contains numbers separated by semicolons or >>>>>> commas and convert it to a list of numbers. >>>>>> >>>>>> (map string->number (string-split "2,3.14;5.8,9" #/[,;]/)) >>>>>> ===> >>>>>> (2 3.14 5.8 9) >>>>> >>>>> What role would these have in the scripting of an automation system? >>>>> IME, tasks in that domain tend to be more procedural oriented. >>>> >>>> WJ is an odd sort. You won't find that he is much of a >>>> conversationalist. Rather he communicates in terms of code for any >>>> manner of interesting, even if irrelevant, examples. >>>> >>>> Just one of the many odd birds flitting about in the Forth newsgroup. >>>> >>>> -- >>>> >>>> Rick >>> >>> He may be an odd sort, but his point is spot on. For *embedded scripting* >>> I wouldn't go near Forth in a bazillion years. Okay, if the *embedded* >>> machine I was using had like, 1K of RAM, then yes, Forth. Otherwise, no >>> way. >>> >>> Look, if you are doing scripting, then you are doing things like: >>> >>> * Pinging IP addresses (e.g. a gateway) and changing routing tables on >>> the fly depending on whether a particular interface is up or not. >>> * Reading through log files, looking for the certain occurrence of strings >>> (error codes/strings, other filenames etc.) >>> * Deleting log or error files >>> * Moving log or error files >>> * Rotating log or error files depending on their age >>> * Searching for files of a given type, or date range, and moving them, >>> or zipping them, or deleting them. >>> >>> Forth has *no* standard way to do any of these things. You'd even have >>> to write your own string array handler FFS. Forget enumerating a disk >>> directory, getting a list of all the files in a structure, with their >>> creation dates, modification dates, filtering by type, sorting by date, >>> looking for duplicate file names (so that you can delete the older >>> versions) etc. >>> >>> Are you kidding me? >> >> No, but you are kidding me. It is clear that you have virtually no >> experience with Forth. Does a language need a "standard" way to do >> everything you want to do? No, none of the things you mention are in >> the Forth "standard" and yet, many apps have been written that do >> exactly these things. > > I'll call you on that. Citations please. SwiftForth can do most of those things, and even our DOS-based systems from years ago can do many of them. >> In fact, most are a part of the Forth systems >> that you would use. But if you check the OP's requirements, he didn't >> mention any of these. "such as scan and ping other devices, string like >> data transfer,etc. And there is need of some logic to parse received >> content." Exactly. Forths that are co-resident with an OS have a straightforward interface to the OS's ability to do this stuff. And in many standalone embedded projects we have worked on we have done many of them. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2015-07-27 01:44 -0700 |
| Message-ID | <c8c14b1d-7b1a-47ff-8f74-8599371c2aa0@googlegroups.com> |
| In reply to | #40823 |
On Monday, 27 July 2015 09:07:35 UTC+1, Elizabeth D. Rather wrote: > On 7/26/15 9:42 PM, Mark Wills wrote: > > On Saturday, 25 July 2015 15:19:28 UTC+1, rickman wrote: > >> On 7/25/2015 4:28 AM, Mark Wills wrote: > >>> On Saturday, 25 July 2015 01:52:11 UTC+1, rickman wrote: > >>>> On 7/24/2015 8:00 PM, Don Y wrote: > >>>>> On 7/24/2015 4:06 PM, WJ wrote: > >>>>> > >>>>>> It's obvious that the reason that he is recommending Forth > >>>>>> over all other languages is that he knows no language that > >>>>>> is higher-level than Forth. And he finds it too difficult > >>>>>> to learn another language. > >>>>>> > >>>>>> If a hammer is the only tool that you have, then you use > >>>>>> a hammer for everything. > >>>>>> > >>>>>> How would these tasks be done with a hammer? > >>>>>> > >>>>>> Using Gauche Scheme: > >>>>>> > >>>>>> Write a function that accepts a vector (1-dimensional array) of > >>>>>> 16-bit numbers and replaces each number with its difference > >>>>>> from the average. > >>>>>> > >>>>>> (use gauche.uvector) > >>>>>> (use gauche.collection) > >>>>>> > >>>>>> (define (relativize vec) > >>>>>> (let ((avg (round->exact (/ (fold + 0 vec) (s16vector-length vec))))) > >>>>>> (s16vector-sub! vec avg))) > >>>>>> > >>>>>> (define my-vec (s16vector 0 1 2 3 4 5 6 7 8 9)) > >>>>>> (relativize my-vec) > >>>>>> my-vec > >>>>>> ===> > >>>>>> #s16(-4 -3 -2 -1 0 1 2 3 4 5) > >>>>>> > >>>>>> > >>>>>> Take a string that contains numbers separated by semicolons or > >>>>>> commas and convert it to a list of numbers. > >>>>>> > >>>>>> (map string->number (string-split "2,3.14;5.8,9" #/[,;]/)) > >>>>>> ===> > >>>>>> (2 3.14 5.8 9) > >>>>> > >>>>> What role would these have in the scripting of an automation system? > >>>>> IME, tasks in that domain tend to be more procedural oriented. > >>>> > >>>> WJ is an odd sort. You won't find that he is much of a > >>>> conversationalist. Rather he communicates in terms of code for any > >>>> manner of interesting, even if irrelevant, examples. > >>>> > >>>> Just one of the many odd birds flitting about in the Forth newsgroup. > >>>> > >>>> -- > >>>> > >>>> Rick > >>> > >>> He may be an odd sort, but his point is spot on. For *embedded scripting* > >>> I wouldn't go near Forth in a bazillion years. Okay, if the *embedded* > >>> machine I was using had like, 1K of RAM, then yes, Forth. Otherwise, no > >>> way. > >>> > >>> Look, if you are doing scripting, then you are doing things like: > >>> > >>> * Pinging IP addresses (e.g. a gateway) and changing routing tables on > >>> the fly depending on whether a particular interface is up or not. > >>> * Reading through log files, looking for the certain occurrence of strings > >>> (error codes/strings, other filenames etc.) > >>> * Deleting log or error files > >>> * Moving log or error files > >>> * Rotating log or error files depending on their age > >>> * Searching for files of a given type, or date range, and moving them, > >>> or zipping them, or deleting them. > >>> > >>> Forth has *no* standard way to do any of these things. You'd even have > >>> to write your own string array handler FFS. Forget enumerating a disk > >>> directory, getting a list of all the files in a structure, with their > >>> creation dates, modification dates, filtering by type, sorting by date, > >>> looking for duplicate file names (so that you can delete the older > >>> versions) etc. > >>> > >>> Are you kidding me? > >> > >> No, but you are kidding me. It is clear that you have virtually no > >> experience with Forth. Does a language need a "standard" way to do > >> everything you want to do? No, none of the things you mention are in > >> the Forth "standard" and yet, many apps have been written that do > >> exactly these things. > > > > I'll call you on that. Citations please. > > SwiftForth can do most of those things, and even our DOS-based systems > from years ago can do many of them. Apps. He said apps. "Many apps have been written which do exactly these things". I don't think so. A few? Sure. You just wouldn't go to Forth for this sort of thing. If I wanted to: * Rotate error logs in a directory (say, keep the last three) * Log on to a Cisco router * Download the day's error logs and copy to the directory * FTP the new error log file9s) to an off-site backup server * Dynamically generate a clean-up script to clean the backup server * FTP that file to the backup server * Do a CHMOD on the FTPd backup file via a Unix shell to give it execute permissions * Execute the cleanup script * Open the logs and analyse for particular occurences of error strings * When found, read the specific error information, and update an SQL database with the stats * Execute an SQL stored procedure to insert a record into a database to indicate that the script(s) ran/didn't run with/without errors * Send an email to sysadmin indicating that the scripts ran with/without errors then I sure as hell wouldn't ever think of Forth in a million years. The above is typical of many office-grown back-office admin scripts written in their millions by millions of sys-admins the world over every day of every week. None of them will be written in Forth. They'll be written in Perl or Python. Some of them (windows boxes) will be written in ASP though that's rather old-hat these days. Perl and Python are cross-platform so it's generally preferable to sys-admins to learn Perl and/or Python as they can write scripts on a multitude of platforms: Win, Lin, Unix, OSX, Sun etc.
[toc] | [prev] | [next] | [standalone]
| From | foxaudioresearch@gmail.com |
|---|---|
| Date | 2015-07-27 05:57 -0700 |
| Message-ID | <ce65bfaa-bb27-415d-9d4b-867161f83f6c@googlegroups.com> |
| In reply to | #40826 |
The only exception to your rational that I can see, is if the OP chose to EXTEND Forth to do those kind of operations by building a custom forth-like language for the purpose, which can be done, but one could ask why? Possible reasons 1. Forth might run faster than the alternatives 2. Forth can interpret a file almost as fast as it can load from disk 3. Adding some unique features to a commercial product that have value to a customer set 4. Creating high level features that make admin easier for operators 5. a domain specific language is in the specifications 6. Because they can 7. To prove a point to their boss 8. Your reason goes here...
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-07-27 14:02 +0100 |
| Message-ID | <mp5a2u$qot$2@dont-email.me> |
| In reply to | #40832 |
on 27/07/2015 13:57:04, foxaudio wrote: To what or whom are you replying? You've trimmed away the entire context. > The only exception to your rational that I can see, is if the OP chose > to EXTEND Forth to do those kind of operations by building a custom > forth-like language for the purpose, which can be done, but one could > ask why? > > Possible reasons > > 1. Forth might run faster than the alternatives > 2. Forth can interpret a file almost as fast as it can load from disk > 3. Adding some unique features to a commercial product that have value > to a customer set 4. Creating high level features that make admin > easier for operators 5. a domain specific language is in the > specifications 6. Because they can > 7. To prove a point to their boss > 8. Your reason goes here... > > >
[toc] | [prev] | [next] | [standalone]
| From | foxaudioresearch@gmail.com |
|---|---|
| Date | 2015-07-27 08:41 -0700 |
| Message-ID | <92d112ba-3832-466b-9347-42570f1320c4@googlegroups.com> |
| In reply to | #40834 |
On Monday, July 27, 2015 at 9:02:52 AM UTC-4, Alex McDonald wrote: > on 27/07/2015 13:57:04, foxaudio wrote: > > To what or whom are you replying? You've trimmed away the entire context. > > > The only exception to your rational that I can see, is if the OP chose > > to EXTEND Forth to do those kind of operations by building a custom > > forth-like language for the purpose, which can be done, but one could > > ask why? > > > > Possible reasons > > > > 1. Forth might run faster than the alternatives > > 2. Forth can interpret a file almost as fast as it can load from disk > > 3. Adding some unique features to a commercial product that have value > > to a customer set 4. Creating high level features that make admin > > easier for operators 5. a domain specific language is in the > > specifications 6. Because they can > > 7. To prove a point to their boss > > 8. Your reason goes here... > > > > > > Sorry. Using the iPad at the breakfast table... doesn't quote the post I replied to. It was Mark's post regarding "If I wanted to: * Rotate error logs in a directory (say, keep the last three) * Log on to a Cisco router * Download the day's error logs and copy to the directory * FTP the new error log file9s) to an off-site backup server * Dynamically generate a clean-up script to clean the backup server * FTP that file to the backup server * Do a CHMOD on the FTPd backup file via a Unix shell to give it execute permissions * Execute the cleanup script * Open the logs and analyse for particular occurences of error strings * When found, read the specific error information, and update an SQL database with the stats * Execute an SQL stored procedure to insert a record into a database to indicate that the script(s) ran/didn't run with/without errors * Send an email to sysadmin indicating that the scripts ran with/without errors" BF
[toc] | [prev] | [next] | [standalone]
| From | Julian Fondren <julian.fondren@gmail.com> |
|---|---|
| Date | 2015-07-27 08:36 -0700 |
| Message-ID | <63192326-c38a-4354-b420-39665aa32ea7@googlegroups.com> |
| In reply to | #40826 |
On Monday, July 27, 2015 at 3:44:16 AM UTC-5, Mark Wills wrote:
> If I wanted to:
>
> * Rotate error logs in a directory (say, keep the last three)
> * Log on to a Cisco router
> * Download the day's error logs and copy to the directory
> * FTP the new error log file9s) to an off-site backup server
> * Dynamically generate a clean-up script to clean the backup server
> * FTP that file to the backup server
> * Do a CHMOD on the FTPd backup file via a Unix shell to give it
> execute permissions
> * Execute the cleanup script
* sling files around
* invoke other programs
* do something dubious to the backup server
> * Open the logs and analyse for particular occurences of error strings
> * When found, read the specific error information, and update an SQL
> database with the stats
> * Execute an SQL stored procedure to insert a record into a database
> to indicate that the script(s) ran/didn't run with/without errors
> * Send an email to sysadmin indicating that the scripts ran with/without
> errors
>
> then I sure as hell wouldn't ever think of Forth in a million years.
That's too bad. I thought of Forth as soon as you got to
* log analysis
I'm sure you'll say that log analysis will be I/O bound and therefore
not benefit from Forth. I had a fellow say to me that a task was I/O
bound and that he couldn't help his script doing it in literally
1/10,000th the time of the script that his was intended to replace.
The rest of that is just 'invoke other programs'. Considering that
Perl scripts by sysadmins also tend to have bash oneliners in them, and
that none of these examples even require reading the output of said
commands, it seems like Forth already has what it needs for these
tasks.
s" logrotated -f /etc/logrotate.d/mysqlerr" system drop
s" rsync -av --ignore-existing logserver:error-logs/ error-logs/"
system drop
> The above is typical of many office-grown back-office admin scripts
> written in their millions by millions of sys-admins the world over
> every day of every week.
There are more than four types of scripts, though. Let's suppose that
you have a bunch of users on your servers, and that these users
sometimes manage to have thirteen million files in their home
directories. This being inconvenient for filesystem-wide operations,
as well as often completely unintended, you'd like to generate a report
on the location of the files in this user's directory so that you can
give the user himself some time to clean it up.
These are such numbers, by the way, where one avoids the use of 'ls' to
look at directory contents. So, would you like to use a
filesystem-walking function in a high-level language that first builds
and then sorts a list of thirteen million files (all in one directory,
of course; the entire rest of the user's files in other directories do
not add up to a fifty thousand), after running internally through a C
opendir/readir loop, which is itself an abstraction over the getdents
syscall?
Sure, why not? Filesystem-walking is I/O bound, after all :-p
> None of them will be written in Forth.
You made that giant wall of four repeated things that Forth can't do,
which it can do with a single word that's built into probably all
hosted Forth systems. You now present this thunderous conclusion that
absolutely everybody reading you will find it easier to attribute to
Forth not being as popular or as well known as those languages. If
Forth caught on as a fad among system administrators, the scripts would
appear, using a library providing file-slinging conveniences. These
things happen. Or do you think that Javascript is a naturally
brilliant server-side scripting language?
You should search for 'Passanti' and see how it's done.
-- Julian
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-07-25 10:20 -0400 |
| Message-ID | <mp05sg$t9i$2@dont-email.me> |
| In reply to | #40796 |
On 7/25/2015 4:28 AM, Mark Wills wrote: > On Saturday, 25 July 2015 01:52:11 UTC+1, rickman wrote: >> On 7/24/2015 8:00 PM, Don Y wrote: >>> On 7/24/2015 4:06 PM, WJ wrote: >>> >>>> It's obvious that the reason that he is recommending Forth >>>> over all other languages is that he knows no language that >>>> is higher-level than Forth. And he finds it too difficult >>>> to learn another language. >>>> >>>> If a hammer is the only tool that you have, then you use >>>> a hammer for everything. >>>> >>>> How would these tasks be done with a hammer? >>>> >>>> Using Gauche Scheme: >>>> >>>> Write a function that accepts a vector (1-dimensional array) of >>>> 16-bit numbers and replaces each number with its difference >>>> from the average. >>>> >>>> (use gauche.uvector) >>>> (use gauche.collection) >>>> >>>> (define (relativize vec) >>>> (let ((avg (round->exact (/ (fold + 0 vec) (s16vector-length vec))))) >>>> (s16vector-sub! vec avg))) >>>> >>>> (define my-vec (s16vector 0 1 2 3 4 5 6 7 8 9)) >>>> (relativize my-vec) >>>> my-vec >>>> ===> >>>> #s16(-4 -3 -2 -1 0 1 2 3 4 5) >>>> >>>> >>>> Take a string that contains numbers separated by semicolons or >>>> commas and convert it to a list of numbers. >>>> >>>> (map string->number (string-split "2,3.14;5.8,9" #/[,;]/)) >>>> ===> >>>> (2 3.14 5.8 9) >>> >>> What role would these have in the scripting of an automation system? >>> IME, tasks in that domain tend to be more procedural oriented. >> >> WJ is an odd sort. You won't find that he is much of a >> conversationalist. Rather he communicates in terms of code for any >> manner of interesting, even if irrelevant, examples. >> >> Just one of the many odd birds flitting about in the Forth newsgroup. >> >> -- >> >> Rick > > He may be an odd sort, but his point is spot on. For *embedded scripting* > I wouldn't go near Forth in a bazillion years. Okay, if the *embedded* > machine I was using had like, 1K of RAM, then yes, Forth. Otherwise, no > way. > > Look, if you are doing scripting, then you are doing things like: > > * Pinging IP addresses (e.g. a gateway) and changing routing tables on > the fly depending on whether a particular interface is up or not. > * Reading through log files, looking for the certain occurrence of strings > (error codes/strings, other filenames etc.) > * Deleting log or error files > * Moving log or error files > * Rotating log or error files depending on their age > * Searching for files of a given type, or date range, and moving them, > or zipping them, or deleting them. > > Forth has *no* standard way to do any of these things. You'd even have > to write your own string array handler FFS. Forget enumerating a disk > directory, getting a list of all the files in a structure, with their > creation dates, modification dates, filtering by type, sorting by date, > looking for duplicate file names (so that you can delete the older > versions) etc. > > Are you kidding me? > > You want Perl, PHP, and Python. Any of those will take you everywhere > you want to go. > > Forth is next to useless for this sort of thing, unless you have a rack > of libraries that you have personally built up over the years. Because, > you know, this is Forth, right, and we don't use each other's libraries > in the Forth world, because everyone else's code sucks, right? We can > *all* do *much* better jobs by ourselves, re-inventing the wheel over > and over and over again. > > Using Forth for this kind of thing would be like setting out to build a > house with a hammer and a screwdriver. Someone says "hey, where's the > cement mixer?" and you hold up the hammer and the screwdriver and say > "we're gonna build our own! It's gonna be the best cement mixer EVER!" > > Don't get me started! I don't even have a cat that I can kick ;-) > > Next-door neighbour... he has a cat... BTW, you only replied to the forth group. If you feel so strongly that Forth is such a bad language, why are you here? -- Rick
[toc] | [prev] | [next] | [standalone]
| From | glidedog@gmail.com |
|---|---|
| Date | 2015-07-26 04:01 -0700 |
| Message-ID | <e2fc3d16-9abd-4328-8770-04454997aee0@googlegroups.com> |
| In reply to | #40799 |
On 7/25/15 10:20 AM, rickman wrote: > On 7/25/2015 4:28 AM, Mark Wills wrote: >> On Saturday, 25 July 2015 01:52:11 UTC+1, rickman wrote: >>> On 7/24/2015 8:00 PM, Don Y wrote: >>>> On 7/24/2015 4:06 PM, WJ wrote: >>>> >>>>> It's obvious that the reason that he is recommending Forth >>>>> over all other languages is that he knows no language that is >>>>> higher-level than Forth. And he finds it too difficult to >>>>> learn another language. >>>>> >>>>> If a hammer is the only tool that you have, then you use a >>>>> hammer for everything. >>>>> >>>>> How would these tasks be done with a hammer? >>>>> >>>>> Using Gauche Scheme: >>>>> >>>>> Write a function that accepts a vector (1-dimensional array) >>>>> of 16-bit numbers and replaces each number with its >>>>> difference from the average. >>>>> >>>>> (use gauche.uvector) (use gauche.collection) >>>>> >>>>> (define (relativize vec) (let ((avg (round->exact (/ (fold + >>>>> 0 vec) (s16vector-length vec))))) (s16vector-sub! vec avg))) >>>>> >>>>> (define my-vec (s16vector 0 1 2 3 4 5 6 7 8 9)) (relativize >>>>> my-vec) my-vec ===> #s16(-4 -3 -2 -1 0 1 2 3 4 5) >>>>> >>>>> >>>>> Take a string that contains numbers separated by semicolons >>>>> or commas and convert it to a list of numbers. >>>>> >>>>> (map string->number (string-split "2,3.14;5.8,9" #/[,;]/)) >>>>> ===> (2 3.14 5.8 9) >>>> >>>> What role would these have in the scripting of an automation >>>> system? IME, tasks in that domain tend to be more procedural >>>> oriented. >>> >>> WJ is an odd sort. You won't find that he is much of a >>> conversationalist. Rather he communicates in terms of code for >>> any manner of interesting, even if irrelevant, examples. >>> >>> Just one of the many odd birds flitting about in the Forth >>> newsgroup. >>> >>> -- >>> >>> Rick >> >> He may be an odd sort, but his point is spot on. For *embedded >> scripting* I wouldn't go near Forth in a bazillion years. Okay, if >> the *embedded* machine I was using had like, 1K of RAM, then yes, >> Forth. Otherwise, no way. >> >> Look, if you are doing scripting, then you are doing things like: >> >> * Pinging IP addresses (e.g. a gateway) and changing routing tables >> on the fly depending on whether a particular interface is up or >> not. * Reading through log files, looking for the certain >> occurrence of strings (error codes/strings, other filenames etc.) * >> Deleting log or error files * Moving log or error files * Rotating >> log or error files depending on their age * Searching for files of >> a given type, or date range, and moving them, or zipping them, or >> deleting them. >> >> Forth has *no* standard way to do any of these things. You'd even >> have to write your own string array handler FFS. Forget enumerating >> a disk directory, getting a list of all the files in a structure, >> with their creation dates, modification dates, filtering by type, >> sorting by date, looking for duplicate file names (so that you can >> delete the older versions) etc. >> >> Are you kidding me? >> >> You want Perl, PHP, and Python. Any of those will take you >> everywhere you want to go. >> >> Forth is next to useless for this sort of thing, unless you have a >> rack of libraries that you have personally built up over the years. >> Because, you know, this is Forth, right, and we don't use each >> other's libraries in the Forth world, because everyone else's code >> sucks, right? We can *all* do *much* better jobs by ourselves, >> re-inventing the wheel over and over and over again. >> >> Using Forth for this kind of thing would be like setting out to >> build a house with a hammer and a screwdriver. Someone says "hey, >> where's the cement mixer?" and you hold up the hammer and the >> screwdriver and say "we're gonna build our own! It's gonna be the >> best cement mixer EVER!" >> >> Don't get me started! I don't even have a cat that I can kick ;-) >> >> Next-door neighbour... he has a cat... > > BTW, you only replied to the forth group. If you feel so strongly > that Forth is such a bad language, why are you here? Mark's lament is understandable. Forth doesn't even have a built-in cell-sized-element array wordset. I think that sort of thing is where he's coming from. But that's Forth. I long ago made peace with this aspect and accept Forth as it is and for what it is (and isn't). -Doug
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-07-26 18:53 +0100 |
| Message-ID | <mp36ne$bte$1@dont-email.me> |
| In reply to | #40802 |
on 26/07/2015 12:01:26, glidedog wrote: \ > > Mark's lament is understandable. Forth doesn't even have a built-in > cell-sized-element array wordset. The definition of a 1 dimensional array is trivial; perhaps that's why. : 1dim create cells allot does> swap cells + ; 10 1dim myarray 10 0 myarray ! 20 1 myarray ! 0 myarray @ 1 myarray @ + .
[toc] | [prev] | [next] | [standalone]
Page 1 of 9 [1] 2 3 4 5 6 7 8 9 Next page →
Back to top | Article view | comp.lang.forth
csiph-web