Visual Perl
by Eric PromislowFebruary 06, 2002
Jumbo shrimp, military intelligence - Visual Perl? ActiveState built its reputation by bringing Perl to the Windows platform, thereby extending the reach of Perl and the size and nature of the Perl community. However, regardless of the Windows port, many Perl programmers don't hesitate to voice their preference for text-based editors (like vi and emacs) over Windows-based integrated development environments (IDEs). Some Perl gurus find text-based editors the most efficient way to code. But for programmers who are new to Perl, and programmers who primarily work in graphical environments such as Windows, the intuitive, visual nature of IDEs help them to learn languages and produce code more quickly.
ActiveState's combined expertise in Perl and the Windows platform, and our stated goal of bringing open-source programming languages to a wider developer audience, has led to our interest in developing IDEs. We have three particular goals:
- to create an intuitive editing environment
- to deliver much of the functionality that powerful text-based editors offer, but without the initial learning curve
- to add language-specific features, such as real-time syntax checking, debugging, colorizing and online help
Therefore, in addition to developing our own Komodo IDE, ActiveState has participated in Microsoft's Visual Studio Integration Program (VSIP) and developed three plug-ins (Visual Perl, Visual Python and Visual XSLT) for Microsoft's Visual Studio .NET.
|
|
Integrating Perl support into Visual Studio .NET required extending Visual Studio to provide Perl-specific functionality. For example, Visual Perl includes module-based code completion, pop-up hints for Perl keywords and module functions, a context-sensitive Perl language reference and emacs-like auto-indenting, brace matching, and block selection. Additionally, Visual Perl makes use of standard Visual Studio .NET functionality through the graphical debugger, the class view (for browsing functions), sophisticated project management, etc.
Visual Perl and .NET
In a separate initiative, ActiveState has developed PerlNET, a tool for building .NET-compliant components with Perl. PerlNET is part of ActiveState's Perl Dev Kit 4.0, and Visual Perl integrates with the Perl Dev Kit, allowing developers to create .NET-compliant components (and also Windows applications, services and controls) from within Visual Studio .NET.
PerlNET and Visual Perl make it easier to build multi-language applications. Previously, the easiest way to build Windows applications quickly was with Visual Basic. However, Visual Basic has drawbacks with regards to the the speed at which the applications run. Also, VB is not the most commodious language for developers accustomed to modern constructs such as associative arrays, dynamic functions, closures, run-time eval and regular expression matching with full backtracking.
Microsoft has addressed this by creating a modernized ".NET" version of Visual Basic, and with the creation of C#, which provides a near-functional equivalent to Visual Basic .NET (some would say "superior, but functionally close"). Additionally, any language that can target the .NET runtime engine can be used to build components, and multilanguage interoperability is transparent. In a nutshell, you can use a high-level language to script the UI, write back-end components in Perl, and tie the two together almost effortlessly. All you have to do is:
- tell Visual Perl that a particular Perl project should be converted to a .NET DLL, and add the interface definition for the component in one or more "=for interface" POD comments
- assign the code in the Perl-sourced DLL a namespace
- point the client application to the Perl-sourced DLL, and use that namespace
Visual Perl and .NET: Making it Happen
As an example, the process of building a .NET-compliant application goes something like this:
- Quickly build a front-end in C# or Visual Basic .NET using Win Forms to populate a form with UI widgets. Double-click on the widgets to script common events ("..._Click" for buttons, "..._TextChanged" for changing text fields).
- When it's time to add more processing to the back end, add a Perl project to the current Visual Studio .NET solution, and treat it like a Perl package. Define the constructor, add methods and fields to the interface definition block, and then define the new methods and fields.
- Like other Perl component builders, you should test and
debug your Perl code before converting it into a DLL. The
simplest way is to put a
block at the end of your module, before the final "1;", and drive your package from that.unless (caller) { ... } - Configure the Perl project as the "startup" project, then run the Perl component straight through, outside Visual Perl's debugger. (You can run programs in a DOS command shell, or in the "Run Window" within Visual Studio .NET. Both support standard IO, including stdin.)
- Change the project type from "Standard" to "Managed DLL," change the "startup" project to the C# project, then build and run.
Pages: 1, 2 |
