Programming And Testing | Exploring Web Marketing and Project Management

While a project manager need not be a programming guru, it is very helpful to understand what programming languages can accomplish certain objectives. In my Web shop, we use Perl, ASP, and VBScript, to do mission-critical operations and Java Script to deploy operations that enhance the graphics.

However, there are many Web programming languages and applications that can be used to bring a Web site to life.

The following article, "Characteristics of Web Programming Languages," is written by Steve Ford, David Wells, and Nancy Wells, of Object Services and Consulting, Inc.^[*]While it does not cover some of the newer tools, like ASP and Flash (the article was written in 1996 and updated in 1997), Steve, David, and Nancy have put together an excellent resource for the project manager. We will research some of the newer programming tools later in this lab.

^[*]Published on Object Services and Consulting, Inc's Web site www.objs.com/survey/lang.htmCharacteristics

Characteristics of Web Programming Languages

Just as there is a diversity of programming languages available and suitable for conventional programming tasks, there is a diversity of languages available and suitable for Web programming. There is no reason to believe that any one language will completely monopolize the Web programming scene, although the varying availability and suitability of the current offerings is likely to favor some over others. Java is both available and generally suitable, but not all application developers are likely to prefer it over languages more similar to what they currently use, or, in the case of non-programmers, over higher level languages and tools. This is OK because there is no real reason why we must converge on a single programming language for the Web any more than we must converge on a single programming language in any other domain.

The Web does, however, place some specific constraints on our choices: the ability to deal with a variety of protocols and formats (e.g. graphics) and programming tasks; performance (both speed and size); safety; platform independence; protection of intellectual property; and the basic ability to deal with other Web tools and languages. These issues are not independent of one another. A choice which seemingly is optimal in one dimension may be sub-optimal or worse in another.

Formats and protocols.The wide variety of computing, display, and software platforms found among clients necessitates a strategy in which the client plays a major role in the decision about how to process and/or display retrieved information, or in which servers must be capable of driving these activities on all potential clients. Since the latter is not practical, a suite of Web protocols covering addressing conventions, presentation formats, and handling of foreign formats has been created to allow interoperability [Berners-Lee, CACM, Aug. 1994].

HTML (HyperText Markup Language) is the basic language understood by all WWW (World Wide Web) clients. Unmodified HTML can execute on a PC under Windows or OS/2, on a Mac, or on a Unix workstation. HTML is simple enough that nearly anyone can write an HTML document, and it seems almost everyone is doing so.

HTML was developed as part of the WWW at CERN by Tim Berners-Lee, who is now Director of the World Wide Web Consortium (W3C) at MIT's Laboratory for Computer Science. Refinement of HTML continues at W3C, with standardization via the Internet Engineering Task Force (IETF) of the Internet Society. HTML descended from SGMC (Standard Generalized Markup Language), the ISO stan-dard language for text. SGML is in widespread use by the US Government and the publishing industry for representing documents. HTML applies SGML principles to the WWW. As such, it implements a semantic subset of SGML with similar syntax.

HTML is a markup language rather than a complete programming language. An HTML document (program) is ASCII text with embedded instructions (markups) which affect the way the text is displayed. The basic model for HTML execution is to fetch a document by its name (e.g. URL), interpret the HTML and display the document, possibly fetching additional HTML documents in the process, and possibly leaving hot areas in the displayed document that, if selected by the user, can accept user input and/or cause additional HTML documents to be fetched by URL. HTML applications, or what we might consider the HTML equivalent of an application, consist of a collection of related Web pages managed by a single HTTP (HTTP is the tcp/ip protocol that defines the interaction of WWW clients and servers) server. This is an oversimplification, but the model is simple, and the language is simple, and that is one of its strengths.

As HTML moves through the standardization process, and is extended by various vendors, it loses some of its simplicity, but it remains a useful language. The Web programmer generally finds HTML lacking in only two areas: its performance in certain types of applications, and the ability to program certain common tasks.

The remainder of the paper: (a) discusses the issues involved in meeting the performance and expressibility goals while still providing safety, platform independence, and the ability to interact with a variety of formats, protocols, tools, and languages; (b) identifies design alternatives addressing these issues; and (c) discusses a variety of Web programming languages in this context.

Power.HTML is limited in its computational power. This is intentional in its design, as it prevents the execution of dangerous programs on the client machine. However, Web programmers, as they have become more sophisticated in their applications, have increasingly been hamstrung by these limits. Tasks unable to be coded in HTML must either be executed on the server in some other language, or on the client in a program in some other language downloaded from a server. Both solutions are awkward for the programmer, often produce a sub-optimal segmentation of an application across program modules, both client and server, and reintroduce safety considerations.

Performance.Because of an HTML program's limited functionality, and the resulting shift of computational load to the server, certain types of applications perform poorly, especially in the context of clients connected to the Internet with rather low bandwidth dialup communications (<=28.8Kbps). The performance problems arise from two sources: (a) an application which is highly interactive requires frequently hitting the server across this low bandwidth line which can dramatically and, at times, unacceptably slow observed performance; and (b) requiring all computation to be done on the server increases the load on the server thereby reducing the observed performance of its clients.

Today, most users have pretty competent client machines which are capable of accepting a larger share of the computational load than HTML allows. For example, an Internet-based interactive game or simulation can be a frustrating experience for users with low speed connections, and can overwhelm the server that hosts it. If you were the developer of such a game, you'd be inclined to push more of the functionality to the client, but, since HTML limits the possibilities, another route to supporting computation on the client must be found. The developer might make an executable client program available to users, which would be invoked via the HTML browser, but users might only be willing to accept such programs if they trust the source (e.g. a major vendor), as such programs are a potential safety concern. Also, users don't want to be continuously downloading client programs to be able to access Web pages, so this solution has real practical limitations considering the size and dynamism of the Web. If safe powerful high performance programs could be automatically downloaded to client platforms, in much the same way as HTML pages, the problem would be solved.

