[Access to Wang masthead]

Script Languages and Getting Online

Concluding the scripting series and information on getting onto the Internet

From "VS & Beyond",  Access to Wang, July 1998
  [ Prior Article ]     [ Return to the Catalog of articles ]     [ Next Article ]  

Over the last six issues we’ve looked at four of the most popular scripting languages; this month, let’s draw together these tools, distill similarities and differences between them, and look at some strategies for determining what you need to pursue for your career.

This month also marks the beginnings of a new Web-based format for Access to Wang, so it is appropriate to review how to choose a Internet vendor, how to set up a new connection, and the software you will want.

Comparing script languages

The four scripting languages covered in this series - VBScript, JavaScript, Perl, and Java - are representative of some of the many scripting languages that are becoming common to development environments everywhere. Many other script languages exist to support the needs of specific products. For example, multimedia development products such as Macromedia’s Director and Asymetrix’s ToolBook use a development model where objects (screens, buttons, animations, etc.) have scripts attached to them that control their behavior when interacting with the end user or with other objects. This model of development - a loose collection of independent objects each with their own behaviors and properties - is considerably different than that of the traditional development environment, where a single program creates all that is seen and done. In spite of these differences in approach, a good programming background and an understanding of application development can help bridge the outward differences between development in these worlds.

We started the script languages series with a discussion of some of the usual aspects of script languages: they are usually interpreted (not compiled), are generally not robust enough for full application development, and work only with a confined environment of supporting applications (browsers, interpreters, etc.). Their structure and syntax are largely drawn from C or C++, not the languages familiar to VS programmers, such as COBOL or BASIC. Some other differences:

1. In contrast to the VS integrated editor and debugger, most script languages provide little or no debugging support nor links to the debugger. In some cases it is possible to choose a set of independent development tools that provide some of these features, but the integration is not as smooth as the Wang Editor’s ties with its symbolic debugger.

2. Some script languages are tied directly to vendor products while others are supported across a range of products and environments. In some cases, this will limit the places where you can get developer support for the products to the vendor of the product. In most cases, however, rich support is available from the developer community itself through Internet-based communication services.

3. Most script languages do not use strong data typing; that is, they do not require declaration of the names, structure, or contents of program variables before they can be used. To put this difference in perspective, consider the results of leaving out the WORKING-STORAGE and FD sections of a COBOL program.

4. The structure and syntax of script languages seems to be converging, with most taking the forms and structure of C/C++ or Java (itself a derivative of C and C++, among other languages). This means it is possible to learn several scripting environments from knowledge gained from one or two.

5. Most developments that use script languages also meld other languages and environments together. For example, all of the script languages that work within Web browsers (VBScript, JavaScript, etc.) must also interact with HTML, the language of Web pages. The mixture of more than one syntax within a single source file (as shown with in January column) will be an increasingly familiar scenario as Web- based information delivery becomes more common. Even Java - which was designed to be a general application development language - is most often delivered within a Web page today. Nearly all script languages use some sort of object-based model, where standard, replaceable objects can be developed and used in a number of projects. This model has also created a rich market for ready-made objects - some available for free (e.g. the Perl CPAN library), some for sale (e.g. Visual Basic custom controls, also usable by VBScript programs).

If you’re considering your next career steps in programming, familiarity with one or more of these environments would be a very good place to begin. The wide range of supporting materials (free software, books, developer email lists, etc.) can provide you with the instruction you need at little or no cost. Less certain is whether a particular language will remain viable over time or become part of that growing heap of discarded technologies as the Web world plunges forward, but the experience of learning one of these environments is transferable enough that this should is not the problem it would appear to be. At any rate, I hope this review of scripting environments helps spark your interest in these tools and techniques.

Getting Online

As you might have noticed, a growing amount of technical support has moved (or been initially developed) using Internet tools - electronic mail, news readers, and the World Wide Web. Vendor Web sites provide updates to their products, demonstration versions, drivers, and documentation, while a galaxy of free software (and support for it) can be yours for the time and trouble of downloading it. In short, it’s time to get connected if you are not already.

What follows is a condensed discussion of the process of selecting and setting up an Internet connection. I will also go over a few sources for tools and some techniques that might be of interest even if you already have Internet services set up.

Selecting a vendor

