Purpose: Discuss what determines whether a language is a scripting language as opposed to some other sort of programming language.
Many people say that AppleScript, Lua, Perl, Python, Rexx, Rebol, Ruby, shell languages (like sh, csh, ksh, bash, zsh, etc.), Tcl, and TKS are all scripting languages.
What criteria can one use to determine whether a language is a scripting language or not?
The italicised word added by me, or you exclude Perl5 and Tcl8 pointlessly - DKF FW: And Ruby and Lua and Python and (I think) Rexx and REBOL! ;)
Discussion:
Are the above valid criteria?
If the creator of a language calls it a scripting language, does that make it so? If the creator denies that a language is a scripting language, does that make it so?
The first language I learned that passes the "interact" criteria was IBM MVS JCL. Is that a scripting language?
I know nothing of Lua and Rexx, so I don't know if they really fit in here or not. Other languages I have lesser familarity with, but which might fit the above criteria, are JavaScript, VisualBasic, VBScript, Smalltalk.
Why would you want to use a scripting language, anyway? Take a look at Why Scripting
AK: An essay about this topic I wrote some time ago [L1 ]
Phil Ehrens wrote:
> Didn't Milton write (Paradise Regained?): > "Perl's lots of funne, but Tcl's where the work is donne"?
RS: I'd replace the overly generic "Shell" above with "sh, csh, ksh, bash, .." - just those "Unix JCLs -, and add "awk". Not sure about "sed", though...
KBK: A test that's quite accurate for whether a language is a "scripting" language: If I have a character string that contains code written in the language, can I evaluate it readily within a running program? By this test, the LISP-like languages are also scripting languages, but many Basic implementations are not. It's not just a question of "does the language support the eval feature." Instead, the presence or absence of eval is a window into what the language designer considered important.
LV does awk have an eval type operation? RS: Not from what I know; hence it's more on the Fortran/C side of code and (string) data strictly separated.
JMN Apparently an ex-TCLer wrote BeanShell which has been described as "a Java source interpreter with object scripting features". The author of BeanShell compares the relationship of Java and BeanShell to the relationship of C and Tcl/Tk. Part of the beanshell manual has some information relevant to this page: http://www.beanshell.org/manual/intro.html#Scripting_vs._Application_Languages
LES: 02 Sep, 2003 - I don't think it is trivial to "interact with other programs, allowing one to trivially pass input and gather output for further processing" when using Tcl. It's been proven that running a sed one-liner from within Tcl, for example, can be very difficult maybe even impossible. Tcl messes too much with the brackets, changes backward slashes to forward slashes on its own and will escape spaces with \ on occasion. Very annoying.
Grrrr; CL says that no, that has not been proven, and, as often as not, the problem is that Tcl does not mess with special characters as naive users expect. Let's talk this over a bit more and make sure we have our stories straight.
LES retorts: http://groups.google.com/groups?th=b46ba29327d4ed2c ... or... http://dbforums.com/t878814.html (looks prettier)
You may prove it is possible, but you won't convince me it is "trivial".
US Sorry LES, I'm unable to see the problem. Your original sed line was:
sed -r -n '/# =+/{h;${x;p;};d;};H;${x;p;}' someFilePathSince single quotes are for the shell what braces are for Tcl, I tried this:
set myTail [exec sed -r -n {/# =+/{h;${x;p;};d;};H;${x;p;}} someFilePath]In my eyes it really looks like a trivial transposition. BTW, I didn't find this in the list of your frustration trials.
escargo 17 May 2004 - OSNews.com has an article called On Scripting Languages, http://www.osnews.com/story.php?news_id=7038
Tcl gets no mention in the main part, but was mentioned once in the responses.
RHS 17May2004 I found the following quote from that article to be amazingly insightful: Scripting is an attitude. Even the author of the article agrees, I believe. The point of thinking in scripting is to put the accent on getting the job done. In this sense, sripting may be a synonimous for agile
PWQ 18 May 04, I would add this as a technical point. Most people confuse scripting for interpreting.
Can the langauge do this:
set fred ut
p${fred}s {Hello World}That is, Are the instructions static or dynamically computed.( The pointy heads may have a formalisim to describe the above). Eval would not meat the above criteria.
In this case I would say that only a small subset of interpreted languages are scripting. Tcl, Dbase (FoxPro et al), and unix shells are the only one that comes to mind.
Well, by definition scripting languages are languages you write scripts in. The question is: What are scripts?
Scripts are a static sequence of commands (analogy: the script to a play). But in this context, it's a static sequence of operations sent into an interpreter instead of the user having to interactively enter the commands in.
So...scripting languages are the command language supported be an (any) interactive environment, provided the commands can be sourced from a file in addition to direct user interaction. Tclsh meets this criteria. So do Unix shells, the dos batch language, perl and python. Even editor macros are often basic scripting language. Note that not all scripting languages are in fact programming languages, as they may not be turing complete.
All that said, terminology is often used loosely, and usually when people say scripting language they mean interpreted language.
FW: I kind of adhere to the idea that the technical definition of a scripting language would be a less-than-natively-compiled language with facilities designed to automate lower-level actions; sort of a format to describe the problem for lower level code to perform. In practice, this causes a paradigm where the language is made for optimum programmer versatility and ease of use. You can work in a fantasy land where everything fits together into some programming ethic, rather than a clunky language tailored to the specific vagaries of the environment. Of course, it's technically possible to write a native compiler for any language, but at a certain level of abstraction it barely gives any boost speed-wise.