Welcome! and rules
Joel on Software
What's the good of Perl.NET?
I want to preface this by saying three things:
1) By Perl.NET, I mean <a href="http://www.activestate.com/Products/Visual_Perl/">Visual Perl</a> from Active State.
2) I like Perl, and it is my language of choice for most projects.
3) I'm IT, not a programmer.
That said, my question is as follows:
What is the point of adding Perl to the .NET CLR? From my experience, Perl's strong point is that it's handy for command-line scripts. Yes, it can be used for GUI applications, but I would wager that the majority of programs written with Perl (for Unix, Windows, Mac, etc. servers) are just small scripts for doing little more that batch processes or website CGI's. (If I am horribly wrong, please feel fre to say so and go on and invalidate anything that comes next, that's why I'm asking.)
I would honestly think, with the .NET integration that Microsoft has planned -- servers, Office, Visual Studios, etc. -- that Perl would become/be obsolete on Windows machines, with VBA, VBScript, VB.NET, and such being more ideal and better integrated for writing small, quick scripts. I know from working on Perl CGI's and Active Server Pages, that many of the commands that make Perl so appealing to me (split(), substr(), and regular expressions) can be found in VBScript (Split(), Substr(), and Replace()/InStr()). With many of the commands being similar, both following a loose version of the C syntax, and VB* already integrated into Windows systems: What advantages are there to Visual Perl that aren't already found in the basic package?
Anywhen, this is an odd question that I thought of, and figured this forum might be the best place to ask, since it is for .NET questions.
Monday, October 07, 2002
A couple of reasons come to mind:
1) There are a lot of people out there who like perl (don't ask me why), and this lets them keep using it while also taking advantage of .NET.
2) It opens up the .NET libraries to the Perl programmer.
3) It proves it can be done, thus helping MS marketing with the ".NET is multilanguage" message.
4) Perl is still particularly good at text munging, in .NET or without. With Perl.NET you can write your text crunching in Perl and then easily call it from your other code in C# or VB or whatever.
Monday, October 07, 2002
First off, as the guy who implemented "split" in VBScript, thanks! That's a nice thing to say about the language and I'm glad you like it.
To actually answer your question "why perl.NET?", well, one of the basic design principles of the whole .NET programming model is to make it as _comfortable_ for programmers as possible. As Joel noted recently, platforms are all about making developers happy and productive.
I certainly see your point. From my perspective as someone who designs programming languages, there are only minor differences between C#, VB.NET, JScript.NET, perl.NET, J#, etc. Heck, from my perspective they're all minor variations on Algol 68!
But that's not the perspective of the vast majority of line-of-business programmers, most of whom do not have computer science degrees. We've done a lot of usability research on this population.
LOB programmers want to express business logic -- that's what they know about. Having to learn the syntactic vagarities of a new language to do so is _intensely_ irksome to them.
We want you pro devs out there to be productive whether you most easily express your algorithms in terse perl or verbose JScript.NET. If you don't then we have both an unsatisfied customer and an impediment to platform adoption.
Monday, October 07, 2002
ActiveState Visual Perl is just a plug-in to VS.NET that allows perl development. From what understand, it has nothing to with .NET architecture, Perl.NET, CLR, etc.
However, the same ActiveState has an experimental Perl compiler for .NET: http://www.activestate.com/Corporate/Initiatives/NET/Research.html?_x=1
As someone who programmed in both Algol 68 (long ago) and Perl, I see them as two completely different languages. (C#, Java, VB are about the same, indeed). I don't see how Perl.NET could support some dynamic Perl features... For example, in Perl, you can change a lot of things in run-time - add/remove class attributes, redefine class methods or even change the whole class hierarchy on-the-fly, add support for multiple-dispatch methods, etc.
The .NET CLR seems to work best with statically-typed OO-languages. It's more difficult to implement dynamic languages like Perl.NET or Ruby.NET efficiently. I suspect, Perl.NET might be just a subset of Perl, corresponding to C# features... In this case, the only good thing about it is that it will attract some Perl developers to the .NET camp.
But then, what about libraries? Are you supposed to use native language's libraries or .NET framework? Nothing wrong with those libraries - they are designed very well... But all languages ARE NOT created equal. Hence, their libraries should be designed differently.
If you put a motorcycle engine to a bicycle, what do you get? Is it an upgraded bicycle or a motorcycle for fellow cyclists? :)
Well... As much as I like Perl, I personally would use C# for .NET development.
Tuesday, October 08, 2002
IIRC, ActiveState has pretty much given up on building a Perl5 that targets the CLR (though they might try again with Perl6); the current PerlNET projects are focused on building Perl<->.NET connectivity, much as ActiveState built extensive Perl<->COM connectivity.
Friday, October 11, 2002
Igor: Re, Algol 68. I was being somewhat tongue-in-cheek of course. They're "the same" in the sense that Algol 68 is a structured, strong-typed language with user-defined data types, etc. The basic features of VB, C, C++, Java, Perl, etc are all found in Algol 68. From a "design a language" perspective there's a reasonable conceptual similarity.
Of course I've never personally written a program in Algol 68 -- from my limited experience with it, it appears to be an even less pleasant language than perl :-).
Re: .NET CLR: The CLR was certainly designed to make it easy to implement statically-typed OO languages. I can't speak to the difficulties of perl compilation personally, but I did work extensively on the JScript.NET compiler.
The CLR supports JScript.NET -- a functional, object-oriented, late-bound language (with both prototype inheritance and class inheritance!) -- and it works just fine. In most common cases the code we generate is comparable to C# codegen. Of course it was a lot of work, but it would have been a lot of work in any runtime -- building modern, fully-featured language engines is nontrivial.
Friday, October 11, 2002
I would give the dot Net framework a generation or two (java wasn't serious until the 1.2 framework came out) and some of the stuff from the research labs has a chance to move into the mainstream: generics (templates in C++ terms) for one thing, contract specifications (Eiffel-ish things) and aspects (Xerox research) are things that I hope make it into the next major releases of the dotNet framework.
Doing things like the dynamic inheritance of Perl classes (just munge the @ISA array, and you're done) will be easier as the work on making dotNet more Lisp-y proceeds.
Sunday, October 20, 2002
Fog Creek Home