Characteristics of Web Programming Languages
This document surveys current and planned languages and interfaces for developing World Wide Web based applications prefaced by a discussion of the characteristics of such languages. The principal goal of creating this document was to identify the various languages currently in use and to provide some insight into the context in which each language is used. Secondarily, the authors sought some insight into the directions that Web programming was going, especially in the context of the intense publicity surrounding Sun's Java.
This document does not attempt to provide in-depth tutorials on these languages and systems. It attempts to be complete in its listing of alternatives. References are provided to more information about each. Our intent is to keep this document current if it proves useful.
General purpose programming languages (e.g. C, C++, Objective-C, Pascal, COBOL, FORTRAN) have not been included in this survey unless there are specific uses of those languages for web programming other than conventional development of clients and servers. In most cases, only variants of such languages specialized for web programming are included here, and, in such cases, are generally listed by the variants' names.
Almost as soon as this effort was started, other similar efforts were encountered. The list that follows is a partial listing of the efforts encountered and used to compile this document.
Issues in the Development of Distributed Hypermedia Applications
Joint W3C/OMG Workshop on Distributed Objects and Mobile Code/
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 SGML (Standard Generalized Markup Language), the ISO standard 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 a 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 HTMLpages, 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 bytecode size and binary speed. Java bytecodes 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 Independence Given 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 applicationis 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 fewerbyte 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. (See Java Security: From HotJava to Netscape and Beyond for a detailed analysis of how safe Java and the Java virtual machine really are). 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 bytecode format, with bytecodes 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 is their languages, by supporting safe client-side execution in some manner, including targetting 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. Its possible that the Java VM ends up being the one trusted 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.
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 is the latest version of the Ada programming language, which now supports object-oriented programming. Ada is used widely in government and industry. Ada and the WWW/Java compares Ada95 to C++ and Java, and discusses its suitability for Internet programming. Programming the Internet in Ada 95 describes efforts by Intermetrics, the principle Ada compiler vendor, to retarget its compiler to generate Java byte-code, in the interest of making the vast body of Ada software suitable for the web. Ada for the Web describes ACM SIGAda's efforts to promote Ada95 for Internet programming. Check out Twelve reasons to use Ada 95 for Java applet development.
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. WebRunner 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. Check out Macintosh World Wide Web Frequently Asked Questions for more info on web programming on the Mac and ScriptWeb for info on scripting on the Mac.
BEF is an object-oriented PASCAL-like scripting language for describing behavior in VRML.
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.
A Web daemon executes a 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, 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 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 Lisp 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 Dylan 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 The Dylan Language 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. Also, check out PCAI's Dylan page.
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 is the English-like scripting language for Apple's HyperCard. 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 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 is the leading contender for a full feature programming language targetted at Internet applications. It 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 off 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. Its 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 in that Java is not simple; its 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. Each of the competitors is described below in more detail. The following compare Java to specific other languages:
Cmm and Java Compared compares Java with Cmm, another C-derived language targeting the WWW.
Differences Between Phantom and Java compares Java and Phantom, a language based on Modula-3 which targets the Internet.
Java is Dead compares Java to pgpsafeperl, as the name implies, a safe derivative of perl, a popular language among Unix sysadmins.
Java Über Alles? compares Java and Perl, addressing the complexity of Java programming.
A survey of distributed languages compares Java to Phantom and Python, an interpreted, interactive, object-oriented programming language.
Sun is working to integrate Java into its OMG CORBA-compliant ORB, NEO, with Joe.
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 (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 much more 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 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.
WWWinda: An Orchestration Service for WWW Browsers and Accessories describes an extensible web browser architecture that uses Linda as the extension language.
Lingo is the object-based scripting language for Macromedia's Director 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 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. Scheme48 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). Scheme48 for collaborative Engineering? is an interesting review by Dan Connolly of the W3C on Scheme48's suitability for Internet programming and the suitability of the Scheme48 Virtual Machine as the common vm for a myriad of Internet programming languages (e.g. Python, Perl, Icon, Tcl, Smalltalk).
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 is comes with Emacs. A browser, GNUscape 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.
The Future of Lisp is an interesting comparison of Lisp, Dylan, C++ and Java by some of their creators.
Idea: A Java-VM Implementation Based on the Modula-3 Runtime explores the idea of basing an implementation of the Java Virtual Machine on the Modula-3 runtime.
Modern Web Programming describes Obliq, another Modula-3 derived distributed object-oriented language.
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 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.
Perl versus .... lists several comparisons between Perl and other languages, including tcl, python, java and csh.
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 couter 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. PerlCCI 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 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. Differences Between Phantom and Java compares Java and Phantom.
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. See Python Compared to Other Languages for a list of comparisons between Python and a variety of other languages. Safe-Python is a design for changes to add safety to Python. Grail is an web browser which supports the download and execution of Python applets in a safe Restricted Execution Mode. Grail uses the Tk GUI library.
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, 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.
Authoring and Delivering Networked Multimedia: Integrating ScriptX with the Web provides an interesting analysis of ScriptX's potential on the Internet.
Re: Python - ScriptX similarities... compares Python and ScriptX.
ftp://ftp.mv.com/pub/ddj/1994/1994.11/scrptx.zip is an sample ScriptX program from Dr. Dobb's Journal. It looks similar to Python and Dylan.
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.
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. See Shells and Shell Programming for a comprehensive comparison. 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 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 bytecode 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 (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 The Relationship Between Tcl/Tk and Java. His point is that its 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. Comparisons of Tcl with other systems is a comprehensive list of comparisons between Tcl and other languages. The Tcl War archives a thread started by Richard Stallman's negative comments about Tcl in 1994. 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.
Check out TCL WWW Info, news:comp.lang.tcl, and the Tcl FAQ, for more info on Tcl.
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 which 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.ppt for a comparison of Tcl, Telescript, Visual Basic, and Java by John Ousterhout, Tcl's creator.
http://www.genmagic.com/About/Releases/prrel960129.html explains 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 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 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 a interpreter, and there are many others.
WebScript is the object-oriented scripting language for NeXT Software's WebObjects 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.
This research is sponsored by the Defense Advanced Research Projects Agency and managed by the U.S. Army Research Laboratory under contract DAAL01-95-C-0112. The views and conclusions contained in this document are those of the authors and should not be interpreted as necessarily representing the official policies, either expressed or implied of the Defense Advanced Research Projects Agency, U.S. Army Research Laboratory, or the United States Government.
© Copyright 1996 Object Services and Consulting, Inc. Permission is granted to copy this document provided this copyright statement is retained in all copies. Disclaimer: OBJS does not warrant the accuracy or completeness of the information in this survey.
This page was written by Steve Ford, David Wells, and Nancy Wells. Send questions and comments about it to ford@objs.com.
Last updated: 1/9/97 sjf
Back to Internet Tool Survey -- Back to OBJS