When code is to be executed on a client, there are two main considerations: what gets shipped and what gets executed. There are three main alternatives for each of these: source code, a partially compiled intermediate format (e.g. byte code), and binary code. Because compilation can take place on the client, what is shipped is not necessarily what is executed.

Byte code, according to measurements presented at the JavaOne conference can be 2-3x smaller than comparable binary code, so its transfer can be considerably faster; especially noticeable over low speed lines. Since transfer time is significant in the Web, this is a major advantage. Source code is also compact. Execution performance clearly favors binary code over byte code, and byte code over source code. In general, binary code executes 10-100 times faster than byte code. Most Java VM developers are developing JIT (Just In Time) compilers to get the benefits of byte code size and binary speed. Java byte codes are downloaded over the net and compiled to native binary on the local platform. The binary is then executed, and, possibly, cached for later executions.

It should be clear that any combination of these strategies could be used in the implementation of any particular Web programming language, and there is in fact wide variation among the systems actually surveyed.

Platform IndependenceGiven the diversity of operating systems and hardware platforms currently in use on the Web, a great efficiency results from only dealing with a single form of an application. The success of HTML has proven this, and Java has seconded it. The ability to deliver a platform-independent application of great appeal to developers, who spend a large portion of their resources developing and maintaining versions of their products for the different hardware/software platform combinations. With Java, one set of sources and one byte compiled executable, can be maintained for all hw/sw platforms.

While platform independence has long been a goal of language developers, the need to squeeze every last ounce of performance from software has often made this impractical to maintain, at least at the level of executable code. However, in the Web this concern becomes less important because transfer time is now a significant component of performance and can dominate execution time.

Platform independence can be achieved by shipping either byte code or source code. One advantage of shipping byte code over source code is that a plethora of source languages would require the client machines to maintain many compilers and/or interpreters for the source languages, while fewer byte code formats would require fewer virtual machines.

Preserving intellectual property.Although not currently discussed much as an issue, the ability to download safe, portable applets in some form less than source code is an additional advantage to developers who wish to protect their intellectual property. Looking at someone else's script or source to see how they do something and just tweaking it a little or copying a piece of it to do the same thing in one's own program doesn't feel like stealing. But if one has to go to the effort of reverse engineering byte or binary code, it becomes more obvious that this code is someone else's intellectual property. For the vast majority of honest people on the Web, this subtle reminder may be enough. For some of the minority, the effort involved in reverse engineering may serve as a sufficient deterrent.

Safety.Viruses have proven that executing binary code acquired from an untrusted, or even moderately trusted, source is dangerous. Code that is downloaded or uploaded from random sites on the web should not be allowed to damage the user's local environment. Downloading binary code compiled from conventional languages is clearly unsafe, due to the power of the languages. Even if such languages were constrained to some ostensibly safe subset, there is no way to verify that only the safe subset was used or that the compiler used was trustworthy (after all, it is under someone else's control).

HTML proved that downloading source code in a safe language and executing it with a trusted interpreter was safe. You can't infect a client with a virus by fetching and displaying an HTML document (although you certainly can fetch a file with a virus in it, which could then be activated by executing the file, something which is not supported directly by HTML, although some browsers allow it). HTML is not sufficiently powerful. A middle ground is being sought in which the downloaded program is less limited in its capabilities than HTML and more limited than a conventional language. Even though HTML has limited power, the general idea behind HTML, that of a somewhat limited language interpreted by a trusted client-side interpreter, has been widely adopted with more powerful languages and interpreters.

Some languages achieve relative safety by executing byte-code compiled programs in a relatively safe runtime environment (a virtual machine). Yet other languages are fully interpreted on the client by an interpreter provided by the language developer. In either case relative safety can be achieved because the interpreter or virtual machine can make safety checks that are impossible to make statically at compile-time. Note that safety can only be provided by the interpreter or virtual machine, not by the language or the language's compiler.

Building a secure virtual machine is a non-trivial task. Not many virtual machines are needed since a single virtual machine can be the target of many languages.

This is not to say that lack of safety or platform-independence disqualify a language for a role in Web application development, but for dynamic applications likely to be downloaded from untrusted sources with current browsers and executed locally on mainstream platforms, a safe and platform independent executable is highly desirable. At the other extreme, the interpreters and runtimes that execute such programs are likely to be developed using unsafe languages and platform dependent executables will be distributed by their developers. For programs intended for execution on servers, there is some value to safety and platform independence, but not to the same degree as on clients.

Conclusions.HTML is proving insufficient by itself to develop the myriad Web-based applications envisioned. As extended by server and client programs, the task is feasible, yet awkward and sub-optimal in terms of performance and safety. The ability to easily develop sophisticated Web-based applications optimally segmented between client and server in the context of the heterogeneous and dynamic environment of the Web while not compromising safety, performance, nor intellectual property, is the goal of current efforts. The first significant result of those efforts is Java, a C++-derived language with capabilities specialized for Web-based application development. Java is compiled by the developer to a platform-independent byte code format, with byte codes downloadable via HTML browsers to the client, and interpreted by a virtual machine which can guarantee its safety. Sun is working to improve the safety, performance, comprehensiveness, and ubiquity of Java, and the industry appears to be accepting their approach. Others, especially other language developers, vendors and users, are taking similar approaches to developing Web-based applications in their languages, by supporting safe client-side execution in some manner, including targeting the Java Virtual Machine.

While Java certainly has the edge at the moment, a belief which was reinforced by the 5000+ attendance figure at the JavaOne conference in May 1996, we believe there is room for more than one winner, and that an end result somewhat broader than just Java would be in the best interest of developers and users alike.

