Slashdot Mirror
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". "
I currently use ActiveState Perl when I'm stuck with the Windows platform. They seem to be a pretty together company. Their commercial license is annoying, but all of the stuff they do that I care about is under the normal Perl license.
As long as ActiveState keeps control over their version of the codebase, and stays autonomous, I don't see any problem here. On the other hand, this is Microsoft we're talking about here. With an agreement in hand between ActiveState and Microsoft, I fear ActiveState is not much longer for this world. Microsoft's past behavior with similar agreements is pretty scary.
----
Open mind, insert foot.
I wasn't aware that it was the base Perl, I just assumed there were some Win32 specific patches that were needed (i.e. the patch file would be their codebase). I stand corrected, but that wasn't my point.
My point is that the agreement itself makes little difference, but it shows that a small company (ActiveState) has gotten Microsoft's attention. Historically speaking, such attention generally means a short term benefit for the small company, and a medium-to-long term disaster. If ActiveState goes byebye, it would be IMHO a loss for the Perl community, particularly any Perl for Windows users out there.
----
Open mind, insert foot.
In general, there is no reason to oppose anyone changing a free software product. The whole idea of free software is that it puts the user in charge and allows him to make changes to suit his needs, even those change the author might not approve of. Larry Wall has stated that he wants to try very hard to ensure that there is only one version of perl (the implementation is the standard) and it looks like this company will be donating most of their code back, so a split is probably unlikely in this case.
Where I have a problem is with the proprietary add on components it looks like they will be developing. I'm not familiar with this company, but from the FAQ it looks like much of their business is writing "freedom subtracted" add-ons to Perl. I think this is very unfortunate and do not think companies should be rewarded for leveraging free software to sell proprietary products.
Bear in mind that PERL is not as vulnerable to
Micros~1 "embrace and extend" game as Java
is because Perl has only around 300 native
functions where Java has around 5000 native
functions -- meaning there is less under the hood
for Micros~1 to mess around with. Also Perl is
less GUI dependent (in fact it is GUI independant)
than Java which makes it much harder to break than
Java. And let's not forget that Perl is Open
Source and Java is not (so far).
When Microsoft corrupted Java all they had to do
was change the behavior and calling conventions
of just a handful of functions and "Voila! It's
now incompatible!" -- with Perl that trick is
not so easy. If you consider Perl's "API" to be
CPAN, well it is almost impossible for Micrsoft
to mess with CPAN since each module is under the
control of each author.
So overall I'm not worried. In fact maybe I would
still use Windows if Micros~1 had released a
"Visual Perl" package -- especially if they
would release a "lite" Visual Perl package for
free maybe I would consider using Windows -- no,
just kidding -- I won't be using Windows any time
soon!
As a perl programmer I sense that this will do us
more good than harm. I have faith that Perl is
strong enough to withstand any "contributions"
from Micros~1.
As I remember it, some of the folks at ActiveState worked at Hip Communications, the company that did a lot of the original Perl for Win32 work. Guess who provided some of the initial investment to jump-start that port of Perl 5 to Win32? Microsoft.
The last time Microsoft was involved with Perl, the Perl for Win32 port was not in the core Perl distribution. It would have been easy to morph it into WinPerl or VisualPerl or who knows what.
But the truth is, Microsoft didn't hijack it back then. Even if they had intentions to do so now, I think it would very difficult given that ActiveState's distribution is based on the core Perl source tree. ActiveState and many other people put a lot of time into merging the core Perl and Win32 branches, and I doubt they are going to allow a split to occur!
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.
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)
--
Consider the following:
1) M$ will not be doing the work itself. We all know what happens when Microsoft intervenes directly; things get wrecked. At least with some other firm Perl has a chance of remaining intact.
2) The development will be Open-Sourced. Under the same license as Perl itself, no less (which does make sense). In other words, we won't have to scramble so much to keep up with the damage M$ does.
3) M$ doesn't dare try to kill Perl. The Internet is the only thing Microsoft has ever fought against and lost. They tried killing TCP/IP; that didn't work. They're doing their damndest to wreck the Web, but that isn't working either (the piece of crap known as IE might be popular, but there are not many sites using IE-only features). And they will not be able to stop Perl for the same reason: it is too deeply entrenched already. Java failed because MS attacked early, while it was still weak. Apple's hanging on because M$ was a little too late; MS has weakened it severely (there was a time when Apple II's and Macs had more marketshare than Windoze or DOS, way back in the beginning) but it can't kill Apple off completely. Likewise, Perl has dug itself in too deep for MS to totally uproot.
4) Consider that DOS and Windows have no native scripting systems. Macs have AppleScript, Unix/Linux have Perl and the shells, DOS/Windows have... nothing. Not as a normal part of the operating system, at any rate (I hardly think batch files count). Simply put, Windows needs scripting, and Perl could well fit the bill. MS needs Perl, so it can't harm it (too much) or it hurts itself.
We should have an open mind about this. It's possible that Perl might just get some improvement out of this deal.
From the FAQ, the main changes are:
1) fork()
This implementation of fork() will clone the running interpreter and create a new interpreter with its own thread running in the same process. Goal is functional equivalence to fork() on UNIX systems without the performance hit of NT's process creation overhead.
2) Microsoft Installer Support
3) Globalization
Extend Unicode support to all system calls in the core. This includes file names, environment variables, etc. Note that this functionality will only be available on Windows NT and Windows 2000 systems.
4) PerlScript performance
These look fairly harmless, no? Firstly,
#1 looks like they're probably keeping the
call on windows' being named fork. That's
pretty good, as it isn't a great departure and
would keep XP compat more likely than replacing
fork w/ something else...
#2 probably won't change anything -- if they're
talking about Perl itself (making a fancy installer), shouldn't change a thing. If not,
whatever it is, it probably will be done in
a module.
#3 this is probably the most cause for worry, but
isn't Unicode supposed to be the big thing in
5.006? If so, the "only on windows" statement
here is probably irrelivant, and all we're talking
about is platform parity, which is a good thing.
#4 So long as this happens w/o changing the
language, this isn't going to really hurt
anyone.
We've seen embrace and extend from Microsoft, but
this particular instance doesn't look too
dangerous, as the extend part seems to be little
more than optimizations which won't change the
language...
For every problem, there is at least one solution that is simple, neat, and wrong.
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.
--
-- "Machines have no conscience" - Queensryche
The thing MS hates most is anything that allows programs to run on different platforms without modification, this makes Windows irrelevant, which is what gives MS its power.
They will make their own version of Perl, and try to convince people that the other versions of Perl are substandard.
They could pull something like they did with their "Frontpage" strategy. If the Web server did not have "Frontpage Extensions" (IE, did not run MS IIS), a "helpful" alert box would appear and inform the user that their ISP 'sucks' and they should choose a different (MS-friendly, of course) ISP. Of course they eventually allowed 'Frontpage' extensions to be incorporated into other web servers, once they were found out.
Of all the comments I've ever posted, this is definately one of them
As far as I can see, this is a perfectly sensible move on the part of MS, and Active State, and one they should be commended on.
The idea of PERL from the beginning, has been to make the job you have in mind easier to achieve.
And faster. It's a damn good tool, and I love it dearly.
Due to the market, I have to use Windows products, as well as my preferred Linux, because, well.. That's what's out there.
One of the things that's always made me sit back and sigh about using Active State PERL is the lack of a fork(). And now, with a little financial aid from MS, it's getting put in.
There are many other functions in PERL that rely on *NIX platforms, and you can find these by reading the PERL docs on functions unsupported by Win32.
I would rate some of these among *NIX platform specific options.
But is that a problem? Not really. If I want to know how to do something specific on a particular platform, I RTFM. And there it is.
I currently use PERL on both *NIX and Win32, and am heartily glad I _can_ use PERL on Windows, as it cuts the hassle of having to learn VB (Use PERL/TK for most GUI functions), works across platform with few mods, and gives Windows a useable script language without having to worry too much about paying huge licence fees to a company selling a new and totally incompatible other language.
By introducing people to PERL, you're introducing them also to the ethic of Open Source (to a good degree), and the wider world of the Perl Mongers, and in general a very nice bunch of people who are altruistic in nature...
Maybe this will push home to even more companies that Open Source works for everyone, be it MS users, Linux, BSD or whatever...
And having a better port only lets me do my job even better, which is no bad thing.
PERL is a well engineered, well thought out language that's stood the test of time..
I say "hurrah!" that windows users now can slowly catch up on where the rest of us have been for years.
Just my tuppence worth,
Malk
Sorry I wasn't a bit clearer...
The idea is, you have two or three characters that look very similar. One is Chinese, one is Japanese, one may be Korean. They look similar, but usage differs (ie, they have different meanings). Because of the ridiculous Unicode proposal, they are all unified into the same code point (ie have the same character code, which means there is no way to distinguish them through Unicode alone).
Now, the problem is, depending on the Unicode font used, you might get the Chinese character, you might get the Japanese character, or maybe the Korean character - but there is no way to be sure beforehand which one it is going to be without breaking the "universal" concept of Unicode.
The whole point of Unicode was that code points were supposed to be kept separate between languages - so an A in English and an A in French (as well as German, Dutch, etc. etc. etc.) are all supposed to have different code points, because usage differs between these languages. (This is just an example; I'm not positive that all these languages have a different code point for A). This concept unfortunately breaks down for CJK fonts.
I hope that was a little easier to understand...
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.
/. - I didn't change it just for this post...
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
...take advantage of platform features on Windows in this case does not appear to mean the same embrace and destroy strategy as seen in the halloween documents. Instead, Microsoft wants to take standard PERL and optimise it for the Windows platform. It will be the same PERL as before, but will run better. And it will still be Open Source. Thumbs up for Activestate!
I doubt they'll keep the source proprietary--that would seem to be self defeating in this case.
I don't think there is any such thing as a "general purpose programming language".
All programming languages involve tradeoffs. Some are easy to implement, some have lots of features, some can be compiled into very high performance code, some are backwards compatible with others, some are easy to understand for a particular community, some catch a lot of errors at compile time, some catch a lot of errors at runtime, some use lots of resources, some are well-suited to development projects with lots of developers, some are well suited to development projects with only a single developer, etc.
Somewhere in that space, Perl, Python, Java, Tcl, Eiffel, Fortran, Lisp, Scheme, C, C++, and all those other languages each have their place. If you pick the best language for each job, it is my experience that there is actually very little overlap between those different languages. Each of them has their communities, and few of them are in danger of going away because some other language supposedly superceded them.
After slogging through all this, I'm annoyed -- no, I'm irate -- that so much of the discussion has been sidetracked by a gale-force Slashdot Paranoia storm.
.exe of Perl 4.0.1.6, ported by Diomidis Spinellis and dated 2/23/1992 -- it would not be exaggerating to say that it changed my life almost more than any other single program).
Sure, Microsoft is blah blah blah [insert favorite pejoratives here]. As a matter of fact, they are not the devil incarnate and some of their stuff does work pretty well. You can thank them for the fact that the Win32::ODBC module is the backbone of many a fine Web site (or didn't you notice that ODBC, a Microsoft project, is a protocol that despite some faults Doesn't Suck).
I'm also appalled that so many of the commenters here didn't even bother to check basic facts about Perl and its history in the DOS/Win realm. I've been using it since I was running everything under DOS 5.0 in 1992 (still have the old
I've also used the various ActiveState Win32 Perl releases for years with excellent results. For example, I use it to munch 2-gigabyte raw dumps from databases and produce crosstabs and statistics two orders of magnitude faster than the databases can do so themselves. One of my main reasons in moving to Linux, actually, was to double that performance, but it's certainly not bad under NT.
I'm glad tchrist showed up to correct some of the more egregious misunderstandings about Perl. The evolution of Perl between 1994 and 1997 from basically a fairly limited domain of text processing to a platform for all kinds of useful things, through the addition of object oriented structures, the revision of the library approach into the full-blown module environment we now have, and so forth, ought to be a classic study in how computing tools can evolve in a positive sense rather than a bloatware sense.
If Microsoft wants to hook into that in a bigger way, that's a very good thing. Perl makes my life in the NT context bearable. However, I don't want to see it fork from the standard distribution in any significant way. Larry understates the importance of reunifying the code bases between the standard development tree and the ActiveState version with the One Perl initiative. And he also plays down the fact that it was not a guaranteed win. But nonetheless it did work out.
So now consider the real story: Microsoft has conceded where the locus of authority is for Perl. They are promising in public to play nice. Their tendency not to do so is well understood and their activities will be thoroughly scrutinized.
In other words, this is precisely the opposite of what happened with Java. And it is no surprise, given that Perl is open source and Java is not.
And that is the most important lesson to be drawn from this.
I don't mind Microsoft throwing in some things to optimize local processing, as long as they are themselves open source and don't fork my code. Because the bottom line is that if I can't run the basic stuff across platforms, their optimizations will disappear from my code first. That is market discipline Microsoft has never had to face, and they may have to grow up (maybe just a bit, but grow up nevertheless) as a result.
Perl is a remarkable accomplishment. Learning more about its history, philosophy and development is a rewarding experience. And, golly guess what, it's all out there readily available to be discovered.
-------
maybe he funds Perl, but
Bill Gates Is My Evil Twin.
I think he was referring more to the fact that originally, if a person was uploading to a web site (html, images, etc) from Frontpage, and the server did not have Frontpage Extensions installed, an message would pop up and tell the user that they might want to switch ISPs due to the fact that the one they were using didn't support frontpage extensions, and therefore their web pages might not work right. After this was found out, MS was made to change it.
-[Blaine]- "'Oh dear,' says God, 'I hadn't thought of that,' and promptly vanishes in a puff of logic."
See subject line.
IF the MS team working on this project "respects" the concept that (most) Perl programs should be able to (pretty much) run on either Win32 or *nix...IF they don't try to make key parts of the core Win32 Perl package MS property...IF all they are doing is adding functionality that exists in *nix versions of Perl that currently does not in Win32 versions....and IF, as it appears, they are trying to help make it compatible with this Win2000 thing....
Then hopefully this is a good thing.
The problem will be if they try to subvert it into "WinPerl" by adding tons of amazing new functionalities and properties that are propietary to MS and closed. I haven't got a problem with adding functionality to Perl for Win32 that takes advantage of OS features. As long as it stays open. As it is, the *nix version of Perl has this edge with all of it's *nix functionality built in.
The simple fact is there are differences between the two OS's that limit usage of a lot of Perl programs between platforms, and if this fixes it, great. Maybe we'll see more *programs* being written in Perl, Tcl/Tk, etc. etc. for Windows.
Blech. Signatures.
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.
I assume they mean, adding it in Windows in a way which is compatible with the way it's being added to the standard Perl base. Larry and co. have been working in Unicode for quite a while now, someone correct me if I'm wrong on an estimate of 2 years.
Perl wasn't designed with Unicode in mind, but as Mr. Wall is fond of saying, Perl is really great at text processing... Unicode is a natural addition.
I don't think this is a big deal. Is it possible for Microsoft to take the Perl idea and pervert it like the wondrous things they've done with Java? I highly doubt it. They are just adding Windows functionality and access points for those who need them.
I won't.
You can't. That's what Open Source means - your enemies as well as your friends can use it. The Serbs can use it as well as the Kossovans. Straights and gays. Republicans and Democrats. Once you open it, you can't put it back in the box.
ben_ the technologist and platform agnostic
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....
"The horse leech's daughter is a closed system. Her quantum of wantum does not vary."
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
Think different? I'd be happy if most people would just think...
>>WinPerl will not be totally compatible with our current incarnations of Perl, and that will be the problem.
Where did you get this idea? All the FAQ and press release say is that there will be access to Win32-specific features, and there have always been such extensions in ActiveState Perl. You can write portable perl and it will work in ActiveState just like on any other platform, or you can write Win32-specific code and it will work only on Win32. You can do the same thing on UNIX; don't tell me you've never seen a Perl script that would only work on UNIX, cause there are plenty of them. It's as easy as `/usr/bin/whatever`
I've written a lot of ActiveState Perl, some of it portable, some Win32-specific. It's impossible to use the type of features they are talking about accidentally. You always have to use some Win32:: module. What could more explicit than that?
LJS
Nostagically relevant, consider pi, pix, px, and pc on old BSD systems for a Pascal environment. I can present you with Pascal source, and ask what it is. You cannot tell me. It could be run under a pure interpreter, a bytecode compiler-and-interpreter, or further translated into some machine's assembly language. All are still interpreted.
Oh, they claim, they claim. But see the old article by Heinz Lycklama. Everyone else who did POSIX compliance did so to create something genuinely useful for their customers. Why use persnickety technicians when you get to hoodwink the courts to ordain you POSIX in a bait-and-switch game? I leave it to the readership to judge Microsoft on their own.--tom
The advent of freely available, plug-and-play substitutes for our standard Unix tools has been a great relief to victims of Big Bad Bill. These include the vi (vim, actually, but that's fine), Perl, the entire UWIN environment, the Cygwin suite, and of course, Perl Power Tools, which also work on non-{Microsoft,Unix} systems.
Some folks feel that we shouldn't port our tools to the evil one lest it thereby become easier to exist under his yoke, and thus perhaps decrease the chance of someone upgrading to Unix. But hold on there. Imagine that you're living in a fertile oasis of plenty, and on a dayhike, come across your friend toiling for his business in the searing desert that surrounds you. He is parched and crying out for aid. You invite him back to your oasis to refresh him, but he says that his job is there in the infernal sands. What do you do? Do you just walk away and abandon him? Of course not! You give him a sip or seven of that cool water you've brought with you from your safe haven.
So too should it be with our tools.
--tom
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
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. :-)
That part is certainly true! And I hope that part is, too.--tom