interpreted scripting language

S

Thread Starter

Stowe, Nathan

I would like to put in my $.02 against using an interpreted language. I have limited experience with SCADA systems, but the one thing that I have found is that using an interpreted language makes it more possible for errors to become prevalent at inopportune times. Yea I know, test, test, test - but....

Nathan Stowe
Systems Engineer
A Finkl & Sons
2011 North Southport
Chicago, IL 60614-4079

[email protected]
http://www.finkl.com

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
B
You have a great point. A compiler will scan your complete program for syntax errors and report them at compile time. An interpreter will
generally only test code when it executes. I have been burned in VB by a line of code that I never tested which caused the program to abort. For some reason, this happens most often right after you leave for the day :(

Some interpreters do have syntax checking programs. I have never tried them, I assume that they help. VB has an option to test all code at the beginning of runtime, I recommend checking that option.

Bill


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
K
Perl (for one) does compile the source, so will catch syntax errors, but valid code can still have bugs and application errors. I'm not
convinced that compiled code is intrinsically any less prone to bugs and errors than interpreted.

Some programming styles can help prevent hidden bugs, e.g,. by ensuring that (nearly) all code is processed on each pass. This tends to rule out
conditional jumps, and increases the amount of code to run, but sometimes it's worth it. This can apply regardless of whether the language is
compiled or interpreted.

Just another $.02.

--
Ken Irving <[email protected]>


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
J

Jocelyn Boily

One of the main advantages of PLC languages is that you can change the program while it is running.

It happen to me very often to maintain the codes of robots on machine that can not be stopped for monetary reasons (production lines, ... ) and had to change the program "On-Line". This is done very easily with PLC like Allen Bradley, GEFanuc and others.

I would hate to see Our LinuxPLC to shy away from this feature. Interpretative languages would allows to do this quite easily, but would it
be possible with a compiling language?

jb


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
> You have a great point. A compiler will scan your complete program for
> syntax errors and report them at compile time. An interpreter will
> generally only test code when it executes. I have been burned in VB by a
> line of code that I never tested which caused the program to abort. For
> some reason, this happens most often right after you leave for the day :(

Python "compiles" from .py to .pyc, and catches errors very nicely. It does it on the fly if there's no pre-generated .pyc files handy. It
also has syntax checking tools. I typically make a lot fewer errors (and far less serious ones) in Python than in most other languages, compiled or otherwise.

I think it's worth considering. Of course, if you go with some standard way of exchanging data on the backend and the SCADA is totally separate, it won't much matter what's used. I'd like to play
with a python front end if it goes that way, but I'm not a SCADA expert by any devious twist of the imagination.

Tim

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
G

Greg Goodman

> I would like to put in my $.02 against using an interpreted language. I have limited experience with SCADA systems, but the one thing that I have found is that using an interpreted language makes it more possible for errors to become prevalent at inopportune times.

here's my 2 cents.

i have a lot of experience with SCADA systems, and i know that all sorts of errors make themselves known at inopportune times. in fact, any error that doesn't get caught during design, code or lab test is going to be inopportune when it does show up. and compiled code demonstrates this just as readily as does interpreted code.

compiled code can suffer from memory leaks, buffer overflows, crashes due to unexpected values or characters in the data stream, read/write failures that produce garbage data because the coder didn't check the error returns... lots of stuff that doesn't show up even in rigorous testing, because it's dependent on system load, or the operating environment, or a real-life data stream with gunk in it that nobody knew about or thought to test for.

i write a lot of interpreted code, and pretty much every line gets tested to some degree; every routine has a unit tester that exercises all of the cases that i coded for... and (for obvious reasons) nothing that i didn't think to handle. that verifies that the code works the way i think it should (which isn't necessarily the way it *should* work) and catches the syntax errors that aren't the result of building variable names on the fly.

it's worth noting that all data or event processor code is subject to the behavior of the data/event stream which, in the automation world, is often (usually?) different from the test data streams we handle in the lab. even a correct program operating beyond its limits will fail, which is as likely to be the fault of the programmer making assumptions as it is of the user abusing the program.
 
Top