Safety is the biggest issue. The safety of a program is a function of the safety of the environment in which it executes, which is just another program. At some level, the user must acquire a potentially unsafe program from a trusted source. At present, we acquire Netscape, Java, and Windows from trusted (relatively) sources. Because there must be a trusted environment in which to execute safe, platform-independent programs and because users are only likely to trust a limited number of big name sources for that trusted environment, there has been speculation that diversity, including diversity in Web programming language choices, would be reduced. While this could become true, it now appears unlikely because language developers are proving that they can retarget their programming language to someone else's execution environment. A more reasonable view of the future is a full diversity of programming languages supported by a few trusted execution engines. At present, most efforts are targeting Java's Virtual Machine(VM), mainly because it is widely distributed with Netscape and is being licensed by other browser vendors. It's possible that the Java VM ends up being the onetrusted execution environment, but it will probably be one of several general purpose execution environments, that together with many special purpose environments, will be distributed by trusted sources. An ideal outcome might be industry-wide standardization on a trusted virtual machine specification and validation of implementations by an industry group such as X/Open. Regardless of how it occurs, we do not think diversity of programming language alternatives will be reduced in the long term. However, it is likely that we will see some narrowing of our choices in the short term as language developers adapt their existing offerings to this new area and develop new ones.

The rest of this document surveys languages and interfaces being used for Web programming, attempting to provide a snapshot view of the direction that language is going to meet the needs of Web programmers, and its status.

Languages and Interfaces

The languages and interfaces surveyed below represent various attempts to create the "ideal" Web programming language, usually by extending and restricting existing languages. Web programming languages have a variety of ancestors: scripting languages, shell languages, mark-up languages and conventional programming languages. The resultant Web programming languages show their ancestry in their syntax, computational and data model, and implementation style (subject to the design constraints discussed in the previous section), and as a result, there are a fair number of distinct approaches taken. However, it is instructive to note that the original language categories tend to blur as development progresses.

The surveyed languages are listed in alphabetical order. If you intend to read the entire survey section, you should first read about Java, Tcl, Python, and Perl, as many of the other languages are compared to them.

Not all relevant languages are discussed. Some entries consist only of a link. They are languages we've seen mentioned as applicable to web programming in some way, but haven't investigated further. We hope to do so in the future.

Ada95

Ada95 is the latest version of the Ada programming language, which now supports object-oriented programming. Ada is used widely in government and industry

AppleScript

AppleScript is Apple's object-oriented English-like scripting language and development environment for the Macintosh. It is bundled with MacOS, and is used widely for all variety of scripting tasks on the Mac. Recently, it has been applied to web programming tasks. Web-Runner enables the execution of AppleScript scripts embedded in HTML files to be executed on a client running Netscape. The most widely used HTTP servers for the Macintosh, MacHTTP, a shareware product, and WebStar, its commercial sibling, both use AppleScript for recording and CGI scripting.

BEF

BEF is an object-oriented PASCAL-like scripting language for describing behavior in VRML.

CCI (Common Client Interface)

NCSA Mosaic CCI (Common Client Interface) is an interface specification (protocol & API) that enables client-side applications to communicate with NCSA Mosaic, the original Web browser, to control Mosaic or to obtain information off the Web via Mosaic. Note that this is not for invoking client-side applications (applets) from Mosaic, but for controlling Mosaic from the application. Invocation of client-side applications from a browser is currently specific to the browser, but most support NCSA helpers. Once the application is running, it can communicate with the browser with CCI. CCI is not the only interface currently defined for this purpose, but it seems to be meeting with some acceptance, as Tcl and Perl now support it.

CGI (Common Gateway Interface)

A Web daemon executesa CGI program on the server and returns the results to the client (e.g. a query against a database server), rather than simply returning a copy of the referenced file, as it does with an HTML reference. Parameters are passed from the server to the CGI program as environment variables. The program is sometimes written in C, C++, or some other compiled programming language, but more often it is written in a scripting language (e.g. Perl, Tcl, sh). To prevent damage to the server, CGI programs generally are stored in a protected directory under the exclusive control of the webmaster.

CMM

Cmm, now renamed ScriptEase: WebServer Edition, is a streamlined version of the C computer programming language. C and Cmm differ in one major area: memory management. With Cmm all memory management is handled automatically, so there is no need to create buffers, declare variables, or cast data types.

With this major exception, Cmm and C are virtually identical. Cmm supports all of the standard C functions and operators (including structures and arrays), and they are used in the same way as in C. For use with CGI programming, Cmm provides specialized functions to easily get data from forms and to create HTML pages on the fly.

Dylan

Dylan is a dynamic object-oriented programming language with a pascal-ish syntax, and a lisp-ish semantics. It was designed at Apple's Cambridge lab in cooperation with Carnegie-Mellon University and Harlequin, Inc., and reviewed by its potential user community, mostly former Common Lisp programmers disenchanted with C++. The goal of the designers was to create a language with syntax, performance, and executable footprint acceptable to mainstream programmers (i.e. C/C++), but with many of the characteristics that programmers value in Lisp (e.g. evolutionary development, optional type declarations, runtime safety, automatic storage management, and ease of maintenance). In late 1995, Apple released its implementation for the Macintosh as an unsupported $40 "Technology Release", and then, for the most part, shut down the Dylan project, although an effort to port Dylan to MacOS on the Power PC appears to have survived. CMU has developed a byte-code compiled version of Dylan called Mindy that runs on several Unix platforms and on Windows NT, and it continues development of a native Unix compiler. Harlequin plans the release of its native compiler and development environment for Windows NT and Windows 95 in mid-1996. See for a comparison of Common Lisp, Dylan, C++, and Java. Scott Fahlman states that Dylan is better suited to complex programming tasks than Java, and "can also be a good language for building safe, Web-mobile code", although I have not seen any effort to apply Dylan to the latter task.

Guile

