Perl and .NET

Kaufmann writes "Good old Perl guru Nathan Torkington has an article on O'Reilly's perl.com about "What every Perl programmer needs to know about .NET". It's quite short and, unsurprisingly, favourable to .NET (although not to Microsoft). Points to the SOAP module on CPAN and a bunch of other stuff. It contains a nasty error, though: claims that Java is the only language that compiles to the JVM. Check it out anyway."

Comments

Vaporware?

[lemox]

It's already released (well, as beta at least). MS sent out the beta kit for Visual Studio .NET about a month ago, anyone can get it and try it out. A few weeks ago, ActiveState released the Visual Perl plugin for VS.NET, along with Perl for .NET.

I'd say .NET already has a strong presence, for better or for worse. The Question really is when it's actually going to be released as a final product.

Re:"only" language

[bjepson]

Jon Udell's December 18th column addresses the issue you raised, questioning whether it is in Sun's best interest to keep the language and the JVM tightly coupled. The column includes a survey of some of the people who have implemented languages for the JVM.

--
Brian Jepson

Inefficienct but useable and can do more

[Fjord]

I'll agree that XML-RPC is inefficient compared to CORBA, but you would be surprised at how useable it is. A long time ago I decided that I wouldn't shun a technology because it was billed as slow until benchmarks show it really is too slow for what I am using it for. I used XML-RPC in enterprise medical systems, and it was never shown to be an important bottleneck.

Plus, you can do so much more with it. The area I found it to excel the greatest in was in security. When you are bulding the XML response, you can be choosy as to what fields you include beased on the user in the session. Contrast this to passing an object by value. It becomes an all or nothing prospect.

Then there is the small bonus that testing your client involves writing a static XML file served to it when it makes the call. It makes automated tests a lot easier. This is a good thing for an XPer, like myself.

Another thing is that is does greatly simplify a design. You don't have to force everything into terms of object models. You just think of it as formatted data, formatted however is logical for the call. This really is a great, and better experienced than explained.

One final note (although there are other good things about XML-RPC), if you are making a web applications, using XML-RPC to distribute the system, gives a homogeny to the model. This is a good thing, because it also makes the overall metaphor for the architecture easier to understand.

It is important to note that XML-RPC is not intrinsic to .NET. The systems I've worked on with it have all been J2EE systems. I just finished a JSP taglib, that, among other things, allows you to select blocks of JSP to include based on the Accept tag. It also does XML/XSLT with xalan. With this, you can use the same application logic for HTML, WML, and XML agents. You can use XMl-RPC to call into .NET (I've done this calling into ASPs before .NET) and .NET can call into J2EE systems. And Sun is a large SOAP supporter.

Efficiency

[Jeffrey Baker]

Soap uses HTTP to send XML-encoded instance and method calls on remotely defined objects and receive return values

The above is what turns me off of SOAP, XML-RPC, and the like. The actual implementation is impossibly inefficient. To make a SOAP call, one's software must build an XML document and an HTTP request, and send them together. To handle a SOAP request, the software must not only handle the HTTP protocol, but also build a DOM tree from the request body and act on the nodes of that tree. This is a serious abuse of CPU power, and not the way to build a performant system.

I like systems that are easy for programmers, but I also like those systems to have advanced, efficient, performant implementations. The two goals need not conflict.

Re:And you can't turn it off...

[Pinball Wizard]

>> Now the "ActivePerl" books will start to appear

Hate to burst your bubble, but the O'Reilly book "Learning Perl on Win32" was written by the founder of ActiveState. Also, from the beginning there was always much more development done on the ActiveState port of Perl than the "pure Perl release" you mention. ActiveState was started with a grant from Microsoft, and since its inception it has worked the "pure Perl" people to merge the two products.

Therefore, Microsoft essentially funded the development of Perl for Windows systems, and also came up with the worlds first Perl IDE. ActiveState, essentially a subsidiary of Microsoft, is also releasing the Perl IDE as open-source software for Linux.

I watch the sea.
I saw it on TV.