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". "
Now, MS is gonna make Perl suck worse.
Is anyone surprised? I'm not...
Why should anybody care? Gimp plugins aren't compatible with Photoshop. Does it make the ground shake?
Grow up, people.
Perl for windows already has lots of windows specific stuff. The engine is implemented as a scripting engine - you can embed perl in your html page and run like javascript in IE.
You can use perl to create and use COM objects - you can't do this on *NIX.
If anything the press release seems to make the implementation closer to the *nix one - like a better fork().
There is nothing new here most of you guys are just spreading FUD.
Heeelllllloooo get a clue. This is nothing new - Active State has always created modified versions of perl for windows.
Forget the fact that there ARE no advantages to the Windows platform in regards to Perl ... in my opinion
Yep, in your opinion.
Sun's fighting back on Java, probably more than anything Microsoft has done, is what has damaged that language.
Have you ever heard of a language called C? Lots of platforms have extensions to C that are optimized for that platform only. Does that make C any more or less powerful on the other platforms it is implemented on?
A bunch of whiners who want a world where every building is painted the same dirty grey.
Odds are that all this entails is making Perl's COM support and Unicode support better than it currently is. If they're really ambitious, maybe they'll add better support for Windows threading (process creation is expensive on Windows, but threads are cheap and easy, so the Unix fork() trick doesn't work so well).
If you want to see what the end result will probably look like, take a look at the Python Win32 extensions or the Active Haskell package for Haskell. These extensions let you do things like write COM servers, conveniently access the Win32 API, and so on from within your scripting language.
This will just add one more language to the toolkit of those who need to automate tasks on their WinXX boxes. It is an event of no particular metaphysical or political significance, so relax.
Will the never ending torment ever end?
I hate to see the day where Micros~1 takes one of our languages and uses it against us.
Have you read the license recently? It's not your language, any more than it's Microsoft's language. It's everybody's language.
(Microsoft does not have to undermine Linux. Linux has a license to undermine itself.)
If you can't beat them - at least drag them down to your level.
That sounds like something Sun would say in defense of Java.
I guess you can say it in defense of 80's technology like Linux as well.
Microsoft wanted to do four things:
(1) Add real fork() support
-- Which will add something useful to *Windows*.
(2) MS Installer support
-- Microsoft can't hold a candle to RPM.
(3) Globalization; adding UNICODE support
-- We've got UNICODE too. Let's be consistent.
(4) Caching of parsed scripts
-- They're worried about performance. But
eventually they'll discover Linux!
But I sure don't like the idea of OUR darling Perl being raped by M$...
If Perl is your darling then you'd better be willing to set it free, and hope it comes back.
If you insist on controlling it, then you're trying to make it your whore.
Wake up.
Perl isn't contaminated with the GPL virus.
Of course they eventually allowed 'Frontpage' extensions to be incorporated into other web servers, once they were found out.
Sorry you're wrong here. There have been extensions for Apache and Netscape Servers since version 1.0 which is before MS even bought the company that made front page.
"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,"
Python works beautifully on Windows already. It has as great OLE support on Windows as it does posix support on Unix. Python also makes it easy to develop software that is either portable or platform-specific. If you don't import platform specific libraries, your code will be as portable as the C standard library allows it to be.
I'm seeing all of these messages saying: "It will be great when we can use Perl on Windows."
YOU ALREADY CAN. This is really just a continuation of a relationship that ActiveState and Microsoft have had for years. Who do you think paid for the original Perl port to Windows???? O'Reilly?
I'll admit that Perl for Windows sucks but this deal isn't going to change that. Perl has a totally Unix centric design and most of the maintainers are Unix-centric. ActiveState did a lot of really nasty stuff working around that unix centricity and some stuff still doesn't work.
If you want a truly cross platform language you could of course use Java or Python. But Java forces that lowest common denominator thing on you.
Python's Windows implementation is powerful and mature. It can do all of MFC, OLE, the Registry and all of the other Microsoft crap. Even better, when you write code on Windows you can usually move it to Unix without a problem (if you are careful with filenames, of coures) and vice versa. Python's platform dependencies are mostly isolated into clearly labelled platform-specific modules.
If you need to administer Unix and Windows boxes you don't need to wait for Microsoft to pay ActiveState take Larry's Unix tool and try to make it work in a foreign environment. Just use PYTHON! It was designed for cross platform use from day 1!
Yawn. Wow. This mean a lot coming from a former Best Buy employee (ROTFL).
Thats right -
Call it ECMAScript
Of course you know that Microsoft's implementation sticks almost 100% to the ECMAScript spec, where Netscape's implementation doesn't even come close...
IIS is not required for frontpage. frontpage extensions run on many servers (apache, netscape) and operating systems (unix,..)
hahahaha. Perl suck worse? Is that possible?
I mean, it does nice things, but the syntax
is the most disgusting bag of junk I've ever seen.
I have to agree with you. Same situation. I have to admin NT boxes (Not by choice) and Perl for Win32 is damn good. I hope this doesn't screw things up and A BIG HOPE that it makes NT ALOT BETTER.
NT sucks and you have to do 20 steps to do something that you can do in Unix in 2. Visual Basic is good but you may have conflicts when you add SP's or patches. I throw in a Perl script and blam it works faster than my Visual Basic or VBscripts. Plus I don't have to recompile my VB exe's if I want to change something.
I think this is another M$ attempt to show that NT is better or will be better than Linux. They have to have something to challenge that Linux is 10 times more stable than NT. If Linux can come up with a standard good desktop GUI interface and big name Apps/Games deployed/support, M$ is real trouble as far as the desktop OS market. They are starting to feel the server market from Linux and it will only get worse. THEY KNOW THIS.
My prediction is we will see, not Office 2000 or the next version after that, but the 3rd version of Office 2000 being ported to Linux to REGAIN Micro$oft's #1 status.
That was worth a laugh. "They know their platform" -- appearantly you've never tried to code on Windows. It's a horrible mess of bizarre APIs with no other intention than to make the program totally dependant on The Monopoly. They don't even know their own platform.
:)
Re: applets on IE vs. Netscape.
You're right, IE performs better. Know why?
Watch your CPU usage: IE takes the majority of your CPU cycles for even a simple applet.
Most of those applets were probably made with an MS Development tool (J++) which we all know is not 100% Java and was designed with the intention of breaking compatible with non-Microsoft VMs.
They were sued over this remember, and had to fix it. (They later won on appeal I >think and the dirty, semi-legal, and monopolistic practice continues.)
This is what they're going to do with Perl, and as someone earlier stated you're being naive if you don't realize this. Why do they care about Perl? They have WHS and OLE for semi-automation. They can extend WHS. Likewise, they extended Java with the intention of taking a platform independent language and tying it to The Monopoly's horrid half-OS and pathetic excuse for a browser. (Netscape 4.6 is 10-20% faster than IE 5, and BTW, that 60% thing they advertise is with a "LAN connection" according to their own fine print. That means the data comes down rapidly, lower-bandwidth users will not notice an improvement because they have a huge network bottleneck. Don't people get this?"
Now, of course, Perl is fairly closely tied to unices, but it's also open. Microsoft has never been interested in truly crossplatform tools, and if you don't believe this...well, wait and see.
This will tell us whether we should or should not use such a permissive license.
...That Microsoft isn't going to force ActiveState into "improving" core language functionality? Yeah sure, right now it's just simple Win32 hooks, but can you be certain that MS wont try to undermine the overall goals of the Perl community by forcing you to code things in that cause major platform dependance on Win32? Can you be sure that MS wont force the depreciation (sp?) of core libraries under the guise of "performance"?
All I keep hearing is "Don't use the new APIs if you want cross-platform Perl", but it's the possibility that Microsoft will make it impossible for scripts written on Win32 to run on Unix that causes concern, and I don't belive that it would be all that difficult to quitely shift people from the Perl standard to MS Perl.
ActiveState is performing trusted transactions with an untrusted entity, and it's going to create unnecessary problems for the Perl community as a whole. Sadly, we will be doomed to repeat history here untill we realize that MS just can't be trusted.
Goodluck to ActiveState their going to need it after this sellout.
Jason Burke
jburke@motion.net
'course, you can never totally get rid of a program under windows, and install wizards don't actually have to check if replaceing a file will do bad, bad things(tm) to other installed programs. RPM isn't perfect, either, but I'd rather have that than the add/remove programs wizard.
I thought the one in the resource kit was an MS-financed port by Intergraph....
I know that when M$ dips it's hand into anything, the kneejerk reaction is pessism. This news is only good. Perl will not be destroyed. If a WinPerl does evolve from this work, then it does. As another post said, you can choose to write portable Perl or Win-specific Perl.
Personally, I don't see myself writing Win-specific Perl unless the "WinPerl" becomes an alternative to VB for A. I think it would be awesome to be able to use Perl in Access, Excel, or Word instead of VBA. I don't want to learn VBA because I'd use it so rarely and it's utility is constrained. However, I use Perl all the time on *nix and Windows. So, I wouldn't have to learn a new language and I might actually use Access/Excel/Word more or better as a result.
You guys are both infants, and need to exercise patience before flaming each other.
In your original post, were you stating that perl ought to be relicensed under the GNU GPL, or were you just advocating that new software be written under that license to avoid embrace-and-extend sabotage? I believe the post that started this thread was speaking specifically about perl; and since old versions of perl have already been released under the Artistic license, this might not be an effective strategy even if Wall could be convinced to do it.
I believe that what everyone's problem is
(of those who are complaining about WinPerl)
is that they realize MS will probably NOT
stick to "improving" the Win32::* extensions.
Rather, they will (as they tried to do w/ Java,
etc.) muck with the core Perl structure in some
unspecified way, and maybe with some other modules, such as IO::Socket, etc...to make them
more "windows compatible", creating extensions
that work fine on windows, but conflict with the LW's official versions.
-Just Another Anonymous Coward
I am appalled at the display of ignorance in the :)
replies to this story. (Most of them.) Perl
already has a lot of Windows-centric add-ons,
such as perlified access to the registry, COM,
etc.
Perl is a glue language. NT needs a lot of
glue. Windows is a legacy system after all,
until you can upgrade to Unix.
else but me remember UCSD Pascal on the LSI-11's? Sometimes this turns into machine code, sometimes it doesn't. The only honest
thing you can say is that all programming languages are by definition interpreted. You cannot a priori look at a program and say what is
going on. In fact, nothing is going on at all.
The fact that it needs perl... the program perl to load it and interpret it is what i see as a interpreted language. :)
A C/ASM program don't need another program to interpret it... the prosessor do it.. that's when it is compiled
Given the tone of the surrounding threads,
are you TRYING to make yourself flame-bait?
while I am repeating the mantra,
I WILL NOT TAKE THE FLAMEBAIT I WILL NOT...
I must say, where did you get that?
It has a well defined syntax, much better than
C's, once you get to know it.
As well, it only one of two languages that
natively allow a function to return multiple
values (the only other one I know of is the
HP's *RPL language). Sure you could do it in C,
with structs, but please...that gets ugly.
Then again, if you don't like it,
I shant stop you.
My only complaint with perl is the absence of
recursiveness in 'use' and 'require', but I don't
really need that.
Perl is my woman, and I shall defend her honor.
-Just Another Anonymous Coward
find the path you downloaded to: if you don't know where you put it, why are you bothering? a fundamental computer skill is navigating the filesystem --- you have to do this on windows as well when you search for that icon!! and, it just so happens that if you can't find it, there's a nifty tool called find which is pretty easy to figure out, since you just type man find to read its manual.
probably from the command line: if this is all you're afraid of, i have no real sympath for you. many many many old-school dos folks around where i work refuse to use the graphical file managers for their work, relying instead on the dos command prompt, which is a primitive, backward hindrance by comparison with unix shells. modern unix shells will even complete your typing for you...
find the path to install to: every single windows installation wizard i've ever seen asks you where you want to install something. rpm's install to default locations for those not interested in knowing, and even give you the option of changing this. also, with rpms you can check what it's going to install before the fact, so you don't wind up with the standard WinInstallWizard surprises. even most modern open source packages install by default to /usr/local, which is where they should go anyway. again, this is nothing that's difficult!
and then figure out if you've installed all the dependant RPM's!: well, rpm will tell you if you haven't. if you use glint, grpm, or gnorpm or some other front end, this is even easier. while it is a pain to have to download and upgrade some other package, there's nothing much to finding out if you have it.
don't even start about mounting file systems!: why not? what's hard about that? in BeOS you must mount and unmount file systems; in MacOS, you must unmount a disk by dragging it to the trash. in each of these OSs the disk then becomes part of the filesystem. only windows/dos is crazy enough to hold with the drive paradigm...
really all this stuff isn't that hard.
We have scripting now. The "Windows Script Host" installs with the nt service pack 4 and is available for win9x. It's ok, j/vbscript based. THere are rexx and perl plugins for the language.
BTW, there has been a perl interpreter available as part of the NT resource kit for a while now. Not a good one, but one none the less.
I think that gettting perl out of the box with windows is going to be cool. I work in a win environment and I've added every ported gnu tool I can find along with the win32 port of perl. I do things with vim and awk around here that leave people who've spent there whole lives in windows amazed.
After all, o'reilley has a Learn Perl on Win32 book now. I'm just glad to see the tools coming in.
>You know, if stopping M$ was as simple as me
>not using (or paying for *cough*) their >products,
Um so your problem has nothing to do with wether
or not Microsoft does somethign with Perl.
and your intrest and or comment not really related to this discussion.
As I see it you do not believe in the free market
nor letting ppl having a choice of OS.
You feel a great need to COMMAND ppl to use
whatever OS you like.
I actually fear you more than I fear IBM,
Sun or MS.
"scripts from the archives or scripts from Unix that shouldn't be causing problems, would cause problems or fail. I don't know exactly how this would be done- it'd be syntactic- but this is definitely what would be happening."
Aren't you contradicting yourself? How could a change to MS-Perl cause a *nix perl script to fail?
From what I hear,
The next scripting release from Microsoft will have SendKeys support.. So you will be able to do quite a bit from WSH..
I understand your digusted feeling toward MS Perl modules.
... where exactly in that post it was commanded that anyone use or not use anything. As far as I could tell, it said that people using certain programs (presumably meaning those that embrace and extend, with intent to extinguish) is a problem.
It was 60% faster *page rendering*, so they didn't even need a network connection to test it. Why, then, use one and not a page cached in RAM? Wonderfully prudent and honest, these benchmarkers are... any wagers as to what web server they were using?
I believe it's because the IE Java uses a much different technique than the one included with Netscape. The IE one, if I remember, uses dynamic (so-called "just-in-time") recompilation, whereas the Netscape one has a more elaborate interpretive mechanism. This is similar to the difference between a compiled and interpreted program. In other words, you're comparing apples to oranges, and this has nothing to do with quality of code, but with the technique used. Before you go and say "Well, MS just used the better technique so theirs is better" it's my understanding that dynamic recompilation has a couple of serious limitations (whether they will matter in a Java program is questionable), such as the fact that IIRC a dynamic recompiler generally can't deal very well with self-modifying code, whereas a proper interpreting engine goes through it the same way it does through other code. Feel free to blast me if I'm wrong.
[ActiveState's] 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 . .
What a shithead. Every damn word I hear out of Wall, I like the man less than before. I'm a Windows user. I use free software. I don't use Perl, because it's not well suited to anything that I do, but I do use GCC, gawk, and whatnot. Basically, Wall's just another childish asshole who flames people because of the platform they use.
Perl [is] a postmodern language that is sensitive to context . .
This is pure babble. It's easier for Larry Wall to memorize new syntax than to learn algorithms. Okay, so he wrote a language that suits his kind of mind. Since he's not the only one who prefers to work that way, he's done us all a great service: Those who aren't into that can continue to use languages we like, while other people who like Perl can use Perl. Wow: Diversity, choice -- it's really a cool thing, you know? Everybody's happy and we all get more stuff done. But don't make it out to be more than it is by surrounding it with self-congratulatory, pseudo-intellectual bullshit about "post-modernism". Outside of Wall's little fan club, that phrase has been known as a sure sign of a pretentious fraud for quite a few years now.
I wish they would use the 32/31 bits unicodes, but they have gone insane and are extending unicode with lead words and trail words...
They are defining D800 - DFFF into to ranges, D800-DBFF and DC00-DFFF, when you combine two 'characters' one from each range to make one whole CJK character. If I knew who suggested this, I would slap them.
Lessons from history indicate that sometimes lands are gained by populating areas with colonists. By analogy then, MS Perl will allow so many Windoze lusers to use non-standard extensions to the language that they will have to become standard. Once they become standard, M$ sells the source to the extensions. We all know what happens when Microsoft "embraces" something:
1) They talk about "compatability" and "standard compliance"
2) Then they generate their own incompatable variant
3) They market the sucker to Windoze lusers and thus force it on the professional population of users.
4) Microsoft goes from "embracing" to "attacking" in three simple steps.
While I'm sure that not ALL of M$ software has done this, an example of a true "embrace" by M$ escapes my memory. And, lastly, How could they make Perl any better?
hi,
problem is, that M$ got a stake in AS. The Perl licenses for the Win distribution are a bit different already.
you will find "copyright M$" a bit.
there is one more problem: they got with gurusamy sarathy the leading force behind the win port of perl. he joined AS in february or so.
and: larry wall works for o`reilly, which owns another stake of AS.
uniting the 2 available perl distributions for win (which had been a big problem due to incompatibilities) is done with his help.
oh my.
anyways. why use a win box at all? if you got some work for perl, use a linux box.
greetings from bavaria, germany
That's funny.
Some in my field consider Linux the "Unix made for Microsoft Windows."
~gurly
I could write a minimalist scripting language that
would not allow for dynamic generation of code for use at run-time.
I'm not sure that you're on the right track with that definition.
oooh wow InterDev!
Stupid a$$. Get out of here you tree hugging shmuck.
One day your trying to save the rain forest, the next your chugging cock.
~gurly
Face it Tom. If Perl were marketed as a compiled language we wouldn't have to deal with a lot of this nonsense. Ask 10 Java programmers what they dislike about Perl and they'll all complain that it is "interpreted". Maybe you and Larry should name the next version of Perl to P++ and then rename .pm to .dll. Add a slick IDE, sell it for $700 and people will wonder why they never heard of this fantastic language before.
The better Perl on Win32 the more Perl on Win32.
The more Perl on Win32 the better Win32
The better Win32 the more Win32.
The more Win32 the less *NIX.
The less *NIX the less Perl on *NIX.
At some time in the above cycle Micros~1 can do a great deal of harm to Perl. If you are unable to see this you are totally blinded or work for Microsoft.
> They know their platform
Oh yeah? Then why did they fail in including parts of their old platform into their new?? (DirectX I mean)
> Ever tried running aplets on IE
> versus Netscape ?
Makes no sense. Netscape is not designed for running them fast. Netscape's not even Java compatible anymore. You need real SUN (or IBM) JDK and compare that to MS.
Too late. Lots of Perl is already written that's broken under Windows. People running ActiveState's Perl interpreter are already running into system-specific problems, and working around them with Windows-specific hacks.
Are there any Unix versions of PerlEx(TM)?
There are currently no PerlEx Unix versions available.
If you owe so much of your business to the open-source world, why not be considerate enough to point people to a solution which YOU begged the question to? Especially when your product does exactly the same thing as a free version that you stole liberally from and then you don't even bother to acknowledge it?
-off rant
>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.
There's a simple way to stop this. Whenever someone creates a new Perl script under Linux/BSD/Unix Perl script all the author of the script has to do is include a licence forbiding users of the M$ versions of Perl to modify the script's code in any fashion.
Since most Perl usage is under Linux/BSD's/Unix, the Windows crowd won't be able to take someone's Perl code and "improve" it or use it without someone's permission, which for the most part they'll never get.
Could there be no ridicule of your worst job? Perhaps daddy took care of you so you would not have to endure such a humble position.
That was without doubt one of the better comments I've seen around here. I compliment you for your equanimity and the thoughtful wording of your prose. More comments from you and I might actually start to enjoy these discussions.
Most Windows users are skeptical of free software, especially software which lacks a formal support agreement.
Actually, you're dead wrong about the support agreement thing, as far as that goes. Every Windows user I know uses shareware, and if WinZip were free-as-in-speech, they wouldn't care one way or the other. True, MIS suits are often skeptical of free software, especially in terms of formal support agreements, but they hardly count for "most" windows users. A lot of MIS types use Solaris, AIX, or HP/UX anyway, and a lot of those guys aren't 100% gung ho for the GPL either (any more than they're gung ho for NT). Suits are suits.
Yes, it is true that there is an army of Windows droids who won't use any non-trivial software not from Microsoft, and a lot of them are visual basic "programmers". That is indeed true, and they're a large part of the target "market" (so to speak) for Perl in Windows. But since Perl shares all of the features of Visual Basic which most annoy me, I can't (for my own purposes, which obviously are not yours nor Wall's) see that it really matters which one they use.
you should lighten up on Larry.
Well, gee. He's flaming people about whom he knows nothing. I'm flaming somebody about whom I know more than I care to. I'll lighten up when he does. The guy's a rock star. He made those remarks to score points with the intellectual low end of the free software "community"; the kids who flame each other about which operating system they use. It's pathetic.
Half the time he's just trying to be humorous. His attitude is very refreshing in comparison to most charisma-lacking gearheads.
I find his attitude almost invariably insulting. In this case it was intentional, but more frequently (to his credit, I suppose) it's not at all intentional; he just seems to have a cloyingly cutesy mind. Well, I guess that's not his fault, and others seem to enjoy it, so I can blow it off.
Perl has only around 300 native functions where Java has around 5000 native functions
Any language with 300 built in functions (if that's what you mean) was born dead and should be left to rot. Java is nowhere near as bad as that. ANSI C has what, 32 keywords or something? And people bitch about bloat in ANSI v. K'n'R. With the grace of God, C9x will never be implemented.
The way MS broke Java was by adding non-standard features (something with event handling IIRC) to the language so their bytecode wouldn't run in a conforming virtual machine, and vice versa. They also broke the native method invocation thing, which is a major pain in the ass. This hasn't affected Java use by corporate MIS, because those guys can decree that all users shall use a given JVM, and make it so. When that kind of top-down authority is unavailable (as when you're distributing
. . . himself.
You're a shrieking, polemical, hysterical flamer. You can't take part in a rational discussion, and you respond to disagreement (however polite and well reasoned it may be) by flaming people.
Grow up.
What you call "freedom" is the freedom to rip off the users. What Richard Stallman calls "freedom" is the freedom of the users to get the best possibly use out of the software. Of course, for a scripty-guru like you, users are pretty much the enemy, aren't they? I've seen your moanings and howlings about replacing the GNU utilities with buggy, stripped-down Perl substitutes. If that's not an anti-user tactic, I can't imagine what is.
If you want freedom, don't tie people up with duct tape.
If you want freedom, you need the source code. I will repeat this again, very, very slowly, because you don't seem to be very bright: If you want freedom, you need the source code.
What, by the way, did the Free Software Foundation allegedly do to Apple?
Notice how Mac OS X is BSD-based, not Linux-based. Think about that for a while, please.
Some of us actually have thought about that, thank you very much. Apple chose BSD over Linux because the BSD license leaves them more wiggle-room than the GPL to take previously free software and make it proprietary. Does this strike you as a good thing? If so, why?
One last thing: Are you still whining and whimpering about how we should use egcs "instead of" gcc? And have you been following the announcements lately?
Is there an OpenSource make utility out there? I thought there was a GNU make for windows somewhere.
i n32/perlwin32faq9.html#Where_do_I_get_a_ Win32_make
:).
If there is then it makes you wonder if Activestate.Microsoft is insiduously pointing people towards SelfishSource software given an opportunity.
See: http://www.activestate.com/activeperl/docs/perl-w
We can either
1) Help give support to windows users and point them to OpenSource software and gradually OpenSource operating systems. Bwahahaha.
2) Ignore windows users and let Microsoft/Activestate give their "help", in which case there will probably be a split at some point.
Too many people tend to go for 2)
The more users heading towards OpenSource the better for OpenSource. Microsoft has their bigmoney agenda but they aren't stupid and if most of the users continue to insist on heading towards OpenSource, Microsoft will be dragged slowly there kicking and screaming
Come on! What better sell is there than it's free, faster, more reliable, flexible AND more choice. You should be able to get "converts" easily!
If we're nasty/unhelpful and alienate potential "converts" guess who is going to "comfort" them..
Think about it. Think strategy.
Tactics:
Have an OpenSource oriented Perl/Win32 FAQ website.
Microsoft would want to make Linux + OpenSource more like Windows. So why not make Windows more Linuxlike/OpenSource ? List OpenSource Windows development tools/apps, advertise OpenSource/Free O/S.
attack the ball not the man.
Tom is right, perl would be nowhere if it was GPLd, cause most cool people have to work for money in companies, otherwise they cant eat. Companies will mostly avoid what to them reads like a communist manifesto (even if thats an unfair description), if there is absolutely any alternative. The alternatives are microsofts (or before them, IBMs), so with no perl and no linux, ironically you get more of what you hate.
Thats the world, its better to work with it and subtly around it rather than scream at it in frustration like Stallman.
Linux and perl has got a lot of mainstream attention recently, and I think the FSF zealots are getting a bit of the green eyed monster... they have waited a long time for the revolution to come and now to their disbelief and amazement, its happening to someone else!
Nobody is going to change the world by writing a new twist on a terms and conditions document, no matter how lovely the thought.
And I could say that Java is an interpreted language, as the bytecode gets translated to machine-specific function calls by whatever VM happens to be executing it.
Face it, the dichotomy of compiled or interpreted languages DOES NOT EXIST. They're all languages, all the same. Use whichever one you will. Just don't bash mine.
And on a side note, why does this argument ALWAYS come up whenever someone mentions Perl? Doesn't seem to matter what the original discussion was about.
Limiting perl to that which is completely portable hacks large chunks of usefulness out of it. Without the VMS::* modules, there'd be considerably less use for perl there, and similarly for MacPerl. Especially for MacPerl. I urge anyone that thinks that perl is identical in all its ports to sit themselves down in front of a Mac, or to tell me how to build a droplet in unix perl :-) For that matter, if you want to maintain pure portability, then you end up with a lowest-common-denominator language -- and you wouldn't even have fork().
*If* Microsoft changes core Perl, then there'll be some compatibility problems. But there's nothing stopping you from going to CPAN and getting the "real" module, or from coming up with a whole new port. I'm not that familiar with Java politics and implementations, but I suspect that it'd be considerably more difficult to branch that than perl, for instance.
Besides, this was the big issue with ActivePerl, when they became the 'main' win32 perl port. "No, they're going to branch perl! It'll be all windowslike and incompatible with the rest!" But the sky didn't fall, and I'm not sure what more Perl FUD is accomplishing for *anyone* involved.
I realize that most slashdotters think that "everything should be the same" means that "everything should work like unix", but that's just not the case in all situations. Using the unix paradigms in MacPerl, for instance, would just frustrate both unix people using it (whose paradigms have been wrapped around an OS that really doesn't want to think that way) and Mac people (whose programming concepts aren't unixlike).
Perl isn't Java, controlled tightly by Sun; it's not IE, a particular program. It's considerably more difficult to derail. (Microsoft offers C in Windows, but that hasn't derailed the language there, either.)
-Rich rich@vax2.concordia.ca
I was under the impression that ActiveVoice or whoever it was, was responsible for adding the functionality, not M$, and that this functionality was not going to be markedly different from the *nix-specific functionality such as fork(). If it's not M$ who's implementing the new functionality, and the implementer is aware of the "embrace and extend" history of M$ (which is overwhelmingly obvious from reading the FAQ) then what's the problem?
The Win32 port *is* a pain in the ass. I have to switch over to Linux to avoid making myself crazy. Probably a lesson to be learned here...hmmm.
Amen to that. Unicode is a typical example of 'standardization' folks completely overlooking the 2 billion or so people that use languages with large numbers of glyphs.
Moreover, with today's CPUs, 32-bit data manipulations is probably considerably easier to work with, and better performing, than 16-bit integers. The only disadvantage is the increased space needed for storage, and any decent compression algorithim will be able to efficiently pack 32-bit unicode with sparse allocation.
You've missed several points. You claim "Unicode is NOT AN IMPROVEMENT over present schemes for CJK encoding". The present schemes are completely incompatible from country to country and can't be used for encoding multilingual text without simply switching from encoding to encoding. This is seen as an enormous problem by most people. The equivalent of having a different JPEG standard for each country.
Unicode is to the world's languages what Latin-1 was to the western languages: a way to write them all with the same, unified encoding. That's a huge advantage in the eyes of most of us who work in multiple languages, yet it is "NOT AN IMPROVEMENT" to you. Imagine working in French, German, Spanish, and English and having to switch encodings for each. Then, along comes Latin-1. Would that be "NOT AN IMPROVEMENT"?
It seems as though your point is that this is of NO VALUE unless 1) every conceivable written symbol, version of any character, etc., no matter how obscure is given its own unique codepoint, 2) that codepoint encodes not just which character it is but which language is using it, and 3) the system for encoding this vast volume of characters be of a fixed, rather than variable, width.
In the case of Latin-1, there are quite a few characters that are occasionally of some use in a western language but that are missing from Latin-1. Has this made Latin-1 of no use for "any serious work" in any western language, and no improvement at all over all the mutually incompatible national "extended ASCII"s that we were seeing before Latin-1? Hardly. It is overwhelmingly popular for almost all computer uses in those languages and a vast improvement over the system we almost ended up with.
Does that mean that Latin-1 was the perfect solution, without compromises, covering all possible needs? Certainly not, but it was a very significant improvement, and a great balance of cost/benefit--as long as only western languages mattered.
Unicode is an analog to the move to a unified "extended ASCII" in the form of Latin-1. To say it is not an improvement at all because it doesn't have all that you want is absurd.
This is especially true because what you say you want is not free. If you examine today's writing, of all sorts in all places, and add it all together in one big pile of characters, there won't be one character in 1,000,000 that is missing from the basic 2-byte unicode character set. That one in a million character can be represented visually using all the standard workaround techniques used today for symbols of all sorts: special fonts, graphic images, etc.
The surrogates system allows an escape valve to be added to implementations that absolutely REQUIRE those one-in-a-million characters to encoded with their own totally unique codepoints for reasons other than presentation. I don't anticipate many implementations bothering with surrogates, since the BMP character set plus special fonts for user-defined characters (using the user-defined codepoints, so there's no question that a special font is required), plus graphic images, is going to be sufficient for ALMOST EVERY computing need. The extra value added by surrogates is so small that, given the costs, they won't be implemented often. When they are required, though, by some special community of users, they can be added to existing software while maintaining backward compatibility. That's useful in the practical world.
As I said, plain 2-byte Unicode plus custom symbol fonts, etc. will be sufficient for almost all purposes. Almost all is not all. You're right that this doesn't cover everything. The crucial issue in real technological solutions is whether that tiny sliver of uncollected value is worth the COST of burdening the entire system with 4-byte characters, massive font system complexification, etc.
I'm NOT missing the point that 2-byte Unicode lacks some things that could be had with a 4-byte Unicode. There are things I could imagine that could be done with a 16-byte/char system that can't be done with a 4-byte/char system, too.
What YOU seem to be missing is any discussion of costs. All you mention are benefits. 2-bytes per character is such a bitter pill for most western developers to swallow that telling them they really ought to go to 4-bytes/char for a little bit extra is living in a fantasy world.
For example, you propose a fixed-width 4-byte/char encoding. Well, you're talking about a code space so vast that it will always be sparsely populated. That means that compression and alternative forms of representation (such as UTF-8) will be the rule, not the exception. With any compression scheme, you'll end up losing your simple, fixed-width encoding and you'll be back to a variable width encoding, in most cases. No better off than with surrogates, except that surrogates will seldom be implemented, but your 4-byte proposal would pretty much mandate something like it.
The need for backward compatibility, not just with the "atrocious 2-byte Unicode" but all the way back to the ASCII-based file systems of most OSes, will also force a variety of compression/encoding alternatives. You'll never see your 4-byte fixed-width encoding.
This always happens. It's the reason for Shift-JIS, UTF-8, surrogates, etc. Practically speaking, you simply can't have what you demand: a pure, fixed-width 4-byte universal encoding. The benefits of going that far aren't worth the cost, and even if you got it, it would be compressed right back to a narrower, and more complex encoding form.
"You say that JIS has been sufficient for all but the rarest applications. That's totally incorrect. JIS has been insufficient for any serious work, resulting in a wide variety of incompatible workarounds." I clearly said the "JIS character sets", which is obviously different from the JIS encoding. In fact, the current character set, whether encoded as Shift-JIS, EUC, Unicode, whatever, certainly does cover the needs of the vast majority of computer applications in Japan. For you to suggest that this character repertoire is "insufficient for any serious work" would be rather offensive to the majority of serious Japanese information industry workers who get along just fine with it. As more characters are determined to be necessary by the Japanese national representatives, they will be added to the BMP in Unicode which, contrary to what many believe, still has a lot of room set aside for just that purpose.
Eventually, though, there will be characters that won't fit into the BMP. The question becomes, what is the way to deal with this? Are they important enough to burden the entire world, in every single character written by anybody in any language, with a 4-byte/char system? Or, are they scarce enough that it is more cost effective to deal with them in some alternative way? Almost everyone in the world (and Unicode is the world's encoding, not just the Japanese') would vote for some less-costly alternative to handle those cases.
"You dismiss Japanese characters not included in Unicode as "spelling mistakes". The spelling used by Shakespeare differed greatly from modern spelling; does that mean his work was full of spelling mistakes?" Actually, I was quoting a term used by the NEC representative at a recent UTC meeting to describe them. They had some statistics showing that the vast majority of ALL characters in the Kang-Xi dictionary, upon which all large Asian dictionaries have drawn, had only been used by a single author in all of history, and in most cases only ONCE by that author.
As a result, there was great reluctance to grant them their own codepoints. After all, they were not "characters" that could be represented in a variety of different fonts, but either variant "spellings" (in other words, glyphs) of a standard character, or else they were just something made up on the spot and never reused or mistakes that were never repeated.
There are so many characters in this category that you really need to think twice about whether they ought to all be assigned a codepoint, thus burdening the entire system. The Japanese decided for themselves that they had no interest in making their own national standard 4-byte character set to deal with these characters. The Chinese, likewise. They might at some point decide to do a special encoding for just those specialty systems that need this, but they haven't indicated any desire to make such a thing their national standard for normal use. There's so little demand among users and implementers that they simply can't justify the extra overhead.
If that's true even in Japan and China, how anxious should the whole world be to shoulder this burden? It's just not worth the cost for the extra benefit.
"You talk about how the large database companies support Unicode "to address a global market". Rubbish. They support Unicode because it allows them to say that their software handles i18n."
Rubbish. That's making the assumption that Asian customers will buy software from western companies purely on the basis of claims of i18n, because they're too stupid to be able to judge for themselves whether Unicode works or not. NEC, Japan's biggest computer company, and JustSystem, the makers of Japan's best-selling word processor, are both members of the UTC. If NEC decided that Unicode was "insufficient for any serious work" in Japan, they would tell their buddies at MITI and the Keidanren, and Oracle, Sybase, Informix, IBM, Sun, Microsoft, etc.'s sales would dry up in Japan. You don't think they would notice? If the Japanese really demanded a 4-byte encoding, wouldn't Japanese companies jump on that as a way to take business away from those "culturally arrogant" western companies and their Unicode?
You'd also have us encode the same character with different codepoints if it came from a different language. This is probably the number one benefit you seek from your 4-byte system. This would mean any Japanese who wrote the name of a Chinese person, or a place name like Beijing, or a Chinese gov't ministry, or any of several other cases where the characters were the same in both languages and it wasn't really clear whether you were writing Japanese or a snippet of Chinese, would have to make that decision right in the input method editor and encode them as different characters, depending on the decision. Some Brits consider the word "restaurant" to still be French, while others consider it English. Imagine having different codepoints depending on your opinion on that issue! Now, try and use a search engine with that mess. Yet you seem to think that this approach would be a lot better for data processing than an out-of-band language tag that is modularized separate from the character itself. And as for different versions of JIS to Unicode conversion, that isn't a problem that could be resolved by any 4-byte encoding, unless you chose to also give a unique codepoint to each character depending on which table was used for the conversion.
This is preposterous. I think your view of this industry is wildly skewed by your "DTP" myopia. You're thinking about things that would be nice to have, assuming that building them all into the encoding would be the best possible solution, and completely ignoring what others in the industry think about the costs of such proposals vs. their putative benefits. You think that everyone else is ignorant of the cost/benefit issues, too, including the Japanese and Chinese themselves.
The Japanese themselves don't seem willing to bear the burden of the system you think the whole world should bear. Why should anyone else?
It's funny that you should say this,
"So are you saying that perl code should be platform independant like Java was supposed
to be?"
If Java isn't platform independent, then I am willing to be that MicroReich(M$) had something to do with it. After all, who did win that law suit between Sun and M$?
Ya right...
What the hell is the matter with all you people?? From what I read, all they where going to do is install a fork() and make the installation processes compatible with the new MSI process.
Its not like they are trying to change localtime() or embed DBI::ODBC (propietary version, hehe) into the core distribution!
Get a grip... I've used ActiveState's Perl on Win32s and the "original" on *nix and I'm quite happy with the results from going cross platform.
If your scared now, I'd wait a bit... Maybe the new application package from M$ will contain Visual P++!!!
:o)
Cheers,
Johnny
> Doesn't perl "take advantage of the platform
> features of *nix" right now, intentionally
> and without shame.
Sure it does. Right now, however, perl on win32 is pretty much the same as perl on unix, except for fork() performance. It *does* make things more tolerable for people trapped in win32-land, much the same as Cygnus' gnu-win32 gives them a bunch of unix tools and gcc. It's great that they're adding Unicode support to perl. The only travesty is that they're doing it for Windows only. They're undoing all of the previous bridge-building that got perl to the point where you could run a perl script anywhere. That's wrong.
MS could never kill java. Its pickup has been slow because it has been crap before 2.0 and dev tools are expensive.
Java is huge and getting bigger all the time...
PERL != Java, folks. Adding OS specific modules only enhances the product. I use ActivePerl ALOT in the administration of my NT servers (yes, i admin unix, too, the nt boxes were forced on us). VBscript, and all that other MS garbage doesnt cut it, PERL for win32, does. They even have GUI libs for it now, modules to hook into the event logs, registry, APIs, etc. take a look at it!
This isn't a flame, and I'll do my best to try and not make it one, but it seems a majority of posters really do jump to conclusions too quickly. Yes, Microsoft employers aren't known for their fantastic programming skills. But, to me it sounds like Microsoft will mostly just give Activestate information to assist in the development of their ActivePERL product. ActivePERL has been nothing but rock solid for me, and I expect it to remain so. As per the press release, all of the core parts of PERL will be Open Source. This is good. Some "value added" (i hate that phrase) components will be closed source (this sucks, but they've gotta make money somehow). I have the utmost confidence in the Activestate folk's ability. Good luck to them. To the people so quick to jump to conclusions, I ask you to STFU until you go download ActivePERL and try it :)
The more UNIX-originated tools on NT the better. UNIX has a lot of what NT doesn't (stability, power, flexibility), and if some of that can rub off on NT and make my hellish job better, all the better. thank dog for ActivePERL, vim/win32, and thegnu tools for NT. Now if only we could get an Open Source GNU NT kernel replacement! (GNU NTURD?)
Don't be so quick to evangelize everything. Try and keep an open mind. It's painful to read the comments sections on Slashdot as of late, because it's usually composed of flames, and the "Linux Or Die" attitude, and as a UNIX person, I don't like to see it. It only pushes people away. Look on the bright side, the more NT assimilates UNIX, the easier it is for the average m0r0n MCSE to migrate to UNIX after he realizes NT just doesn't cut it in the enterprise...
Whatever the backgound motivations of M$ are, there is a useful analogy to the polical process here. M$, rightly so, identified a threat to itself. Whether they see this threat as an inadequacy on their part or just as a target to shoot does not matter. They are adapting (this perl thing is just one case) to the pressure.
Much like politicians. Clinton, as evil and inept as he sometimes is, morphed to the right. Not for good reasons, just for votes. But the effect is the same. Forbes is very aware of this effect, and never intends to actually win, but he applies pressure for change in his direction by running.
M$ may being doing things like this just for votes/sales, but this sort of thing will change what M$ is. Our pressure for good can morph the giant instead of killing it. Face it, we cant kill it.
I am not saying I will ever advocate or use M$ voluntarily, but if their power for evil reduces through magnitude or intent below a critical threshold (total brainwashing of PHBs) our lives and good engineering sense may return to some sane state.
Gee, what a bunch of misinformed nonsense! I'm "sorry [you're] not clearer", too. Too bad I didn't catch this thread earlier. It's probably too late, now.
I work in CJK computing, and I speak all three languages. I use a Unicode-based machine to read all three. I assure you that I have none of the difficulties you describe. Someone working in just one of those languages would have it even easier. You're not going to get hit in the face by some horrible Chinese font if you are trying to read Japanese on a Japanese-only machine.
You say the following:
"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 is extremely misinformed. The whole point of Unicode was never such a thing. It was to create a single, unified encoding for all languages, just as Latin-1 (ISO 8859-1) was a unified encoding of major western European languages. Latin-1 was valuable because it kept the French, Germans, Americans, etc. all from using different code points for the same characters.
No, there are not different code points for "A" in different languages in Unicode, and there never were. It's ridiculous to suggest that there should be. How often do we suffer because the French word "chat" (cat) and the English word "chat" are represented by the same code points in Latin-1? Approximately...never.
Because English and French share a common encoding, in the case of Latin-1 (ISO 8859-1), you can tell at a glance what language it is and what it is saying. If you want to switch to a font that is more "French" in appearance, that's easy to do. If you want that change to occur automatically, use language tagging or font tagging.
I agree that the font differences are greater between the C-traditional, C-simplified, J, and K than between English and French. They are not so great, though, that you can't read any of them in any of the others' fonts well enough to easily determine what language they're in and switch to a more appropriate font. Usually, they are so easy to read that you might not even bother to switch fonts unless you plan to print it.
When you need to indicate explicitly what language a sample of text is written in, you tag it with an ISO standard language tag, or one that is customized for your application. If it needs to be represented with a certain font (say MS Gothic for Japanese Win32 instead of MS Song for Chinese Win32), you use a font tag (or some equivalent out of band markup.
It's simply not necessary for the codepoint to declare both the character and the language and absurd to imagine doing so. There are something in excess of 5000 languages that use the Latin alphabet (cf. SIL's Ethnologue). Are programmers clamoring for 5000 different codepoints for the letter 'A'? They would all fit in a 4-byte encoding, but is that what you'd really want? There are dozens of languages that use the Arabic script. Should there be dozens of copies of each character? Even something like the Hebrew script, which you'd think would be limited to Hebrew language, is used in half a dozen other languages (Yiddish, Ladino....)
Essentially, creating a separate code point for each character in each language is the equivalent of adding language tags character by character. Is this really better than having language tags used only where actually necessary?
Imagine the font size! If you just use tables of pointers to the same glyphs instead of containing multiple copies within the same font, imagine the lookup table size! Imagine the performance hit to do that kind of nonsense for each character.
You say even the current system is better than Unicode. Really? Currently, if I send you a snippet of text in some East Asian language, how do you know what characters it represents? The major national encodings for Chinese, Japanese, and Korean completely remap the same double-byte codepoints. You have different characters depending on which encoding it is, so you have to be told the encoding, don't you? Having an encoding tag is just an out-of-band markup, but unlike the case of a language tag, the text is complete gibberish without the encoding tag with things as they currently are.
Also, you say there aren't enough codepoints in double-byte Unicode to hold the needed number of Asian characters. Really? There are no currently implemented computer systems in all of Asia that contain any characters than are not already encoded in today's 2-byte Unicode, and more are being added from obscure old paper sources--characters so rare that nobody has yet used them on any computer. There's still room for many more of these in Plane 0, and surrogates allow for the addition of nearly a million more without going to 4-byte encoding.
There are too many other flaws in your diatribe for me to be willing to go on any longer, especially when I don't know if anyone will even read this comment so late in the game.
You are too uninformed about these issues to be making such a fuss. (For example, you mention a 4-byte Unicode. There is no such thing. You're thinking of ISO 10646's UCS-4, which is not a part of the Unicode standard, but then you only seem to know enough about this to have a lot of strong mistaken opinions, so that's no surprise. I'm not going to get started again....)
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.
I read that phrase differently than you did. It looks to me like activestate plans to add features to the "windows" version of perl that do not exist on other platforms (activex controls for example). This means that a lot of perl written by windoze coders may not run on every other version of perl, which is exactly what MS and other commercial software houses love to do. (it's called "value adding")
Of course if Activestate keeps their version of perl in line with the "main" distribution, and contributes ALL relevant changes back to the community, then this will be an undoubtedly good thing for perl. I should point out that history is against this course of events.
I read the internet for the articles.
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.
The one thing you can be pretty certain of is that Unix perl scripts running on Unix hosts are pretty well immune. The source to it is available, and it's not subject to being seized or perverted. :)
What MS will be doing if they want to play hardball is this: breaking Unix perl scripts for THEIR OWN PEOPLE. Making little changes so only MS-Perl runs properly, and scripts from the archives or scripts from Unix that shouldn't be causing problems, would cause problems or fail. I don't know exactly how this would be done- it'd be syntactic- but this is definitely what would be happening.
Again: they would break it FOR THEIR OWN PEOPLE, w.r.t running scripts from the Unix community. This is a dangerous tactic because if they do it too much (combined with all the lovely license and 'user protection' schemes they're into), the temptation will simply be to abandon ship entirely. However, that is a risk they have to take because their only real option is to poison their own well- to make MS-Perl begin to act incompatibly and hope they can load so many examples into it that people will still choose that fork- this in spite of the fact that someone could try to make another Win32 Perl to compete with MS-Perl (at least until legislation is passed that is draconian enough about reverse engineering to make this awkward to impossible- in that case they would change Win32 just a bit and not update the docs and then the choices (for that API) become 'fail' or 'break the law')
Expect MS Perl to not run *nix perl scripts forever- however, the example given ('my perl script running on a *nix server') _would_ be safe as the script only has to run on *nix, and the Win32 browser does not have to run it.
Perhaps they will build it into IE and attempt to get people to make MS-Perl scripts that run on the client, not the server. After all, IIS seems not to be the most effective way of producing dynamic content anyhow, and offloading that dreadful processing load could be a real win
You can't. This is a suicidal strategy. :)
You can't make sure anything runs better on Windows, because you do not own it. You can't count on reverse engineering, because legislation is being forced through to make that a crime. You can't significantly help free software by establishing beachheads of it on MacOS and Windows, because it is a luxury on those platforms, easily outmaneuvered in flash and glitz by proprietary vendors, and it cannot be certain the APIs it relies on are the true APIs- the vendor can change the rules of the game at any time.
Hell, I _program_ GPLed free software on MacOS, and I don't think this is a sane strategy. I program that way because I _use_ MacOS and because I want there to be GPLed software there, not because I have any illusion that this will cause Mac market share to be lost to Linux because I'm putting GPLed stuff there. It is not- the stuff that I write can only _increase_ the market share of MacOS. I'm OK with this, it could do with a bit of increasing and is a nice weird option to have around the industry, plus easy to maintain
If you want to get market share for Linux then present people with no option- the arrogance of commercial software will do the rest.
Posted by FascDot Killed My Previous Use:
This is great news, in a way.
I tried using Perl Win32 about 1.5 years ago to do NT login scripting. It totally sucked. So I'm glad Win32 functionality will be expanded.
OTOH, I'm not sure I like the idea of MS doing the work.
I haven't studied Perl's licensing very closely so I don't to what extent the GPL applies to modules. And, of course, I have no idea what form MS's extensions will take.
--
"Please remember that how you say something is often more important than what you say." - Rob Malda
Posted by Lulu of the Lotus-Eaters:
I am confused by BJH's discussion of CJK characters and Unicode. I am sure s/he is correct, but I just don't understand it.
How does the fact that a Chinese-based character appear differently in a different font differ from the fact the the Roman "A" appears differently in TimesRoman than in Helvetica? Would not the solution to DTP in Chinese-based languages simply be to install multiple Unicode fonts on a system, and choose the correct font based on the context (much like one does in DTP for Roman-based alphabets/fonts)?
I've tried to use gcc/egcs to build Perl for MSWin32-x86. For the most part, it works fine.
;), is the ability to ``write-once-run-anywhere''.
My most critical criterion, in a grossly heterogeneous environment (*NIX, OS/390, Tandem -- you name it, we're running it
Unfortunately, I haven't been able to compile many of the modules thusly, such as the libwin stuff.
I've brought this up to perl5-porters and comp.lang.perl.misc; but, I've received only apologies and ``we'll get there eventually''.
Do any of you, dear readers, have truly Open Source Perl deployments running on wintel and *NIX? How do you compile modules?
Best Regards, mds
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.
Uhm, aren't they basically admitting publicly that NT's process creation model is dog-slow? It's pretty strange to hear them admit that outright.
And also, isn't that just a horribly bad idea to alter the Perl interpeter so that when a perl script does a 'fork' that it ends up making just a thread instead of a process? It sounds like a good idea for performance, but pre-existing scripts that *expect* their forks to create processes are going to run into trouble on this. (One reason for forking in a server is so that if the sub-server dies from a bug the main server is still going - this change blows that idea out of the water.)
Don't label something "offtopic" unless you know the topic well enough to tell what's on topic.
I think we all remember what MS has done to in regards to HTML right? Any webmaster knows what I'm talking about.
... in my opinion, so what is there for MS to take advantage of? Nothing. They will simply try to bastardize the popular CGI language and lock in even more MS shops because they were foolish enough to follow suit.
What about what they have done to "take advantage of platform features on Windows" regarding Java? Another clusterf**k. Luckily Sun had the $$$ to fight it.
Forget the fact that there ARE no advantages to the Windows platform in regards to Perl
If you can read this message, your threshold is too low.
Notice that goal #4 of this project as stated in
the FAQ is to "improve PerlScript performance
under IIS" -- I think someone at Micros~1
realized that beating Apache/mod_perl in the
perl scripting department would be a bid win
for them.
I'd have to admit it is a noble cause, but it
will take more than that to convince me to run
NT web servers instead of UNIX.
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.
Looks to me like it's not Microsoft who would need to worry, but ActiveState.. THEY are working with Microsoft themselves, not the other way around..
-- I'm the root of all that's evil, but you can call me cookie..
Err, Activestates codebase and the BASE Perl codebase where mereged as of 5.005.. Maybee I'm just not getting your point here, though..
-- I'm the root of all that's evil, but you can call me cookie..
Perl isn't under the GPL. It's bad to assume things are GPL'd, in case they're not. See also mySQL...
--
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)
--
I worked for an (unnamed) company, and I needed to automate a wide variety of Windows tasks, including accessing the Windows NT registry, and the IIS Metabase. Without Perl, this would have taken forever, as I would have needed to write a complete compiled program.
Instead, with ActiveState, and the ALREADY exiting Win32 extensions, I managed to write a usable program using batch files and Perl in just a few hours.
You can complain about Win32, (I do) but a lot of us have to work on it, and more tools that we know inside out, never hurt.
After all, try telling me to use Windows without using the Win32 port of VI.
----------------- "I have a bone to pick, and a few to break." - Refused -------------------
According to the Unicode web page and everything I have ever read on Unicode the unification only takes place if the characters have the same meaning. Can you name an exception where that rule hasn't been followed?
depending on the Unicode font used, you might get the Chinese character, you might get the Japanese character, or maybe the Korean character
That's just font management and/or language management. Every decent DTP system needs font management anyway, and if it is going to get hyphenation right it needs language tagging, even if you are only using Latin-1.
The whole point of Unicode was that code points were supposed to be kept separate between languages
What on earth makes you think that was the whole point of Unicode?
One of the big points in Unicode is that it should be possible to convert from any character set encoding to Unicode and then back again. That has caused some compromises for example the fact that the Greek capital letter Alpha has a different encoding to the Latin capital letter A although you could argue that they are the same character.
But you can't make that 2-way conversion guarantee for encoding systems that let you switch from character set to character set with escape codes. Amongst other problems that would make that impossible is the fact that you can use the same escape codes to switch into Unicode, so you would get an infinte recursion.
If you want to convert to and from escape-code switching encoding systems you will have to extract the implicit language and font information and make it explicit in the Unicode version of your data. That is probably a good idea anyway, and is possible in HTML and any other serious text format.
If it's a 'plain text file' then you can't embed the font or the language information, but that's why plain text sucks, and the same problem appears in Latin-1 plain text files.
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.
A feature I'd rather Perl didn't have.
Deleted
It's simple to stop proprietary extensions to software ala "embrace and extend".
Simply use the GPL.
Deleted
Please carefully read the question, and then the reply and then sit and think for a few minutes, then when you are just about ready to post, sit and think for a few more minutes.
GPL'd software can also be extended at whim.
Deleted
You haven't taken my advice I see. I know exactly what the artistic license is and I know exactly what the GPL is.
Tell you what, have another go, on me, for free... All you have to do is read the little words one after another to see if you can work out what my point is, look I'm even using short words for you now.
Deleted
with a properly designed perl object this should be a reasonable expectation. but as far as this whole thing goes, i don't see any real danger. if they destroy that version of perl, i'm sure another version will come up. i tried to be a purist and use the win32 compile of perl and all i got were headaches. the activeperl distribution just installed it. i liked that. i still have some problems with some custom modules though. i do wish that i could just do a make on the modules in either platform and have it work. but yeah it would be nice to have it only as a module. i hope that's what they're thinking!
"The lie, Mr. Mulder, is most convincingly hidden between two truths."
--
And Justice for None
Larry Wall was a fool for not using GPL for Perl. One would expect to see M$ try to exploit a bad "Open Source Compatable" licence. Use the GPL!
I'll defer to tchrist's clarifications of the perl side of this statement.
On the Java side, nobody said you had to run Java on a client. In fact, Java's most vital current development is on the server side. Some Perl bigots find this threatening because Java servlets are displacing Perl CGI, but Java and Perl have different strengths and weakness -- they are not interchangable and we should just stop trying to compare them.
- A language is interpreted if it's able to generate dynamic code and run it at run time.
Java can do this (you can generate new classes in bytecode on the fly), BASIC can do this (you can evaluated BASIC code in strings), Lisp can do this and non-compiled Perl can do this.Compiled C/C++ cannot do this. You can generate machine code on the fly, but you can't generate C/C++ code on the fly and run it at run time. It has to be compiled.
Yes, and I'll go further: even if the picoJava chip didn't exist, the fact that you could create one would be sufficient. I don't think a "picoPerl" chip could be designed, much less fabricated.
That means that all I'll have to do to make the Perl thingie-that-wishes-it-were-a-compiler into a true compiler, is, ... wave my magic wand and create a chip that happens to directly use the Perl bytecodes as its native instructions.
Yes, that's what I said. Should I say it again? Would that help?
Meanwhile, get a really good wand, Tom 'cause it will take some powerful magic to implement Perl in silicon. Gosling designed Java to be implementable in an embedded computer. Wall had no such plans with Perl and I don't think it's possible. Of course, you've made it clear to anyone still reading this thread that I'm a numbskull who knows nothing of the true "Computer Sciences", so post your schematic post haste and make me the laughingstock of slashdot.
Because I can already convert the Perl bytecodes into something to feed a C compiler...
If you want to call a Perl-to-native process "compiling," I'll be in agreement. Most of the time, however, Perl is interpreted by a "perl.exe". Again, you seem to be the only person who finds this distinction puzzling.
You have demonstrated... [blah blah blah]
So, when you're losing an argument, you retreat into "my thesaurus can beat up your thesaurus"? Pathetic.
Fluent in a dead language. When Nietzsche wrote about the Superman, did he have you in mind or what?!
- Perl code is always interpreted, just like all programming languages, including Java and C++.
... your firmware is doing that interpretation.
What if there's no firmware? You... uh... did know that not all processors have firmware? Right? You're not trying to argue a point outside your narrow and increasingly inconsequential sphere of expertise? You wouldn't do that, would you?- Your pop-culture
... references are completely lost on me...
Well, at least they're in good company. My brilliant insights are completely lost on you too.- I do not do television
... I pursue a long-forgotten diversion called the reading of books.
Fear not, I have not lost the ability to read, although your posts are inspiring me to try. I have also not become so narrowminded and stagnant that I can'n appreciate music, film, television, dance or any number of arts.You might try it some time.
Get out more.
-trp
P.S. I left you a typo to criticise! I'm try to be kind to the rhetorically handicapped.
Am I the only one who smells MS setting up a migration path?
Personally, a better Perl on NT is fantastic. It increases the value of Perl as a programming language... Now I have no reservations about spending the time to learn it. On the otherhand, it bugs me that Microsoft seems to be making a good move, and integrating one of my favorite features of Unix into NT. Not necesarily Perl, just a good scripting language.
The less I have to deal with NT the better.
Win32::* should be OK, with attribution in perldoc... I wonder if we'll get to see Win32::MFC::*?
(Hardly.)
Why not permit WinXX developers to use Perl instead of VB? I'd love to see Perl embrace and extend Microsloth...
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
This story's only been up for a few minutes ... and it runs on Micros~1 (it doesn't end in "asp" but it does end in "htm" - a sure giveaway).
Everyone hit your reload buttons a few times!!
support gun control: take guns from cops
...just what the hell ActiveState is doing in Bed with M$. My guess is that M$ is splashing some cash on ActiveState...well, is that so bad? I don't know. But I sure don't like the idea of OUR darling Perl being raped by M$...
Just my 2 cents...
Later,
WebDosa
Maybe they could integrate Perl support into Visual Interdev and allow you to make the scripts and such inside of their project mentality. For purist reasons, I don't want Microsoft subverting Perl for their own ends, but I would like an cross-breed Visual Interdev/Visual Perl beast. This isn't a troll.
"Dogs and cats, living together...it's mass hysteria!"
ActiveState sent out a message about this on their announcment list this morning. They said that there are four main areas of development with M$:
- improving the impementation of fork() to reduce overhead
- improving the Windows installer (especially for Win2K compatibility)
- improved Unicode support
- performance boosting of PerlScript (embedded Perl within Active Server Pages)
I don't rightly see how any of this could be seen as a bad thing - it'll be easier to install and use Perl on Windows, which will result in more developers writing Perl code, which means it'll be easier to port their existing code to other operating systems when they decide to ditch NT/Win2K.As for people's fears of embracing/extending, there are already a number of Perl modules specific to the Win32 platform for system services, registry, ODBC, etc. so it's already happened - and it's users who did it, not M$. As other people here have noted, most Perl scripts run in a controlled environment (i.e. your server) rather than an uncontrolled environment (i.e. someone else's web browser), so the comparison to Java is mostly irrelevant.
________________________
Corporate Jenga: You take a blockhead from the bottom and you put him on top...
Not so fast! A line of text on UNIX ends with a CR, while in the M$ world it is CR + LF. When you use your perl chop() function, will it work on M$ text? also, I have noticed that unlike UNIX programs, windows programs have output that is difficult to parse, assuming that there is a text version of the utility to begin with. Something like expect might be handy.
JET Program: see Japan, meet intere
No, you use the more modern chomp() which removes EOL's from lines as defined by the $/ variable.
:)
I imagine that $/ defaults to CRLF on Windoze.
RTFM.
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
:-)
DFL
Never send a human to do a machine's job.
There is also Tcl/Tk available for Windows. I am using it in a project at the moment.
A significant amount of the development effort will be released as Open Source code under the Artistic License, Perl's Open Source license.
This makes me wonder of to whom it will be significant: Microsoft or OSS community? For the latter I think 100% open source is the only significant amount, otherwise someone will yet again have control over features dooming portability. This reminds me cool language called Java.
AtW,
http://www.investigatio.com
alexc
Join Majestic-12 Distributed Search Engine
I am not clear why everyone is whining so hard. The FAQ indicates that most of the work will be open source. But the knee-jerk whine-about-everything-that-MS-does slashdot peanut gallery want a good whine about how MS are trying to make perl windows only and blah blah blah. I doubt it will happen soon. And the people who care about portability will not use MS perl anyway. They'll stick to the standard release.
You can set up autofs so that removable media is
automatically mounted. See my homepage for an autofs tutorial if you're
interested.
How is this any different than Xlib or Tk extentions for *NIX? Or native GUI support under BeOS, DECWindows or GEM? Not all Perl scripts are meant to be portable.
Now, you may ask, why would I think this? Well, let's see... Java is a language whose purpose is to be able to write full-blown, platform independent applications. Why does this scare Microsoft? Well, it has the potential of making the OS a "commodity", since an app written in Java will run on any platform. So, MS decided to try and corrupt Java to ruin this "write once, run everywhere" philosophy.
However, Perl does not have the same purpose. Perl is designed to be almost a swiss army knife of programming languages... it allows the user to perform a myriad of different tasks and, as Larry Wall stated, acts as an excellent "glue" language, joining various tools and components together. In this way, it doesn't threaten the Microsoft hegemony, since it doesn't commoditize the OS in the same way that Java potentially can. As well, there is no strong corporation controlling the Perl language, so there's less of a corporate threat.
So relax, people. From what I can tell, the point of this partnership is to make Perl work better on Windows. And the only thing this can do is benefit the community, since more people will become aware of Perl and start using it. And isn't this what we all want?
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
Whereas most of the Perl that has been written by Unix users is always *completely* compatible with perl on other platforms...
Come on! Any extensions that Microsoft add that are windows-specific are likely to be just that: specific to windows. You *wouldn't want* to do them on Unix - things like playing with the registry etc..
If anything, any windows-specific extensions will probably result in *more* portable perl code being written, as the 'write portable code' issue becomes more visible. Windows perl users are used to the idea that you have to give a little thought to portability, because of all the Unix-specific perl out there that they've had to alter.
actually linux, like most unixes is a 70's technology. WinNT is loosely based on VAX/VMS which is a 60's technology. Dragging 70's technology down to the 60's level is a disservice to everyone.
I'm afraid you've got that backwards. Unix started, more or less, in 1970, and much of its early development was done on DEC PDP machines. VMS was first released in 1978 and developed in conjunction with VAX microprocessor, which was one or two generations past the processor in the PDP systems, depending on whether you're looking at the PDP-11 or PDP-8 machines.
Both systems have seen development since, of course, though VMS in general still holds a mild technical lead over Unix in some areas. Cluster support on VMS, for example, makes the Unix and NT offerings look sad and pitiful. (If you think the FUD microsoft spews at linux is bad, try wading through the cluster MarketSpeak Micro$oft emits after comparing VMS clusters with NT 'clusters')
And yes, everyone things VMS is dead and sucks technically. That's only because Digital's Marketing department was filled with AntiMarketroids... Dec had a marketing department every bit as good as Microsoft's. Alas, they were using that skill to drive customers away, rather than keep them.
Q: Is this going to be a custom version of Perl for Microsoft?
A: In a word, no. We will always use the mainstream version of Perl as our core technology. All potential
work we undertake to do on the mainstream Perl source code will be achieved through open development
with the community.
Q: Why is Microsoft doing this?
...
FOR IMMEDIATE RELEASE
FAQ - ActiveState and Microsoft
Vancouver, Canada - Update June 2nd, 1999
We want to make sure that you, as members of the Perl community, are informed on our latest efforts to
advance Perl technology for Windows. We are quite excited about this development, and see it as a truly
winning proposition for Perl.
Below we have attempted to answer the questions that many of you will have about this development. If you
have further questions or concerns, please send them to Press@ActiveState.com
Q: What is the scope of the work that is being done?
A: ActiveState proposed many potential areas of work to Microsoft, based on feedback we have had from
Perl users over the years. Microsoft accepted the items of work listed below as being important enough for
them to support with funding. As a result, there are four main areas of development, all of which target the
Windows platform.
The interfaces and implementation of all parts of the work that have a chance of being generally useful will be
discussed amidst the Perl development community (perl5-porters@perl.org, archived at www.deja.com) for
inclusion in Perl.
fork()
This implementation of fork() will clone the running interpreter and create a new interpreter with its
own thread, but running in the same process space. The goal is to achieve functional equivalence to
fork() on UNIX systems without suffering the performance hit of the process creation overhead on
Win32 platforms.
Emulating fork() within a single process needs the ability to run multiple interpreters concurrently in
separate threads. Perl version 5.005 has experimental support for this in the form of the
PERL_OBJECT build option, but it has some shortcomings. PERL_OBJECT needs a C++ compiler,
and currently only works on Windows. ActiveState will be working to provide support for revamped
support for the PERL_OBJECT functionality that will run on every platform that Perl will build on,
and will no longer require C++ to work. This means that other operating systems that lack fork() but
have support for threads (such as VMS and MacOS) will benefit from this aspect of the work.
Microsoft Installer Support
Microsoft is moving towards providing improved package management facilities in Windows 2000.
This aspect of the work will make the ActivePerl installer compatible with the new MSI DB, which is
an important requirement for easy management of the Perl installation process on Windows 2000
systems.
Globalization
The Unicode support that Larry Wall created for Perl extends to Perl operations but not to system
calls. Windows NT supports Unicode at the system-call level, and it would be natural to provide a
way to enable the Unicode variants of the system calls. This allows users to create files that have
names comprised of Unicode characters, for example.
This aspect of the work covers extension of the existing Unicode support to all Win32 system calls
in the Perl core, for such things as file names, environment variables, command-line arguments, etc.
This functionality will only be available on Windows NT and Windows 2000 systems (not on
Windows 98 or similar).
The implementation for this is Windows-specific, but the interface to enable it from Perl will be
general and portable to all platforms that support Unicode. This interface will be decided based on
discussion with the development community. The implementation will be built over Perl's existing
abstraction for system calls, which means other platforms that need to support Unicode system
calls can follow the same model if they wish to do so.
It must be noted that support for Unicode will have no effect on the default behavior of Perl. It will
continue to be enabled only when explicitly requested by the script with a pragma. Other existing
internationalization features like locales will continue to work as they have done before.
PerlScript Performance Enhancements
Caching and cloning of compiled scripts in memory will significantly boost the performance of
PerlScript running under IIS/ASP.
The implementation of this aspect will utilize the facilities for creation of multiple interpreters, but will
be otherwise independent of the Perl core.
Q: Is this going to be a custom version of Perl for Microsoft?
A: In a word, no. We will always use the mainstream version of Perl as our core technology. All potential
work we undertake to do on the mainstream Perl source code will be achieved through open development
with the community.
Q: Why is Microsoft doing this?
A: Microsoft knows first hand that Perl is an important tool for their customers, since they are a heavy user
of Perl internally. They want Perl to work well on the Windows platforms and to take advantage of platform
features on Windows.
Some people have expressed fears about a potential "embrace and extend" manoeuvre by Microsoft. We
would like to reassure the Perl community that we see no danger of this ever happening with Perl. Perl's
development model is based entirely on open discussion of changes, and is one of the most important
reasons for the dynamic evolution that Perl has enjoyed over the years. To change this would be
counter-productive to any commercial entity that may have a stake in Perl's success.
It seems more to be like Microsoft is FUNDING them to code on Win32 related perlcode, in the official perl release... I don't think we have to worry about anything...
/olle
Yes, Microsoft tries to do to Perl exactly what it did to Java.
Make it incompatible with other platforms.
Times change, Microsoft doesn't
--Roman , remove spamless. to mail me.
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.
Aren't "non-clued suits" already using it? Isn't the fact that Perl is so widely used and accessible one of the reasons Microsoft is doing this?
WinPerl will not be totally compatible with our current incarnations of Perl, and that will be the problem.
Correct me if I'm wrong, but isn't one of the licenses Perl is distributed under the GPL?
If so, then aren't any of the modifications that ActiveState/Microsoft makes to the Perl interpreter itself also covered under the GPL (which, I beleive, they state in their FAQ)? That is, we can pick it apart, correct "intentionally broken" functions and the like?
I don't know how or if the GPL covers modules, so it could be possible that ActiveState/Microsoft could write a proprietary Win32 module and restrict our ability to dissect it, but as someone else said, don't write scripts using that module and you should be okay.
I mean, gimme a break. If you write cross-platform code, then don't use any modules that gives advantages to one OS over the other -- I could be wrong, but I think MacPerl has some of those (especially for mac Toolbox functions). If you want to write platform-specific code (optimized for performance on a given OS/application combination) then use their stuff and be bound by whatever restrictions thay come up with.
Isn't that one of the meanings of TMTOWTDI?
Jay (=
Am I mistaken, or isn't Perl supposed to be a language where the code can be ported across several platforms with very-little-to-no code change (hence why you should sometimes avoid system() or exec() calls)?
Wouldn't Microsoft's proposed implementation of Perl extensions damage this methodology?
If nobody were to implement these Windows specific extensions then it wouldn't be an issue. The problem is that many Windows programmers are so easily sucked into the black hole of platform specific coding.
It'll be good to have the Win32 port fully compatible with the unix version. There are already tons of Win32 specific bindings that one can use to create windowed applications/scripts with Perl which are much like the tcl/tk and gtk bindings. MS would just be doing similar things to these so it's not that these things hasn't been done before. I say we just have a mass-boycott.
Yeah, that's pretty much it. The whole point of Unicode was that it's not supposed to depend on the font, but here we are with the same problems as Big5, JIS, SJIS, EUC, etc., had. In other words, there's not a lot of point in shifting to Unicode for people using these character codes.
Yeah, the fact that UTF-8 allows the use of ASCII in its present form was a big plus when it went up for approval.
Unfortunately, while it can handle UCS-2 (16bit) and USC-4 (31bit) characters, the Unicode codespace standard is brain-damaged; they decided to transfer the whole 16bit code space to UCS-4, which means we're still stuck with the mess of CJK unification, whereas if they'd had a clue, they would have thrown out UCS-2 and redefined the whole ball of wax for UCS-4.
The upshot is, even when we shift to 31bit UCS-4, people using CJK characters are still going to deal with the pile of crap that is UCS-2.
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
That's funny, I remember seeing "Plug and Play" stamped all over the power strips and UPS's when I worked at a computer store. I laughed my off.
I've seen "Y2K Compliant" keyboards...
Another damned comic
+++ NO CARRIER
...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.
"The problem is new Perl users getting
introduced to MS-Perl, and MS-Perl becoming defacto standard so that the majority of Perl out
there becomes Windoze based, thus basically
eviscerating a perfectly good language. "
Are you on crack ? How is it going to happen ? You are not using Windows right, so your Perl will always be the same. And how can you assume that mere fact of extending Perl to better support Win32 platform will be "eviscerating a perfectly good language." If you think that your computing platform is so much better than anything else then stick with it and be happy. For many people ( majority) Win32 is the platform and they are perfectly happy using MS tools and "dreaded" IDEs. And I bet ( just as it was with Java) MS extensions will kick ass. They know their platform and therefore their tools are almost always the best in the industry ( on Win32 , that is.) Ever tried running aplets on IE versus Netscape ? Then you know what I am talking about.
AppleScript is really the best of both worlds here. It is a command line interface to a purely graphical environment. Remember that Windows and UNIX are at their base, CLI's with a GUI spattered ontop of it. The Mac OS is pure GUI. There's no "native" or "underneath" CLI to work on. If you want one, you have to make it yourself, and it runs On TOP of the GUI.
That does't mean that CLI's ontop of GUI's aren't useful... I spend the better part of my day using AppleScript to create turnkey systems for the computer lab I work for... it's great. Of course, this is purely proprietary to the Mac OS, and it requires significant effort by the 3rd party Mac programmers to make their programs "scriptable". but there's a tremendous pay off.
Proprietyary schemes show that a CLI interface ontop of a GUI *can* make sense, but I wouldn't trust MS would an Open Source one.
Hire a Linux system administrator, systems engineer,
I wish it were that simple. If Micro$oft "extends and embraces" something, and I don't like what they turn it into, I may very well have no choice but to use it. If my language choices were governed by language quality alone, I don't think any of us would have a problem with what Micro$oft is doing. The unfortunate reality is, due to politically pressures in the job-world, the programmer rarely (in my experience) can choose to program in something based on language quality alone (or at all)!
implementing in Windows and integrating it with the OS would be nice..
but the "extend"ing features bit scares me..
memory: remember back when Java was written platform independant? Remember how M$ added "features" that made you code Java for either M$ machines or everyone else
perl is nice cause its powerful and platform
independant. Let's keep it this way!
Let M$ add it to their OS: but if they extend it, it will ruin it, as perl scripts will have to be written either for M$ machines or everyone else
-Z
I'm afraid. I'm afraid, Dave. Dave, my mind is going. I can feel it. I can feel it. My mind is going.
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.
Many poosts have already said this,
I gotta repeat the obvious.
Microsoft intentionally killed Java.
Keep them away from my language.
Bob
Stop-Prism.org: Opt Out of Surveillance
ianal, but the gist of it is that you can modify and redistribute perl as you wish, in accordance with some fairly lenient conditions (which do *not* oblige you to redistribute the source, although you get out of some other clauses if you do).
beware the trap of thinking that everything's gpl'd.
however, this can't really be as bad as it first looks. if microsoft go ahead and 'embrace' perl, what's the worst market it's going to affect? NT web servers? do we care?
-- in china, chinese food is just called food.
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.
My fear is that they will do to Perl what they are trying to do to Java.
photosMy Photostream
As has already been pointed out elsewhere, Microsoft funded the initial port to Win32 years ago and Hip did a decent job of it. Most of Sun's complaints about the MS Java port were related to omissions and not breakage. RMI comes to mind.
I must be a sort of oddity here though because I don't view the 'purity' (whatever that is) of Perl as a religious issue. I run a small network of NT workstations because that is what was provided me by my employer. I have no user account issues because they are running an HMI (Human-Machine Interface) package. I suppose QNX was an option instead of NT, but that isn't free or open either. Another reason is the operators are familiar with the interface.
I use Perl because the scripting tools provided by the HMI vendor is utter garbage for anything more complex than turning a pump green if it is running and grey if it isn't. We have many instruments that provide text data in fixed width or comma delimited formats and Perl is great for extracting and reporting operational data from them.It's great for quick and dirty programs that would not be worth the effort in C. I suppose it could be done in Python too but I don't really want to learn yet another language for cross-platform compatability that I don't need anyway.
This announcement (by ActiveState and not by Microsoft you'll notice) appears to be a minor upgrade to an existing product and not a major rewrite by Microsoft employees for release as a sort of Visual Perl (tm) that doesn't play nice with others. People who need multiple platforms will find a way to support them anyway and those of us who don't will be happy with this.
Do this don't do that Can't you redesign.
Anyone know how we can stop them?
There will probably be functions added to allow you to change the registry from within Perl among other things. But I don't expect anyone to find these functions useful on the Unix side. If you want to build platform independant system utilities using Perl, you may have to do some magic (do an if else on the OS version). But I expect that most of your perl scripts will work no problem on either platform (ie text parsing is text parsing whether you are on NT or Unix).
And if you only use Perl on Unix, the fact that Perl may have Windows specific functionality in it will have ~zero effect on you.
Now what would be ideal, is if these extensions were done as part of a module. That should make everyone happy...
It seems that the only way to really fight Microsoft on this front is for Open Source developers to make the current Win32 version of PERL run better. If the open source, free version of perl for Windows runs better than this "proprietary-ish" version, what incentive would there be for others to use it?
In fact, the open source movement could really turn the tables on Microsoft if we could get even half as many Windows-specific open source programmers as we have for *ix. As an example, there is currently no good cross-platform group scheduling and contact management software, even between MacOS and Windows. If some group were to take something like KOrganizer, add some polish and a good port to MacOS and Windows as well, I think we could easily steal market share away from Outlook. I'm hoping that Mozilla's calendaring component will be able to do this if nothing else.
In the long run, as long as Windows is the dominant platform, the best way for us to gain market share is to port the best open source programs to Windows and Mac, rather than waiting for the commercial programs to come to us from the other platforms.
If it turns out to be evil, then don't use it. I know this has been said 1.0e6 times but you don't have to use anything. You can go on writing batch files, or WSH scripts, or using the open Perl distro or just sticking to Linux. But it may just solve some people's problems. Note that it's semi-proprietary to begin with (ActiveState) so users of that system may actually gain benefit from it.
Java is a lot easier to write Windows apps in than MFC, IMO. And Perl scripts, if well written are alot more readable and maintainable and scalable than batch files. Management is interested in saving development time and if they're tied into Windoze choosing the "best language for the job" while still "having all the features" is a tempting thing. M$ sees this and gives it to them, so they don't jump ship. Developer relations is more than just providing the best technically elegant solution, it's giving the suits (or aspiring suits) what they want.
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 really love *NIX but I think that there would be more games on the Mac. *NIX isn't really easy to use for a non techie (it's coming thanks to Gnome and KDE) and the Mac had less HW compatibility problems than the PC and less OS compatibility problem than *NIX.
"The obvious mathematical breakthrough would be development of an easy way to factor large prime numbers." Bill Gates,
...but this seems like it could turn into a move in MICROS~1's game of defying, overrunning, and closing standards. there is nothing wrong with MS adding to Perl; this is somewhat admirable of them. but i see this going in the same direction as Browser Wars did; "HTML" and "Java" became very subjective terms and one could not count on certain features ALWAYS being there.
and couldn't this be construed as MS "embracing" free software? i can't even imagine the spin they might like to put on that.
Cretin - a powerful and flexible CD reencoder
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.
Hey,
I was thinking, when MS was 'embracing and extending' java, Sun could sue them for it, but I think the GPL explicitly gives MS the right to take perl and change it. (I nevertheless expect a lot of 'oh no! we must stop them!' posts.)
One thing though, if they do this, they must release the source to their modifications (don't they?). Will be the first time that MS releases something that 'takes advantage of their platform' as source.
Hmm.. and if they don't release the source code, then we might see the first legal fight involving the GPL (remember the thread a while back stating that the GPL has never been tested in court?)
But still, doesn't article 4 of the osd
("the license may restrict source-code from being distributed in modified form only if the license allows the distribution of "patch files" with the source code for the purpose of modifying the program at build time.")
still apply?
Tom!!! You crack me up! It takes a lot of cohones to post this on Slashdot.
Way to go pal!
Microshaft languages are not platform independent. When they can "extend" other languages so they lose their platform independence then Microcrap languages are on an equal footing.
If you can't beat them - at least drag them down to your level.
Dyslexics Untie!
Here's what annoys me: The FAQ says
So if they're counting on the Perl Community to do the work, what exactly is it that they're getting paid for again?Oh, and of course none of the Win32-specific scripts will work on Unix. But then, none of your scripts that use fork or other various process- and user-management features will run on Win32, either (though one of the goals ActiveState has is to implement fork on the Win32 port.) I don't see how this is a problem.
Clicking on an icon and a couple of "next" buttons may be more convenient but... Have you ever come to the point where you decided you didn't like that particular piece of software and used the uninstall "feature"?
I strongly believe that trying to be clever is detrimental to your health. -- Linus Torvalds
Perl wasn't invented for the web. It was invented for Unix as a scripting langauge. It just happen to make it into the web too. So of course Perl uses native Unix functions and crap like that. It was design for it. Porting it to Windows has been hard because of it.
Java is still a threat, but not quite in the same way. The current thing to do if you nee a cross platform app is to use C/C++ to write the frontend and native OS things and hook Java into it with Corba. So You can get a program that loads fast and about 80% Java which is cross platform.
The thing that makes me wonder is why any company will still deal with MS. I know that MS is powerful and if you can get in with them, you'll have an advantage. I can certainly see where ActiveState would be in the driver's seat if they were the sole source of the "MS Approved" Perl distribution. But I can't think of a single deal that MS has made where the other party didn't get screwed. I guess Barnum was right.
I know it's premature to judge MS on their Perl efforts, but their history makes this smell bad (and a bit like Java). As for me, I need to run my scripts on three different platforms (one of them Win32). I hope they don't decide to redefine the behavior of existing functionality to be more Win32 dependent, ahem, I mean savvy.
Can't wait to see "MS's" latest innovation heralded in the press.
-Jennifer
LISP, ML, Scheme, and just about any other functional language will let you return multiple values from a function.
I guess the fork is mightier than the FUD.
Just one more thing for Microsoft to convert to bloatware.. Now PERL will always be in a state of BETA.
The early bird gets the worm, but the second mouse gets the cheese!
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."
If that's all they were going to do (make
Perl function better under Windoze) that would
be fine. But do you REALLY believe that M$
has these noble intentions? Read between the
lines, my friend.
...dave
Think different? I'd be happy if most people would just think...
Exactly how does Perl on Windows and Perl on
*nix (etc.) allegorize well to Gimp and PhotoShop?
Gimp and Photoshop are 2 TOTALLY different
animals, and are used in totally different ways
than a programming language.
You don't understand that a Perl script written
for this new MS breed of Perl will not work for
other platforms, that is where the problem lies.
Yes, Gimp plugins and PhotoShop plugins aren't
compatible, but that's like saying Doom saved
games and Half-Life saved games aren't compatible
(or maybe i should say mods.)
It would also be nice if you weren't so flip at
the end of your posts when you're not even making
any sense.
...dave
Think different? I'd be happy if most people would just think...
Ok, one last time :
a) It's not said explicitly that this will be
an all-snafu'd up implimentation of Perl, but with
M$ involved you can lay your bets pretty safely
that it will be.
b) The problem is not those of us who know
what we're doing writing incompatible Perl on
accident. The problem is new Perl users getting
introduced to MS-Perl, and MS-Perl becoming defacto standard so that the majority of Perl out
there becomes Windoze based, thus basically
eviscerating a perfectly good language.
If you don't understand this, then I don't know
what else to say, it's plainly obvious to me.
...dave
Think different? I'd be happy if most people would just think...
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...
This is just what happend with Java... WHY do they do such things???
// Simon
C'mon! What's with all the pessimism? If windows writes its software with pearl, it will be that much easier for us to port windows apps to *nix! A major complaint of business' that there aren't enough apps for *nix! We win.
I say it's time to fear the peguin instead of the DAC (Digital Anti-Christ, BG). Someone needs to make a peguin icon wearing guerilla clothes! Wahooo!
My cube. My friend. My solace. My prison.
:}
My cube. My friend. My solace. My prison.
pardon me - but my a[??]! ;) RPM may be more flexible, but to an end user (the majority of users)...
I'm a reletive newbie to Linux, a little less so to unix, and I would take an installation wizard from Winblows over an RPM any day. I'm still trying to figure out how to get gnome working, apparently I'm missing some files or something... that just doesn't happen with M$ wizards (assuming of course the app doesn't crash. A Technicality
So get real. In winblows you find the right icon, double click and your home free, or just stick the cdrom in the drive. In *nix you have to find the path you downloaded to, probably from the command line, find the path to install to, and then figure out if you installed all the dependant RPM's! And don't even start about mounting file systems!
My cube. My friend. My solace. My prison.
Responses like that make me think you are WAY too defensive, and can't read. The wizard/RPM point I was making was that for first time users, or those who don't care to use the command line, or for those who just don't give a $#i! as long as it gets done, wizards are easier. Plain and simple my friend, wizards do what most users can't.
Get over it.
And to Donovan below, Thanks! nice to see someone posting here who can demonstrate their knowledge (your web page) and be constructive. And he's not a "coward".
My cube. My friend. My solace. My prison.
Lets face it - to be accepted in the mainstream you have to work and work well on Microsoft platforms.
As long as they isolate most of the changes, I don't mind.
A Microsoft:: package hierarchy would be just fine - such a hierarchy already exists for others OSs.
Sorry, perl does not use the GPL. It can be extended at whim.
Please see Pete's Place for an alternative to activestate PERL. If we use the alternatives then activestate may back off in any case we should get the word out that activestate is not the only game in town win32 PERL.
"One World, One Web, One Program" - Microsoft Promotional Ad
War is necrophilia.
Sounds like the "Made for Windows 95" monitors we used to have here.
I've written lots of ActiveState Perl and there are modules for registry access, for NT security management, not to mention plenty of famous 3rd-party modules, like Win32::ODBC.
It's just like the Win32-specific Java stuff in Microsoft's Java. Nobody can use it accidentally, but if you want to write a Win32-speicific program it's there for you to do (just like you can write UNIX-specific Perl programs just by calling native code).
So the problem is not smart people like you, it's all those stupid people out there. All those novices buying computers at CompUSA and then unwittingly writing Windows Perl scripts. Sounds real plausible to me.
LJS
I've heard many posts saying "Micros~1 can't hurt Perl the way they did Java" and things like that. People basically defending the language and Micros~1 porting of it. Sure, they cannot ruin the unix version of perl, or directly affect what we do with it. What they CAN do is create a handful (And for Micros~1, that's a pretty big hand) of Perl programmers who know MS-Perl, and not Perl as it REALLY is. This would diversify and seperate us in to multiple communities, and put us at arms with each other. Just the same as I consider nothing makes MS happier than seeing new Linux distros come up, because that makes war among us, and less Big Brother'll have to do to get people to stop converting...
That's funny, I remember seeing "Plug and Play" stamped all over the power strips and UPS's when I worked at a computer store. I laughed my butt off.
An ironic quote from news.com's article on what's being added... noting that "forking" in the open-source world means something on its own...
For example, something that's present in Unix but missing on the Windows version is the "fork" feature, which lets a program make a copy of itself, Hardt said, a very useful ability for programs that use the network.
ActiveState will add the fork function into Perl for Windows and release the code to the
open source community, he said.
Do you write Lisp scripts? Do you write BASIC scripts? Do you write Java scripts? Do you write Pascal scripts? Do you write C scripts? You can, of course. You can set those all up so they are run by a different virtual machine than the one that's doing firmware interpretation. And just who is doing the interpretation and how much preprocessing is done on the very same source code can vary from run to run.
Face it, this is an altogether silly idea borne of marketroids and other atechnical jargonizers with no legitimate foundation in the computing sciences.
--tom
There are plenty of other cases, some of which are not obviously public, of companies shipping products with Perl bundled in, companies whose lawyers absolutely would not have permitted their product to require a GPV'd program. Whether the contamination were really there or not, the lawyers would only know how to say no.
And that helps no one. This way, more people can use Perl, and on their own terms, and without fear of reprisal from any rabid lawyers. Perl is more useful, more widespread, and more free than it would be were it saddled with nothing but the GPV. If you want freedom, don't tie people up with duct tape.
The Artistic Licence does just exactly what it was intended to do, and consequently is unlikely to disappear just because you want to remove people's freedom with a more restrictive, binding licence. Perhaps you might please reread it seen in this light.
--tom
--tom
Let's see now. That means that all I'll have to do to make the Perl thingie-that-wishes-it-were-a-compiler into a true compiler, is, without touching a single little bit within the aforementioned pseudocompiler's tender little binary image, wave my magic wand and create a chip that happens to directly use the Perl bytecodes as its native instructions. Voila! The old thingie-that-wished-it-were-a-compiler has had its heartfelt desire granted, all without altering it at all.
Because I can already convert the Perl bytecodes into something to feed a C compiler and thence an assembler using one of our various code generators, it would to appear that the existence of such a process has magically elevated the hitherto humdrum role of the whilom pseudocompiler into that of a proper compiler, but that before such code generators for Perl existed, no such appellation was merited. In short, the presence of an external, unrelated entity alters the very nature of a particular process, yet miraculously does so by changing neither the input nor the output of that same process.
You have demonstrated how the principle of strange action at a distance is one limited not merely to quantum physics, but that its reach in fact extends even to compiler theory. Your peccable perspicacity, sir, has so completely overwhelmed me, that I can but stand in humble awe--nay, call it shock--before you. Doubtless this is but the tip of the iceberg, and wholly new fields of figmentation await your inventive elaboration. You must definitely write a thorough treatise on your fascinating findings of Heisencompilers. Do be sure to please include some of that tasty postmodern deconstructionism while you're at it.
--tom
--tom
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
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
Yes.. we are about to won in the server side (desktop is other history) ... Perl is used in Server side primarily, so.. use a Linux/*BSD in the server.. and never..never..never..never touch MS-Perl for nothing.
1. Java could have possibly damaged the windows monopoly, but because of Sun's stupidity it probably will only exist as a C++ for dummies style language.
2. M$ doesn't like technologies that it doesn't make. This makes it look like it isn't the constant innovator.
3. Java was made by a company that is in direct competition with M$
---Got Coffee?---
Did not know this. I might try to get it to work again on my BeOS partition. BeOS r4 is a sweet little OS that beats Linux, Windows and MacOS in the home market. Don't get me wrong though, even though I am a newbie, I really like linux. However if I had to choose between giving a newbie Linux or BeOS, I would give them BeOS since it is so easy to use, configure and fix problems. Who needs a station wagon or a sports car when you have a tank and a flying bat mobile?
---Got Coffee?---
in one way or another :P