What is Scripting?
A computer is a machine that runs programs. This is a simple and fair way to look at it. Programs must be written in some language, called a programming language which is either compiled or interpreted. Interpreted programming languages are also called scripting languages.
The difference between interpretation and compilation is that interpreted languages run directly from the source code, i.e. a programmer writes the program and it runs straightaway. A compiled program goes through an intermediate process called compilation where it is converted from source code, which is how the programmer writes it, into an object module which can be easily converted to an executable version by a computer to then run.
Why Not Script All Computer Programs?
Scripting provides an easy convenience since the programmer can take their program and just let it run. So why not script all computer programs? There are two good reasons for having compiled languages.
Compiled programs are generally faster than scripted programs. This is partly because programmers, in order to write comprehensible source code will use names that are meaningful and therefore may be long. Variable and object names like $path_to_server and @weekly_salary_sums are commonly found in programs. When a program is compiled there is no need to maintain these lengthy names because the computer doesn’t care about such things. ‘A1’, ‘A2’ are just as meaningful to a machine. Also, a compiled program may be optimized which is a process where the computer applies efficiency techniques to the code before making it executable. Finally, scripted programs must be run by the interpretor which is in and of itself a program consuming machine resources, while compiled programs may be standalone entities which run by themselves.
Another reason for compilation, an important one in the software industry is that scripted programs are run in source format. This means that anyone who has the ability to run a scripted program also has the ability to change it. And unless they’ve gotten permission from the owner of the program to do so this is illegal. It is also something that is very hard to enforce. Compiled programs do not have to be made available to the person running them in a source code form, only in an executable form. Which means they cannot be readily plagiarized.
Ocean and Cliffside
What is Client Side Scripting?
What is Server Side Scripting?
Server side scripting involves running a scripted program on the computer that is responsible for preparing and delivering a webpage to a visitor; more technically the content delivered to the client i.e. the browser which the visitor is using to view the webpage.
The most popular server side scripting language on the web is Perl, which is also a very efficient programming language. One of the reasons for the popularity of scripting languages like Perl and PHP on the web is that they are free and easy to get started using.
The Parable of the Two Programmers
The Parable of the two Programmers
Neil W. Rickert
Dept. of Math, Stat., and Computer Science,
University of Illinois at Chicago.
Once upon a time, unbeknownst to each other, the “Automated Accounting Applications Association” and the “Consolidated Computerized Capital Corpora- tion” decided that they needed the identical program to perform a certain ser- vice.
Automated hired a programmer-analyst, Alan, to solve their problem.
Meanwhile, Consolidated decided to ask a newly hired entry-level program- mer, Charles, to tackle the job, to see if he was as good as he pretended.
Alan, having had experience in difficult programming projects, decided to use the PQR structured design methodology. With this in mind he asked his department manager to assign another three programmers as a programming team. Then the team went to work, churning out preliminary reports and problem ana- lyses.
Back at Consolidated, Charles spent some time thinking about the problem. His fellow employees noticed that Charles often sat with his feet on the desk, drinking coffee. He was occasionally seen at his computer terminal, but his office mate could tell from the rhythmic striking of keys that he was actually playing Space Invaders.
By now, the team at Automated was starting to write code. The programmers were spending about half their time writing and compiling code, and the rest of their time in conference, discussing the interfaces between the various modules.
His office mate noticed that Charles had finally given up on Space Invaders. Instead he now divided his time between drinking coffee with his feet on the table, and scribbling on little scraps of paper. His scribbling didn’t seem to be Tic Tac Toe, but it didn’t exactly make much sense, either.
Two months have gone by. The team at Automated finally releases an imple- mentation timetable. In another two months they will have a test version of the program. Then a two month period of testing and enhancing should yield a com- pleted version.
The manager of Charles has by now tired of seeing him goof off. He decides to confront him. But as he walks into Charles’s office, he is surprised to see Charles busy entering code at his terminal. He decides to postpone the confron- tation, so makes some small talk then leaves. However, he begins to keep a closer watch on Charles, so that when the opportunity presents itself he can confront him. Not looking forward to an unpleasant conversation, he is pleased to notice that Charles seems to be busy most of the time. He has even been see to delay his lunch, and to stay after work two or three days a week.
At the end of three months, Charles announces he has completed the project. He submits a 500 line program. The program appears to be clearly written, and when tested it does everything required in the specifications. In fact it even has a few additional convenience features which might significantly improve the usability of the program. The program is put into test, and, except for one quickly corrected oversight, performs well.
The team at Automated has by now completed two of the four major modules required for their program. These modules are now undergoing testing while the other modules are completed.
After another three weeks, Alan announces that the preliminary version is ready one week ahead of schedule. He supplies a list of the deficiencies that he expects to correct. The program is placed under test. The users find a number of bugs and deficiencies, other than those listed. As Alan explains, this is no surprise. After all this is a preliminary version in which bugs were expected.
After about two more months, the team has completed its production version of the program. It consists of about 2,500 lines of code. When tested it seems to satisfy most of the original specifications. It has omitted one or two features, and is very fussy about the format of its input data. However the company decides to install the program. They can always train their data-entry staff to enter data in the strict format required. The program is handed over to some maintenance programmers to eventually incorporate the missing features.
At first Charles’s supervisor was impressed. But as he read through the source code, he realized that the project was really much simpler than he had originally though. It now seemed apparent that this was not much of a challenge even for a beginning programmer.
Charles did produce about 5 lines of code per day. This is perhaps a little above average. However, considering the simplicity of the program, it was noth- ing exceptional. Also his supervisor remembered his two months of goofing off.
At his next salary review Charles was given a raise which was about half the inflation over the period. He was not given a promotion. After about a year he became discouraged and left Consolidated.
At Automated, Alan was complimented for completing his project on schedule. His supervisor looked over the program. With a few minutes of thumbing through he saw that the company standards about structured programming were being observed. He quickly gave up attempting to read the program however; it seemed quite incomprehensible. He realized by now that the project was really much more complex than he had originally assumed, and he congratulated Alan again on his achievement.
The team had produced over 3 lines of code per programmer per day. This was about average, but, considering the complexity of the problem, could be con- sidered to be exceptional. Alan was given a hefty pay raise, and promoted to Systems Analyst as a reward for his achievement.