![[Access to Wang masthead]](images/access96.gif)
|
|
The VS Developer's Guide to Script LanguagesPart 1: Introduction to script languages |
|
From "VS & Beyond", Access to Wang, January 1998 |
|
| [ Prior Article ] [ Return to the Catalog of articles ] [ Next Article ] | |
Over the last several months I've compared the VS development world to that of the distributed applications I work with now. A consistent aspect of Web and multimedia development is the need to work with script languages - small development languages that are used with specific environments to solve specific needs. Some examples include: HTML, VBScript, Java, and JavaScript for web development; shell languages for Unix (C, Bourne, Korn, etc.) that tie processes and small tools together; text processing tools (sed, AWK, grep) that can select, format, and report on textual data; and Perl, which can be used for almost anything listed above.
If you're considering work in any of these new development arenas, script languages will become part of your life, too. You won't have just one language to learn, either; some development environments require the use of one, two, or even more language syntaxes - sometimes all within the same file. The Active Server Page (ASP) Web page listing in Figure 1 shows an example of this, with a mixture of HTML (to describe the page), JavaScript (to confirm field entries), SQL Server (data access), and VBScript (server-side interactivity and page logic).
Fortunately there are similarities that make it easier to master these small languages and learn new ones as they emerge. This month I'll introduce the world of script languages and their general characteristics.
So what makes a script language different from third-generation development languages like C, Basic, or COBOL? There are no definite rules for this division, but here are some general ones:
Not intended for full applications: Script languages are usually intended to perform small tasks that don't require the power or warrant the overhead of a full development language.
Interpreted operation: Almost all script languages are interpreted - analyzed and translated by an interpreter as they run - not compiled into machine instructions prior to use. This makes them considerably slower in execution time but often simplifies development, since it is sometimes easier to step through the program during execution.
Independent: Scripts are often working without direct knowledge or interaction with other scripts. Variables are isolated from other code, so they can be named the same. . No file reads or writes: Most script languages - like Wang Procedure - cannot directly read or write text; instead, they might use programs or system utilities and pass the products to other program or utilities. The most obvious exception - again - is Perl, which has strong file read and write functions.
These rules do not hold up well when specific examples are cited, however. Large Perl applications are available everywhere. (How many of us have written applications using Procedure?) Some scripts become part of an executable file and, thus, are compiled. Several can read or write files. Still, the intent of scripts is to solve small programming problems with less effort.
When approaching any new programming language, it is easier to understand by comparing similar needs and functionality. Common programming language requirements include data types and structures, program decision control and flow, interaction with the user, and specific syntax. I refer to this collection of attributes as the language model.
Most script languages borrow from other development languages for these dimensions. For example, VBScript is a subset of Visual Basic, which itself is derived from the Basic language. In many cases, it is possible to leverage the knowledge gained from experience with high-level development languages to work effectively with script languages. Unfortunately for most of us, the language model most often used for script syntax is the C language - not COBOL - so there may be some adjustment necessary to an alien syntax.
In addition to the language itself, the development environment should be considered when comparing scripts. Some of the parameters in this are include:
Developer support: The availability of support information and code samples to assist in development.
Platforms for development, execution: Specific systems that must be used for development and execution.
Development tools: The editor, debugger, and other tools required to develop and test applications.
Debugging tools: The types of tools available for debugging and how they operate.
The availability of development support information and its location are usually tied to the origins of the language: commercial tools have vendor support and purchased products for specific needs, while public-domain languages have more free support and code samples. Likewise, the development tools and platforms are closely tied with the needs of the language.
Some script languages were developed as publicly-available resources while others are part of commercial products. In general, the script languages that were developed outside of a vendor's direct control (Perl, JavaScript, etc.) have a larger amount of developer activity and support and offer rich libraries of free or low-cost code samples. This partially makes up for the lack of support from a vendor; in some cases, the support from an active developer community can exceed that found from any commercial product. Code samples and libraries (collections of special functions) are usually available for free from public sources. Many of these samples are actually complete applications - some of them quite elaborate.
Vendor products such as VBScript have active developer communities as well, but more often program solutions cost money. For example, a large market developed several years ago for Visual Basic custom controls (programs that offer special functions) that has now expanded to similar small commercial programs for Active Server Pages. Recently I needed to add the capability to send electronic mail from a web page and purchased a small component that adds that functionality to a web server.
Similar web server add-ins are available to provide access to databases, allow web page content to be formatted with more designer control, or change the appearance of a dialog box. In either case, much of this support takes place through Internet connections - via Web sites, electronic mailing lists, or news groups. An e-mail account should be considered a basic requirement when approaching development with a scripting language.
The specifics of platform requirements for script development vary tremendously, but there are some similarities between them. Web scripting languages require a text editor and compatible browser for testing but may also need an active Web server to be present. Sometimes other special conditions must be met, such as server extensions (Active Server Pages) or the presence of a browser plug-in (VBScript, JavaScript). Of course, these special conditions make the development environment more difficult to set up and use.
Since most script languages are interpreted, the related interpreter programs must be available during development and execution. In most cases, the interpreter is part of the target environment for final delivery of the application, so there is no special requirements. For example, VBScript is developed for use with the Microsoft family of browsers, and most of its functionality comes from the language support within those browsers.
The Perl script language is an exception here as in other areas. Perl must be installed on any system that will be used for its development or execution; once in place, the Perl interpreter is invoked whenever needed. (Versions of Perl are available for nearly every computer system ever made, so this is not the problem it might seem.)
Debugging functions in most script languages are typically weak or missing. Some of this is because of the design goals of script languages: small programs for small tasks. Some is also due to the amount of "churn" in the industry; with new development products rolling onto the market daily; it is nearly impossible for manufacturers to keep up with their own pace of innovation.
Wang systems are blessed with a reasonable set of development tools, including a very good symbolic debugger, so the script world will seem a little rugged at first. You will have to use old techniques for debugging, such as displaying the contents of variables on the screen during program execution or writing log files to trace execution.
It's clear that there will be more script languages to learn as information systems evolve to a distributed, network-based form. To meet this need, I'll cover several script languages over the next few months, comparing and contrasting their use and benefits. Join me next time.
Figure 1: Sample ASP File
Protocol or Sample code Language -------------- -------------------------------------------------------- VBScript <%@ LANGUAGE="VBSCRIPT" %> HTML <!-- #include VIRTUAL="/include/setvar.inc" --> HTML <!-- #include VIRTUAL="/include/adovbs.inc" --> HTML <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN"> HTML <html> HTML <head><title>Sample ASP page</title></head> HTML <H2 align="center">Sample ASP Page</h2> SQL Server <% sSQL = "SELECT * FROM SQLtable" SQL Server OpenWebRecordset adOpenDynamic SQL Server rs.Source = sSql SQL Server rs.open %> HTML <form method="POST" action="choice1.asp"> JavaScript <SCRIPT LANGUAGE="javascript"> JavaScript function doDelete(){ JavaScript if (confirm("Delete the current record? JavaScript This operation cannot be reversed.")) JavaScript parent.location.href = JavaScript JavaScript "delete.asp?id=<%=Request.QueryString("id")%>" JavaScript else JavaScript return false JavaScript } JavaScript </SCRIPT> HTML <table border="0" cellpadding="3" HTML cellspacing="3"> HTML <tr> HTML <td valign="top"><strong>Headline</strong></td> HTML <td> VBScript/ <%=rs.Fields("Dbfield1")%> SQL Server HTML </td> HTML </tr> HTML <tr> HTML <td HTML valign="top"><strong>Teaser</strong></td> HTML <td> VBScript <%=sTeaser%> HTML <td> HTML </tr> HTML <tr> HTML <td colspan="2"><center> HTML <input type="hidden" name="RecordID" VBScript/ value="<%=rs.Fields("StoryID")%>"> SQL Server HTML <input type="submit" HTML value="Edit This Record" HTML name="submit_button"> HTML <input type="button" value="Delete This Record" HTML name="submit_button" JavaScript onClick=doDelete()> HTML <input type="button" value="Review Stories" HTML name="submit_button"> HTML </center></td> HTML </tr> HTML </table> HTML