Why use an IDE?
This section will examine the reasons behind using an Integrated Development Environment (IDE) over more traditional methods.
Before looking at the reasons behind using an IDE over more traditional methods, it is worth considering all the tasks you tend to perform when developing with a scripted language. There are differences from the typical compiled language. You generally don't need to compile the source into the final application, but some of the tasks remain constant:
- Writing the code -- This includes getting the format right so it is readable.
- Checking the validity -- Although you won't compile the code, there is still a formal structure, and you can still introduce bugs and problems into the code that can be identified by running some simple checks on the code.
- Access documentation -- No matter how good a programmer you are, it is almost inevitable that you will need to look up some aspect of documentation.
- Write comments/documentation -- Adding commentary to your code makes it readable, and adding documentation as you go helps to make it portable.
- Executing the code -- Often, perhaps more so with scripted languages, you tend to try out the code you are writing.
- Debugging -- Any problems during execution will normally need to be investigated through a determined period of debugging.
How you perform each of these tasks will depend on what environment you use. Let's look at the typical non-IDE based environment first.
Ask a typical Perl programmer what he uses for editing and working with Perl scripts, and it's likely that he will simply return the name of his favorite editor -- perhaps vi, maybe even Notepad. At a push, he might be using a more extensive and intelligent editor like Emacs or oXygen that provides built-in markup, highlighting, and intelligent formatting.
The ability to use a standard editor and execute the program directly through the command line is one of the major benefits and advantages of scripting languages like Perl and other scripted languages like Python, PHP, and Ruby.
There are some obvious benefits to the editor approach. For example, you can easily edit and create the scripts pretty much everywhere, with or without a specific editor, so there are no limits on when and where you can program.
Some aspects, though, are less than perfect. Looking up documentation, for example, often needs to be handled in another application or terminal window. Execution of the application will also require dropping to a shell or terminal to execute. Also there is no management of the project as a whole. A typical Perl project will consist of Perl scripts, modules, and probably other data, as well, like XML files or other data sources. They may all exist in the same folder, but their relationship to each other and their significance might be less clear.
The key element to any IDE is directly related to that first word: integrated. All the steps outlined in Tasks can generally be performed within an IDE without ever having to leave or switch from the application.
For example, code can be written and automatically formatted. Errors and typos in your code can be highlighted as you type, and you can use the hot links to documentation to verify the functions or modules you need to use, without separately looking up that information.
Usually, you can also execute -- and monitor the execution -- of your application so you determine whether it works correctly, and you can debug its operation in the process.
You can use the information generated, and output during the execution and debugging process in your application directly. For example, generated errors and warnings will provide a link that will take you directly back to the appropriate line of your source code.
Overall, the main benefit of the integrated system is to save you time. You no longer have to spend time switching between applications, or finding and locating the code that generated problems. All of the information is not only highlighted but linked and accessible, making it easier to work within the code structure.
Many of these abilities are unfamiliar to the typical script programmer who is used to the simple editor approach. But it's time to move on to a more coherent environment.