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

Perl supports UTF-8, not limited to 16 bit chars

[Chip Salzenberg]

Perl's new Unicode support -- which is already in the development sources -- is mostly in the form of support for UTF-8 encoding. The neat thing about UTF-8 is that it is NOT limited to 16-bit Unicode. It's an encoding-neutral way to put big (up to 40-some bit) characters into an otherwise ASCII byte stream.

So if Unicode grows beyond 16 bits -- which I'm sure it will -- Perl's UTF-8 support will already be there, ready to support it.

In other words: Don't Panic.

Good

[slim]

Seems fine to me. Activestate will be doing it, not MS, and the results will be released under the Artistic Licence. Perl will prosper.
Note that Larry Wall himself did a fair amount of work making Java play nice with NT -- O'Reilly paid for that; and nobody complained then.
The only danger I can see here is a glut of Perl scripts that don't run under non-Windows environments -- but it's already perfectly possible to write Perl scripts that call C functions from Windows DLLs (don't ask me how; I skipped past it in comp.lang.perl.misc)
--

Before you freak out...

[Nekromantic]

Before everyone freaks out, think about how this will affect you directly. When Microsoft E&E'ed Java, it was a problem because it introduced incompatible VMs to potential users of your code base -- good code could be broken by a bad interpreter. It also led many developers to use their "extensions" of the language, which meant that if you had a correct VM, you couldn't run their software.

What can Microsoft do to Perl? Ask yourself this: If MS were to mess around with win32 perl, would it break your code? Probably not. Because perl code is run in an environment of *your* choice, there no place where MS can break your code. The client doesn't have to run a (possibly broken) interpreter - you choose the interpreter. And if someone else uses an "extended" perl, will you still be able to use thier site? Of course. They run the MS version on their side, and all is well.

Whether you use perl for system administration or CGI, take a moment to think what microsoft could do to break your environment - probably not much.

--

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....

Re: O, were it so simple...

[ebbv]

You know, if stopping M$ was as simple as me
not using (or paying for *cough*) their products,
then guess what? They would not be where they
are today. IE would not be so popular, there
would be more *nix games, et cetera, et cetera..

The problem is not me (or dare I say us)
using it, the problem is the rest of the world,
especially the non-clued suits using it and
bringing it to the fore. WinPerl will not
be totally compatible with our current incarnations of Perl, and that will be the
problem.
...dave

++TMTOWTDI

[Tom Christiansen]

Larry Wall once wrote:

Some of you know what the Perl slogan on Windows is, and you can say it with me: ``It's a good thing there's more than one way to do it, because most of them don't work.''

There will now be one fewer way for Perl not to work under Microsoft: forking is good for you. This helps everyone because we can all fork off at will without the grinch that stole Redmond barking at us.

I'm curious how it will avoid the insanely inefficient process start-up penalties one incurs under Microsoft, as well as how the non-shared data pages will be fast without being copy-on-write. The multiple-interpreters-in-one-process work will also help everyone.

I'd say to reserve one's fears until there's something to fear. ActiveState can't after all be all bad: they even list the Perl Power Tools on their pages to help people sentenced to tool-deprived systems. :-)

--tom

`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