Guile is GNU's extension language library. It includes a virtual machine, a run-time system, and front ends for multiple languages (e.g. Scheme, Ctax (scheme with C syntax, Emacs Lisp (future)). Guile interacts at several levels with Tcl/Tk. The VM can call Tcl programs, and, therefore, the front end languages can call Tcl programs. The Tk library is also accessible in this way. Tcl programs can call Guile programs written in any of the extension languages, like Scheme. The Guile Virtual Machine is similar to Java's. A byte-code interpreter is being developed. Guile is implemented in a mix of Scheme and C, and C and Scheme libraries are available to programmers using the extension langauges. TkWWW, GNU's Web Browser, written in Tcl, is being adapted to work with Guile.

HyperTalk

HyperTalk is the English-like scripting language for Apple's Hyper-Card. It's described by its fans as similar to AppleScript, but simpler and more forgiving. Given the large number of HyperTalk-literate programmers in the Mac world, HyperTalk might very well be preferred by many over AppleScript and UserTalk for many web scripting tasks on the Mac.

Icon

Icon is a full-featured programming language developed at the University of Arizona with a C-ish syntax and a SNOBOL heritage, making it particularly suitable for string processing, and, therefore, similar in this way to other languages being used for Internet programming. I've seen Icon mentioned in this context, but haven't come across any active efforts towards that end.

Java

Java is the leading contender for a full feature programming language targetted at Internet applications. Its advantages are: familiarity (derived from C++), platform independence (will run on any platform which implements the Java Virtual Machine), performance (byte-code compiled faster than fully interpreted), and safety (downloaded applets are checked for integrity, and only interpreted by trusted Virtual Machine). Java is being aggressively distributed and promoted by Sun Microsystems, which developed it, and, evidently, sees it as a way to loosen Microsoft's and Intel's grip on the computer platform. Netscape, the leading web browser, now includes the Java VM, and Java applets are appearing on Web sites everywhere. Even Microsoft, which is promoting Visual Basic Script for this purpose, has licensed Java from Sun and will be supporting it in its browsers. The list of Java licensees is long, and includes other major players, like DEC and IBM. Sun is distributing a Java developers kit free of charge as of this writing, in the interest of promoting Java's widespread use. It recently announced the development of microprocessors optimized for Java for different markets (from cellular phones to high performance 3D "Network Appliances.") If their strategy is successful, the application platform is raised, and Java displaces Windows or other OS's as the target platform of application developers, then the whole ballgame changes, and the impact is potentially across the entire computer industry, not just the Internet. The ability to deliver a platform-independent application, or, more correctly, an OS-independent application, is of great appeal to developers, who spend a large portion of their resources developing and maintaining versions of their products for the different hardware/ software platform combinations. With Java, one set of sources, and, even more important, one byte compiled executable, can be delivered for all hw/sw platforms. While interpretation of byte-compiled program is slower than execution of a native executable, the claim is made that, once interpreted, the resulting executable is of comparable performance, which means Java apps could be interpreted once and the result cached locally, and thereafter executed optimally. This is great news for Unix, OS/2, and Macintosh vendors and users, who often suffer from limited or delayed availability of software and high prices due to limited demand, and, likewise, for non-Intel chip and computer vendors. It's potentially disastrous news for Microsoft and Intel, who, arguably, often sell their products solely on the basis of their market position, rather than their technical merit. Hopefully, the result will be a more level playing field for vendors and more choice for consumers, and not just the replacement of Microsoft and Intel with Sun and Netscape.

That said, not everyone agrees that Java is the answer. The most common complaint is that Java is not simple; it's basically a slimmed down, cleaned up C++, with a big GUI library. C++ programming is not described by most as "simple", and Java programming is not much simpler, especially when compared to HTML, or some other languages put forward as its competition. Java is the market leader at the moment, so it is the obvious target.

HORB is a freeware implementation of a superset of Java.

Jylu adds support for Java clients and servers to Xerox's ILU, a sourceware ORB that supports interoperability between programs written in Python, Common Lisp, C, C++, and Modula-3.

JavaScript

JavaScript (nee LiveScript) is Netscape's scripting language for integrating HTML, Netscape plug-ins, and Java applets. It is based on Java, and is mostly syntactically compatible, but differs from Java in that it is interpreted, rather than compiled, only supports built certain built-in objects and user-defined functions, rather than full support for user-defined classes with inheritence and methods, is integrated with HTML, rather than invoked from HTML files, weakly typed, and dynamically bound. JavaScript is meant to extend HTML to be more of a full programming language, but retaining HTML's ease of use. The principal criticism of Java programming is that it is muchmore complex than HTML programming, more like C++ programming, and therefore is not as accessible to users as HTML. This is an issue that JavaScript attempts to address.

KQML (Knowledge Query and Manipulation Language)

KQML is a language for describing the exchange of information among agents. Agents are one of the paradigms for how knowledge is accumulated and processed in a distributed heterogeneous environment like the World Wide Web. Telescript uses the agent paradigm. Standards for the interoperability of such agents are crucial to their use on the web, and KQML and its siblings provide such a standard.

Linda

Linda is an extension language for extensible Web browser architecture.

Lingo

Lingo is the object-based scripting language for Macromedia's multimedia authoring system created by John Thompson. It is often compared to ScriptX, Telescript, Java, Tcl, and HyperTalk, resembles the latter most, but it is more special purpose than any of those. It is specific to Director, which is used extensively for authoring CD-ROM titles, and is not available separately, which limits its applicability to other purposes. With the release of ShockWave,a free Netscape plug-in, software developed with Director can be displayed in Netscape, and soon other browsers.

Lisp

Lisp is a lisp processing language created for artificial intelligence research by John McCarthy at MIT in the late fifties.

