Ironically, while open source is often associated with the Internet, many Web development managers remain uncertain about whether open source software can become a viable source for the tools they need to deliver their e-commerce projects on time.
However, open source has huge potential advantages when compared to traditional proprietary software models. The obvious advantage is that, with the software freely available to developers, open source is developed by, in effect, the world’s largest R&D teams. Improvements such as bug fixes and functionality extensions become available much faster–sometimes literally overnight–compared with traditional vendor models.
Another effect of the open source community is the ability to experiment in marginal areas or produce enhancements that do not have immediate, known commercial potential. Conventional ISV teams are rarely allowed to produce things that the customer isn’t asking for.
For instance, an integrated development environment (IDE) may provide the development and debugging environment. However, an IDE typically does not address design and analysis, configuration management, project management, and testing. And it won’t easily support the unique workflows, project management requirements, or technology requirements of specific deployments, such as multiple application servers or highly distributed components. Most IDEs run only on Microsoft Windows, so they really can’t handle optimization, testing, and deployment spanning NT, Linux, Solaris, and mainframe platforms.
Open source, with its wide platform support and rapid innovation, promises a wider range of solutions to development teams under the gun. For instance, while a development team might not have the time to port the source code of the right tool to another platform, the open source model makes it more likely some third-party vendor will rise to the challenge.
Impact on the Toots Market
Today, most commercial development tools are sold only in binary form, created from proprietary source code that is available only to the vendor. Add-on products from third parties must use limited, predefined extension interfaces provided by the tool vendor. This model and its associated business arrangements have limited the availability and longevity of add-ons. When customers require features not provided by the core IDE, the only alternatives have been:
* Using third-party add-on tools endorsed by the core tools vendor;
* Trying to integrate third-party tools themselves; or
* Using multiple tools in standalone mode.
By contrast, publicly available open source code encourages any vendor to develop complementary add-ons, without having to sign restrictive technology or marketing agreements. The only requirement is that the add-ons be fully compatible with the standards and APIs (application programming interfaces) of the source. The resulting add-on tools may be open source, but most of the commercial ones are not. However, by operating from a common, publicly available source code base, customers are assured that the add-ons will be compatible with their core tool system. This mixture of open source technology base with commercial add-on modules changes the business model of the tools industry.
The result is that the barriers to market entry are dramatically lowered. Any vendor with a development team and Web site can afford to introduce a new tool. The lowered barriers, in turn, make it easier for vendors to justify developing niche tools, such as content-driven Java Server Page (JSP) editors, that might not have been feasible under traditional proprietary software models.
And thanks to the Internet, these tools are more accessible than ever. All it requires is a search engine or a portal. Developers don’t have to wait for the sales rep to call.
Impact on the Development Cycle
Open source technologies fit nicely with the new, shorter-fuse development cycles that typify e-commerce projects. With only weeks, rather than months, to deliver, development teams don’t have time to evaluate large umbrella tool suites or endure lengthy sales cycles from their enterprise software company. Instead, they can get the right tool at the right time.
Here’s how it works. The team must start with an almost-immediate learning curve, and then produce a small deliverable. As the project progresses, developers add niche tools to satisfy specialized requirements that suddenly crop up. For instance, a state-of-the-art e-commerce site containing highly dynamic content may require tools supporting advanced technologies such as EJBs for distributed business logic, along with servlets and JSPs for generating dynamic content, XML, and HTML pages. The team itself might be spread across several locations. They would need tools that allow Java developers, HTML coders, and graphic designers to collaborate and produce new site updates on a daily basis, such as:
* IDEs for developing the Java business logic;
* Analysis tools for application designers;
* Testing tools for developers and deployment staff;
* Authoring tools for Web page design;
* Graphic and animation tools for designers; and
* Project management, workflow, and change management tools to coordinate the teams.
As an example, open source development has come to the Java community. NetBeans.org is an independent organization for the Java community. The site provides the downloadable source code for the purpose of applying patches, adding extensions, or developing complementary add-on tools. Under terms of the open source license, any vendor is free to take the IDE and develop new products without cost or marketing obligation. Modeled on the Mozilla open source license, the NetBeans license allows the community to evolve freely and rapidly.
If development tools are open source, developers can count on finding compatible tools. If a tool system is proprietary, developers have to wait for one vendor team to get it right.
When Push Comes to Shove
With e-commerce ratcheting up the demands to deliver new applications quickly, development teams require a dependable source of tools that will satisfy often-unpredictable development requirements, a “just-in-time” tools system.
A new hybrid open source software model is emerging that features communities of commercial products available in finished binary form. The model is based on the premise that a core tool, such as a Java IDE, becomes freely available to the community of tools developers, who in turn are free to develop their own offerings that may–or may not–be open source. In the new model, open source does not mean trolling the Internet for “do-it-yourself” source code. Instead, open source translates to a vast new market for compliant tools. For development teams and vendors alike, open source is a win-win situation.
Tags: ecommerce, open source tools
Lots of people fly in airplanes, but few understand how aviation works. That’s why many of us cling to erroneous ideas about flying, believing that air turbulence is dangerous, say, and can even cause an airplane to fall out of the sky. For these unfortunate travelers, ignorance is not bliss; it’s the cause of unnecessary anxiety.
PostScript is what makes desktop publishing fly–it’s the underlying structure on which many magazines, books, and newspapers are built. Sure, you can use QuarkXPress or Adobe InDesign without knowing anything about PostScript, just as you can fly without understanding the physics of lift. But knowing even a littie about PostScript can go a long way: it can help you predict what’s going to come out of your printer, saving you time and frustration. It can also help you troubleshoot problems. And with a smattering of PostScript, you can do a few tricks you may not have thought possible (see “Zap the Big White Box”).
PostScript is a programming language that describes text and graphics on a page. Its commands control where a Laser printer (or any PostScript device) places a line of text, a circle, a Bezier curve, or a bitmapped image. Although you can easily write your own code (see “PostScript Unveiled”), few people actually write PostScript anymore; instead, programs such as Macromedia FreeHand, QuarkXPress, and Apple’s LaserWriter driver write PostScript commands to a disk file and then send the file to the printer. The printer’s interpreter reads the PostScript commands and converts them to marks on the page.
Adobe Systems originally wrote PostScript and licenses it, but many other companies have built interpreters that can read PostScript. Adobe has released three different versions over the years: PostScript, PostScript Level 2, and PostScript 3. While most imaging devices today can handle Level 2 commands, only newer printers can deal with PostScript 3 commands (including the ability to process native Adobe Acrobat PDF files and perform in-printer trapping). Ultimately, for the sake of compatibility with older devices, few programs and drivers take advantage of the higher-level commands available in Level 2 and PostScript 3.
Knowing how PostScript builds pages is helpful in understanding how desktop publishing applications work–and why your output may not always look the way you expect it to. PostScript describes a page one object (a circle, some text, or whatever) at a time, with each object sitting on top of the previous objects. In QuarkXPress, you might create a text box that has a solid white background and the word Macworld in it. When you print, QuarkXPress and the LaserWriter driver together convert this image into PostScript: the PostScript file describes the rectangle, fills it with white, and then places the text on top of it. (If the text contains any type effects, such as kerning, PostScript may place the text one character at a time.)
There’s a common myth that it takes longer to print a QuarkXPress page if your text boxes have a background of None. As this example shows, that’s balderdash. If the text box were transparent rather than white, the only difference would be that the PostScript commands would not paint the box white before placing the text. Therefore, it’s actually faster to print transparent text boxes, though the difference is only a fraction of a second.
PostScript is an opaque imaging model, which means that whatever you place on the page will totally cover what’s beneath it. If you use PostScript to describe a 50 percent gray box on your page and then put a 20 percent gray box on top of it, you don’t get a 70 percent gray box. Instead, you see only the 20 percent gray box. Whatever is on top takes precedence.
The fact that PostScript describes opaque objects also explains why there’s no such thing as a truly transparent object in PostScript (although hopefully Adobe will address this limitation). If you place a soft drop shadow on top of something else in QuarkXPress, you can’t see through the shadow because, again, whatever is on top entirely covers what’s underneath. Any program that offers a transparency feature has to fake this effect when it prints your page.
Errors in Interpretation
A common incentive to learn PostScript is the alarming “PostScript Error” message that stops a print job dead in its tracks. PostScript is a very sensitive language; even a small error can wreak havoc on your page. For instance, a command called “lineto” draws a line from one page coordinate to another. If your computer makes an error when writing the PostScript code, it might write this command as “lneto.” Because the interpreter won’t know what this command means, it will respond with the “Undefined Command” error. Another common error, especially on older printers, is “Limitcheck,” which occurs when some internal limit has been exceeded. For instance, old devices can’t handle long, complex Bezier curves and may return a “Limitcheck” error if you don’t simplify the shape.
To find out exactly what the error is when using QuarkXPress or Adobe PageMaker, turn on the error-handling feature in the Print dialog box. In other programs, you can choose Error Handling from the General pop-up menu in the Print dialog box (if you don’t see this pop-up menu, you’re using an older LaserWriter driver). Either way, you’ll get a page that lists the offending command and the type of error. If it’s an “Undefined Command” error, something’s wrong with the print stream and your best bet is to send the job again. If you see “Limitcheck,” you should try to simplify the file’s contents.
The Future of PostScript
Although PostScript has long been at the core of desktop publishing, the industry is moving toward using Acrobat PDF as the standard imaging language. But there’s life in the old language yet: because Adobe originally based the PDF specification on PostScript, knowledge of PostScript is very useful in understanding how Acrobat works, too. And it’ll be years before PDF fully replaces PostScript. Until the majority of imaging devices can read native PDF files, these documents will still require translation (usually by a printer driver) into PostScript.
POSTSCRIPT LOOKS DIFFICULT, BUT IT’S ACTUALLY A PRETTY SIMPLE LANGUAGE. Because it’s almost always just plain text, you can use any text editor to write or edit it (don’t use a word processor such as Microsoft Word; it might add formatting). I often use Bare Bones Software’s BBEdit (www.barebones.com) because it also lets you download PostScript to the printer quickly to see your results.
Here’s a sample PostScript program that draws a series of boxes (you can type this code in or download it from www.macworld.com/1999/12/create/). Open any EPS file and you’ll see something similar: an EPS file starts with all the procedures it’s going to use and ends with the actual commands to makemarks on a page. (EPS files don’t include the showpage command, though.)
When you’ve finished writing your program, save it as a text file and download it to your printer. If you use BBEdit, you can choose Send PostScript from the Tools menu. Or you can use another utility, such as Adobe Font Down-loader, to send the file.
(1) Lines that begin with a percent sign are comments, and the interpreter ignores them. The one exception is this first line, which some interpreters require to inform them that the following file is Postscript.
(2) A slash at the beginning of a line identifies a procedure that we’ll use multiple times later in the program. Procedures are always defined inside curly brackets and end with def. We’ve called this procedure drawbox (but you can call procedures almost anything you want).
(3) The program does all drawing on a giant grid, and there are generally 72 points per inch. Here, we set PostScript’s virtual drawing tool to the (0,0) coordinate; the program then draws a line 100 points to the right and 0 points vertically. Note that in Postscript, the values (in this case, coordinates) always come before the command. This is called putting values on the “stack.”
(4) The closepath command makes the open-ended line into a closed box. The box doesn’t actually appear until you stroke or fill it. In this case, stroke instructs the printer to paint the line with the default 1-point rule but not to fill the box.
(5) The (0,0) coordinate is usually at the lower-left corner of the page. The translate command tells the printer to move (0,0) to a different coordinate–in this case, 250 points from the left edge of the paper and 350 points up from the bottom of the page. We’ve already specified a procedure, so we can call it by name anytime. The program draws the box.
(6) Here, the whole coordinate grid system rotates 15 degrees and the program draws the box again. This way, you don’t have to figure out new coordinates for the box’s corners. In this case, each time you give the rotate command, the grid rotates further. The second time you give the rotate command, the grid rotates a total of 30 degrees, and so on.
(7) The showpage command tells the imaging device to print the page. If you don’t include the command, then the program draws the virtual page but no paper comes out of your device.
Zap the Big White Box
HERE’S A REAL-WORLD EXAMPLE OF HOW EDITING POSTSCRIPT CAN SIMPLIFY YOUR life. QuarkXPress 4.X creates EPS files slightly differently from how previous versions did: it always draws a white box behind your page. If you are compositing your EPS file on top of some other image and want the background transparent, you’re out of luck–unless you can edit PostScript.
(1) Open the EPS file in a text editor such as BBEdit (word processors like Microsoft Word can mess up the text by adding formatting).
(2) Search for the line that reads %%EndSetup. Soon after it you’ll see another line that reads something like g np clippath 1 H V G calcbnd.
(3) The commands g, np, H, and so on are all procedures defined earlier in the file. Remove the characters 1 H V and save the file again. Those three characters create that white box (the 1 is the color white; if you were to change this to 0, the box would be black).
Tags: apple postscript, behind the scenes with PS
It turned out that this was the first subscriber whose name contained a character not representable in 7-bit ASCII. The character is one that I can type in my emacs text editor (using its insert-ascii function) as the integer 232 (hex E8), thusly: e. What you will see, in your browser, depends on the encoding that it’s using. For many of us, that encoding will be ISO-8859-1, and you will see the character whose Unicode number is 00E8, and whose name is LATIN SMALL LETTER E WITH GRAVE:
But if your encoding is set to ISO-8859-2, you will instead see the character whose Unicode number is 010D, and whose name is LATIN SMALL LETTER C WITH CARON:
The Web form that accepted this ASCII 0xE8 character relayed it to a backend business system that happily stored it. But that backend system also communicated the character, by way of XML-RPC, to another system. And that system — specifically, its XML parser — choked on the character. It did so because the parser, MSXML, defaults to UTF-8. This, by the way, is one of those infuriating industry acronyms that is often used but rarely spelled out, and that must also be recursively expanded. Thus, UTF-8 stands for UCS Transformation Format 8, and UCS in turn stands for Universal Multiple-Octet Coded Character Set (UCS).
I found an excellent description of the properties of UTF-8 in the UTF-8 and Unicode FAQ for Unix/Linux:
UCS characters U+0000 to U+007F (ASCII) are encoded simply as bytes 0×00 to 0x7F (ASCII compatibility). This means that files and strings that contain only 7-bit ASCII characters have the same encoding under both ASCII and UTF-8.
All UCS characters >U+007F are encoded as a sequence of several bytes, each of which has the most significant bit set. Therefore, no ASCII byte (0×00-0x7F) can appear as part of any other character.
The first byte of a multibyte sequence that represents a non-ASCII character is always in the range 0xC0 to 0xFD, and it indicates how many bytes follow for this character. All further bytes in a multibyte sequence are in the range 0×80 to 0xBF. This allows easy resynchronization and makes the encoding stateless and robust against missing bytes.
All possible 231 UCS codes can be encoded.
UTF-8 encoded characters may theoretically be up to six bytes long, however 16-bit BMP characters are only up to three bytes long.
The sorting order of Bigendian UCS-4 byte strings is preserved.
The bytes 0xFE and 0xFF are never used in the UTF-8 encoding.
So, MSXML saw the 0xE8 as the first byte of a multibyte sequence, expected the next byte in the sequence to be in the range 0×80 to 0xBF, and choked when that wasn’t the case.
There are a couple of ways to “fix” this problem. One would be to use only 7-bit ASCII characters, which mean the same thing in UTF-8. To do this, you’d represent 0xE8 as the entity e. Note that to ensure you see what I intend in the last sentence, I actually had to write e — that is, “escape” the ampersand. Then, of course, to show you how I did that, I actually had to write e. And to show you how I did that, I had to write…oh, never mind, just view the source in your browser.
Another “fix” that we in fact adopted, was to tell the XML-RPC module that sent the packet of data containing the 00E8 character to use the ISO-8859-1 encoding. That meant that instead of beginning like this:
it instead begins like this:
<?xml version=”1.0″ encoding=”ISO-8859-1″?>
As my quotation marks around “fix” suggest, neither of these approaches is a complete solution. When I mentioned this issue in the newsgroup, a longtime correspondent — whose name includes a Unicode 00E1, LATIN SMALL LETTER WITH ACUTE — responded:
You have to use an encoding that suits the parser that will read the XML *AND* preserves the information you are trying to convey.
If I am writing XML that will be read by a UTF-only parser, I will have no choice but to encode it so, even if I (as a Portuguese-speaking Brazilian) somewhat prefer ISO-8859-1 or Windows-1252 to anything else (and wonder why ASCII had to be 7 bits wide). That’s sad, but true; XML is not that portable.
There are parsers that don’t care about encoding, but won’t be able to change the encoding. If they get UTF-8, they will spit UTF-8 out.
I wouldn’t encourage using numeric entities, as they depend on the encoding (a “C” may have the same numeric under ISO-8859-1 code as “[yen]” under ISO-8859-12; of course, I made this up) and this information is sure to be lost somewhere. I find “Ç” preserves the meaning much better. However, it is useless if you intend to put it inside an e-mail message or print it on a POS printer or sort it on a relational database.
Welcome to the wonders of XML.
Of course it wasn’t really XML’s charter to solve this problem. That’s what Unicode is for, and XML can do no better than to follow the evolving Unicode saga.
Tags: encoding characters, xml programming
Your domain name is simply an alias for an Internet Protocol address that directs users to your site, through the Domain Name System (DNS). If you want a site that a few friends and family can visit every now and then to view photos or read your latest pithy thoughts, the domain name you get with your Web space should suffice.
A domain name is registered for a period of one to 10 years with a central registrar and costs about $30 to $35 per year. The easiest way to register is through your Web-hosting service when you buy your Web space. If you want to register your name before you find a Web host, you can do it yourself. When your site is ready, your hosting provider can arrange the transfer.
Tip: Domain-registration services such as Network Solutions and Register.com let you search for available domains. The search tools of some sites, including Register.com, will identify the owner of the domain and when the registration is scheduled to expire.
Plan and Gather Content
When building your first Web site, keep it simple, and begin with at least a rough sketch of what you want, including text, images, and links.
As you gather photographs and graphics, make sure to keep file size in mind: The smaller the files, the more you can fit within your allotted Web space, and the faster your site will load when browsed. As a rule of thumb, resize images at 72 pixels per inch (screen resolution) to fit the space you want on the screen, and save images in JPEG (.jpg) format. Graphics work better as GIFs.
Create the Site Locally
Begin building your site by defining it on a local hard drive. Using FrontPage, select File > New > Web to create a new Web-site structure. You can set the folder location or accept the default location of \My Documents \My Webs\. When your site opens, click on Default.htm (or Index.htm, depending upon your installation) to open a blank page. Front Page creates a separate images folder for graphics.
Tip: When you create a new Web site, FrontPage lets you choose from several templates you can use to build your site.
Set Background Color or Image
To set a background image, right-click on the blank default page and open Page Properties. In Page Properties, set a background color using the provided color palette, or load a background image by browsing to a file on your hard drive. Your image can be nearly any size, but the smaller the better. If the image isn’t large enough to fill your screen, FrontPage will automatically tile it to fill the background area. We created our gradated background using one 25-pixel-high strip, which employed a color gradation near the left.
While you have Page Properties open, also enter a title for the Web page. This title will show up on the bar at the top of the user’s browser.
Draw a Page-Layout Table
An HTML table is a structure that lets you create rows and columns to hold pictures and text, much like an Excel spreadsheet, although HTML tables tend to be irregular. An HTML table is a way of dividing the screen so that you can place different elements where you like. FrontPage’s Draw Table tools make it easy to create custom tables using a pencil-and-eraser metaphor.
To lay out your Web page using FrontPage, select Draw Table from the Table menu, and pencil in the table by drawing cells and subdividing them with the pencil tool. You’ll also need to change border width from 1 to 0 in the Table Properties menu.
To add a headline or greeting, draw a table cell on your page to hold text. Click inside the cell and type the text you want, such as “Welcome to my site.” To make the text a suitable size and color, click and highlight the text to change the font properties. With the font properties at the top of the screen, set individual font size, color, and alignment.
HTML text uses heading sizes of one to six (largest to smallest) or sizes one to seven (smallest to largest). You can also set size by +/- font sizes, which key off the default size. It can be a little confusing, so preview your page to be sure it’s what you want.
Also, make sure to check the readability of your text against your chosen background image or color in a browser. Poor readability can kill a Web page.
Tip:FrontPage lets you use any font installed on your machine, but to view your site correctly, visitors to your site must have the same font installed. If you want to use a fancy font, consider using a graphics program to create the text on a transparent background, and then save the graphic as a bitmapped file.
Chances are you’ll want images on even the most basic Web site. To insert an image using FrontPage, click inside the table cell where you want the picture and select File > Insert > Picture. The Insert Picture dialog box lets you browse for an image. To alter image size or alignment within FrontPage, right-click on the image, choose Picture Properties, and click on the Appearance tab.
You can use links to connect to another location on the same page, another page of your site, other sites altogether, or even to bring up the user’s e-mail client. It’s easy to define either text or a graphic as a link.
To create a text link in FrontPage, highlight the text, then choose Insert > Hyperlink. The Create Hyperlink dialog lets you enter a URL or e-mail address.
We opted for images as a means to let our users link to our About, Contacts, and Gallery pages. To assign a link to a graphic or image, simply right-click on the image and invoke the Picture Properties dialog box. Then specify the link by entering the URL or browsing to it. To link to another page on your site, just enter the page name, for example “about.htm.”
With image links, it’s important to enter a short descriptive caption for the image, which will display when you pass the mouse over the image or when a visitor has turned images off in his or her browser. To enter this “alternative representation,” simply type the caption into the Text field under Alternative Representations within the Picture Properties dialog.
When you’ve perfected your site, you simply need to publish it-that is, upload it to the Web-storage space you identified or purchased. You can upload manually using FTP clients such as WS_FTP from Ipswitch or CuteFTP from Global Scape, but the easiest way if you use Front Page or Dream weaver is to have the program handle the task for you.
To publish from FrontPage, select File > Publish, enter your Web address, and, when asked, the username and password for your Web space. You can choose to upload the whole site or just elements that have changed, which can save a lot of time when you later begin to update the content.
Once you’ve uploaded your site, you can test it by visiting from any PC with a browser and an Internet connection.
One advantage of having your own domain name is that you can move from ISP to ISP, and your e-mail address will never change. That’s because Web-hosting providers such as DellHost, Interland, Verio, and Web2010 offer POP e-mail along with their Web-hosting services, and most include multiple e-mail accounts. POP e-mail accounts let you send and receive mail using a client such as Outlook or Eudora, though most providers also offer browser access.
You can also get e-mail through domain registrars such as Network Solutions (www.networksolutions.com), Register.com (www.register.com), and others. A POP e-mail-only account ranges in price from free, as with Register.com (with registration of a domain name), to $60 a year with Network Solutions. Going through a registry for your e-mail account is also a good way to guarantee that you are the owner of your domain for future use.
If you already have an existing e-mail account you’re happy with, registrars such as Mydomain.com (www.mydomain.com) will register your domain name and include free e-mail forwarding to your old account. A search on the Web for e-mail accounts will result in thousands of e- mail hosts offering you “branded” (your domain) e-mail, including well- known names such as Yahoo, at a low monthly or yearly fee.
Tags: hosting your website, website building
Green Hills Ada programming tools are involved in projects to build the future U.S. Joint Strike Fighter, as well as programs to upgrade the B-1B strategic bomber, B-52 bomber, AV-8B Harrier jump jet, and C-17 airlifter, Carbone says.
Green Hills officials are not alone in their optimism about Ada. “We are seeing the language popping up in places far afield from the military, such as in yachts, video systems, and video encoding for images stored on tapes and disk,” says Joyce Tokar, vice president of technology at Ada tools vendor DDC-I in Phoenix.
“The market is recognizing there is an advantage to a programming language that supports early detection of errors at compile time,” Tokar says. DDC-I provides Ada compilers and tools for the U.S. Army RAH-66 scout-attack helicopter computer systems.
Things did not always look so good for the Ada business. As a matter of fact, only three years ago it looked as if Ada had hit bottom and was on the verge of being forgotten.
In 1987 the DOD dropped its longstanding mandate to use Ada. Perhaps more significantly, Pentagon leaders a year later not only disbanded the DOD Ada Joint Program Office (AJPO), which was the premiere government and industry clearinghouse of information and reusable software libraries, but also cut off virtually all funding for Ada development.
At the time, many in the software business saw those developments as the death knell for Ada. Today, however, some experts say the DOD’S withdrawal of support for Ada was a blessing in disguise. The reason: prospective customers now judge Ada purely on its technological and financial merits, with little political baggage.
“On a whole it is a good thing that Ada must stand on its own two feet,” says Ben Brosgol, Ada technologist at Aonix of San Diego. “With the mandate no longer operative, and with the AJPO no longer in business, the interest is coming from commercial business rather than in DOD.”
Freedom from government mandates is giving Ada a second chance, which is starting to pay off, Carbone says. “Now that there is no longer a mandate, people are even more receptive to it. Maybe the Ada mandate had a depressing effect on the use of Ada outside of government.”
The demise of DOD’s Ada mandate “has not hurt us at all, and may have helped,” Tokar says. “Today the software community recognizes the value of process and rules of developing software. People are much more familiar with packages, and components of software.”
It is no secret that DOD’s involvement in the language gave Ada a huge boost in the early 1980s. Yet many longtime industry experts now believe that DOD attention may have hurt Ada perhaps as much or more than it helped.
Software pioneers crafted Ada, named for 19th century mathematician Ada Byron Lovelace, two decades ago under DOD sponsorship in an attempt to create a standard and validated programming language that lent itself to rigid software engineering discipline, high reliability, and easy code reuse.
At that time, DOD leaders envisioned Ada as their key to reining in runaway software costs and centralizing control over a fast-growing number of software projects using different programming approaches and languages. DOD leaders moved quickly — some say too quickly and too zealously — to mandate Ada for all of the department’s new projects.
Not only did DOD officials provide seed money to push Ada development along, but they also established the AJPO, which served as a nucleus that held much of the Ada community together.
Despite a promising beginning, trouble for Ada began almost instantly. “Early on, Ada was over-hyped, and was considered to be too much of the silver bullet,” Brosgol explains. “People ended up with an initial bad taste in their mouths.”
The specification for the first version of Ada, called Ada 83, hit the streets before reliable Ada compilers were available. While the fledgling Ada industry struggled to develop usable compilers, DOD officials tried to develop a compiler and tools called the Ada Language System, which Brosgol says was a technological disaster.
“When Ada 83 came out there were no compilers, and when they did come out they were very poor,” Brosgol says. Critics not only resented the DOD’s forcing them to use a new and unproven language, but they also complained that Ada code was too large to run efficiently on the microprocessors of the day. In addition, the Ada and tools and compilers available then were relatively expensive.
To complicate matters further, many early proponents viewed Ada as a one-size-fits-all language that software engineers could apply to a wide variety of programming tasks, from databases and financial-management software, to real-time embedded applications.
Now much of that is changed. “People are using Ada where it is appropriate,” Carbone says. “You don’t have to use Ada for anything other than what you want to use it for — large bodies of code where structure and error detection is important. People like the language for its inherent security features. It is a rigorously typed language that keeps the programmer well within defined bounds.”
Ada vendors also have learned from past mistakes, and try to put the language’s compromised reputation behind them. The latest version of the language, Ada 95, has rectified many of the previous version’s technological shortcomings.
More importantly, Brosgol says Ada industry leaders made sure they had reliable compilers available when Ada 95 became widely available. In addition, the prices of Ada tools have come down, and free open-source Ada tools are available from Ada Core Technologies Inc. (ACT) in New York.
Members of the Ada community also are much more realistic than they used to be. “Ada is no longer at the hottest edges of development,” Brosgol concedes.
Even Carbone of Green Hills admits the demand for Ada overall is not growing quickly, and has settled into serving niche markets. His company’s Ada business is growing by picking up opportunities that other companies have abandoned. “Our competitors are de-emphasizing their support for Ada, and we are getting more and more of the available business.”
Looking back, Ada experts now realize that they faced some problems in the early days that were outside of their control.
“Ada was ahead of its time, and behind its time,” Brosgol says. Ada, he points out, came to maturity in the middle of the computer industry’s transition from mainframes to PCs. Ada traces its lineage from mainframe languages such as FORTAN, COBOL, and Pascal. It never made a smooth transition to PCs as the C language did.
Tags: ada, dead languages