Microsoft Embraces and Extends Perl

Anonymous Coward writes "According to this Press Release, Microsoft has signed an aggreement with Active State to add missing functionality to the Windows version of Perl. But the FAQ states that they also want Perl to "take advantage of platform features on Windows". "

Comments

Good or Bad?

[The Dodger]

This isn't necessarily an altogether Bad Thing (tm). It means that Microsoft must feel they are losing out by not supporting Perl fully. Unfortunately, the nature of the Perl source licence means that Microsoft don't have to publish the source for their implementation.

And before people start spouting off about how Microsoft shouldn't be allowed to embrace Perl like this, don't forget that the whole idea of Open software is that anyone can use it, and one of the reasons that Perl uses the Artistic licence, as opposed to the GPL is to allow companies to use Perl in commercial software. It's not something I personally agree with, but the creators of Perl decided to do it that way, and it was their choice.

I also foresee dire predictions that Microsoft will turn Perl into a proprietary technology, like they did with Java. However, so what if they do? Perl isn't like Java - for the most part, it's a server-side scripting language, not a half-compiled binary which is meant to run on the client.

The main thing is, don't panic. This will probably turn out to be good for Perl in the long run.

The Dodger

Looking at the FAQ...

[BJH]

It would seem that Microsoft is out to improve Perl performance on WIndows, but a closer look at the FAQ makes me suspicious. I know that Larry Wall said that ActiveState isn't so bad, and the fork() stuff doesn't bother me, but it rather goes against the grain of Perl to make alterations like MS is proposing (converting all applicable calls to use Unicode) without doing it in a cross-platform manner.

One other thing - the press release says that Unicode is greatly desired by Asian customers. This is nothing but marketing bullshit. Anyone in Asia who works with text processing knows that the current implementations of Unicode (including 2.0) are almost pitifully inadequate. And before anybody leaps forward to defend Unicode, please study up on the CJK problem before doing so. Unicode causes so many problems in its present state that it may simply be easier to continue using present "standards", at least in Asian countries. I'm quite simply disgusted with the way countries that don't use an ASCII superset have been treated with regard to Unicode.

(The CJK problem I'm referring to above, for those who can't be bothered looking it up for themselves, is that the present implementations of Unicode allow pretty much only for 16bit characters, which is nowhere enough to contain the number of characters required for Chinese-based fonts - ie, China, Japan and Korea (CJK). The idiots in charge of Unicode then decided that "similar" characters would have to use the same code point, thereby defeating the whole point of Unicode - that is, for CJK characters, the appearance of a character can vary depending on the font used, even though Unicode is supposed to define separate characters based on differences in usage between languages. To put it simply, a Unicode font is useless for DTP or other areas where the appearance of a particular character must be clearly defined. Iknow, there is a 31-bit version of Unicode, but nobody has made any serious attempt at defining code points outside of the 16bit code space.)

With this development, it would seem that Microsoft is going to ride roughshod over Asian markets by saying that Unicode is the complete solution to all our problems. Well, I say, stuff that where the sun don't shine, Billy boy.

BTW, my sig has been the same since I first registered at /. - I didn't change it just for this post...

let's not be hypocrites...

[sporkboy]

Doesn't perl "take advantage of the platform features of *nix" right now, intentionally and without shame. Having the ability to do good system-integrated admin scripts on Windoze in something other than VBScript or J-don't call it java-Script would be a Good Thing in my book, and make life somewhat more tolerable for those used to the platform tightness on *nix.

What about the Larry Wall interview?

[Quaternion]

Correct me if I'm wrong, but didn't Larry Wall sort of address the commercialization of Perl issue in the interview he gave to Linux Journal (a few stories ago on /.)?

I think the quote was:
"I'm not directly affiliated with ActiveState, but I've worked with them, and I think the problems they've solved far outweigh any problems they've created. You've got to understand their market has always been the Windows space, where you're actually doing people a favor by charging them money for things, because that's the only way to keep from confusing them. Linux users are smarter than this, of course, but some Linux users aren't quite smart enough to realize Windows is a different culture, and Perl, being a postmodern language that is sensitive to context, will look different in a different culture. "

Don't get me wrong... I'm not a big Microsoft fan. But it seems to me that if even more people use Perl, that will be good for the community in general. And it wouldn't violate any of the "sacred principles" of Perl/Linux advocates in the process....

`Server-side' and `Scripting' as pejoratives

[Tom Christiansen]

Perl isn't like Java - for the most part, it's a server-side scripting language, not a half-compiled binary which is meant to run on the client

I'm afraid that your statement is disingenuous at best, deceptive at worst. Perl is hardly a `server-side scripting language' as you portray it.

First, to relegate Perl to nothing more than CGI is a tremendous disservice. Perl is a general-purpose programming language whose process, file, and text manipulation facilities have made it the programming language of choice for tasks involving quick prototyping, system utilities, software tools, system management tasks, database access, graphical programming, and world wide web programming--just to name a few. Systems administrators, network administrators, and web administrators on all platforms flavors especially love it because of its potential to automate virtually everything they need to do.

The second misconception to disabuse oneself of is this whole `scripting' notion as being somehow different from `programming'. It's not. They're quite the same thing, at least as used in the vernacular now that JCL scripts and uucp chat scripts are largely (and thankfully) gone. And before you mumble something about `interpreted', you should think about how, contrary to popular misconception, not merely Perl but all programming languages are interpreted. The only question is, at what level?

In the normal case, the Perl compiler compiles source code into parsetrees of Perl Pseudocode (PP), and hands those off to the PP interpreter to execute (one could say `interpret') these trees.

In other cases, the Perl compiler compiles source code into parsetrees of Perl Pseudocode (PP), and hands those off to a code generator, which generates bytecodes. These bytecodes are then later loaded by a special module that converts them back into PP trees, which are then handed off to the PP interpreter to execute (one could say `interpret').

In still other cases, the Perl compiler compiles source code into parsetrees of Perl Pseudocode (PP), and hands those off to a code generator, which generates C source code, which is handed off to the C compiler, which generates assembly source code, which is handed off to the assembler to produce object code, which is handed off to the linker to create a linked binary image, which is then handed off to the kernel to execute (one could say `interpret') at some later date, whose instructions are then often handed off to the firmware to execute (one could say `interpret').

In all cases, the Perl compiler runs an optimization pass, just like any other compiler. For example, the expression $x = 2 ** 31 - 1 would be computed at compile-time, since it's a constant expression. But the Perl compiler is rather more clever than just that, sometimes inlining certain subroutines, ignoring unreachable code, doing loop hoisting, etc.

I hope that's all clear now. :-)

The main thing is, don't panic.

That part is certainly true!

This will probably turn out to be good for Perl in the long run.

And I hope that part is, too.

--tom