Common Lisp is the dialect of Lisp with the most widespread current use, especially for large complex systems (esp. artificial intelligence) in industry, government, and academia. It was designed in the early eighties with some DARPA sponsorship by representatives of the several lisp dialects in use at that time as a way to converge on a common dialect. There is some use of Common Lisp for Web-based server applications. CWEST is a tool to convert CLIM GUIs to HTML and GIFs for display with a client's browser. CL-HTTP is an HTTP server implemented in Common Lisp and targeting the intersection of the interactive hypermedia and artificial intelligence research domains. Harlequin, the vendor of a commercial Common Lisp, offers WebMaker, which enables conversion of Framemaker documents to HTML.

Scheme is a statically scoped dialect of Lisp in widespread use, primarily in academia for research and educational purposes. Scheme 48 is an implementation of Scheme that compiles to a byte-code representation that is then executable by a Virtual Machine, much like Java does. The Scheme Underground is an MIT project aimed at developing a substantial body of Scheme48 software, including software appropriate to the Internet (e.g. TeX->HTML, Web agents, tk).

Emacs-Lisp (Elisp for short) is the dialect of Lisp used to implement and extend the Emacs text editor, which was developed at MIT in the sixties. It is similar to Common Lisp, but smaller and free, and is in very large distribution, as it comes with Emacs. A browser, GNU-scape Navigator, has been implemented in, and is extensible with, Elisp. Due to its widespread use as a scripting language, its small size, and the long-term Internet-awareness of its large user base, I would have expected to see some effort to apply Elisp to client-side applet execution, but I see no evidence of such an effort.

WINTERP is a GUI development environment comparable to Tcl/Tk and Python, but based on XLISP-PLUS, a small object-oriented lisp implementation, and including interfaces to the X Windows and Motif libraries. WINTERP runs on a variety of Unix platforms (XLISP runs on a variety of platforms), but has not been ported elsewhere. While WINTERP seems as suitable for adaptation to Internet programming as Tcl/Tk and Python, I see no effort to move it in that direction.

Perl

Perl is described as a compiled scripting language. It combines elements of C with some Unix scripting and text manipulation languages (e.g. sh, awk, sed) into a more complete language that subsumes the functionality of all into one consistent whole, and is compilable, and, therefore faster than its forebears. Perl's advocates tout its ease of use when comparing it to Java, especially. One of the motivations in developing Perl was to provide an alternative to C for tasks that were a little too hairy for an existing Unix tool, or where performance was an issue. C was seen as unnecessarily low level, and C development too time consuming. Perl tries to delay the need to program at a lower level. Its been very successful, especially among system administrators. Since CGI scripts are often built by systems folks, Perl is widely used for this, too.

The major difference pointed out between perl and tcl is that perl is somewhat faster because it is partially compiled and optimized, which dramatically reduces the parsing and reparsing required in tcl. There is also a heavy bias in tcl, and in other shell languages, towards string manipulation, which gets in the way when using tcl for programming types other than strings. On the other hand, tcl is simpler, and more useful as a meta-language, in developing special purpose languages, as it does with tk.

Perl's roots in the world of Unix system administration (e.g. C, awk, sed, sh), and its much larger user base, are the primary differentiators between Perl and Python.

Perl advocates eschew Java's greater complexity, and incredible hype. On no subject do emotions run hotter. Perl predates Java, better suits internet programming than Java, they say. A common comment is that Perl has proven to be a good language for this purpose, but there are other good languages. There are some reasons to believe Java might also be good, although there is counter evidence also, but, overall, there is no evidence that Java should be the one and only client extension language for the Internet, but it is being promoted as such by Sun and Netscape, and that infuriates users of other languages.

Perl, as a programming language, doesn't offer the graphics and security desired for Internet programming. Not to worry; those features are now available. Perl/TK extends Perl with access to the Tk GUI library (from tcl/tk). Penguin is a Perl module that enables perl code to be sent encrypted and digitally signed to a remote machine over the Internet, and executes such code in a secure, limited environment. Pgpsafeperl and LPSP (limited pgpsafeperl) are, I believe, names for Penguin precursors. The two together are equivalent (to some, superior) to Java. Perl CCI enables NCSA Mosaic CCI programs to be written in Perl. Safecgiperl executes CGI programs written in Perl in a safe environment on a WWW server.

Phantom

Phantom is an interpreted language targeting large-scale, interactive, distributed applications such as distributed conferencing systems, multi-layer games, and collaborative work tools. Phantom combines the distributed lexical scoping semantics of Obliq with a safe, extended subset of Modula-3. Objects, static-typing, threads, exceptions, garbage collection, and an interface to the Tk GUI toolkit, are included.

Python

Python is an interpreted, object-oriented language developed as a full-featured, but easy to use, scripting language, by Guido van Rossum at CWI in the Netherlands. Initially developed in a Unix environment, Python is now available on PCs and Macs, and applications are portable across platforms. Python has developed a substantial, although still modest, following, as a scripting language, an application development language, and an embedded extension language. Python's design was most influenced by ABC, a little known language also developed at CWI. Python's syntax evokes C and C++, but doesn't stick too closely to those languages. Python fans tout its clear, intuitive syntax in comparison to C, C++, Java, Perl, shell languages, and most other interpreted languages, the completeness of its type system and its suitability for significant application development in comparison to Tcl , and its extensibility with Python and C/C++ libraries. Like Java, Perl and Tcl, Python offers a portable GUI library, several really. Perl advocates complain about the lack of regular expression matching and output formatting natively in Python. Perl is a little more of a sysadmin's shell language than Python, and Tcl is a little simpler and less capable. Python is more of a regular programming language, but simpler and easier to program than Java. But, all are suited to Internet programming. Safe-Python is a design for changes to add safety to Python. Grail is a web browser which supports the download and execution of Python applets in a safe Restircted Execution Mode. Grail uses the Tk GUI library.

REXX

