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

Discussion in 'Python' started by tdi, Aug 24, 2004.

  1. tdi

    tdi Guest

    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
     
    tdi, Aug 24, 2004
    #1
    1. Advertising

  2. tdi

    Phil Frost Guest

    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.

    On Mon, Aug 23, 2004 at 05:18:40PM -0700, tdi wrote:
    > 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, Aug 24, 2004
    #2
    1. Advertising

  3. tdi

    Porky Pig Jr Guest

    Phil Frost <> wrote in message news:<>...

    > 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)'.
     
    Porky Pig Jr, Aug 24, 2004
    #3
  4. tdi

    Peter Hansen Guest

    Porky Pig Jr wrote:

    > Phil Frost <> wrote in message news:<>...
    >>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)'.


    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
     
    Peter Hansen, Aug 24, 2004
    #4
  5. In article <>,
    Porky Pig Jr <> wrote:
    >Phil Frost <> wrote in message
    >news:<>...
    >
    >> 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)'.


    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.
     
    Cameron Laird, Aug 24, 2004
    #5
  6. tdi <> wrote:
    > 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

    --
    Oliver Fromme, Konrad-Celtis-Str. 72, 81369 Munich, Germany

    ``All that we see or seem is just a dream within a dream.''
    (E. A. Poe)
     
    Oliver Fromme, Aug 24, 2004
    #6
  7. On 24 Aug 2004 13:45:38 GMT, Oliver Fromme <>
    declaimed the following in comp.lang.python:

    >
    > 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".

    --
    > ============================================================== <
    > | Wulfraed Dennis Lee Bieber KD6MOG <
    > | Bestiaria Support Staff <
    > ============================================================== <
    > Home Page: <http://www.dm.net/~wulfraed/> <
    > Overflow Page: <http://wlfraed.home.netcom.com/> <
     
    Dennis Lee Bieber, Aug 24, 2004
    #7
  8. tdi

    Donn Cave Guest

    In article <>,
    Dennis Lee Bieber <> wrote:

    > On 24 Aug 2004 13:45:38 GMT, Oliver Fromme <>
    > declaimed the following in comp.lang.python:
    >
    > >
    > > 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.


    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,
     
    Donn Cave, Aug 24, 2004
    #8
  9. 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.
     
    Colin J. Williams, Aug 24, 2004
    #9
  10. tdi

    Darren Kirby Guest

    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
     
    Darren Kirby, Aug 24, 2004
    #10
  11. On Tue, 24 Aug 2004 09:22:18 -0700, Donn Cave <>
    declaimed the following in comp.lang.python:

    > > automatically passed to the current defined command host (normally a
    > > command shell, but could be a REXX compatible editor, or other


    <snip>

    > 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>


    --
    > ============================================================== <
    > | Wulfraed Dennis Lee Bieber KD6MOG <
    > | Bestiaria Support Staff <
    > ============================================================== <
    > Home Page: <http://www.dm.net/~wulfraed/> <
    > Overflow Page: <http://wlfraed.home.netcom.com/> <
     
    Dennis Lee Bieber, Aug 25, 2004
    #11
  12. tdi

    Greg Ewing Guest

    Porky Pig Jr wrote:
    > Phil Frost <> wrote in message news:<>...
    >
    >> 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.


    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.

    --
    Greg Ewing, Computer Science Dept,
    University of Canterbury,
    Christchurch, New Zealand
    http://www.cosc.canterbury.ac.nz/~greg
     
    Greg Ewing, Aug 26, 2004
    #12
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. alex9128
    Replies:
    2
    Views:
    684
  2. ad
    Replies:
    0
    Views:
    346
  3. Rahul
    Replies:
    16
    Views:
    511
    dohboy
    Feb 26, 2008
  4. Amit Jain
    Replies:
    3
    Views:
    1,771
  5. king
    Replies:
    5
    Views:
    205
Loading...

Share This Page