Talk:Scripting language

From Wikipedia, the free encyclopedia

This is the talk page for discussing improvements to the Scripting language article.
Article policies
This article is within the scope of WikiProject Computer science, which aims to create a comprehensive computer science reference for Wikipedia. Visit the project page for more information and to join in on related discussions.
Start rated as Start-Class on the assessment scale
Mid rated as Mid-importance on the assessment scale

Contents

[edit] Interpretation versus Compilation

"Scripting programming languages are computer programs that are interpreted not compiled."

This is clearly incorrect, in many ways. A programming language is not an interpreted language or a compiled one; programming languages are interpreted or compiled by computer programs. You can compile or interpret C, you can compile or interpret Basic. The issue of whether or not a programming language is a scripting programming language is orthogonal. The real distinction is that a scripting programming language is good for scripting some system. For instance, C is a good language for scripting Unix. So is Perl.

[1 minute later]: Oh, someone beat me to it, while I was writing the above. Cool.

Yeah, I fixed it, but the issues aren't 100% orthogonal, either: Scripting languages are more often interpreted than compiled, and non-scripting languages are more often compiled than interpreted, for the good reason that their syntaxes are designed to make one or the other easier. Anyone who uses the term "scripting language" in even the remotest connection to C is making the term utterly meaningless. C is the ultimate anti-scripting language. Yes, there have been various attempts to interpret C with various levels of success, but all of them are awkward and incomplete because C just isn't designed that way; it expects a compiler and a linker to resolve things. The text I think reflects this now, but if you can think of a better way to say that, I'd be pleased. --Lee Daniel Crocker
"Scripting lnaguage" in Oxford's A Dictionary of Computing says it is, "A programming language that can be used to write programs to control an application or class of applications, typically interpreted." "Script" in the same publication reads, "A file containing commands or other actions that could have been entered from the keyboard." "CGI (Common Gateway Interface)" in World of Computer Science backs up that view:

A CGI application would traditionally be described as a script, rather than as a true program. The distinction is to a certain extent semantic--a "script" is thought to be any application that is created merely by the line-by-line interpretation of code in some functional programming language like Perl or Python. A "program" in the classical sense is, on the other hand, code written in a language such as C or C++ which has to be compiled to obtain a binary (executable) that is then run; the program itself cannot be run on any system.

We need to emphasize this characteristic. The corresponding Spanish wiki article is called "Lenguaje interpretado" (Interpreted Language). Even after I read those articles about scripts, I had a very hard time understanding the introduction for this entry because it is so ambiguous. It also reads like it was written for a programmer to read. The introduction should be the simplest part of an entry.--HQCentral 12:21, 6 November 2006 (UTC)

[edit] Article title: Script(ing) language?

Shouldn't the title named simply "script language"? It may be misnomer but more recognized I guess. -- Taku 02:10 Mar 22, 2003 (UTC)

Yes, this article should be named "scripting language". That article currently redirects here. A while ago somebody added "programming language" to the titles of a bunch of articles. The best way to change that would be to delete the redirect page so this page can be moved cleanly. So, if any admin wants to do that... -- Merphant
  • I agree, so I moved it. Not an admin tho so history will look weird. Elfguy 20:37, 16 August 2005 (UTC)

[edit] Scripting vs General p-languages

Perhaps the vague difference between a scripting and general purpose language is merely that it is possible to write and run a "script" without any command-line compilers, makefiles, or other "developer tools". For example, Scheme48 is a runtime for the general purpose language Scheme, but scsh is a scripting language using a hacked Scheme48 runtime that supports the "#!" shell syntax. By the way, Mondrian is a strongly typed "scripting" language. Also, the page uses "scripting" in the definition of scripting language, which is circular and not terribly illuminating. --Anon 19:42, 11 Aug 2003 (UTC)

Coupla good sources on complexity of defining scripting languages:

- http://www.cs.man.ac.uk/~pjj/cs211/langdes/script.html
- http://www.softpanorama.org/Scripting/index.shtml

I expanded description on main scripting page to fit in some of the blurriness elaborated at those links. Basically, we are talking about a field of applied engineering and active computer science research, still evolving, hard to pin down; lots of schools of thought.

--Stevelu, Feb 25 2004

Nice work :-) -- Arvindn 05:19, 26 Feb 2004 (UTC)

If a scripting language is meant to mean a language which is chiefly used to control or connect other programs -- the old sense of a job-control language -- then whole swaths of the listed languages do not fit.

Dylan is a general-purpose programming language. Perl was originally a text-processing language like awk, but is now mostly a general-purpose one. Scheme is a family of educational and general-purpose languages. Guile and Lua are general extension languages, intended to be embedded in applications written in another language. QuakeC and ZZT-OOP are similarly extension languages, but specialized for particular games (just as AutoLisp is an extension language for one particular application, AutoCAD). PHP is arguably an extension language for Apache Web servers.