REXX is IBM's dynamic scripting and extension language, developed by Mike Cowlishaw at IBM's UK Labs in 1979. It is descended from EXEC, the command language for IBM's CMS operating system, and influenced by PL/I. REXX is used extensively on IBM platforms, especially OS/2, and is now available for other platforms (e.g. DOS, Windows, UNIX). REXX is like Tcl in that it is simple and the string is its only data type. REXX is easily interpretable, and many is often implemented only as an interpreter, although compilers are available. Object REXX extends REXX with object-oriented semantics, by adding objects, classes, and methods to REXX's strings and functions. It also adds a number of predefined classes. Object REXX programs can interact with Smalltalk, C, or C++, programs via SOM (or DSOM, IBM's OMG CORBA-compatible extension to SOM, for distributed interaction). IBM is also developing a VisualAge-based GUI builder and visual application development environment for Object REXX. Object REXX is being used by NIIIP, a US-government sponsored consortium aimed at facilitating electronic commerce on the Internet. NetRexx is REXX's response to Java, a REXX to Java translator that permits REXX programs to be delivered as Java bytecodes, and executed on client platforms with the Java Virtual Machine, combining the ease and efficiency of REXX programming with the performance and wide availability of the Java VM.

ScriptX

ScriptX, a multimedia object-oriented programming language, was the principal technology produced by Kaleida Labs, a joint venture of IBM and Apple started along with Taligent and PowerPC. Kaleida Labs was shut down late in 1995, with ScriptX considered two years behind schedule and having lost a significant portion of its potential market to MacroMedia's Lingo. Release 1.5 of ScriptX and the associated Media Player (required to view ScriptX scripts) was announced in January, as control was passed to Apple.

ScriptX proponents tout its platform independent persistent object store, and rich multimedia class library. One use of the former is as a local cache for applets retrieved over the Internet.

SDI (Software Development Interface)

Spyglass SDI (Software Development Interface) is the main competitor to NCSA Mosaic CCI (Common Client Interface). The expectation is that SDI and CCI will eventually converge into a common specification. In addition to what CCI offers, SDI also provides a protocol for initiating messages from the browser to the client application. This protocol causes the application to be informed when the certain events occur on the browser or actually diverts handling of those events to the application. This addition makes SDI an appropriate protocol for invoking a new client application from a browser. The Netscape Navigator Web browser supports SDI under Windows and MacOS.

sh, csh, ksh, bash, tcsh, rc, zsh (UNIX shell languages)

In Unix-speak, a shell is the user's command-level interface to the operating system. The Bourne shell (i.e. sh) was the initial Unix shell, and still is the most widely used, but, over the years, other shells were developed, differing primarily in the syntax and semantics of the command languages they implemented. Other Unix shell languages are csh (C shell), ksh (Korn shell), bash (Bourne again shell), tcsh (Tenex C shell), rc, and zsh (Z shell). I won't go into the differences here. My point here is that these shells are essentially interpreters for scripting languages, and are commonly used on Unix platforms for a variety of programming tasks, especially by system administrators, including Web site maintenance chores like CGI scripting. Newer languages used in this context, like Perl and Tcl, were heavily influenced by the shell language forebears, and were generally developed to deal with the ever increasing complexity of scripting tasks, and the desire to apply such high-level languages to somewhat different tasks. Perl is a case of the former, Tcl a case of the latter, with the new task being quick development of GUI interfaces.

Smalltalk

Smalltalk is a dynamic, object-oriented programming language with an integrated GUI development environment and execution environment. It has a considerable following. It was developed by Alan Kay and others at Xerox PARC in the early seventies. Smalltalk is the central language of the object-oriented programming community. The fully integrated nature of Smalltalk has been both a strength and a weakness. It provides a very consistent conceptual model and look and feel across all components of the system, but this also serves to accentuate the disconnect between it and more conventional languages. This has also been observed of Lisp and APL. It has kept the Smalltalk world somewhat isolated from the rest of the application development world, although the rise of the object-oriented analysis and design, the success of C++, and the adoption of the object-oriented model as a standard for interoperability in many domains has brought Smalltalk into the mainstream in the last several years. Smalltalk's dynamic nature, and extensive GUI orientation, make it a natural for Internet programming, but the Smalltalk community has been slow to capitalize on this.

ParcPlace-Digitalk recently introduced VisualWave, which facilitates the use of Smalltalk in Web-based applications, by generating the CGI between the HTTP server and a Smalltalk application, and by generating the HTML necessary to provide a GUI for the application in conjunction with a Web browser. VisualWave does not appear to include the ability to safely deliver and execute Smalltalk applets on the client platform, although the source is evidently portable, and connectivity with OLE, CORBA and Java is planned. The former is likely to result from their recent licensing of HP's Distributed Smalltalk, which adds CORBA compatibility to ParcPlace's Smalltalk. Whether the latter means the generation of Java byte code applets from Smalltalk is not known.

IBM has announced WWW Parts for Visual Age for Smalltalk. The latter combines a visual application builder with IBM Smalltalk and SOM (and DSOM, IBM's OMG CORBA-compatible extension to SOM), to enable applications built graphically in Smalltalk to use components separately developed in other language. WWW Parts seems comparable to ParcPlace's VisualWave, described above.

If GNU Smalltalk is going to be an extension language for Guile, I haven't heard about it.

Tcl

Tcl (tool command language) is a widely used scripting language generally used in conjunction with the Tk GUI library for building quick and easy X windows GUIs on Unix platforms, but also valued for the ease by which C libraries can be imported and referenced from Tcl. Tcl/Tk was developed by John Ousterhout while at UC Berkeley. Development continues at Sun Labs under his leadership. It's interesting to see this going on at Sun, also Java's home. Java is probably Tcl's principle competitor. John Ousterhout addresses this in his article, "The Relationship Between Tcl/Tk and Java." His point is that it's true that both languages are appropriate to Internet programming, but they are different, have different strengths, and are likely to complement each other. Tcl is higher level, quicker to program, and slower to execute; Java is lower level, harder to program, quicker to execute. Tcl is mainly used to tie together other programs, generally written in C or C++. John expects Java to replace C++ in this role for Internet applications. This role puts Tcl in competition with Javascript.

A couple of years ago, Tcl was receiving the kind of attention that Java is receiving today, lots of it, with some of it overhyping Tcl's benefits, and some of it defensively attacking Tcl's weaknesses-the downside of success.

ftp://ftp.perl.com/pub/perl/versus/tcl-discussion and ftp://ftp.perl.com/pub/perl/versus/tcl-complaints compare Tcl to Perl. In the interest of hugely oversimplifying the arguments, let me summarize by saying that Tcl critics think Tcl is incomplete, inelegant, and inefficient. Its proponents say it is quick and easy to program for what it was intended.

There's quite a bit of activity at Sun, and elsewhere, that extends Tcl/Tk towards being more appropriate for Internet programming. Ports are underway (some are already available) to MS Windows et al and MacIntosh, so that scripts will run on any platform. A Tcl/Tk GUI builder and an on-the-fly Tcl compiler are being developed. Safe-Tcl adds security to Tcl. Sun is integrating Safe-Tcl into their release. ccitcl integrates Tcl/Tk, Safe-Tcl, and NCSA Mosaic CCI into a solution for client-side scripting for the WWW. Expect extends Tcl for interacting with other interactive programs or users. TclDii provides a Tcl interface to the OMG CORBA Dynamic Invocation Interface (i.e. Iona's Orbix), enabling Tcl scripts to interact with CORBA services.

Telescript

Telescript is General Magic's interpreted, object-oriented language with for remote programming. It uses an active agents paradigm. Agent programs are sent to places where they execute, possibly in conjunction with other agents. Agents can move themselves to new places to execute, taking their state with them. Places are subprocesses associated with a Telescript Engine, which is a server program that may be integrated with an HTTP server (with CGI) to produce what they describe as an active Web server. This is similar architecturally to ParcPlace's VisualWave and IBM's WWWParts, both for Smalltalk. Agents are mobile in that their site of computation can move from one place to another, but they can only execute in the context of a Telescript engine, so agent programs should not be considered client programs, as Telescript provides no runtime support on the www client side to execute agents. This separates them from Java applets, for instance, which move computation from web servers to clients. Telescript moves computation in a different direction, from one web server to other web servers. The Telescript language itself is similar to C++, but is specialized to support the agent paradigm with built-in support for moving agents and interacting with other agents, and supports advanced memory management, including the persistence of all objects. Like Java, Telescript is safe and platform-independent.

See http://www.sunlabs.com/people/john.ousterhout/agent.pptfor a comparison of Tcl, Telescript, Visual Basic, and Java by John Ousterhout, Tcl's creator.

http://www.genmagic.com/About/Releases/prre1960129.htmlexplains the difference between Telescript and Java.

Frontier is another popular script development environment for the Macintosh, which comes with its own scripting language, UserTalk. It was developed by Dave Winer of UserLand Software. Frontier is used to develop scripts in UserTalk, or AppleScript, or any other scripting language conforming to Apple's Open Scripting Architecture (OSA). For the same reason, UserTalk scripts can be developed with AppleScript tools, and CGI scripts, and other web-related scripting applications, can be written in UserTalk, and/or developed in Frontier. For instance, CGI scripts for WebStar can be developed in UserTalk with Frontier.

VBScript (Visual Basic Script)

VBScript is Microsoft's planned candidate for an Internet scripting language. It is expected in mid-1996. It is a subset of Visual Basic, Microsoft's popular visual programming language, with no GUI building capability, with unsafe operations removed, and with access to other applications via OLE. VBScript source code is embedded in HTML, and downloaded to the client in the HTML file, where it is compiled and executed in association with its runtime libraries. Microsoft envisions an OLE Scripting Manager on the client-side with which browsers interact with a specified interface. The Scripting Manager would manage compilation and invocation of downloaded scripts in Visual Basic Script or any other scripting language. Microsoft also intends to support Visual Basic and Java in this way. The idea is to make multiple language runtimes pluggable into browsers. Microsoft intends to elicit the cooperation of various consortia and vendors in defining and standardizing this interface. Microsoft intends to support VBScript on its various Windows platforms and on the Macintosh and will license the technology to UNIX vendors.

VRML (Virtual Reality Modeling Language)

VRML is a specialized language for describing 3D worlds and movement through them. VRML is the standard language in describing such scenes in the context of the Internet and the World Wide Web. As more and more sites include 3D simulations, VRML will become more omnipresent. VRML, like HTML, is downloaded from a server and executed using an interpreter on the client, just as a Java applet might be downloaded and executed. Netscape now supports such an interpreter, and there are many others.

WebScript

WebScript is the object-oriented scripting language for NeXT Software's development environment for Web-based applications. WebScript is an interpreted subset of Objective-C, in much the same way that JavaScript is a subset of C++. WebScript, however, is used in WebObjects primarily for Web server scripting, where CGI and Perl might be more commonly used, rather than for client-side applets. WebObjects is expected to support Java and JavaScript on the client side, and JavaScript on the server side, in addition to WebScript, which may relegate WebScript to the scripting language of choice only for Objective-C users.

There was also another WebScript, from WebLogic, Inc., which has since been renamed htmlKona. It is a Java package for generating HTML pages.

As a project manager, you do not need to know how to code an SQL database using Active Server Pages and VB Script. However, it's important to know the limitations of using these programming tools to accomplish this task. By introducing you to these programming tools and descriptions, it is hoped that you will be able to understand which tools offer the best functionality for the task at hand.

Exercises

Oversee Coding

Research and write descriptions for three relatively new programming tools. What are their best applications?

__________________________________________________________

A subcontractor fails to produce the functionality that has been contracted. What is your fall-back plan?

__________________________________________________________

Your company is dealing with a new programming language. There is a significant learning curve and the project is falling behind schedule and beyond budget. What are your options?

__________________________________________________________

Oversee Testing

How would you verify that the Web site has been adequately reviewed for quality control purposes?

__________________________________________________________

Who would you have testing the Web site? What would their objectives be?

__________________________________________________________

Exercise Answers

This section gives you some suggested answers to the questions in Lab 12.3 with discussion related to those answers. Please post any alternative answers to these questions at the companion Web site for this book, located at http://www.phptr.com/phptrinteractive.

Answers

a)	Research and write descriptions for three relatively new programming tools. What are their best applications? __________________________________________________________ __________________________________________________________ __________________________________________________________
Answer:	*Macromedia Director 7* Used to build applications that enable real-time animation with graphics, sound, text, and video. Essentially, Director creates Shockwave multimedia content. Director supports Java, HTTPS, XML, and more. {Private} The Director 7 Shockwave Internet Stu-dio specializes in creating multimedia productions, including interactive Web content (using Shockwave Player or Java), business presentations, interactive advertising, and CD-ROM or DVD-ROM titles and games. In comparison, Flash produces vector graphics and animation, including navigation interfaces, technical illustrations, and long-form animations. Flash files can play back using the Flash Player, Java, Director projectors, or Shockwave Player. *XML* Also known as eXtensible Markup Language, XML is a new specification being developed by the W3C. XML enables developers to create customized tags to provide more functionality than HTML. XML programs are not yet supported by current Web browsers. However, Microsoft has committed to supporting XML in Internet Explorer sometime in the future. XML's usefulness depends solely on its ability to be deployed cross-platform. Once Internet Explorer supports XML, it will become a player. In my opinion, its only use right now is on intranets, where XML-enabled browsers can be loaded onto company machines. *Active Server Pages* ASP is the scripting language supported on the NT platform. It allows the developer to embed functionality similar to that of Perl-providing the user with an interactive experience. The main difference between Perl and ASP is that Perl must be installed in the cgi-bin on the server side. However, ASP can be embedded right into the HTML code. ASP can be used to access databases, set up in SQL Server or Oracle, and provide the user with searching capabilities and other personalized interactive sessions.
b)	A subcontractor fails to produce the functionality that has been contracted. What is your fall-back plan? __________________________________________________________ __________________________________________________________ __________________________________________________________
Answer:	First, you have to assess whether the subcontractor has generated substantial performance. What are the reasons why the subcontractor has failed to produce? Arethey on the client side? Have they completed 70% of the requirements and were unable to finish because of any unreasonable expectations? If the problem truly resides on the subcontractor side, then you, as the project manager, have the ability to cite the project specification and programming plan and ask the subcontractor to accept a reduction in fee, based on the amount of programming modules actually completed. If the subcontractor is leaving modules only half completed, then it's difficult to determine if the programming is even functional. Therefore, payment really needs to be made for functioning modules. Also, it is always good to have several programming shops as outsourcing possibilities. Therefore, if a firm just cannot complete that ASP script, the project manager should be able to call on another ASP firm to fill in. This is where a project manager needs to be fair. If the blame could possibly be laid at the contracting firm's feet or the client, the problem is really out of the subcontractor's control. If the client's requirements keep changing, it is up to the project manager to manage the client,*not*to expect the subcontractor to bear the burden of the client's changes, when most likely the sub has flat bid the project. This is how a project manager can easily alienate good firms and sharp programmers.
c)	Your company is dealing with a new programming language. There is a significant learning curve and the project is falling behind schedule and beyond budget. What are your options? __________________________________________________________ __________________________________________________________ __________________________________________________________
Answer:	First, I feel that the client should never have to bear the burden of a learning curve. While the Web firm may feel that a particular project may be a good opportunity to get its feet wet with a new level of functionality, the extra costs associated with this should not be passed on to the client. This is true, unless the client is looking for something extremely new and innovative, which would takeanyfirm some research and development to complete. This is the only circumstance in which I feel it's ethical to pass these costs along. Too many times I've heard of people just completing their first HTML class taking on a freelance Web project. If the new developer charges time and materials, unless it's about $5 an hour, the client is probably going to be paying too much. When the client figures this out, the freelancer's reputation is damaged. How do you plan for this? Figure out how much a more experienced firm would charge to do this kind of work and then flat bid it. Any type of project that has a learning curve associated with it should not be undertaken for its profitability. The object usually is to cover the firm's costs. Rather, the project becomes a portfolio piece. The firm has gained experience and can bid other work based on the credibility this project has brought. If all is going down the tubes fast, it's best to subcontract the more difficult functionality out to a more experienced firm. Hopefully, the project manager will have identified several "bail-out" options before contracting on the project and thus can contact another firm immediately to act as a back-up programming team.

Answers

a)	How would you verify that the Web site has been adequately reviewed for quality control purposes? __________________________________________________________ __________________________________________________________ __________________________________________________________
Answer:	Interview the content editor. Has the site been proofread? The testing team should be able to produce screen shots of successful programming outcomes, as defined in the test plan.
b)	Who would you have testing the Web site? What would their objectives be? __________________________________________________________ __________________________________________________________ __________________________________________________________
Answer:	I would prefer not to use people who had been involved in any way on the project. Rather, I would prefer that a test team enter the Web site, figure out how it is supposed to work, try all possibilities, and try to break it using input that the Web site would not expect. I would also have a test plan that I would later want them to follow to the letter. The testing team's objectives are to identify any and all unexpected responses by making the Web site jump through hoops.

Self-Review Questions

In order to test your progress, you should be able to answer the following questions:

(True/False) The following is beyond the subcontractor's control.

_____ Changing programming requirements necessitate changes in completed programming code.
_____ Illness rocks the subcontractor's firm, causing programming to fall behind because of employee absences.

(True/False) Which individuals would be a good addition to a Web site testing team?

_____ Project manager
_____ Programmer
_____ Graphic designer
_____ Editor