Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #60222 > unrolled thread
| Started by | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| First post | 2017-06-03 09:09 +0000 |
| Last post | 2017-06-13 10:52 -0500 |
| Articles | 20 on this page of 125 — 21 participants |
Back to article view | Back to comp.lang.forth
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 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7 Next page →
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2017-06-03 10:15 -0700 |
| Message-ID | <4e405e42-f148-4514-b023-0df92ea41159@googlegroups.com> |
| In reply to | #60222 |
In the first year of faculty we learned Pascal (in 1990). Not very easy. Next year we started with C. Even harder. After five years of study and 4 years of using C, we still didn't get a very solid grasp of it. And you really thing Forth is easier? Make a slow forth, but full of comodities. Arrays, strings, lists, trees, maps, database access, access to the tcp/ip sockets, etc. all of them very well documented, and EASY for students. That may catch some attention. And just freeware, not $$$. For real poor students. The forth community is very busy in discussing compiler internals though. Let me say a thing: a (normal) forth programmer shouldn't ever need to use a CREATE DOES> thing. Never. Or [ ] thing. Or worse, POSTPONE and other nightmares. Or recognizers... really?
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2017-06-06 06:20 -0700 |
| Message-ID | <ab1f27d8-56b0-4140-98d6-50dc5eb1cfa0@googlegroups.com> |
| In reply to | #60240 |
On Saturday, 3 June 2017 18:15:17 UTC+1, Raimond Dragomir wrote: > In the first year of faculty we learned Pascal (in 1990). Not very easy. > Next year we started with C. Even harder. After five years of study and > 4 years of using C, we still didn't get a very solid grasp of it. And you > really thing Forth is easier? > Of course it's easier. What on earth are you talking about? It's the simplest language in the world to learn. It takes *a day*. After that, it's just experience. I have my six year old daughter writing Forth. I showed her the stack using lego bricks. SWAP, DROP, DUP etc. all done with lego bricks. A six year old (at least, a six year old anywhere on the "normal" IQ bell- curve") cannot learn C. > Make a slow forth, but full of comodities. Arrays, strings, lists, trees, > maps, database access, access to the tcp/ip sockets, etc. all of them very > well documented, and EASY for students. That may catch some attention. > And just freeware, not $$$. For real poor students. > Agree with you on that. > The forth community is very busy in discussing compiler internals though. > Let me say a thing: a (normal) forth programmer shouldn't ever need to use a > CREATE DOES> thing. Never. Or [ ] thing. Or worse, POSTPONE and other > nightmares. Or recognizers... really? I never really thought about it, but yes.
[toc] | [prev] | [next] | [standalone]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2017-06-06 07:13 -0700 |
| Message-ID | <3daf336e-6996-4de4-be0e-9ced579314ab@googlegroups.com> |
| In reply to | #60387 |
marți, 6 iunie 2017, 16:20:46 UTC+3, Mark Wills a scris: > On Saturday, 3 June 2017 18:15:17 UTC+1, Raimond Dragomir wrote: > > In the first year of faculty we learned Pascal (in 1990). Not very easy. > > Next year we started with C. Even harder. After five years of study and > > 4 years of using C, we still didn't get a very solid grasp of it. And you > > really thing Forth is easier? > > > > Of course it's easier. What on earth are you talking about? It's the simplest > language in the world to learn. It takes *a day*. After that, it's just > experience. I have my six year old daughter writing Forth. I showed her the > stack using lego bricks. SWAP, DROP, DUP etc. all done with lego bricks. > A six year old (at least, a six year old anywhere on the "normal" IQ bell- > curve") cannot learn C. > > > Make a slow forth, but full of comodities. Arrays, strings, lists, trees, > > maps, database access, access to the tcp/ip sockets, etc. all of them very > > well documented, and EASY for students. That may catch some attention. > > And just freeware, not $$$. For real poor students. > > > Agree with you on that. > > > The forth community is very busy in discussing compiler internals though. > > Let me say a thing: a (normal) forth programmer shouldn't ever need to use a > > CREATE DOES> thing. Never. Or [ ] thing. Or worse, POSTPONE and other > > nightmares. Or recognizers... really? > > I never really thought about it, but yes. When everything is hiding on the stack (you don't see it!), it's not that simple. Not to say that in forth you have to do everything by yourself at the low level. That can be just too much for a beginner. C has some weirdness, especially when typedef-ing function pointers or even arrays. I also remember that I had a hard time understanding the printf (coming from the much more elegant pascal). Now, I have quite a hard time deciding what kind of scripting language to embed in my industrial automation controller. It seems to be that the programmers which will be scripting it are Visual Basic and C# Windows only ones. I'm afraid that Forth will be just too weird for them. Howeaver, the critical and sensitive functions will be provided by the kernel, so they don't have to write everything from scratch :) I'm contemplating changing some bits here and there to make my forth more friendly, especially by using local variables, and by having a unified variable like the VALUEs (fetch by name, store by TO). This will just let them write: : SQR ( a -- a*a ) a a * ; The paren will be local parameters syntax, not the comment. Just an idea, and a simple one. The other solution is to embed some basic interpreter. That's ugly. Lua or python are out of question. Too big and really too complicated for the application at hand.
[toc] | [prev] | [next] | [standalone]
| From | minforth@arcor.de |
|---|---|
| Date | 2017-06-06 08:21 -0700 |
| Message-ID | <ce55bbea-d45d-4350-b28c-def7ad86da90@googlegroups.com> |
| In reply to | #60392 |
Am Dienstag, 6. Juni 2017 16:13:27 UTC+2 schrieb Raimond Dragomir: > marți, 6 iunie 2017, 16:20:46 UTC+3, Mark Wills a scris: > > On Saturday, 3 June 2017 18:15:17 UTC+1, Raimond Dragomir wrote: > > > In the first year of faculty we learned Pascal (in 1990). Not very easy. > > > Next year we started with C. Even harder. After five years of study and > > > 4 years of using C, we still didn't get a very solid grasp of it. And you > > > really thing Forth is easier? > > > > > > > Of course it's easier. What on earth are you talking about? It's the simplest > > language in the world to learn. It takes *a day*. After that, it's just > > experience. I have my six year old daughter writing Forth. I showed her the > > stack using lego bricks. SWAP, DROP, DUP etc. all done with lego bricks. > > A six year old (at least, a six year old anywhere on the "normal" IQ bell- > > curve") cannot learn C. > > > > > Make a slow forth, but full of comodities. Arrays, strings, lists, trees, > > > maps, database access, access to the tcp/ip sockets, etc. all of them very > > > well documented, and EASY for students. That may catch some attention. > > > And just freeware, not $$$. For real poor students. > > > > > Agree with you on that. > > > > > The forth community is very busy in discussing compiler internals though. > > > Let me say a thing: a (normal) forth programmer shouldn't ever need to use a > > > CREATE DOES> thing. Never. Or [ ] thing. Or worse, POSTPONE and other > > > nightmares. Or recognizers... really? > > > > I never really thought about it, but yes. > > When everything is hiding on the stack (you don't see it!), it's not > that simple. Not to say that in forth you have to do everything by > yourself at the low level. That can be just too much for a beginner. > > C has some weirdness, especially when typedef-ing function pointers > or even arrays. I also remember that I had a hard time understanding > the printf (coming from the much more elegant pascal). > > Now, I have quite a hard time deciding what kind of scripting language > to embed in my industrial automation controller. It seems to be that > the programmers which will be scripting it are Visual Basic and C# > Windows only ones. I'm afraid that Forth will be just too weird for them. > Howeaver, the critical and sensitive functions will be provided by the > kernel, so they don't have to write everything from scratch :) > I'm contemplating changing some bits here and there to make my forth > more friendly, especially by using local variables, and by having > a unified variable like the VALUEs (fetch by name, store by TO). > This will just let them write: > : SQR ( a -- a*a ) a a * ; > The paren will be local parameters syntax, not the comment. > Just an idea, and a simple one. > > The other solution is to embed some basic interpreter. That's ugly. > Lua or python are out of question. Too big and really too complicated > for the application at hand. The real question for skripting is not the beauty or ugliness of a RPN syntax like in Forth, but to design a suitable DSL for engineering and servicing the automation controllers. That's where Forth shines. In other words: you create your own programming language. When you want to square f.ex. the delta pressure over a flow orifice, you are dealing with signal tag names and write results to other signal tags. A contrived example, but you'll get the meaning: #4 IO_CARD #7 CHANNEL DEFINE P_ORIF_BEFORE #4 IO-CARD #8 CHANNEL DEFINE P_ORIF_AFTER INTERNAL SIGNAL DEFINE DELTA_P10 P_ORIF_BEFORE P-ORIF_AFTER MINUS SQRT := DELTA_P10 This is a plain Forth-made DSL in a sealed application vocabulary. Even RPN is preserved. "Sealed" means that there are no visible standard Forth compiler words or words that could havoc the controller e.g. misprogram timers or do memory access violations. Why waste precious resources with another blown-up but hip skripting langage?
[toc] | [prev] | [next] | [standalone]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2017-06-06 09:05 -0700 |
| Message-ID | <bf694f7c-ae83-497c-9d22-048d17603fcb@googlegroups.com> |
| In reply to | #60396 |
marți, 6 iunie 2017, 18:21:07 UTC+3, minf...@arcor.de a scris: > Am Dienstag, 6. Juni 2017 16:13:27 UTC+2 schrieb Raimond Dragomir: > > marți, 6 iunie 2017, 16:20:46 UTC+3, Mark Wills a scris: > > > On Saturday, 3 June 2017 18:15:17 UTC+1, Raimond Dragomir wrote: > > > > In the first year of faculty we learned Pascal (in 1990). Not very easy. > > > > Next year we started with C. Even harder. After five years of study and > > > > 4 years of using C, we still didn't get a very solid grasp of it. And you > > > > really thing Forth is easier? > > > > > > > > > > Of course it's easier. What on earth are you talking about? It's the simplest > > > language in the world to learn. It takes *a day*. After that, it's just > > > experience. I have my six year old daughter writing Forth. I showed her the > > > stack using lego bricks. SWAP, DROP, DUP etc. all done with lego bricks. > > > A six year old (at least, a six year old anywhere on the "normal" IQ bell- > > > curve") cannot learn C. > > > > > > > Make a slow forth, but full of comodities. Arrays, strings, lists, trees, > > > > maps, database access, access to the tcp/ip sockets, etc. all of them very > > > > well documented, and EASY for students. That may catch some attention. > > > > And just freeware, not $$$. For real poor students. > > > > > > > Agree with you on that. > > > > > > > The forth community is very busy in discussing compiler internals though. > > > > Let me say a thing: a (normal) forth programmer shouldn't ever need to use a > > > > CREATE DOES> thing. Never. Or [ ] thing. Or worse, POSTPONE and other > > > > nightmares. Or recognizers... really? > > > > > > I never really thought about it, but yes. > > > > When everything is hiding on the stack (you don't see it!), it's not > > that simple. Not to say that in forth you have to do everything by > > yourself at the low level. That can be just too much for a beginner. > > > > C has some weirdness, especially when typedef-ing function pointers > > or even arrays. I also remember that I had a hard time understanding > > the printf (coming from the much more elegant pascal). > > > > Now, I have quite a hard time deciding what kind of scripting language > > to embed in my industrial automation controller. It seems to be that > > the programmers which will be scripting it are Visual Basic and C# > > Windows only ones. I'm afraid that Forth will be just too weird for them. > > Howeaver, the critical and sensitive functions will be provided by the > > kernel, so they don't have to write everything from scratch :) > > I'm contemplating changing some bits here and there to make my forth > > more friendly, especially by using local variables, and by having > > a unified variable like the VALUEs (fetch by name, store by TO). > > This will just let them write: > > : SQR ( a -- a*a ) a a * ; > > The paren will be local parameters syntax, not the comment. > > Just an idea, and a simple one. > > > > The other solution is to embed some basic interpreter. That's ugly. > > Lua or python are out of question. Too big and really too complicated > > for the application at hand. > > The real question for skripting is not the beauty or ugliness of a > RPN syntax like in Forth, but to design a suitable DSL for engineering > and servicing the automation controllers. That's where Forth shines. > > In other words: you create your own programming language. > > When you want to square f.ex. the delta pressure over a flow orifice, > you are dealing with signal tag names and write results to other signal tags. > > A contrived example, but you'll get the meaning: > > #4 IO_CARD #7 CHANNEL DEFINE P_ORIF_BEFORE > #4 IO-CARD #8 CHANNEL DEFINE P_ORIF_AFTER > INTERNAL SIGNAL DEFINE DELTA_P10 > P_ORIF_BEFORE P-ORIF_AFTER MINUS SQRT := DELTA_P10 > > This is a plain Forth-made DSL in a sealed application vocabulary. > Even RPN is preserved. "Sealed" means that there are no visible > standard Forth compiler words or words that could havoc the controller > e.g. misprogram timers or do memory access violations. > > Why waste precious resources with another blown-up but hip skripting langage? Exactly. The DSL can be quite ok if you manage to hide DUPs DROPs SWAPs ...
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2017-06-06 23:49 -0700 |
| Message-ID | <87o9u0mgw3.fsf@nightsong.com> |
| In reply to | #60392 |
Raimond Dragomir <raimond.dragomir@gmail.com> writes: > Lua or python are out of question. Too big and really too complicated > for the application at hand. Lua and Micropython (micropython.org) are relatively small, not tiny but they run ok in the ESP8266 and comparable Cortex-M cpus. Micropython is on the BBC Microbit too, though it's a tight fit there.
[toc] | [prev] | [next] | [standalone]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2017-06-07 00:58 -0700 |
| Message-ID | <de7e1800-9cb4-4a0f-87e4-fb53a2fff471@googlegroups.com> |
| In reply to | #60422 |
miercuri, 7 iunie 2017, 09:49:36 UTC+3, Paul Rubin a scris: > Raimond Dragomir <raimond.dragomir@gmail.com> writes: > > Lua or python are out of question. Too big and really too complicated > > for the application at hand. > > Lua and Micropython (micropython.org) are relatively small, not tiny but > they run ok in the ESP8266 and comparable Cortex-M cpus. Micropython > is on the BBC Microbit too, though it's a tight fit there. I don't trust python or lua for my type of applications. They should be fast and predictable. Also, when started, they should run forever. The lua and python are too dynamic, with GC and all the malloc stuff. I don't need any dynamic allocation, at least not in the classical way. If I will need some sort of allocation, it will be in a pool of MAX objects, when MAX will be known and allocated at the start. Micropython on microbit is just a toy. Even for ESP8266 I'm not sure how is it going, the ram isn't too big either. I don't know for sure how it works, but throwing memory allocation exceptions is a no go, or being very slow because the GC hits more often because the lack of memory. My requirements are: At startup: loading the scripts fast. They could be quite large. Here the forth compiler is doing very well, I'm not sure for the others. At runtime: fast enough, as for example a tokenized forth VM. No need for native code or STC. But predictable performance. I know that micropython prduces native code, but I don't care as long as the GC can hit any time.
[toc] | [prev] | [next] | [standalone]
| From | Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> |
|---|---|
| Date | 2017-06-07 16:05 -0400 |
| Message-ID | <20170607160543.303725c0@_> |
| In reply to | #60392 |
On Tue, 6 Jun 2017 07:13:26 -0700 (PDT) Raimond Dragomir <raimond.dragomir@gmail.com> wrote: > Now, I have quite a hard time deciding what kind of scripting language > to embed in my industrial automation controller. BASIC. It's interpreted. It's easy to learn. It handles strings and integers, which covers 90% of general purpose programming. An entire generation of programmers were taught it in public school, along with Pascal, at least in the U.S. Older factory machines use BASIC for industrial control. It'll typically have an escape character to switch the interpreter to machine specific commands for a specific line of code. > The other solution is to embed some basic interpreter. That's ugly. > Lua or python are out of question. Too big and really too complicated > for the application at hand. What languages are they teaching in public school nowadays? That will be what the current generation of programmers expect. You can't expect all of your programmers to be formally trained in college or university. Some have to make do with a high school or primary education. I.e., what is the lowest common denominator? Of course, whatever language they teach might be regional, e.g., EU may teach something different from the US. After searching for a while, I see mentions of RobotC, EasyC, Scratch, Alice, Kodu, Java, C++, Visual Basic.NET, and Ruby. Of course, Swift is another language that has become popular recently. http://www.alice.org/ https://scratch.mit.edu/ https://swift.org/ https://www.kodugamelab.com/ http://www.robotc.net/ http://www.intelitek.com/engineering/easyc/ Apparently, the goal is to start teaching kids programming concepts prior to introducing them to text-based programming languages like C, Forth, Fortran, Pascal, Basic, etc. This would be similar to teaching LOGO to young children decades ago. See here: http://blog.acthompson.net/2012/12/programming-with-blocks.html The link below lists C++, HTML, JavaScript, Perl, PHP, Python, and Ruby as the most important and the most commonly taught programming languages in high school: http://www.computerscienceonline.org/cs-programs-before-college/ TIOBE Index ranks all of those except HTML. The top of the list is Java, C, C++, Python, C#, Visual Basic.NET, Javascript, PHP, Perl. https://www.tiobe.com/tiobe-index/ The TIOBE ranks is probably a good place to start your selection. Lua ranks low. Python ranks high. Ruby and Swift rank in-between. Rod Pemberton -- The Paris Agreement is irrelevant. A carbon tax is futile. The only solution is technology. Please tell Elon Musk that he is not being a technology visionary.
[toc] | [prev] | [next] | [standalone]
| From | "Rudy Velthuis" <newsgroups@rvelthuis.de> |
|---|---|
| Date | 2017-06-07 20:26 +0000 |
| Message-ID | <xn0kqygr5ayz9ed000@nntp.aioe.org> |
| In reply to | #60443 |
Rod Pemberton wrote: > On Tue, 6 Jun 2017 07:13:26 -0700 (PDT) > Raimond Dragomir <raimond.dragomir@gmail.com> wrote: > > > Now, I have quite a hard time deciding what kind of scripting > > language to embed in my industrial automation controller. > > BASIC. > > It's interpreted. It's easy to learn. "It is practically impossible to teach good programming style to students that have had prior exposure to Basic; as potential programmers they are mentally mutilated beyond hope of regeneration." -- Edsger Dijkstra -- Rudy Velthuis http://www.rvelthuis.de "One word sums up probably the responsibility of any Governor, and that one word is 'to be prepared'." -- George W. Bush
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2017-06-07 14:00 -0700 |
| Message-ID | <a92624e1-dd1b-41ca-b680-acf4cc94bbe4@googlegroups.com> |
| In reply to | #60444 |
On Wednesday, 7 June 2017 21:26:36 UTC+1, Rudy Velthuis wrote: > Rod Pemberton wrote: > > > On Tue, 6 Jun 2017 07:13:26 -0700 (PDT) > > Raimond Dragomir <raimond.dragomir@gmail.com> wrote: > > > > > Now, I have quite a hard time deciding what kind of scripting > > > language to embed in my industrial automation controller. > > > > BASIC. > > > > It's interpreted. It's easy to learn. > > "It is practically impossible to teach good programming style to > students that have had prior exposure to Basic; as potential > programmers they are mentally mutilated beyond hope of > regeneration." -- Edsger Dijkstra > > -- That was true of BASIC in 1979, but modern Basics are as good as any other language, and a whole world better than Python.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-06-07 15:46 -0700 |
| Message-ID | <69385591-cef7-44ba-9cbe-94b91cd39500@googlegroups.com> |
| In reply to | #60445 |
On Wednesday, June 7, 2017 at 2:00:46 PM UTC-7, Mark Wills wrote: > On Wednesday, 7 June 2017 21:26:36 UTC+1, Rudy Velthuis wrote: > > Rod Pemberton wrote: > > > > > On Tue, 6 Jun 2017 07:13:26 -0700 (PDT) > > > Raimond Dragomir <raimond.dragomir@gmail.com> wrote: > > > > > > > Now, I have quite a hard time deciding what kind of scripting > > > > language to embed in my industrial automation controller. > > > > > > BASIC. > > > > > > It's interpreted. It's easy to learn. > > > > "It is practically impossible to teach good programming style to > > students that have had prior exposure to Basic; as potential > > programmers they are mentally mutilated beyond hope of > > regeneration." -- Edsger Dijkstra > > > > -- > > That was true of BASIC in 1979, but modern Basics are as good as any other > language, and a whole world better than Python. QBASIC was pretty nice, and I would expect something like that to be supported on an ARM fairly easily --- and upgraded to 32-bit.
[toc] | [prev] | [next] | [standalone]
| From | "Rudy Velthuis" <newsgroups@rvelthuis.de> |
|---|---|
| Date | 2017-06-07 23:06 +0000 |
| Message-ID | <xn0kqyxmqb4odku001@nntp.aioe.org> |
| In reply to | #60445 |
Mark Wills wrote: > On Wednesday, 7 June 2017 21:26:36 UTC+1, Rudy Velthuis wrote: > > Rod Pemberton wrote: > > > > > On Tue, 6 Jun 2017 07:13:26 -0700 (PDT) > > > Raimond Dragomir <raimond.dragomir@gmail.com> wrote: > > > > > > > Now, I have quite a hard time deciding what kind of scripting > > > > language to embed in my industrial automation controller. > > > > > > BASIC. > > > > > > It's interpreted. It's easy to learn. > > > > "It is practically impossible to teach good programming style to > > students that have had prior exposure to Basic; as potential > > programmers they are mentally mutilated beyond hope of > > regeneration." -- Edsger Dijkstra > > > > -- > > That was true of BASIC in 1979, but modern Basics are as good as any > other language, and a whole world better than Python. I thoroughly disagree. No modern Basic is better than Python, IMO. Note that I am not a Python fan, but I know enough of it to see it is far more sophisticated and useful than any Basic I know. -- Rudy Velthuis http://www.rvelthuis.de "War is wretched beyond description, and only a fool or a fraud could sentimentalize its cruel reality." -- Senator John McCain
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2017-06-08 01:24 -0700 |
| Message-ID | <10d81f3c-8021-46f3-97c9-a4c7f5246b1e@googlegroups.com> |
| In reply to | #60447 |
On Thursday, 8 June 2017 00:06:06 UTC+1, Rudy Velthuis wrote: > Mark Wills wrote: > > > On Wednesday, 7 June 2017 21:26:36 UTC+1, Rudy Velthuis wrote: > > > Rod Pemberton wrote: > > > > > > > On Tue, 6 Jun 2017 07:13:26 -0700 (PDT) > > > > Raimond Dragomir <raimond.dragomir@gmail.com> wrote: > > > > > > > > > Now, I have quite a hard time deciding what kind of scripting > > > > > language to embed in my industrial automation controller. > > > > > > > > BASIC. > > > > > > > > It's interpreted. It's easy to learn. > > > > > > "It is practically impossible to teach good programming style to > > > students that have had prior exposure to Basic; as potential > > > programmers they are mentally mutilated beyond hope of > > > regeneration." -- Edsger Dijkstra > > > > > > -- > > > > That was true of BASIC in 1979, but modern Basics are as good as any > > other language, and a whole world better than Python. > > I thoroughly disagree. No modern Basic is better than Python, IMO. Note > that I am not a Python fan, but I know enough of it to see it is far > more sophisticated and useful than any Basic I know. > -- > Rudy Velthuis http://www.rvelthuis.de > > "War is wretched beyond description, and only a fool or a fraud > could sentimentalize its cruel reality." > -- Senator John McCain You're entitled to your opinion, of course. You clearly haven't worked with VB.Net though.
[toc] | [prev] | [next] | [standalone]
| From | "Rudy Velthuis" <newsgroups@rvelthuis.de> |
|---|---|
| Date | 2017-06-09 17:27 +0000 |
| Message-ID | <xn0kr155tbcfe6t00g@nntp.aioe.org> |
| In reply to | #60455 |
Mark Wills wrote: > On Thursday, 8 June 2017 00:06:06 UTC+1, Rudy Velthuis wrote: > > Mark Wills wrote: > > > > > On Wednesday, 7 June 2017 21:26:36 UTC+1, Rudy Velthuis wrote: > > > > Rod Pemberton wrote: > > > > > > > > > On Tue, 6 Jun 2017 07:13:26 -0700 (PDT) > > > > > Raimond Dragomir <raimond.dragomir@gmail.com> wrote: > > > > > > > > > > > Now, I have quite a hard time deciding what kind of > > > > > > scripting language to embed in my industrial automation > > > > > > controller. > > > > > > > > > > BASIC. > > > > > > > > > > It's interpreted. It's easy to learn. > > > > > > > > "It is practically impossible to teach good programming style > > > > to students that have had prior exposure to Basic; as > > > > potential programmers they are mentally mutilated beyond hope > > > > of regeneration." -- Edsger Dijkstra > > > > > > > > -- > > > > > > That was true of BASIC in 1979, but modern Basics are as good as > > > any other language, and a whole world better than Python. > > > > I thoroughly disagree. No modern Basic is better than Python, IMO. > > Note that I am not a Python fan, but I know enough of it to see it > > is far more sophisticated and useful than any Basic I know. > > You're entitled to your opinion, of course. You clearly haven't worked > with VB.Net though. I have, but reluctantly. If I'd have to use .NET a lot, I'd be much more comfortable with C#. -- Rudy Velthuis http://www.rvelthuis.de "Military justice is to justice what military music is to music." -- Groucho Marx
[toc] | [prev] | [next] | [standalone]
| From | "Rudy Velthuis" <newsgroups@rvelthuis.de> |
|---|---|
| Date | 2017-06-07 23:08 +0000 |
| Message-ID | <xn0kqyxoqb4rarr002@nntp.aioe.org> |
| In reply to | #60445 |
Mark Wills wrote: > > "It is practically impossible to teach good programming style to > > students that have had prior exposure to Basic; as potential > > programmers they are mentally mutilated beyond hope of > > regeneration." -- Edsger Dijkstra > > That was true of BASIC in 1979, but modern Basics are as good as any > other language, and a whole world better than Python. Also note that I am one of those people who started programming in Basic, especially ZX80 BASIC (for a short while) and then BBC Basic. <g> -- Rudy Velthuis http://www.rvelthuis.de "I find that the harder I work, the more luck I seem to have." -- Thomas Jefferson (1743-1826)
[toc] | [prev] | [next] | [standalone]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2017-06-07 22:26 -0700 |
| Message-ID | <7fb6a060-8759-402f-ae5a-dda44f7ac870@googlegroups.com> |
| In reply to | #60448 |
The target programmers are PC/embedded windows programmers which I know for sure they program right now in Visual Basic, at least as a fast "prototyping" language. Current basic interpreters that I know of are ugly like I said. But I'm sure that if I start with my current scripting forth I can make a pretty decent basic, with no line numbers et. co, something like Visual Basic but much more simpler. Two types, 32bit integer and string. In my current forth I also have only two "types" left, single cell and double cell, double currently supported only for strings (no double arithmetics). And in the case of needing floating point numbers (hardly), I would make the double being also a big integer (needing the D+ D- D* D/). Or just a fixed point type. But I'm not sure... My forth is so easy that I would want to put it to real use... BTW, does anybody know an embeddable scripting basic interpreter to be integer only? Just for a start.
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2017-06-08 01:29 -0700 |
| Message-ID | <58ef3396-e54f-4c83-8886-48bf48ad86bf@googlegroups.com> |
| In reply to | #60453 |
On Thursday, 8 June 2017 06:26:14 UTC+1, Raimond Dragomir wrote: > The target programmers are PC/embedded windows programmers which I know > for sure they program right now in Visual Basic, at least as a fast > "prototyping" language. > > Current basic interpreters that I know of are ugly like I said. > But I'm sure that if I start with my current scripting forth I can > make a pretty decent basic, with no line numbers et. co, something > like Visual Basic but much more simpler. Two types, 32bit integer and > string. In my current forth I also have only two "types" left, > single cell and double cell, double currently supported only for > strings (no double arithmetics). And in the case of needing floating > point numbers (hardly), I would make the double being also a big > integer (needing the D+ D- D* D/). Or just a fixed point type. > > But I'm not sure... My forth is so easy that I would want to put it > to real use... > > BTW, does anybody know an embeddable scripting basic interpreter > to be integer only? Just for a start. Maybe you can just your your own Forth. Supply a raft of functions for the users, pre-written to do the things that they will need to do, and then they just write simple Forth definitions to glue them together. Give them local variables and they will not have to worry about stack juggling. With locals Forth can feel much more like a regular language.
[toc] | [prev] | [next] | [standalone]
| From | Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> |
|---|---|
| Date | 2017-06-08 08:28 -0400 |
| Message-ID | <20170608082828.6d7bdb42@_> |
| In reply to | #60453 |
On Wed, 7 Jun 2017 22:26:12 -0700 (PDT) Raimond Dragomir <raimond.dragomir@gmail.com> wrote: > The target programmers are PC/embedded windows programmers which I > know for sure they program right now in Visual Basic, at least as a > fast "prototyping" language. > > Current basic interpreters that I know of are ugly like I said. > But I'm sure that if I start with my current scripting forth I can > make a pretty decent basic, with no line numbers et. If you're using BASIC to control a machine, then you want a line numbered BASIC. BASIC is just being used as a way to implement control-flow, printing, variables, input, and saving the non-BASIC commands to file (together with the BASIC code). A line-numbered BASIC allows you to easily edit a single line of the non-BASIC code use for machine control. You just type in the new line with line number. BASIC only needs a single line editor, in this situation, instead of a TUI or full-screen text-editor. The non-BASIC code will usually start with an escape character, such as '$', right after the line number. The non-BASIC code is custom to the machine. Rod Pemberton -- The Paris Agreement is irrelevant. A carbon tax is futile. The only solution is technology. Please tell Elon Musk that he is not being a technology visionary.
[toc] | [prev] | [next] | [standalone]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2017-06-08 08:02 -0700 |
| Message-ID | <386d0390-2325-45a5-b258-efb81b6c5172@googlegroups.com> |
| In reply to | #60468 |
> If you're using BASIC to control a machine, then you want a line > numbered BASIC. BASIC is just being used as a way to implement Really? I'd rather use forth blocks or sort of. For example, I'm using an 8MB serial flash memory which has 4K uniform sectors. So, I can have 4K blocks (not 1K). And the simplest editor can be a 16x64 traditional 1K screen with four screens per block. Just an ideea.
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2017-06-08 01:26 -0700 |
| Message-ID | <10c990dc-ff00-45ad-bc81-59658f1aa615@googlegroups.com> |
| In reply to | #60448 |
On Thursday, 8 June 2017 00:08:22 UTC+1, Rudy Velthuis wrote: > Mark Wills wrote: > > > > "It is practically impossible to teach good programming style to > > > students that have had prior exposure to Basic; as potential > > > programmers they are mentally mutilated beyond hope of > > > regeneration." -- Edsger Dijkstra > > > > That was true of BASIC in 1979, but modern Basics are as good as any > > other language, and a whole world better than Python. > > Also note that I am one of those people who started programming in > Basic, especially ZX80 BASIC (for a short while) and then BBC Basic. <g> > > -- > Rudy Velthuis http://www.rvelthuis.de > > "I find that the harder I work, the more luck I seem to have." > -- Thomas Jefferson (1743-1826) Which (with respect) explains (to me) your current thinking re Basic. Vb.Net is very very good. It's a fully object oriented language that targets the Microsoft CLR (Common Language Runtime).
[toc] | [prev] | [next] | [standalone]
Page 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7 Next page →
Back to top | Article view | comp.lang.forth
csiph-web