Looking over the list, it seems to me as if these can be divided into four categories -- no, five. Job control languages are chiefly used to direct the input and output of other programs, such as Unix shells, JCL, and REXX. Text processing languages are used to format text or produce reports, such as awk, sed, and (originally) Perl. Embedded extension languages differ from job-control languages in that they can access the internal state of applications designed to use them, such as Guile, AppleScript, and VBScript. Application-specific extension languages are those embedded in a single application, such as QuakeC (in Quake), ZZT-OOP (in ZZT), AutoLisp (in AutoCAD), or PHP (in Apache). The fifth category is dynamic languages called "scripting languages" by people who don't like dynamic languages -- such as Python, Scheme, Dylan, or modern Perl. --FOo 13:52, 4 May 2004 (UTC)

[edit] Scripting vs. Programming

(Sorry for the crude formatting, I'm a Wikipedia novice.)

A bunch of us at META Group have been discussing this distinction, so I thought I'd post some of my thoughts here:

Ousterhout (http://home.pacbell.net/ouster/scripting.html) in his article on scripting, which I highly recommend reading thoroughly, nails the sence of "gluing" that distinguishes system programming languages (SPLs) from scripting languages (SLs): "System programming languages were designed for building data structures and algorithms from scratch, starting from the most primitive computer elements such as words of memory. In contrast, scripting languages are designed for gluing: they assume the existence of a set of powerful components and are intended primarily for connecting components together." It is this distinction between "building from scratch from primitive elements" and "building from already built-up components" that is fundamental. Yes, you can add a rich library or framework to an SPL (think Unix libraries or MSFT MFC), but then you are still stuck with a language (eg C++) with a set of powerful but complicated capabilities for "building from scratch from primitive elements". If all one wants to do is to exploit the rich library of already developed data structures and algorithms (DSAs), and does not want to add any more, then the SPL is overkill.

Flex and Flash are perfect examples of this. The geniuses at MM have already created the DSAs for UI building and animation, respectively--Flex and Flash just let you compose them. If you want to design new DSAs for UI building and animation, then don't use Flex and Flash.

In short, SLs are designed for composing existing DSAs for a specific use. SPLs are designed for defining new DSAs for general use.

I also think references to scripting languages just being for automating what one would do at a keyboard are obsolete. They are used for an incredibly wide variety of uses. In fact, given this definitional distinction between "composition" vs "definition", I would claim that BPEL (Business Process Execution Language) is a scripting language for scripting together existing Web services.

It should be noted that Ousterhout didn't claim that his "dichotomy" partitioned the set of programming languages. I quote:
There are many other attributes of programming languages besides strength of typing and the level of programming, and there are many interesting languages that can't be characterized cleanly as a system programming language or a scripting language. For example, the Lisp family of languages lies somewhere between scripting and system programming, with some of the attributes of each. Lisp pioneered concepts such as interpretation and dynamic typing that are now common in scripting languages, as well as automatic storage management and integrated development environments, which are now used in both scripting and system programming languages. [1]
I have to wonder if what Ousterhout is really describing when he classes C, C++ and Java as "systems", Perl and Tcl as "scripting", and Lisp as "neither" is not the languages' positive features but their deficiencies. His "systems" languages are ones that lack powerful tools for abstraction -- so their users lean on external scripting and macro packages. His "scripting" languages are ones that nobody has written good native-code compilers for yet -- so they are slow; in order to get good performance you have to use modules written in compiled languages like C.
But Lisp is strangely in the middle -- modern Lisp systems (like SBCL for instance) are fast and compiled, but have powerful abstraction tools. So they don't fit either category. Hmm. --FOo 04:57, 10 Aug 2004 (UTC)

Old first paragraph of Description section:

Computer languages are created with varying degrees of abstracion, that is, the extent to which multiple smaller operations are combined into single named operations. Those languages that tend to introduce the most abstraction are typically called scripting languages. Another use of the term is to describe "small" languages, where the over all functionality of the language is limited to very specific tasks.

Here's why I replaced it:

This paragraph is erroneous, chiefly for the reasons I have given in the earlier discussion above. The existence of powerful abstraction mechanisms in a language is not correlated with its usefulness for scripting. For instance, Common Lisp is a language with more powerful abstraction mechanisms than virtually any other, but it is not very suitable for scripting since it is not very good at interfacing with foreign components. On the other side, Perl is a language which is quite suited to scripting, and which has many powerful mechanisms built it, but not particularly good abstraction mechanisms.

Scripting, the connection of existing external program components which may be written in different languages, is a specific application. Some languages (Perl, Tcl) are well-suited to it. Others (C, Lisp) are not particularly suited for it. Despite the blatant misreading of Ousterhout's work which led to the common perception of "Ousterhout's dichotomy", there is no partition of languages into "those with strong abstraction mechanisms that are good at scripting and are implemented with slow interpreters" and "those with weak abstraction mechanisms that are no good at scripting and are implemented with fast compilers". --FOo 02:35, 26 Aug 2004 (UTC)

OK, good stuff. My primary concern had been the original sentence, which was just a self-referencing statement, "Languages that are used specifically or designed primarily for scripting are called scripting languages". By "abstraction", I guess I was more or less thinking about what you said, working with "pre-existing components," etc. (And I confess to the terrible crime of having only skimmed over most of the discussion on this page prior to editing the article, sorry). AdmN 03:01, 26 Aug 2004 (UTC)

[edit] The scripting language question

It seems from what I have read online that there are many different opinions of what a scripting language is. This article states such, but doesn't do a very good job outlining the differing opinions. As I see it, there are currently a coulple different opinions of what a scripting language:

  1. A language used exclusively for scripting
  2. An interpreted language
  3. A loosely typed language
  4. A language which is used often for scripting
  5. A language that can be used for scripting

Clearly the distinction completely lies with a person opinion. The problem is that the phrase was originally coined to describe languages which were purely for scripting (such as shell scripting), but now is often used loosely to describe languages that are good for scripting. It should also be pointed out that this term is also sometimes used (usually falsely) to have a negative conotation, meaning that a language is only good for scripting. — マイケル ₪ 19:45, Dec 9, 2004 (UTC)

[edit] Any recommendations for literature on developing proprietary scripting language?

Anyone have literature/web recommendations detailing what decisions to make when designing your own scripting language for a single piece of software / single purpose? For example, what syntax would be efficient for a new MUD engine, etc... --I run like a Welshman 09:53, 11 Dec 2004 (UTC)

A pretty common thing to do is to make bindings to an existing scripting language such as Tcl, Lua, or Guile. This has all sorts of advantages -- you don't have to come up with your own language, and your users have at least some chance of having heard of the language before. --FOo 13:44, 11 Dec 2004 (UTC)
I am working on some articles regarding bond trading, particularly collateralized mortgage obligations. The big investment banks who do this have generally developed proprietary languages to describe the transactions (as the most natural description is in procedural terms). These languages are more analagous to a macro language developed within an applications (such as emacs lisp, or (I hate to say it) the version of basic in Excel) than something like bash, but still might be applicable.
Do you (anyone) think that describing that technology would be appropriate here? Morris 13:54, Dec 11, 2004 (UTC)

[edit] recommended

"In most modern systems, the latter case is very seldom recommendable, since one or more suitable script languages is usually available."

Of course it doesn't make any difference, unless you're porting the platform between systems and need a virtual machine to go along with it. But how many platforms really need virtual machines? Almost any virtual machine, anyway, can be shrunk so that a good inter-platform compiler will have no trouble building its scripts. --VKokielov 15:24, 29 August 2006 (UTC)

The essential advantages of writing scripts in C are two: speed of execution and the absolution of the headache you get when you write your own compilers. A reliable architecture of abstraction - COM, for instance - allows the house to implement a reliable communications interface. I also see two drawbacks, viz.: compiled languages run amok, and end-users don't usually have compilers. Neither is an obstacle when the system in question is to be scripted in-house. --VKokielov 21:35, 9 September 2006 (UTC)

[edit] JavaScript as a Programming language not a Scripting language

".. JavaScript is a very influential standard, supported by virtually every browser on the market."

This line is referring to JavaScript as a Scripting Language, however the name of the language is confusing. JavaScript is in fact a full programming language. —The preceding unsigned comment was added by 81.179.250.255 (talk) 15:14, 6 May 2007 (UTC).


[edit] XSLT listed as a server-side scripting language

Shouldn't XSLT be listed under both (or neither) of the "Web programming languages" subcategories? According to the XSLT article, "XSLT processor implementations fall into two main categories: server-side, and client-side."

Most modern browsers can apply XSL transformations to XML documents, so it seems inaccurate to have it listed only under the server-side category. -- Krilnon 01:56, 19 May 2007 (UTC)

[edit] Is ActionScript a scripting language?

For instance: MTASC is an ActionScript 2.0 Compiler. It compiles an ActionScript Source Code to SWF ByteCodes. No Just In Time interpretation. Fırat KÜÇÜK 20:50, 7 July 2007 (UTC)

"Scripting" really describes a purpose to which the language is put, rather than an implementation strategy. Given a language specification, a language can be implemented in many ways, including an interpreter, a JIT compiler, or a traditional compiler. --FOo 21:14, 7 July 2007 (UTC)
http://en.wikipedia.org/wiki/Talk:ActionScript#Scripting_Language.3F : Same discussion. ActionScript is more similar to Java than JavaScript. Fırat KÜÇÜK 04:56, 8 July 2007 (UTC)

[edit] Is Java Server Pages a Scripting Language?

We can use scripting inside a Java Server Pages but JSP is not a scripting language. JSP code is compiled by JSP compiler. Infact a JSP file is a compiled Java Servlet. Fırat KÜÇÜK 05:27, 8 July 2007 (UTC)

[edit] zeroes and ones

Isn't the "clarification" in the into more muddying the waters than clarifying them ?

It claims that scripts are distinguished from programs in that programs consits of ones and zeroes. What then, pray tell, does scripts consist of ?

And is a "script" any program written in a "scripting language" ? If so, does this mean a completely normal GUI spreadsheet-program is a "script" if it happens to be written in Python ?

Is C a "scripting language" if anyone cares to sit down and write an interpreter for it ? I'm sure it's been done repeatedly already...

I think the next paragraph is much better. A script is a script because of what function it performs, not because of what language it happens to be coded in. And a scripting-language is one used for creating scripts. Which yes, means that all languages are sometimes used as scripting-languages. --Eivind Kjørstad 13:51, 11 September 2007 (UTC)

[edit] Not a technical term

"But basically, scripting is not a technical term. When we call something a scripting language, we're primarily making a linguistic and cultural judgment, not a technical judgment.", Programming is Hard, Let's Go Scripting... by Larry Wall. --mj41 (talk) 12:16, 9 December 2007 (UTC)


[edit] Linden Scripting Language

Although low knowledge + high boldness is a common recipe for disaster on Wikipedia, I've ignorantly + boldly added Linden Scripting Language to the list of Application-specific languages. If this is a problem, somebody please fix it. Thanks. -- Writtenonsand (talk) 03:57, 12 December 2007 (UTC)

[edit] Historical context

I'm considering rewriting this article. Scripting languages can only really be understood from the historical context of the automation of computer operations, which were formerly carried out by human operators. Here's my version of how it happened. Comments and corrections welcome.

The first interactive shells developed to enable remote operation of the first timesharing systems generated a demand for scripting, to relieve the human operator of the tedium of re-entering sequences of commands at a teletype keyboard, so from there were developed JCL macros, the precursors of what we now know as shellscripts. In a parallel development, larger more complex applications developed embedded scripting facilities, at first very rudimentary, to facilitate batch operation.

So strictly speaking, by history and by purpose, embedded languages used for the scripting and extension of applications are distinct from scripting shells associated with computer automation, though there are close affinities.

As scripting facilities approached Turing-completeness, the skills and techniques developed in application programming were brought to bear. The nascent scripting languages acquired variables, sequencing, iteration, decisions, procedures, and even modules. In time some embedded scripting languages became complex enough to be used to extend the application (Emacs is one classic example still in daily use).

General purpose computer scripting became highly developed on UNIX platforms, with a massive proliferation of general purpose shells (Bourne shell, C shell, and their derivatives). The "programming tool" approach of UNIX led to the development of more specialized tools such grep, sed, and awk, which led in turn to the development of perl, Larry Wall's highly successful attempt to improve and supplant the limitations of such tools, which went on to become one of the most widespread scripting tools.

Some mainstream languages, such as Lisp, adapted well to embedding within applications by providing high expressive power in a small footprint. Others, such as Tcl, were specifically designed as general purpose embedded scripting languages. Other systems such as VBA (Visual Basic for Applications) provided strong integration with the automation facilities of the underlying system.

Although historically most scripting languages have been interpretive rather than compiled languages, applications requiring speed require fast extensions. QuakeC, developed for use in scripting the Quake game engine, is an example of a scripting language that is compiled to bytecode which is interpreted by a bytecode interpreter or virtual machine. This isn't exactly new. In the seventies, a common system command and scripting language of DEC's RSTS/E operating system prior to version 9 of the O/S was Basic, compiled to byte-code.

Early web servers generated non-static web content in response to an incoming query by launching a program or shellscript to handle each individual task, but the relatively high cost of launching a process for each query led to the development of server systems such as ASP, PHP, and JSP, which remained memory resident and, of course, came with their own scripting languages specialised for the purpose of serving web content. In using modules scripted in Java, JSP provides a highly sophisticated software engineering infrastructure to web-based scripting.

We should mention keyboard-based and GUI-based macro languages, I suppose, though these tend to be very rudimentary. They can be used for automation of repetitive tasks, and have often been provided as an extra scripting language in applications where they are likely to be useful even to unsophisticated users. --Tony Sidaway 15:16, 15 January 2008 (UTC)

Yikes, I omitted javascript! --Tony Sidaway 15:43, 15 January 2008 (UTC)

I've gone ahead and cleaned up the article, concentrating on removal of the listcruft while ensuring that the more significant scripting languages are mentioned in context. --Tony Sidaway 16:58, 16 January 2008 (UTC)