Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

chromatic (983)

chromatic
  (email not shown publicly)
http://wgz.org/chromatic/
Blog Information [technorati.com] Profile for chr0matic [technorati.com]

Journal of chromatic (983)

Friday February 29, 2008
08:59 PM

The Difference Between a Program and a Script

[ #35804 ]

The difference between a program and a script isn't as subtle as most people think. A script is interpreted, and a program is compiled.

Of course, there's no reason you can't write a compiler that immediately executes the compiled form of a program without writing compilation artifacts to disk, but that's an implementation detail, and precision in technical matters is important.

Though Perl 5, for example, doesn't write out the artifacts of compilation to disk and Java and .Net do, Perl 5 is clearly an interpreter even though it evaluates the compiled form of code in the same way that the JVM and the CLR do. Why? Because it's a scripting language.

Okay, that's a facetious explanation.

The difference between a program and a script is if there's native compilation available in at least one widely-used implementation. Thus Java before the prevalence of even the HotSpot JVM and its JIT was a scripting language and now it's a programming language, except that you can write a C interpreter that doesn't have a JIT and C programs become scripts.

Hm.

Of course, if someone were to write an extra optimizer step for Perl 5 to evaluate certain parts of the optree and generate native code in memory on certain platforms without writing it out to disk (uh oh...) and then execute that code under certain conditions, all Perl 5 scripts would automatically turn into programs.

You know, like .pmc files, or Python's .pyc files. Uh.

As well, if more people use Punie (Perl 1 on Parrot) this year than native Perl 1 -- a possibility -- then Perl 1 scripts automatically become Perl 1 programs because Punie can use Parrot's JIT. I don't know if this powerful upgrade from script to program is retroactive, but I see no reason why not.

Perl 5 scripts were briefly programs while Ponie was viable, but the removal of the code from the Parrot tree has now downgraded them back to scripts. We apologize for the inconvenience.

To summarize, if you have a separate compilation step visible to developers, you have programs. If not, you have scripts. An exception is that if you have a separate, partial compilation step at runtime and not visible to users, then you may have programs. The presence of one implementation that performs additional compilationy thingies at runtime instantly upgrades all scripts to programs, while the presence of an interpreter for a language in which people normally write programs, not scripts, does not downgrade programs to scripts. Program-ness is sticky.

I hope this is now clear.

Ironically some JavaScript implementations have JITs, so the colloquial name of the language should change from JavaScript to JavaProgram.

Script bad, four-legs good.


List all Journal entries
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

The Difference Between a Program and a Script 10 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • While I don't think the script/program distinction is useful (uh, duh?), I think there is a useful distinction between 'compiled' or perhaps 'compilable' languages and 'interpreted' ones. A compilable language is one which can be translated into a form that doesn't depend on the compiler; or, an interpreted language is one with 'eval'. Perl is an interpreted language by this definition: this is one of the reasons why PAR is a much more successful way of turning a Perl program into an executable than B::C ev

    • A compilable language is one which can be translated into a form that doesn't depend on the compiler; or, an interpreted language is one with 'eval'.

      The first half of that may be true. It may not be; consider a self-hosted language. The latter half is likely not true, as I can write eval for C in C if I can make system calls, open shared libraries, and call functions from shared libraries.

      "Compiled" and "interpreted" are characteristics of execution models and are rarely intrinsic to the language.

      • The first half of that may be true. It may not be; consider a self-hosted language.

        I was proposing it as a definition, not a statement of fact :). The only thing that might not be true is that the two halves are equivalent; obviously, they aren't: the latter implies the former but not vice versa. Still, a language that required its compiler to run but didn't provide 'eval' would be rather odd, and probably could be implemented better, so I don't think that matters.

        I'm not sure what you mean by a 'self-hos

        • ... you can't without effectively writing a C compiler...

          I can write system( "/usr/bin/gcc -o mynew.so mynew.c" );. The same thing is possible in a Perl without eval. Neither of us said that portability affected the definition.

          Maybe 'compiled' and 'interpreted' aren't quite the words I'm looking for.

          As long as our general purpose computing devices use the Von Neumann architecture, any operation that allows you to modify the contents of memory as the program runs makes it possible to allow eval or

          • I can write system( "/usr/bin/gcc -o mynew.so mynew.c" );.

            ...at which point your program requires a compiler to run, and is written (by my definitions) in an interpreted language ('C-plus-the-assumption-that-/usr/bin/gcc-is-a-compiler'). I think that if you wrote any sizeable amount of code making use of that construction, or any other like it, you would find you were using a rather more powerful language than C.

            • ... at which point your program requires a compiler to run, and is written (by my definitions) in an interpreted language...

              Thus question of whether a language is compiled or interpreted depends on the specific program or script. Suppose instead of invoking an external compiler I used the JIT to generate new code instead of speeding up existing code. If the language itself does not provide eval and I don't invoke an external compiler through a system call, does the language suddenly become interpreted

              • This is why I think that declaring a language as interpreted or compiled is silly.
                Perhaps a more useful analysis would be how much or how often a particular language is generally used in an "interpreted" or a "compiled" mode of operation? Then it becomes a matter of choosing the appropriate metric and using some basic stats. I don't know if it would be very useful in absolute terms, but it would probably be more useful, at least.
  • I think we all know how I stand on this one. :-)

    http://xoa.petdance.com/stop_saying_script [petdance.com] if you don't.

    --

    --
    xoa

  • A scripting language, script language or extension language, is a programming language that controls a software application. "Scripts" are often treated as distinct from "programs", which execute independently from any other application.


    http://en.wikipedia.org/wiki/Scripting_language [wikipedia.org]

    • For that to work, you have to examine the purpose of a specific piece of code. That seems reasonable.

Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.