Scripted Development Answers

 
 
By Peter Coffee  |  Posted 2005-08-08 Email Print this article Print
 
 
 
 
 
 
 

Find the right time and place for scripting languages in the enterprise.

Every enterprise IT constituency craves the attractive user experience and low life-cycle costs that can flow from the use of scripting languages—notably JavaScript, Perl, Python and PHP—and script-based application models such as AJAX. Those benefits are multiplied by growing connectivity, and the synergy of client-side scripts manipulating server-side data, to make scripting a candidate for a lengthening list of tasks.

Its necessary, though, for practitioners to recognize and confront scriptings challenges. The use of scripting on the Web—JavaScript, specifically—"suffers from outdated, uninformed, and inaccessible development methods which preclude it, and therefore Web development in general, from attaining its full potential," asserted "The JavaScript Manifesto" released last month by The Web Standards Project.

Scriptings worst faults for enterprise development flow directly from its strengths as an end-user tool. Scripting lets a user tailor generic applications to handle routine tasks quickly, conveniently, consistently and intelligently, with minimal time between recognizing and meeting a need—and with relatively little concern for general-case rigor or long-run maintainability.

Scripting languages are intuitive, with loosely typed variables and other flexible data structures that relieve users of the nuisance of variable declarations and the like. Scripting provides the immediate gratification of interpreted languages, able to execute statements as soon as theyre written—or even generate and execute statements from within a running script, without compilation or linking.

That direct interpretation also makes for relatively straightforward debugging, with tools such as the JavaScript debugger, code-named Venkman, whose 0.9 release is part of the current Mozilla distribution .

"You can be fairly sure that a script is doing what you wanted," IBM Rational Software Product Manager Ed Gondek told eWEEK Labs.

These traits make scripting productive on the upside, albeit error-prone and resource-intensive on the downside. However, a script thats written by its own user to meet a short-lived need can tolerate those drawbacks. The risk level rises when developers, who are also users, let the appeal of scripting draw it into roles beyond what it was designed to handle.

Developers benefit from the support of scriptable platforms that let them prototype applications quickly, in a way that scripting proponents often compare to sketching with a pencil instead of drawing with a pen. Developers also enjoy the freedom that scripting tools provide to refine applications immediately in response to user feedback. Moreover, developers can radically reduce a projects cost by making maximum use of a platforms bundled tools or built-in facilities—in many cases a core competence of scripting tools.

These strengths of scripting languages are especially relevant to teams that want to bring the domain knowledge of business systems analysts closer to the implementation of business processes as Web services. When business analysts write code in a scripting language, said IBMs Gondek, "theyre working at an abstract level, with a much-higher-level verb set, and they dont have to worry about the plumbing. Abstraction lets them spend more time in the cognitive part of the problem—they just get more done."

Development managers will also find that their training costs are reduced by the high leverage and approachability of scripting tools. "To learn these languages—Perl or Python or EGL [Enterprise Generation Language]—is relatively inexpensive; management doesnt have $50,000 to invest in retraining a 4GL [fourth-generation language] programmer in Java," said Gondek, whos based in Research Triangle Park, N.C.

To read why Peter Coffee thinks developer tools are never good enough, click here. Scripting languages are traditionally used for integrating tools with well-structured text output that can readily be captured in a file or pipelined—with any needed transformations—from one application into the input of another. "Scripting is really good for systems administration and text processing," said Gondek. "Theres a lot of lower-level types of manipulation—log files, data conversions—that you can do with scripting languages." Indeed, scripting tools such as REXX have been used in such roles at eWEEK Labs for a decade and a half.

More complex and risky is the use of scripting methods for adding interactivity to content and function presented through a Web browser—but this is the hottest growth area for scripting, often under the banner of AJAX (Asynchronous JavaScript and XML) but also in other forms. The eWEEK Excellence Awards entry and judging Web sites have long used scripting for such tasks.

The problem is that unlike relatively stable platforms such as Windows, Unix and Mac OS, "every new version of Internet Explorer presents new challenges and limitations; every new version of Mozilla and Firefox has changes," said Alexei White, product manager at eBusiness Applications Ltd., based in Vancouver, British Columbia. "With scripting, you can do simple things very easily; to do more complicated things takes more time to understand the browser internals more fully."

Even so, there are compelling reasons for enterprises to consider a script-enhanced, browser-based application model as the path of least resistance for a new projects design.

The sluggish performance of older Web applications, with their constant page updates, is dramatically improved in AJAX applications. Anyone who doubts this, the Labs would suggest, can simply compare an AJAX-based interactive site such as Google Maps against mapping sites such as MapQuest that use older page-refresh models.

Performance gains are not merely an end-user amenity. "AJAX is all about cost containment," White said. "Licensing is cheaper, deployment is cheaper, and, fundamentally, AJAX-based solutions work faster. You put a user on a task, and an AJAX-enabled scripted solution can save half of a users time, in terms of page reloads and such. That adds up to a lot of cost savings."

Developers used to find that writing a Microsoft Corp. Visual Basic application, which can reach the 90 percent of the user base that runs Windows, made more sense than doubling development effort to produce applications for multiple platforms but only broadening ones user base by a few percentage points.

Today, the Labs finds that the incentives have tipped in the other direction: An AJAX application is accessible to essentially 100 percent of users with essentially zero cost of deployment or update distribution, and it offers a richness of user experience comparable to what most users expect from a traditional thick client.

Scripting as an application model brings along crucial caveats. Scripting languages are almost defined by their ease of using global variables and other progenitors of unmaintainable code.

"Its harder to build modular solutions" with scripting tools, warned eBusiness Applications White, whose companys packaged components are aimed at improving that situation.

Development managers should therefore apply the power and flexibility of scripting where it has the greatest leverage—where it can provide an effective bridge between task domain knowledge and platform facilities, and where it can add interactivity to Web applications with minimum client-side footprint and bandwidth use.

The power of scripting can lead to its being used to do more things than it should. Yes, scripting is easy to learn—but when a script grows without a high-level plan into a massive and unmaintainable monster, its developers may relearn painful fundamentals of software engineering. Developers must draw the right line between what theyll do with scripts and what theyll do with less convenient but more structured tools.

Technology Editor Peter Coffee can be reached at peter_coffee@ziffdavis.com.

Check out eWEEK.coms for the latest news, reviews and analysis in programming environments and developer tools.
 
 
 
 
Peter Coffee is Director of Platform Research at salesforce.com, where he serves as a liaison with the developer community to define the opportunity and clarify developers' technical requirements on the company's evolving Apex Platform. Peter previously spent 18 years with eWEEK (formerly PC Week), the national news magazine of enterprise technology practice, where he reviewed software development tools and methods and wrote regular columns on emerging technologies and professional community issues.Before he began writing full-time in 1989, Peter spent eleven years in technical and management positions at Exxon and The Aerospace Corporation, including management of the latter company's first desktop computing planning team and applied research in applications of artificial intelligence techniques. He holds an engineering degree from MIT and an MBA from Pepperdine University, he has held teaching appointments in computer science, business analytics and information systems management at Pepperdine, UCLA, and Chapman College.
 
 
 
 
 
 
 

Submit a Comment

Loading Comments...
 
Manage your Newsletters: Login   Register My Newsletters























 
 
 
 
 
 
 
 
 
 
 
Thanks for your registration, follow us on our social networks to keep up-to-date
Rocket Fuel