I recently shopped for cellular phone services and found a confusing array of options, contradictory claims by vendors, and a vast amount of questionable advice from current customers. Unfortunately, the process of selecting an Internet vendor can be very similar. Internet Service Providers (ISPs) can be found serving local, national, and international needs, and there are many possible aspects to the decision. I will attempt here to distill my experience as a customer of a local service and while providing support to others using national and international services.

Your first consideration is the general type of service you are looking for - a no-frills connection to the Internet through an ISP or through an online service such as America Online, CompuServe, or the Microsoft Network. Online service providers provide additional content - some at additional cost - that is not available outside their services. Such content includes scheduled events (music presentations, celebrity chat forums, etc.) and tailored services (stock portfolio management services, news clip services, etc.).

In addition to this additional content, online services provide some means of connecting to the Internet world outside their walls. In all cases, connections to the Internet through these online services are worse than those made through Internet-based ISPs - slower, less reliable, and constrained to specific vendor-supplied, proprietary Web browsers and electronic mail programs. For example, America Online’s browser - while based on the Microsoft Internet Explorer - does not have the display features incorporated into the current release of the product and, thus, cannot display some Web pages correctly.

In contrast, ISPs provide a generic connection to the Internet and little or no additional services. While some ISPs distribute copies of recommended software, it is usually the responsibility of the customer to find and install a Web browser, electronic mail program, and other items. In return, you gain a faster and more reliable connection to the Internet and can build up a suite of generic software and connection profiles that would allow you to switch vendors at any time if you chose to do so.

In short, you should select an online service if your primary interests lie in their content and an ISP if you are mostly interested in connecting to the Internet. If you are not sure which of these approaches meets your needs, I suggest trying each out and deciding for yourself; nearly all ISPs and online services allow you to try the service before you commit yourself.

The connection model

The Internet uses the TCP/IP (Transmission Control Protocol/Internet Protocol) protocol, which was developed for the Internet but also widely used within organizations. In the Internet model, all devices appear to be connected to a single network and are capable of sending messages between all other devices. Each node on the Internet has an IP address - an unique identifier - that identifies its identity and, to some extent, its physical location. Large Internet systems such as universities, corporations, and ISPs are assigned one or more sets of IP addresses blocks (commonly grouped in units of 256 per block) and distribute these addresses to workstations and other devices on the network.

In organizational settings, where devices have full-time connections to the Internet, IP addresses are usually assigned permanently to a specific device. This is known as a static address, since it does not change. Where connections are not permanent - such as connections through an ISP or online service - a dynamic addressing model is used: each time the user attaches to the Internet, a temporary address is issued from a range of available addresses. This temporary address is stored in memory on the user’s system and returned to the pool of available addresses when the connection is broken.

In addition, special network software is used to make the transition between the TCP/IP protocol used by the network and the dial-up connection. The two most popular protocols for this need are SLIP (Serial Line Internet Protocol) and PPP (Point-to-Point Protocol). Both have similar requirements and features, but it is up to the ISP or online service to choose which one will be used.

Setting up the first connection

The specifics of setting up a connection vary with the service, your local telephone service, the type of system you use, the communications equipment in use, and other factors. Nonetheless, there are some specific things required of all Internet connections:

1. IP address: In most cases, this will be set to obtain an address from an outside source (the ISP or online service). If static addresses are used, the unique identifier for this workstation would be entered here.

2. DNS servers: The IP address (numeric) of one or more Domain Name Servers - systems which accept a verbal name and return its IP address. For example, when you enter the address of a Web page on a browser address line, this name is translated by a DNS server to its numeric form and returned to the browser to locate the page and load it.

3. Host name: A local name for this workstation; typically a short name followed by the name of the ISP or online service.

4. System network software: In addition to the translation required to convert TCP/IP to a dial-up connection, there must also be supporting network software. For Windows systems, this is typically referred to as Winsock (Windows sockets); for Macintosh systems, there is SLIP and PPP software available from Apple and through other sources.

5. Dial properties: As with other dial-up connections, you must enter the phone number and specific modem commands as necessary.

All of this information is commonly provided by the vendor you choose, and you might also receive telephone support while you’re getting the connection set up. After the initial connection is set up, you will need one or more pieces of client software - Web browsers, electronic mail clients, and the like - to use your new connection. Again, the vendor will have recommendations and may provide specific software.

Next month: More on online tools and the new systems support model.


  [ Prior Article ]     [ Return to the Catalog of articles ]     [ Next Article ]  


Copyright © 1998 Dennis S. Barnes
Reprints of this article are permitted without notification if the source of the information is clearly identified