It is a very powerful language, but it is very difficult to get a good grasp on it, and finding those server errors can often be quite frustrating, especiallly if it is a very large script.
One typo can lead to hours of hair pulling EDIT: If you are using Notepad
That's true with ALL programming languages. While I agree that the hashes of arrays of hashes thing is at best very ugly and convoluted and needs to be rethought. On the positive side the data::dumper is incredibly useful and I find myself using it for all but very trivial programs. The built in debugger is also nice. I do find that PERL will usually take a good guess at what you meant based on the context of what you're doing. Very useful in a non-teaching language!
Okay.... I knew I was stepping out on a limb with my comment and Dave presented some interesting and honest points.
So I will go a step further and say that programmers are bound by the bounds of the programming language itself, availability of documentation, and availability of programming examples. C and C++ are by far the most powerful languages available, with the most abundant availabilty of documentation and programming examples, however, PERL may be close in terms of power, but I doubt it. And BASIC is certainly up there.
In your instance, FORTH and Tachyon may be sufficient for you, for what you want to do. As Dave pointed out, one of the key aspects of my comment was the porting of existing code. I have used this example in the forum several times in the last week or two, so please forgive me for being redundant. I needed source code for a TI ADS1015 12-bit 4 channel ADC. I found the source code, ported it to Prop-GCC, and had it in full working order within 11 hours. Here is a list of the functions available from this source code:
With any other language available at our disposal, I challenge anyone to create ADS1015 source code that can match that level of functionality in 11 hours.
And furthermore, that does not even include additional source that was added to the original files, such as:
EDIT: However, this additional code, added to the development time significantly.
// The number of value pairs in the table.
#define TABLE_SIZE 53
//
// This is a table of ADC readings and corresponding temperature values for both the
// extruder and heated build platform. In determining the thermistor resistance values,
// data was extracted from the EPCOS B57560G1104F000 datasheet, because that is the
// thermistor being utilized for both the extruder and heated build platform.
//
// During the calculations of this table, a resistor having a nominal value of 4.7K,
// with a 10% tolerance was utilized, however the calculations were performed and based
// upon the actual resistance, which was 4,602 Ohms.
LOOKUPTEMP lookup_temp[TABLE_SIZE] = {
{.sample = 1591, .temp = 20},
{.sample = 1577, .temp = 25},
{.sample = 1560, .temp = 30},
{.sample = 1540, .temp = 35},
{.sample = 1517, .temp = 40},
{.sample = 1490, .temp = 45},
{.sample = 1459, .temp = 50},
{.sample = 1424, .temp = 55},
{.sample = 1386, .temp = 60},
{.sample = 1343, .temp = 65},
{.sample = 1296, .temp = 70},
{.sample = 1245, .temp = 75},
{.sample = 1191, .temp = 80},
{.sample = 1135, .temp = 85},
{.sample = 1076, .temp = 90},
{.sample = 1016, .temp = 95},
{.sample = 956, .temp = 100},
{.sample = 895, .temp = 105},
{.sample = 835, .temp = 110},
{.sample = 776, .temp = 115},
{.sample = 719, .temp = 120},
{.sample = 665, .temp = 125},
{.sample = 612, .temp = 130},
{.sample = 563, .temp = 135},
{.sample = 517, .temp = 140},
{.sample = 474, .temp = 145},
{.sample = 434, .temp = 150},
{.sample = 397, .temp = 155},
{.sample = 362, .temp = 160},
{.sample = 331, .temp = 165},
{.sample = 302, .temp = 170},
{.sample = 276, .temp = 175},
{.sample = 252, .temp = 180},
{.sample = 231, .temp = 185},
{.sample = 211, .temp = 190},
{.sample = 193, .temp = 195},
{.sample = 177, .temp = 200},
{.sample = 162, .temp = 205},
{.sample = 149, .temp = 210},
{.sample = 136, .temp = 215},
{.sample = 125, .temp = 220},
{.sample = 115, .temp = 225},
{.sample = 106, .temp = 230},
{.sample = 98, .temp = 235},
{.sample = 90, .temp = 240},
{.sample = 83, .temp = 245},
{.sample = 77, .temp = 250},
{.sample = 71, .temp = 255},
{.sample = 66, .temp = 260},
{.sample = 61, .temp = 265},
{.sample = 57, .temp = 270},
{.sample = 53, .temp = 275},
{.sample = 49, .temp = 280},
};
double extruder_celsius;
double bed_celsius;
void UpdateTemp(uint8_t channel)
{
double samples[NUMSAMPLES];
uint8_t i;
double average;
// take N samples in a row, with a slight delay
for (i = 0; i < NUMSAMPLES; i++)
{
// read channel the specified channel
samples[i] = readADC_SingleEnded(channel);
pause(10);
}
// average all the samples out
average = 0;
for(i = 0; i < NUMSAMPLES; i++)
{
average += samples[i];
}
average /= NUMSAMPLES;
if(channel == 0)
{
extruder_celsius = lookupTemp(lookup_temp, average);
}
if(channel == 1)
{
bed_celsius = lookupTemp(lookup_temp, average);
}
}
/**************************************************************************/
/*!
@brief Given an ADC sample average, lookup the appropriate temperature.
*/
/**************************************************************************/
double lookupTemp(const LOOKUPTEMP *table, double sample)
{
int index;
index = 0;
// find the two points in the table to use
while(index < TABLE_SIZE && sample < table[index].sample)
{
index++;
}
// make sure the point isn't past the end of the table
if( index == TABLE_SIZE)
{
return table[index - 1].temp;
}
// make sure the point isn't before the beginning of the table
if(index == 0)
{
return table[index].temp;
}
return table[index].temp;
}
With any other language available at our disposal, I challenge anyone to create ADS1015 source code that can match that level of functionality in 11 hours.
You're setting yourself up for getting torn down with this quote. In another thread, you mentioned that not all 11 hours were spent programming. You should figure out how many hours you actually spent working on it and then rephrase your challenge.
You're setting yourself up for getting torn down with this quote. In another thread, you mentioned that not all 11 hours were spent programming. You should figure out how many hours you actually spent working on it and then rephrase your challenge.
Your right and it is true.... Someone may prove me wrong and be able to do it in 11 hours or less.... But in this case I will have to be a doubting Thomas....
A little more information about the Teacup 3D printer code that Bruce is working with. It contains a little more than 7000 lines of C code. I was able to build the simulator mode and get it running under Linux in less than a half hour. I never tried running it on the Prop with PropGCC, but it will clearly not fit in the hub and will require the XMMC model to run. To me this is clearly a case where it's easier to port the C code than to try to convert it to Spin, Forth, PropBASIC or any of the other languages available on the Prop. Of all the languages on the Prop only ANSI Forth and C have a chance of being ported without major changes, and there is more C code out there than there is Forth by several orders of magnitude.
I would like to see someone try to port the Teacup code to their favorite non-C language. I'm telling you right now, it's impossible.
A little more information about the Teacup 3D printer code that Bruce is working with. It contains a little more than 7000 lines of C code. I was able to build the simulator mode and get it running under Linux in less than a half hour. I never tried running it on the Prop with PropGCC, but it will clearly not fit in the hub and will require the XMMC model to run. To me this is clearly a case where it's easier to port the C code than to try to convert it to Spin, Forth, PropBASIC or any of the other languages available on the Prop. Of all the languages on the Prop only ANSI Forth and C have a chance of being ported without major changes, and there is more C code out there than there is Forth by several orders of magnitude.
I would like to see someone try to port the Teacup code to their favorite non-C language. I'm telling you right now, it's impossible.
Why port teacup when a 15 year old can utilize a forth engine and come up with brand new technology for 3d printing, that was a FORTH engine in case you missed it, Just like what minecraft uses, every see the command console in minecraft?
Why port teacup when a 15 year old can utilize a forth engine and come up with brand new technology for 3d printing, that was a FORTH engine in case you missed it, Just like what minecraft uses, every see the command console in minecraft?
dp
Good to see someone getting away from archaic G-codes as well. I wonder if they have also dumped the steppers and closed the position loops on servo motors.
D.P., since you quoted my post I feel compelled to answer your questions. I didn't see any reference to Forth in the article, but I'll take your word that the 15 year old did it in Forth. Is his code open source? I didn't see any link to source code. If it's not open source it wouldn't make any sense to try to port it to the Prop.
Minecraft looks pretty cool. I'm always impressed by people that can do amazing things in Forth like the writer of Minecraft and Peter's Tachyon. I would never have the patience to code something that complex in Forth.
-q || --quiet show less output
-v || --verbose show more output
-g || --gcode show gcode on console as it is processed
-p || --pos show head position on console
-t || --time-scale=n set time-scale; 0=warp-speed, 1=real-time, 2=half-time, etc.
-o || --tracefile[=filename] write simulator pin trace to 'outfile' (default filename=datalog.out)
Or point your browser at sim.html to see it run in a web page.
We don't have that Espruino JS engine built for the Prop yet. It should be workable if we can add a megabyte of RAM to the Prop. Slow as molasses of course.
I don't think there is a device that runs Espruino that has space for 670K of JS + the required RAM to run it in.
I moved from the BS2 to the Propeller about a year ago and Spin made the transition a lot easier.
I never found C as easy to learn as BASIC or Pascal and from what I understand C was designed for making Operating Systems but now it's used for just about everything.
I finally dug out my C notes and textbook and it still looks like greek to me but the world loves C.
I might try Espruino on the Pi for fun but it's a bit pointless when node.js runs on there just fine.
More likely candidates would be smaller ARM systems that run can run OpenWRT, mostly routers, but then we don't have the I/O it needs.
I have an STMF4 Discovery board here somewhere that runs Espruino, 1 MB Flash, 192 KB RAM. I don't recall if we can get that JS source into FLASH without loading it to RAM first. Most likely not enough space anyway.
Edit: Occurs to me that for extra weirdness, nothing to do with Teacup, I need to compile the Espruino JS engine into JS and run that under node.js. And then run some JS on that:)
Why port teacup when a 15 year old can utilize a forth engine and come up with brand new technology for 3d printing, that was a FORTH engine in case you missed it, Just like what minecraft uses, every see the command console in minecraft?
D.P., since you quoted my post I feel compelled to answer your questions. I didn't see any reference to Forth in the article, but I'll take your word that the 15 year old did it in Forth. Is his code open source? I didn't see any link to source code. If it's not open source it wouldn't make any sense to try to port it to the Prop.
Open source? I don't think so!!!! Video distinctly says patent pending technology
I moved from the BS2 to the Propeller about a year ago and Spin made the transition a lot easier.
I never found C as easy to learn as BASIC or Pascal and from what I understand C was designed for making Operating Systems but now it's used for just about everything.
I finally dug out my C notes and textbook and it still looks like greek to me but the world loves C.
If I can get one SPIN convert out of this thread, then it has served it's purpose
While I don't disagree with that, I think the work ethic sort of thing taught/expected in education has been drastically dumbed down. At least this side of the pond.
In reality, starting with Assembler would be a logical start, the problem is that all the adults in charge would invariably say that there is no instant gratification to reward kids with and that they'd loose their interest.
Unfortunately, with most school kids having an internet at their fingers 24x7, with games, IM, snapchat, facebook, the adults are right.
For that subset of children that might be interested in learning, I think learning flow-charting is actually productive exercise/skill that can also be applied outside the CS domain and help throughout their life.
I think Goto/Gosub is sort of required in a BASIC type of language, because are like novice chess (checkers?) players, and only looking 1-2 moves ahead.
They are programming with a short horizon, and at some point they need to test with some if-then statements. At that point, how are they going to programmatically choose between 2 paths of execution?
If x=1 goto 100, if x=2 goto 200 is a very easy way for them to be able to have multipath, without forcing them to really master some structured programming paradigm.
And I think thats a primary point that so many enthusiast and professional programmers overlook in their automatic dismissal of BASIC.
BASIC was designed for ease of use first, not elegant expressive coding.
Wiki is worth reading just for the first paragraph:
"BASIC (an acronym for Beginner's All-purpose Symbolic Instruction Code) is a family of general-purpose, high-level programming languages whose design philosophy emphasizes ease of use.
In 1964, John G. Kemeny and Thomas E. Kurtz designed the original BASIC language at Dartmouth College in New Hampshire.
They wanted to enable students in fields other than science and mathematics to use computers.
At the time, nearly all use of computers required writing custom software, which was something only scientists and mathematicians tended to learn."
I don't know about that GOTO thing. My feeling is that if you want to teach "goto style" programming, with flow charts and all, you're better off doing it in assembler. In fact when we were teenagers exposed to programming for the first time after a quick intro with BASIC we were expected to be proficient in assembler at the end of the year as well. Soon after that I started to think that BASIC was a waste of our time, very restricting, we could have been using a real language already instead.
Me too! Its the only way I am going to be productive with the prop
@ Mickster
DOS and a wonderful programming language called QuickBASIC enabled....
...me to convert a cement batching plant system based on a BBC Micro (going obsolete and becoming unreliable), to a PC based system on a 4 inch square SOC board with flash memory for disc drive, monitoring and controlling six aggregate hoppers and two cement hoppers, strain gauges, relays and user interface with cement proof keypad etc. - no goto's or line numbers.
The BBC Basic and the Qbasic were very similar and then very different. BBC had line numbers and crude editor, but what a revelation with Qbasic - a text editor and NO line numbers - bliss. This is now replaced by FreeBasic and FreeDos- Hi res graphics and oodles of memory, and modern IDE.
@ Mickster
I really, really, really believe that a refined PropBASIC would be a huge success for the Prop. I for one would pay $$$ for such a thing.
Dollars! I'd pay Pounds....
Dave
Love it! In my book that is an embedded control system and as far as FreeBasic goes it is OS portable Windoze, DOS, Linux, BSD. I loved working in DOS using QB + MASM and I find myself doing similar things with the Prop such as optimizing for speed whilst minimizing memory consumption.
My very first project was scary and funny. My boss at the time (machine-tool sales company) sold a totally unsuitable piece of equipment to a tier-one supplier to GM ($600,000). It flat could never work for several reasons. Three controls engineers were trying their best but every code modification required a compile/link/download that took so long that it was painful. GM were about to take us to the cleaners so after a few G&Ts one night, I persuaded my boss to let me try a new approach. The controller was some multi-68008 processor, VME-Bus monstrosity that I proceeded to tear out. Imagine the horror on the other guys' faces when I slapped an office grade IBM PC in there...LOL! I was 26 at the time and what little credibility I had with GM just went out the window. Long story short, the equipment was soon doing what it was supposed to, courtesy of Mr. Gates' threaded p-code interpreter.
QuickBASIC, VB, it's all the same to me. Spend a long time writing an application in that, then, perhaps years later, try and run it somewhere else. Oops does not work. Start again. I have been bitten by and seen companies bitten by this phenomena may times over the years. Enter the charms of C and such like languages. Programs I wrote ten or twenty years ago are still in use. Usually running on very different machines and with different operating systems than the original roll out. Others have taken them over and extended them.
Ahh, I think theres been a flag thrown down the field on that.
C is able to do that because it was used to implement(re-implement?) Unix. Ipso facto, it was available across a very wide range of machines.
BASIC was dreamed up at Dartmouth as a teaching aid, and as such never had anywhere near the depth/breadth of opportunity that C had.
I'm counting that as a non-scoring point for you Heater.
On the other hand, the vast number and variety of BASIC dialects shows the massive amount of general interest in it, which should be worth a half-point.
I finally decided to post on this thread. I fit the mold of Bruce's "reluctant target" in the first post, see this post, but I did recently start looking at the tutorials on the Learn site, specifically for a few items that I use frequently in SPIN. I figure if I can correlate the two from a functionality standpoint, I could learn faster. Alas, as soon as I started the endeavor, I acquired a system administrator role for a software migration about to start. My time to allocate to C just got wiped out, but I plan to keep dabbling on the Learn site any chance I get.
re: D.P., since you quoted my post I feel compelled to answer your questions. I didn't see any reference to Forth in the article, but I'll take your word that the 15 year old did it in Forth. Is his code open source? I didn't see any link to source code. If it's not open source it wouldn't make any sense to try to port it to the Prop.
Yes, it's open source
Also, you can see a screen shot of his code with the URL below. (321 lines of code reduced to 24 lines of code)
"To control the printer CarrotCorp have also re-designed the building blocks of G-code in order to develop the unique language of codes, which is intended to be human-readable. To provide an example of such a code CarrotCorp developed a 24-line Orb Print Code instead of the 321-line G-code. The new code allows 3D printing the same object."
So the phrase "patent pending technology" refers to the printer itself, instead of the software? I am assuming yes, since you are saying it is open source.
"Furthermore, the entire system will be modular and open source, so that there is an individual module to handle the extrusion and the disc rotation, allowing anyone to create personalized modules to fit their own specific requirements."
Comments
Erlend
That's true with ALL programming languages. While I agree that the hashes of arrays of hashes thing is at best very ugly and convoluted and needs to be rethought. On the positive side the data::dumper is incredibly useful and I find myself using it for all but very trivial programs. The built in debugger is also nice. I do find that PERL will usually take a good guess at what you meant based on the context of what you're doing. Very useful in a non-teaching language!
Okay.... I knew I was stepping out on a limb with my comment and Dave presented some interesting and honest points.
So I will go a step further and say that programmers are bound by the bounds of the programming language itself, availability of documentation, and availability of programming examples. C and C++ are by far the most powerful languages available, with the most abundant availabilty of documentation and programming examples, however, PERL may be close in terms of power, but I doubt it. And BASIC is certainly up there.
In your instance, FORTH and Tachyon may be sufficient for you, for what you want to do. As Dave pointed out, one of the key aspects of my comment was the porting of existing code. I have used this example in the forum several times in the last week or two, so please forgive me for being redundant. I needed source code for a TI ADS1015 12-bit 4 channel ADC. I found the source code, ported it to Prop-GCC, and had it in full working order within 11 hours. Here is a list of the functions available from this source code:
With any other language available at our disposal, I challenge anyone to create ADS1015 source code that can match that level of functionality in 11 hours.
EDIT: However, this additional code, added to the development time significantly.
You're setting yourself up for getting torn down with this quote. In another thread, you mentioned that not all 11 hours were spent programming. You should figure out how many hours you actually spent working on it and then rephrase your challenge.
Your right and it is true.... Someone may prove me wrong and be able to do it in 11 hours or less.... But in this case I will have to be a doubting Thomas....
I would like to see someone try to port the Teacup code to their favorite non-C language. I'm telling you right now, it's impossible.
Why port teacup when a 15 year old can utilize a forth engine and come up with brand new technology for 3d printing, that was a FORTH engine in case you missed it, Just like what minecraft uses, every see the command console in minecraft?
https://www.freedomsphoenix.com/News/170378-2015-01-31-15-year-old-unveils-orb-3d-printer-new-print-code.htm
dp
Good to see someone getting away from archaic G-codes as well. I wonder if they have also dumped the steppers and closed the position loops on servo motors.
Minecraft looks pretty cool. I'm always impressed by people that can do amazing things in Forth like the writer of Minecraft and Peter's Tachyon. I would never have the patience to code something that complex in Forth.
...wait a minute...
...here it is in JavaScript, see attached package.
You can see Teacups main() start at line 7070 in sim.js.
Only took me half an hour
Run like so: Or point your browser at sim.html to see it run in a web page.
I have no idea what to do with it after that.
We don't have that Espruino JS engine built for the Prop yet. It should be workable if we can add a megabyte of RAM to the Prop. Slow as molasses of course.
I don't think there is a device that runs Espruino that has space for 670K of JS + the required RAM to run it in.
I never found C as easy to learn as BASIC or Pascal and from what I understand C was designed for making Operating Systems but now it's used for just about everything.
I finally dug out my C notes and textbook and it still looks like greek to me but the world loves C.
I might try Espruino on the Pi for fun but it's a bit pointless when node.js runs on there just fine.
More likely candidates would be smaller ARM systems that run can run OpenWRT, mostly routers, but then we don't have the I/O it needs.
I have an STMF4 Discovery board here somewhere that runs Espruino, 1 MB Flash, 192 KB RAM. I don't recall if we can get that JS source into FLASH without loading it to RAM first. Most likely not enough space anyway.
Edit: Occurs to me that for extra weirdness, nothing to do with Teacup, I need to compile the Espruino JS engine into JS and run that under node.js. And then run some JS on that:)
The exact same thought process I just went through...I know I just saw it!
Open source? I don't think so!!!! Video distinctly says patent pending technology
If I can get one SPIN convert out of this thread, then it has served it's purpose
While I don't disagree with that, I think the work ethic sort of thing taught/expected in education has been drastically dumbed down. At least this side of the pond.
In reality, starting with Assembler would be a logical start, the problem is that all the adults in charge would invariably say that there is no instant gratification to reward kids with and that they'd loose their interest.
Unfortunately, with most school kids having an internet at their fingers 24x7, with games, IM, snapchat, facebook, the adults are right.
For that subset of children that might be interested in learning, I think learning flow-charting is actually productive exercise/skill that can also be applied outside the CS domain and help throughout their life.
I think Goto/Gosub is sort of required in a BASIC type of language, because are like novice chess (checkers?) players, and only looking 1-2 moves ahead.
They are programming with a short horizon, and at some point they need to test with some if-then statements. At that point, how are they going to programmatically choose between 2 paths of execution?
If x=1 goto 100, if x=2 goto 200 is a very easy way for them to be able to have multipath, without forcing them to really master some structured programming paradigm.
And I think thats a primary point that so many enthusiast and professional programmers overlook in their automatic dismissal of BASIC.
BASIC was designed for ease of use first, not elegant expressive coding.
Wiki is worth reading just for the first paragraph:
"BASIC (an acronym for Beginner's All-purpose Symbolic Instruction Code) is a family of general-purpose, high-level programming languages whose design philosophy emphasizes ease of use.
In 1964, John G. Kemeny and Thomas E. Kurtz designed the original BASIC language at Dartmouth College in New Hampshire.
They wanted to enable students in fields other than science and mathematics to use computers.
At the time, nearly all use of computers required writing custom software, which was something only scientists and mathematicians tended to learn."
Love it! In my book that is an embedded control system and as far as FreeBasic goes it is OS portable Windoze, DOS, Linux, BSD. I loved working in DOS using QB + MASM and I find myself doing similar things with the Prop such as optimizing for speed whilst minimizing memory consumption.
My very first project was scary and funny. My boss at the time (machine-tool sales company) sold a totally unsuitable piece of equipment to a tier-one supplier to GM ($600,000). It flat could never work for several reasons. Three controls engineers were trying their best but every code modification required a compile/link/download that took so long that it was painful. GM were about to take us to the cleaners so after a few G&Ts one night, I persuaded my boss to let me try a new approach. The controller was some multi-68008 processor, VME-Bus monstrosity that I proceeded to tear out. Imagine the horror on the other guys' faces when I slapped an office grade IBM PC in there...LOL! I was 26 at the time and what little credibility I had with GM just went out the window. Long story short, the equipment was soon doing what it was supposed to, courtesy of Mr. Gates' threaded p-code interpreter.
Ahh, I think theres been a flag thrown down the field on that.
C is able to do that because it was used to implement(re-implement?) Unix. Ipso facto, it was available across a very wide range of machines.
BASIC was dreamed up at Dartmouth as a teaching aid, and as such never had anywhere near the depth/breadth of opportunity that C had.
I'm counting that as a non-scoring point for you Heater.
On the other hand, the vast number and variety of BASIC dialects shows the massive amount of general interest in it, which should be worth a half-point.
re: D.P., since you quoted my post I feel compelled to answer your questions. I didn't see any reference to Forth in the article, but I'll take your word that the 15 year old did it in Forth. Is his code open source? I didn't see any link to source code. If it's not open source it wouldn't make any sense to try to port it to the Prop.
Yes, it's open source
Also, you can see a screen shot of his code with the URL below. (321 lines of code reduced to 24 lines of code)
"To control the printer CarrotCorp have also re-designed the building blocks of G-code in order to develop the unique language of codes, which is intended to be human-readable. To provide an example of such a code CarrotCorp developed a 24-line Orb Print Code instead of the 321-line G-code. The new code allows 3D printing the same object."
http://3dprintingfromscratch.com/2015/01/thomas-suarez-set-to-release-10x-faster-modular-3d-printer-this-year/
Seems as if he's a SPIN programmer as well " spin 100 " LOL
So the phrase "patent pending technology" refers to the printer itself, instead of the software? I am assuming yes, since you are saying it is open source.
re:since you are saying it is open source.
"Furthermore, the entire system will be modular and open source, so that there is an individual module to handle the extrusion and the disc rotation, allowing anyone to create personalized modules to fit their own specific requirements."
Comment taken from here:
http://3dprintingindustry.com/2015/01/13/teen-takes-3d-printing-into-orbit-with-new-orb-technology/
http://orbprinter.com/index.html
Here's a better screen shot of the code
http://orbprinter.com/printcodes.html
I believe that is a highly deceiving.
Why? It's nothing new. Galil's (www.galil.com) scripting language has been doing this for almost 30 years now.