Programming PerlNET

To judge the book for yourself, you should have at least an "executive-level" understanding of .NET. Explaining .NET is more challenging than, for instance, explaining HTML or CGI or SQL or other topics popular among Perl programmers. The difficulty is that Microsoft has constructed .NET as an idiosyncratic combination of marketing plan, business strategy, and engineered software. For an accurate technical picture, you must discount at least a portion of .NET's marketing. It's only valid in a figurative sense, from our perspective as developers.

Here's the core of what is technically true: .NET is a framework; that is, an enormous collection of classes that provide functionality common in office automation, so-called "e-commerce," and related areas, along with XML awareness and other low-level routines. In principle, the framework is language-neutral and perhaps platform-neutral, and even bigger than any one language or operating system. In practice, .NET works best under Windows, and Microsoft's new C# language is the one best able to exploit .NET.

If you know how much more productive you can be with Perl than C# or Visual Basic, the availability of PerlNET (.NET-hosted Perl) will thrill you. Along with its familiar capabilities as a Perl processor, PerlNET both creates and uses .NET components. This means that you have all of Perl's flexibility in accessing such key .NET dimensions as the Windows Forms GUI toolkit, the Active Server Pages (ASP) web application system, and the ActiveX Data Objects (ADO) data manager.

I like Programming Perl in the .NET Environment for its recognition that programmers with different backgrounds need different information, for its accuracy, and for the richness of the example code explained in the text. The prose of the book is generally well edited and readable; only isolated sections show the flab or lack of polish that suggests editors overlooked them. Small imprecisions regarding typing—dynamic versus static, and strong versus weak—will bother pedants, but neither they nor occasional typographical errors interfere with the main points of the chapters.

The introduction of Programming Perl in the .NET Environment includes more cheerleading for Microsoft in its creation of .NET than I prefer. While it's important to provide clear explanations of .NET's commercial and engineering advantages, and the authors' enthusiasm appears genuine, I think the book would have been better with just a bit more reserve.

In principle, PerlNET has at least three distinct roles: development of new applications; reuse of legacy Perl-coded components (all of CPAN, for example); and exposure of a scripting interface to large applications. I'm not certain at all which will prove to be most important. Programming Perl in the .NET Environment is aimed at programmers with the Perl lust for high productivity. My impression of large information technology (IT) shops is that Perl's culture of flexibility and clever concision interests them little. One way to think about .NET and such ancestral technologies as COM and Visual Basic is that they're designed to lift up masses of mediocre coders, not expand the horizons of elite wizards. IT managers who favor ".NET's power" generally are talking about things such as business-ready report generators or colorful navigational aids. The large body of Perl programmers seem to regard such pieces as algorithmically uninteresting. What Programming Perl in the .NET Environment doesn't tell us is how the organizational cultures of Perl and .NET will accommodate each other over the next couple of years.

TPJ