How does a "script" differ from a "program" or "subroutine"?

[tdi]

Ok, stupid question for the day. I'm reading the interview with Steve
Moret and he says: "Once a lot of scripts started going in we knew
there was no way we could back out of using Python."

I'm just getting into Python and am wondering if I'm missing something
or this is just a semantic issue.

Thanks.
-Ted

 

[Phil Frost]

A subroutine is another name for "procedure", "function", or "method".
They are made like this:

def fu():
...

A program can contain any number of subroutines, along with classes,
variables, etc.

A script is just a program, but has the implication that it's a simple
program for a simple task.

 

[Porky Pig Jr]

A script is just a program, but has the implication that it's a simple
program for a simple task.

I think the major implication is not that it's simple but it's written
in some 'interpreted' (rather than compiled) language. so we say
Python or Perl or Bash script, but not 'C script'. Look at the job
openings: you'll often see something like this: 'knowledge of
scripting languages (such as Perl and/or Python)'.

 

[Peter Hansen]

I think the major implication is not that it's simple but it's written
in some 'interpreted' (rather than compiled) language. so we say
Python or Perl or Bash script, but not 'C script'. Look at the job
openings: you'll often see something like this: 'knowledge of
scripting languages (such as Perl and/or Python)'.

Before this explodes into another long thread, please check the
archives for this newsgroup if you have any interest in this
topic. It has been discussed at length, and both Phil's and
Porky Pig's responses have been posted before, along with
others (which I have a feeling we're about to see yet again
from other people in spite of this post... ;-).

-Peter

 

[Cameron Laird]

I think the major implication is not that it's simple but it's written
in some 'interpreted' (rather than compiled) language. so we say
Python or Perl or Bash script, but not 'C script'. Look at the job
openings: you'll often see something like this: 'knowledge of
scripting languages (such as Perl and/or Python)'.

All true--but we also shouldn't limit ourselves to the notoriously
imprecise dialect of employment advertisements. Let's recognize
that's how managers and HR functionaries talk, but recognize that
our own concepts need to be sharper.

 

[Oliver Fromme]

> Ok, stupid question for the day. I'm reading the interview with Steve
> Moret and he says: "Once a lot of scripts started going in we knew
> there was no way we could back out of using Python."
>
> I'm just getting into Python and am wondering if I'm missing something
> or this is just a semantic issue.

Historically, the term "script" means a batch job, i.e. a
sequence of OS commands that are executed in an automated
manner (as opposed to typing those commands interactively),
with very limited possibilities of loops, conditionals and
variables. DOS batch files (.BAT) are a typical example.

The term "program" means complex processing instructions
which implement algorithms in a particular programming
language (which does not normally contain OS commands
directly).

With some languages, the differences become very small, and
people tend to pay less attention to the distinction, so
"scripts" and "programs" are used as synonyms. For example,
some advanced UNIX shells (like the zsh) have features that
support complex programming, such as various kinds of loops
and conditionals, arrays, dictionaries etc.

Python is more a programming language than a scripting
language (more than Perl, at least), although you can very
well use it for tasks which would typically be written in a
scripting language.

A subroutine is just another name for a procedure or a
function, i.e. a piece of program code that performs a
specific task, and which can be called from within the
program (once or multiple times). You can define sub-
routines in almost every language (both for programming
and for scripting).

Best regards
Oliver

 

[Dennis Lee Bieber]

Python is more a programming language than a scripting
language (more than Perl, at least), although you can very
well use it for tasks which would typically be written in a
scripting language.

I'd put REXX at the split point between a strictly OS scripting
language (JCL, DCL, shell scripts) and interpreted programming language
(Python, BASIC, PERL, etc.). Primarily for REXX's easy means of using OS
commands -- any statement not recognized as a REXX statement is
automatically passed to the current defined command host (normally a
command shell, but could be a REXX compatible editor, or other
application). None of this hassle of explicitly calling os.system() (for
example). For ambiguous statements (those that could be REXX or command
host), putting quotes around those meant for the host was sufficient.

A subroutine is just another name for a procedure or a
function, i.e. a piece of program code that performs a
specific task, and which can be called from within the
program (once or multiple times). You can define sub-
routines in almost every language (both for programming
and for scripting).

And to confuse the matter, the old FORTRAN terminology (at
least, in my old classes) referred to "function subprograms" and
"subroutine subprograms".

--

 

[Donn Cave]

I'd put REXX at the split point between a strictly OS scripting
language (JCL, DCL, shell scripts) and interpreted programming language
(Python, BASIC, PERL, etc.). Primarily for REXX's easy means of using OS
commands -- any statement not recognized as a REXX statement is
automatically passed to the current defined command host (normally a
command shell, but could be a REXX compatible editor, or other
application). None of this hassle of explicitly calling os.system() (for
example). For ambiguous statements (those that could be REXX or command
host), putting quotes around those meant for the host was sufficient.

And you might have added, it can be applied to other environments
besides the OS, as an application scripting language. In either
case it takes functionality of a type that is commonly wielded by
hand, and exposes it in a programming language. Hence, a script,
obviously derived from common English usage of the word.

Donn Cave, (e-mail address removed)

 

[Colin J. Williams]

Dennis Lee Bieber wrote:
[snip]

And to confuse the matter, the old FORTRAN terminology (at
least, in my old classes) referred to "function subprograms" and
"subroutine subprograms".

Yes, because the former returned a value, the latter did not.

Colin W.

 

[Darren Kirby]

Larry Wall said it best:
"A script is what you give the actors, a program is what you give the
audience"

--
Part of the problem since 1976
http://badcomputer.no-ip.com

"...the number of UNIX installations has grown to 10, with more expected..."
- Dennis Ritchie and Ken Thompson, June 1972

 

[Dennis Lee Bieber]

And you might have added, it can be applied to other environments
besides the OS, as an application scripting language. In either

I thought I had, though the use of "defined command host" may
have been obscure. <G>


--

 

[Greg Ewing]

I think the major implication is not that it's simple but it's written
in some 'interpreted' (rather than compiled) language.

To my way of thinking, a "script" is a canned sequence of
commands for something that one normally uses interactively.
On that basis, python "scripts" aren't really scripts, they're
programs -- because the Python interpreter isn't normally
used interactively, except for trying things out during
programming.