Beefy Boxes and Bandwidth Generously Provided by pair Networks
The stupid question is the question not asked
 
PerlMonks  

When is a script an application

by camelman (Sexton)
on Nov 07, 2001 at 21:25 UTC ( [id://123859]=perlmeditation: print w/replies, xml ) Need Help??

I was contemplating the terms "script" and "application". I did a search on perlmonks and found a node stating that it's difficult to distinguish due to factors such as compiling vs. run time interpretation. As a UNIX admin it seems my Perl "scripts" are considered by some to be cute little curiosities no matter how much I parse an XML file, manipulate a mySQL database, or offer a nice HTML interface. Yet VB developers write applications. Are scripts looked down upon in the rest of the world?

Yes, I admit I'm too sensitive and should spend more time improving my code than complaining about such things. ;-)

Thanks . . . Kevin

Replies are listed 'Best First'.
Re: When is a script an application
by jeroenes (Priest) on Nov 07, 2001 at 22:20 UTC
    From another perspective: What's the definition of application and script? This shows up in http://dictionary.com:

    Application

    1. Computer Science. A computer program with a user interface.

      A CLI is also an user interface, isn't it?

    2. 3: a program that gives a computer instructions that provide the user with tools to accomplish a task; "he has tried several different word processing applications" syn: application program, applications programme

      Another user-oriented def

    3. <programming, operating system> (Or "application", "app") A complete, self-contained program that performs a specific function directly for the user. This is in contrast to system software such as the operating system kernel, server processes and libraries which exists to support application programs.
      Editors for various kinds of documents, spreadsheets, and text formatters are common examples of applications. Network applications include clients such as those for FTP, electronic mail, telnet and WWW.
      The term is used fairly loosely, for instance, some might say that a client and server together form a distributed application, others might argue that editors and compilers were not applications but tools for building applications.
      One distinction between an application program and the operating system is that applications always run in "user mode" (or "non-privileged mode"), while operating systems and related utilities may run in "supervisor mode" (or "privileged mode").
      The term may also be used to distinguish programs which communicate via a graphical user interface from those which are executed from the command line.

      Now that is application versus system. May apply to many perl programs, actually.

    Script

    1. Computer Science. A simple program in a utility language or an application's proprietary language.

      What would an utility language be? Is 'C' an utility language?

    2. A program written in a scripting language, but see Ousterhout's dichotomy.

      Scripting language?

    3. scripting language (Or "glue language") A loose term for any language that is weakly typed or untyped and has little or no provision for complex data structures. A program in a scripting language (a "script") is often interpreted (but see Ousterhout's dichotomy).

      Well, let's look that up than.

    4. John Ousterhout's division of high-level languages into "system programming languages" and "scripting languages". This distinction underlies the design of his language Tcl.
      System programming languages (or "applications languages") are strongly typed, allow arbitrarily complex data structures, and programs in them are compiled, and are meant to operate largely independently of other programs. Prototypical system programming languages are C and Modula-2.
      By contrast, scripting languages (or "glue languages") are weakly typed or untyped, have little or no provision for complex data structures, and programs in them ("scripts") are interpreted. Scripts need to interact either with other programs (often as glue) or with a set of functions provided by the interpreter, as with the file system functions provided in a UNIX shell and with Tcl's GUI functions. Prototypical scripting languages are AppleScript, C Shell, MSDOS batch files, and Tcl.
      Many believe that this is a highly arbitrary dichotomy, and refer to it as "Ousterhout's fallacy" or "Ousterhout's false dichotomy". While strong-versus-weak typing, data structure complexity, and independent versus stand-alone might be said to be unrelated features, the usual critique of Ousterhout's dichotomy is of its distinction of compilation versus interpretation, since neither semantics nor syntax depend significantly on whether code is compiled into machine-language, interpreted, tokenized, or byte-compiled at the start of each run, or any mixture of these. Many languages fall between being interpreted or compiled (e.g. Lisp, Forth, UCSD Pascal, Perl, and Java). This makes compilation versus interpretation a dubious parameter in a taxonomy of programming languages.

      Ah! That seems sensible. let's stick with that.

    And is VB strongly typed? Yeah, guess it is (but see elsewhere in this thread on interpreted) (Update: I should have said: it's stronger typed than perl, perhaps). And I think most of them VB coders wouldn't dubb Java stuff 'scripts', but we know better now, do we?

    Update: In retrospect, the definitions above actually show that the terms 'application' and 'script' are orthogonal. An application is defined in terms of user interaction, while a script is defined in terms of the programming language, or in terms of programming approach, as tilly arguments elsewhere in this thread.

    So a script can be an application, and not every program automatically is an application.

    I noticed furthermore that C can be argumented to have weak typing, and so can be seen as having 'scripting' features.

      "Scripts need to interact either with other programs (often as glue) or with a set of functions provided by the interpreter, as with the file system functions provided in a UNIX shell and with Tcl's GUI functions."

      That says more to me than any of the other babble, I usually divide script by "does it need anything other than libs to run?" in this case the perl interpreter. And yes I understand that you can "compile" perl into an executable, but really, that just bundles the enterpreter and the script into one package.

      My $0.02 ($0.032 CDN)

      "Nothing is sure but death and taxes" I say combine the two and its death to all taxes!
(jeffa) Re: When is a script an application
by jeffa (Bishop) on Nov 07, 2001 at 22:49 UTC
    A script is a program that is perceived as a script, and an application is a program that is perceived as an application. It is all really a matter of perception.

    Applications are, however, generally considered to be larger in sheer size and more complex in their design than scripts. Generally - there are always exceptions to the rules, and the line between scripts and applications can be very blurred at times.

    Think of each of your 'cute' little 'scripts' as a squirrel, a cute fuzzy little critter that works hard to gather to food for the winter. Nobody really notices them, but they GET THE JOB DONE. Now think of an application as a large whale, slowly moving through the water - unchanged or very difficult to change. If the whale isn't careful, one wrong turn and it will wind up stuck on the beach, an obsolete piece of blubber.

    Extreme, but i guess my point is that if you are worried that you are missing out on some 'big adventure' of application developement and you are stuck writing minor utility scripts, consider yourself fortunate. Your scripts have a better chance to be usefull longer than many applications 'out there'. And yes, even though the whale lives much longer than the squirrel - i see many more squirrels out there than whales.

    OK, OK! So i live in Tennessee - it's a metaphor!!! ;)

    jeffa

    L-LL-L--L-LL-L--L-LL-L--
    -R--R-RR-R--R-RR-R--R-RR
    F--F--F--F--F--F--F--F--
    (the triplet paradiddle)
    
      Yep, its all perception. I use to tell my boss 'I wrote a little Perl script that did this or that'. This was a way to brag on Perl, that it only took a little Perl script to get the job done.

      Easy to get a reputation as a little script writer that way. I quit writing 'little Perl scripts' about a year ago. I now only write 'Perl programs', some are big, some are little.

      YuckFoo

        Thanks to everyone here for their responses. I think jeffa and YuckFoo really hit it on the head for me. I'm the one with the problem. I probably downplay my "little scripts" and need to market them better and educate those that don't use Perl. What can't one do in Perl? When will they learn! Many Thanks! ...Kevin

      Good Perl is hidden and has no name.

      f--k the world!!!!
      /dev/world has reached maximal mount count, check forced.

Re: When is a script an application
by davorg (Chancellor) on Nov 07, 2001 at 21:44 UTC

    One definition that I've often heard is that scripts are interpreted and applications are compiled. Of course this works in Perl's favour as Perl programs are compiled, even if it looks like they're interpreted.

    Update: Should probably make it clear that this isn't a categorisation that I agree with (for many reasons including the ones mentioned by mikeB below. I jsut mention it as the most common explaination that I've heard.

    --
    <http://www.dave.org.uk>

    "The first rule of Perl club is you don't talk about Perl club."

      Where do you draw the line between "compiled" and "interpreted"? Perl, Java, and older VB among others are compiled to an intermediate code which is then executed by an interpreter.

      By the compiled/interpreted definition, VB programmers 5 years ago were writing "scripts" which, when compiled in a recent version, are now "programs".

      Come to think of it, some mainframes use microcode to execute machine instructions. The microcode is an "interpreter" for the machine's assembly language. Guess that makes all those big COBOL programs scripts, not applications :)

        x86 asembly is compiled into macrocode. Each instruction is then translated by the CPU to a number of microcode instructions that are then run by the functional units. Is a hardware interpreter still an interpreter?
Re: When is a script an application
by kwoff (Friar) on Nov 07, 2001 at 21:47 UTC
    I'd say if a VB developer gives you a contemptful response, then they're trying to cover up an inferiority complex. I think of VB "apps" as more like "plugins" to Windows. Ask them to run their VB app on a non-Windows OS.
      If you want to be _really_ mean to a VB programmer, ask them to solve a problem on a chalk board without their IDE's to 'method complete' their code for them. >:)
Re: When is a script an application
by arashi (Priest) on Nov 07, 2001 at 21:54 UTC
    Where I work we have two types of employees: web designers and web application developers. The web designers write scripts, nothing fancy, mostly just working from a template that has been provided for them, mostly pure HTML with a little JavaScript. The web application developers also write scripts (since Perl, HTML, etc... are all scripting languages, they are writing scripts), however the projects they work on are deemed to be applications because they provide some sort of interaction with a user, and are dynamic. As soon as a web designer writes something that is fits the definition of an application, they become a web application designer. No one employee is more important that another, at least where I work.

    I guess if I'm writing some code for myself, that does some little job, I can really call it an application. However, as soon as I write some code that can be used by other users, and provides some service other than displaying static data, I would call that code an application, no matter what language it was written in.

    Personally I don't think the measure of an individuals skill should be based on whether or not he/she is writing scripts or applications, but it should be based on the usefulness and quality of the code they write.

    I hope my thoughts on this matter help you answer your questions.

    Arashi

    I'm sure Edison turned himself a lot of colors before he invented the lightbulb. - H.S.
Re: When is a script an application
by mr_mischief (Monsignor) on Nov 08, 2001 at 03:03 UTC
    I call a program which wraps another program or is built into another program to automate a function normally done by hand a 'script' or a 'macro'.

    I call a program that an end-user uses by hand an 'application'.

    I call a program that an administrator uses by hand (or controlled via a script ;-) a 'utility'.

    I call a program that developers use by hand a 'tool'.

    I call a program that runs in the background waiting for events a 'daemon'.

    I call a program that writes another program a happy program. ;-)

    Maybe these are just peculiar to me, or maybe I'm just peculiar. Either way, those are my thoughts.
(ichimunki) Re: When is a script an application
by ichimunki (Priest) on Nov 07, 2001 at 21:49 UTC
    My humble opinion: the difference is that an application is an open-ended set of tools for a certain purpose-- the user tells it when the user is done rather than the script running out of input data from STDIN or files and then ending. All Perl scripts are scripts, regardless of whether or not they are also applications.

      You're telling me that all those COBOL batch programs that I wrote back in the good old times aren't applications? ;-)

      f--k the world!!!!
      /dev/world has reached maximal mount count, check forced.

Re: When is a script an application
by sm3g (Hermit) on Nov 07, 2001 at 23:17 UTC
    I tend to think of a script as a small program that runs without user interaction and an application as something that requires someone to help it along. So a log parser or backup program that runs as a cron job is a script and a mail program is an application. On the same thought sendmail is not a script but an application because even though it doesn't require direct input it gets input from whatever other program is using it.

    However this is a huge generalization and they tend to be pretty much worthless in the real world. (:

    requisite obfuscation sig below:
    perl -e 's;;uoli;;$a=length;y;g-w;e-u;;;$a--;s;j;$a;;print"$_\n";'
      I've heard a lot of technical and dictionary definitions here, and I was hoping I'd be the first to say it, but hey, AMEN!!! fellow monk.

      That's the definition I go with. A script is something without a "user interface", where as an application is something with a user interface, whether it be command line or gui or voice (or what have you).

       
      ___crazyinsomniac_______________________________________
      Disclaimer: Don't blame. It came from inside the void

      perl -e "$q=$_;map({chr unpack qq;H*;,$_}split(q;;,q*H*));print;$q/$q;"

Re (tilly) 1: When is a script an application
by tilly (Archbishop) on Nov 08, 2001 at 17:21 UTC
    I forget who said it (perhaps Larry Wall?), but a thought I have always liked is, There is no real difference between scripting and programming, but the ones who call it programming usually do it better.

    Seriously, if your approach to programming is to walk through what you need to do in order, and write code fairly linearly to do the task, then what you are doing is scripting. Even if you are doing it in C. Even if some of the steps you are calling are from complex libraries.

    On the other hand if you are trying to factor and organize your code from the get-go, then you are probably programming. No matter what language you are writing in.

    By my definition I have personally seen scripts written in C, and programs in DOS bat files. In my books it isn't what language you are using, or what task you have accomplished. Rather it is how you went about doing it.

Re: When is a script an application
by Elliott (Pilgrim) on Nov 07, 2001 at 22:29 UTC
    To me, the phrase "scripting language" implies a set of controls for some other application or operating system, in other words a "macro". For example, a script might open files in Photoshop, convert them from CMYK to RGB and save them as GIFs.

    This contrasts with a "programming language" that is essentially unlimited in its power. This definition puts Perl firmly in the "programming language" camp and I've always been baffled to hear it described as a "scripting language".

    But I'm obviously out of step here....

Re: When is a script an application
by mrmick (Curate) on Nov 07, 2001 at 23:00 UTC
    To me, a script is something that you throw away after using it once. ...but since you NEVER throw anything away that you have written, everything is an application. I tend to refer to everything as a program if it does something for me or others.

    Cheers,

    Mick
This is a FAQ
by perrin (Chancellor) on Nov 07, 2001 at 23:29 UTC

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://123859]
Approved by root
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others studying the Monastery: (6)
As of 2024-03-29 01:04 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found