Slashdot Mirror
Open Source Community reaction to ActiveState & Perl
feeder sent us a recent Techweb story purporting to talk about the Open Source community reaction to the announcement from Microsoft and ActiveState about ActiveState being funded to extend Perl support under Windows. The story is indicative of some of the standard concerns-but how much do we have fear - what does everyone think?
The entire reason that Perl on Win32 exists in as good a form as it does is because Microsoft wanted to ship Perl in the NT Resource Kit a few years back, having recognized its importance, and hence paid for the port.
In doing so, a somewhat roughshod port & a set of new packages were created. Since then, things have been cleaned up a lot and Win32 is a well supported Perl platform, largely due to MS's original investement.
Now they're just doing exactly the same thing. Of *course* they want to make Perl MS-proprietary if they can. However, they really can't. Perl itself is not controlled by MS or ActiveState, so there's no way they can get total crap into *true* Perl.
ActiveState always has, and will continue to, distribute a version of Perl that it has compiled, no doubt together with some new modules etc., but I don't really think this will change things too much. It certainly can't affect Perl on other platforms since they can't directly affect the real Perl distribution, so all us Unix people are quite safe.
Now, they could fork Perl and produce an MS-only version, but would that be *so* bad? *If* this happened, then ActiveState would certainly continue to graft in any enhancements to the Perl core and hence users wouldn't lose anything much, except for perhaps a time delay, much like the one that we have now waiting for AS to give us a new build.
We can all argue that adding Win32 features is poluting Perl, but I can't really agree. There is no logical reason Perl should not expose Win32 APIs (via modular modules) other than the MS-is-shit-Down-with-MS-I-am-a-sheep attitude.
It's doubtful that an installation program or various other proprietary add-ons would be covered by the GPL in any case. The GPL can't solve all the world's problems.
BTW: perl is dual licensed under the GPL and the Artistic license.
- Tk::FileSelect (or it's front-end top methods getOpenFile() and getSaveFile()). The response to various configuration paramaters varied greatly - '-initialdir' and '-defaultextension' is ignored and '-initialfile' was buggy on the NT Windows platform; on the other hand, the '-filetypes' command was supported on Windows and not in the X version. I eventually ended up wrapping it to hide the differences.
- The tear-off menu items are nonfunctional in Windows, but can't be removed.
Other than this, there were some minor font sizing descrepancies, and the usual expected differences stemming from the basic nature of the underlying OS - file names, etc.Having a portable windowing toolkit is a good thing... Even if you don't actually run a particular app on more than one platform, you need learn only one toolkit for both - MS must hate that. And of course, Perl is just about the best thing since sliced bread.
An esoteric scratched itch:
Homeworld Map Maker Tool
I also don't think MS can kill Perl.
However, your parallel of MFC/C++ with J++/Java is somewhat flawed. Adding MFC libraries to C++ made no difference because if you're writing apps in C++, it pretty much _has_ to be platform specific. The reason one might port to Java isn't speed, it's portability. You can write Java apps and run them anywhere.
MS made their Java IDE create Java apps that would run ONLY on Windows (unless you jumped through hoops). (Actually, only on a MS JVM running on windows... even worse). So anyone using J++ from MS was defeating the ENTIRE purpose Java was created. What were they thinking? They also made thier JVM so that it wouldn't run 100% pure apps as well as MS java apps. Again, not trying to stay true to the Java concept.
No, MS didn't kill Java... but they tried as hard as they could to co-opt it. What will they do to perl? Perl's licence should keep them from making proprietary Windows 'language extensions', but since when has MS cared about that? they'll do it anyway, and let the layers deal with it.
And if they do add 'extensions' to Perl, and make a VB-style IDE for Perl? --It makes CGI programming, Perl programming easy! Yaay, use it! (oh, and if you don't change lots of settings, the Perl will only run under a MS interpreter. The MSPerl interpreter is free, though, and easily available, so no problem, right?).
It won't kill perl. Most Perl is used on platforms that MS can't influence, and by people who don't like them. They may try (and they may not, who knows?), but I don't think anything will come from it.
Only the Artistic License is mentioned. Perl is licensed under both the GPL and the Artistic License. So no, the changes will not be made available under the same license.
ActiveState may not be out to 'embrace and extend' PERL, but MicroSoft probably is.
This is probably the first step toward a Microsoft PERL[tm]. Then, after they have distributed it with the the operating system (probably in a Service Pak) and given it away to thousands of developers and developer CD, the embracing and extending comes.
Many of us will know the difference, but many, many more will not. What we need to do is be able to educate developers on what the word "Standards" means (MS has a really weird definition) and come up with further strategies on how to prevent corporations from hijacking our software. The GPL is good, but nothings been tested yet.
Hang on. It's going to be a bumpy ride.
jf
Medichlorians would be first-level primitives. Booleans would use light\dark instead of true\false. You destroy an object by setting its alignment to dark, or maybe by incrementing its anger counter. A | (lightsaber) would be used in place of a ;. The core distribution would include the Light and Dark modules. use Dark| lets you create objects which have kill and choke methods. And of course, "The source is strong in this one."
I get really passionate about this because I believe in libre source software. Folks, no matter what M$ does, they cannot steal the source. You have your copy. M$ cannot take that back.
Suppose the worst the Artistic License lets them do is release their own MicroPerl with proprietary core additions that they don't release source for. Now what?
You still have the real Perl. And M$ has just inherited a can of worms, trying to keep their proprietary version in sync with the legions of Perl hackers maintaining the real thing. If they succeed, it robs them of a lot of manpower, and for no gain, because, either way, they are incompatible with, and have lost the utility of, the thousands of CPAN modules. Can you spell W-O-R-T-H-L-E-S-S?
Now let's go to motive. Why would M$ want to hijack Perl? I mean hijack as in destroy, not hijack as in use productively. Their reason for destroying Java is to prevent "write once, run everywhere" as a Windows alternative, and to piss off a competitor (Sun). Guess what? Perl isn't a similar threat, and there is *no* competitor to damage.
You naysayers and doomsayers remind me of politicians with knee jerk reactions. Grow up, figure out what's between your ears, learn how to use it for yourselves without being a slave to Microsoft. Whether you follow them slavishly, or react against them slavishly, matters not. You need to think for yourselves, not for or against Microsoft!
--
Infuriate left and right
Well, it could go either way. On one hand, to quote Larry, "perl is a post-modern language"... and as such adapts to it's surroundings. If Microsoft Windows is it's surroundings, then it would make perfect sense to integrate API calls and the like into perl. Whether it's developed by a proprietary company, or developed openly, doesn't matter too much: what matters is that more developers will use perl.
free software broke into the market by creating better, faster, and cheaper products than commercial ventures did. I see no reason why it wouldn't be different here... once a idea reaches "critical mass", some developer will start the development of a free version of whatever module is in demand. The important thing here is.. perl will be exposed to alot more people.. which means that perl will be developed alot more quickly.
Maybe we will wind up paying for Feature X for awhile, but if enough people want it, a free version will be created.
--
So, how 'damaging' are all the Unix specific features of PERL? Did these features fragment PERL? Are you confused by the Unix features? If you are going to bash OS specific features of PERL be thorough!
So, M$ gets some custom Win32:: modules, and the win32 platform-specific code gets some extra stuff in it to make up for the limitations in Windows. Big deal. This is no different from the platform-specific bits for VMS, MVS, OS/2, Plan9, or half a dozen different flavors of Unix.
/proc, or the SYSUAF) is all that portable.
Anything that ActiveState puts into the core has to be covered by perl's licensing terms, so the source'll be in the main tarball. And if they really want to fork off the source tree and make changes they don't release, well, that's OK too by perl's license.
Besides, 90% of the perl people write is platform specific anyway, so who really cares? Is it so much worse to have a perl program that does Windows specific stuff than it is to have one that does something Linux specific, or VMS specific? It's not like code that plays with the registry (or
Perl will remain perl regardless of what M$ might like to do to it. They've as much chance of coopting perl as they do coopting Linux.
The worst case scenario that I can think of is that ActiveState develops some Tk-like library that let's you create GUI widgets, but is not cross-platform.
OK. Then we have Tk stuff on UNIX and Tk-mutant stuff on Windows.
How bad is that really? Will this kind of "balkanization" halt the development of good Perl scripts for the Unices? I doubt it.
Color me not worried.
Sorry, I think this must be wrong. I work with one fellow who discovered at some point that an OS upgrade to an NT IIS server broke all his Perl stuff; so he abandoned Perl, in favour of VBScript. Honest to every deity you can imagine.
To me, a webserver always has Perl available. If NT 4.0 broke my server, I know what I would have replaced. Hint: it wouldn't be Perl. But for many NT admins, the point is single-sourcing. If it's an MS product, it's in; and if it's not an MS product, it's out. This is because of the putative greater compatibility between programs on an all-MS box.
And never you mind the evidence! Integrated solutions work, no matter what your experience is. If your experience suggests otherwise, you need thousands of dollars in support services.
The idea of Perl replacing VB/VBA is seems a little farfetched. MS has a huge investment in VB, and there is a large developer community dependent on it as well. VBA is also relied upon heavily in many Win apps at the moment. Perl is a different tool, IMHO, for the most part. On NT, I use Perl for CGI scripting ... I use VB when I want to quickly whip up a GUI that will be used on Windows only.
...
As far as I can see, MS seems to try to keep its fingers in as many pies as possible
YS
"Arrr! The laws of science be a harsh mistress." -- Bender
and that OS will improve as a result.
and Micros~1 Needs a good modern language
and the API requirements of a Win32 port will tend to open now closed Micros~1 code.
Seems like win-win to me.
Perl cannot be corrupted, but it can and will improve its operating environments
I want Perl as deep inside as we can get it
Lets call it Beauty and the Beast
Just another perl hacker in Bangkok
artistic license
You may charge a reasonable copying fee for any distribution of this Package. You may charge any fee you choose for support of this Package. You may not charge a fee for this Package itself. However, you may distribute this Package in aggregate with other (possibly commercial) programs as part of a larger (possibly commercial) software distribution provided that you do not advertise this Package as a product of your own. [ heh.. Microsoft P++ ? ]
hrm, it's not gpl.. and it is rather confusing. will they have to provide the source to the changes that they made or just point to where to get a real version of perl? [point 3-a, 3-c in the license.]
I have to admit in the perl case I really don't
see the problem. It isn't like perl is a well
defined API, there is no formal definition and
every time I upgrade perl -something- breaks because of a perl change.
Alan
This not the first article I've seen on this topic where posters refer to, "...the way Microsoft killed Java."
I respect the programming language Perl and understand that it is very powerful. I am not a Perl coder, however (yet).
I use a handful of other languages, though. Java is one of them. I'm not "married" to any language (well, ok, C perhaps) and can get along fine if one or more of them is "killed". If Java really was killed, I would say, "Bummer -- it was a nice language," and fire up the C or C++ compiler.
That hasn't happened yet. Reports of Java's demise are greatly exaggerated.
It's more accurate to say that Java has not lived up to its hype. In 1996, pundits expected everyone to be porting all of their C++ apps to Java in 3 years. Obviously, that's not happening.
But I don't think any language COULD live up to that amount of hype or that aggressive a time table. Furthermore, anyone who expects companies to rewrite millions of lines of legacy code written in very popular, powerful languages like C++ is just not being realistic.
I recognize and thoroughly resent Microsoft's attempt to "embrace and extend" Java with incompatible libararies. Honestly, though, did anyone really think that Microsoft would just stick with Sun's standard and not try to add their own goodies? I look at C++ vs. Visual C++ here. As best I can tell, Microsoft's Foundation Classes have done nothing to harm good ol' C++. When programmers want portability, they just don't use MFC.
So Microsoft may not support pure Java anymore. So what? Sun and others make perfectly good runtime environments that are zero-cost and run just fine on Win32.
In short, it just bugs me when I see people pronouncing Java "dead". Especially in a forum like slashdot where FUD is a four-letter word. Why all this langauge "holy war" nonsense anyway? Is anyone really willing to bet the farm that their favorite language today will be their first choice in ten years? If Java goes away and I decide to code in Perl, so be it. The langauge is just a tool.
Save the whales. Feed the hungry. Free the mallocs.
Sarathy Gurusamy made the first announcement of all of this to perl5-porters about two weeks or so ago, and it was discussed quite to death. (Read the archives if you're interested.)
Things seem resolved for now, unless ActiveState changes things... and if they do, the perl5-porters group will have quite a lot to say about it.
But for now, things seem just hunky dory.
BIFFSTER, perl porter
Looking over the press release and the FAQ at activestate's web site, I find a couple of interesting things.
1. "We are very pleased to continue this relationship with Microsoft," said Dick Hardt, CEO of ActiveState.
2. Microsoft funded the first port of Perl version 5 to Windows in 1993.
Doesn't sound like this is any new deal, just renewing an old arrangement. It's too early to tell what this will mean, but let's see what happens.
Free for use is the biggest load of double speak I've heard lately. It tries to coopt the term "free software" (in the FSF parlance) while completely opposing the spirit of this concept. Let's be honest. Real translation:
------------
Q: Will the work be Open Source?
A: Most of the work done for Microsoft will be released as Open Source, but some of it will be distributed only as proprietary Win32 binaries. Part of our business model is to sell proprietary components that only run on Win32. Everything that is not Win32 proprietary will naturally be distributed exactly under the same terms as Perl. (Because it has to be.)
The ActiveState installer for Perl and any other technologies that we develop and want to make money from, such as PerlScript and Perl for ISAPI, will continue to be proprietary Win32 only binaries.
In summary, some of the things we do will be Open Source, and the remaining things will continue to be proprietary Win32 only binaries.
-----------
Look, fact is, yeah - ActiveState is attracting people to Perl. But at what cost?
Seeing all the expected flamage over the issue makes me wonder how many people posting actually know anything about coding Win32 Perl ... ActiveState (under other names) was initially tasked and paid by MS to make a better Perl port to NT (so getting more funding to do more work shouldn't be chilling or even surprising) - this being back before the standard source wouldn't build particulaly well with NT compilers.
Having a clean installer (along with the bonuses of being able to twiddle with the registry and such) makes scripting on Windows boxes so much nicer, particularly when I want to ship out some nice utility to a friend or client that doesn't have a compiler and if they did wouldn't know what to do with it.
But hey, the article mentions MS, so let the knee-jerk reactions continue.
Even if they keep it open they can do a great deal of damage by implementing MS Windows-specific functions. That would fragment Perl and introduce much confusion into even the usage of the term, "Perl". Would even the GPL protect against this kind of "embrace and extend" strategy? I think not.
FUD
There are already MS Windows specific functions in Perl. There are Mac specific functions in the Macintosh port of Perl. There are VMS specific functions in Perl. There are Unix specific functions in Perl.
ActiveState doesn't maintain Perl. ActiveState doesn't determine what goes into Perl and what doesn't. Ultimely, it is Larry who has a final say what goes into Perl and what doesn't. And Sarathy, the current Perl pumpkin. And he listens to what p5p (perl5-porters) have to say.
Microsoft can contribute a lot. If it's good, and if it benefits Perl (like a fork() for the Windows platform) it will be added to Perl, be it in the core, or as a module in the standard library. If they come with crud, it will never find its way to Perl.
People should learn to listen to what the people that work on Perl have to say about this before uttering their FUD on forums like this.
--- Abigail