My friend and co-worker and I had a discussion the other night about "when do scripts become programs, and programs become applications".

If any of the users here are like me, they take a SLIGHT offense when another person calls their 'program' a script. We came up with a simple definition just for our own information.

A script is somthing done to do a job, usually interpreted in a line-by-line order.

While a program is set up to be modular with re-called subroutines and differential dynamic output.

An application is a set of programs that are combined in an easy manner, with a backend, and a frontend.

I dont know, anyone else got any of their own opinions?

Replies are listed 'Best First'.
Re: scripts-programs-applications
by arhuman (Vicar) on Mar 03, 2001 at 12:13 UTC
    I had a similar discussion with GLOOM once.
    (It was : why do people call perl a 'script' language ? and it then leads to what is the difference between a 'script language' and a 'language' ?)

    Some people think that the difference is the interpreted way is specific to script language : TCL,VB...
    But they will not consider JAVA as a script language however (algthough it's an interpreted language)

    You can't distinguish them in term of feature, for all scripts languages often have plenty of predefined functions to do high-level operation

    It seems that the more common point of view is that if you usually use a language to code big application it's a 'language' but if you usually use it to do short prog it's a 'script language'.
    (It seems to be your point of view as you usually use function as soon as the code isn't very small; But be aware that some people use functions even in small script(I do)...)

    I think that the difference between script and program are an obsolete thing which came from old age when a script was a custom made with very poor/limited language by opposition to a program which was a lengthy piece of code made in a REAL labguage (COBOL, FORTH...)

    IMHO, nowadays the language are so powerful you could produce lengthy and efficient code with almost all (so called) scripts languages...
    A script is only often just a program that someone find small.
[reply]
Re (tilly) 1: scripts-programs-applications
by tilly (Archbishop) on Mar 04, 2001 at 02:41 UTC
    Scripting and programming IMHO are all about attitude. In my books scripting refers to thinking through a series of steps one by one, usually in straight line code, and just walking through a process. Programming refers to thinking about what you are doing and trying to write a program that happens to accomplish the task, applying all of your knowledge of how to program well to write a good program.

    I have rather strong opinions on which is generally a better attitude to take.

    It is very straightforward to approach small problems by scripting a solution, and a scripting language (IMHO) is a language that tries to make it possible to go quite far that way. Therefore Perl is a scripting language. But scripting as an approach does not scale, and so you will be able to accomplish more with Perl if you try to program. (Most Perl disaster stories are scripts that got out of control.) So learn to think of it as programming even though you might be able to script up an answer that works for now.

    For more thoughts on it, Simon Cozens has a nice article called, Ten Perl Myths. On of my favorite quotes there that pretty much sums this up is, ...there's no real difference between programming and scripting- it's all just telling the computer what you want it to do...I'm going to talk about Perl programs here, but you might hear some people call them Perl scripts. The people who call them `programs' on the whole write better ones. There it is. Scripting and programming are the same activity. But if you are thinking about it as scripting, you will hit a wall sooner rather than later.

    For an unexpected take on this, read The Curse of the Gifted. When you script rather than program, you are falling into a version of that trap. The general pieces of advice that ESR is giving Linus Torvalds there apply (with only minor translation) to a large number of Perl scriptors as well...

[reply]
Re: scripts-programs-applications
by extremely (Priest) on Mar 04, 2001 at 01:25 UTC
    Feh, I object to these sorts of false categorizations. Like some types of program are better or wors than others. It is hubris, false pride, and nothing more.

    A program is code that performs a task or tasks in expressed or encoded form. The generic term.

    A script is a program whos expressed and encoded form are the same, ala a program that is directly or indirectly interpreted.

    An application is a program designed for continuous interaction or end-user use. In other words, a "seen" program designed for regular use. Compare application to utility, daemon, driver, and kernel.

    You are talking about words on different axes. Program and code are the generics, where one tends to lean toward the expressed and the other to the post-processed forms. Script vs. Compilable or Interepreted vs. Compiled is one axis (and where Perl falls in that spectrum is rather hard to define). That axis is concerned with how the language works internally, a classification of design. The Application vs. Utility axis is concerned with how the program or programs are used. It is a classification of applicability and user needs.

    Script has a deprecating sense in that most people perceive "scripts" as being linear, disposable programs that aren't created with serious code standards. I tend to call them scripts, even when they get past 10,000 lines and multiple design reviews and such simply because I am an engineer at heart and the emotional overtones of words are ignored by the (overly?) technical. If you find that "script" gets your code treated differently, start calling all of them "programs". =)

    --
    $you = new YOU;
    honk() if $you->love(perl)

[reply]
Re: scripts-programs-applications
by arhuman (Vicar) on Mar 06, 2001 at 21:14 UTC
    I feel the Larry's opinion could matter, so here's from the perlfaq (interesting reading...) :

    Is it a Perl program or a Perl script?

    Larry doesn't really care. He says (half in jest) that "a script is what you give the actors. A program is what you give the audience."

    Originally, a script was a canned sequence of normally interactive commands, that is, a chat script. Something like a UUCP or PPP chat script or an expect script fits the bill nicely, as do configuration scripts run by a program at its start up, such .cshrc or .ircrc, for example. Chat scripts were just drivers for existing programs, not stand-alone programs in their own right.

    A computer scientist will correctly explain that all programs are interpreted, and that the only question is at what level. But if you ask this question of someone who isn't a computer scientist, they might tell you that a program has been compiled to physical machine code once, and can then be run multiple times, whereas a script must be translated by a program each time it's used.

    Perl programs are (usually) neither strictly compiled nor strictly interpreted. They can be compiled to a byte-code form (something of a Perl virtual machine) or to completely different languages, like C or assembly language. You can't tell just by looking at it whether the source is destined for a pure interpreter, a parse-tree interpreter, a byte-code interpreter, or a native-code compiler, so it's hard to give a definitive answer here.

    Now that "script" and "scripting" are terms that have been seized by unscrupulous or unknowing marketeers for their own nefarious purposes, they have begun to take on strange and often pejorative meanings, like "non serious" or "not real programming". Consequently, some Perl programmers prefer to avoid them altogether.
[reply]
scripts-programs-applications: whither libraries?
by princepawn (Parson) on Mar 06, 2001 at 21:39 UTC
    I see Perl as an excellent language for stepwise refinement. You just write the damned script. And then later you decide to abstract domain-independent parts into modules. Then this same script can be rewritten with a clearer distinction between doamin-independent and domain-specific parts. And the domain-indepedent parts can serve well in applications because they have a well-defined general purpose.

    For me, this has happened many times. I was re-writing a largish FTP application which was using Net::FTP. Common domain-independent patterns of usage led to my development of Net::FTP::Common.

    On the other hand, we must admit something, no one is ever going to say: "write a script to compute the first N Fibonacci numbers." It is more likely that they will use the word program... I am not enough of a linguist to say why this might be, but there is something about this calculation that lends itself to be called a program instead of a script.

[reply]

Back to Meditations