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". "
> 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.
- If whatever is considered the executable form of the program (what you'd send to someone and say "run this") is not loaded directly into the processor (whatever the hardware designers of your system would consider "the CPU")
- via an instruction fetch cycle, then it is interpreted.
If you are unclear what exactly constitutes a CPU is or what differentiates an instruction fetch cycle from any other kind of cycle, RTF Hardware Docs.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
Yes, I know, but upto now, they were just holding hands :-)
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!"
Exactly!
The fear is not that it will be _possible_ to write win32 specific code, but that it will be _inevitable_. Meaning code that was designed to be portable won't be. Just as Java code won't run under The MS Program Formerly Known as Java and vice/versa. Just as html written for Netscape won't work right under IE, and vice/versa.
The enemies of Democracy are
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.
However, I think it's a bit of a big step to assume that Microsoft *will* do this, when all they have said is that they will help with perl...
The reason they went after Java was because of the abiulity to run precompiled binaries on any Java compliant platform, which would undermine people's reliance on their operating system. However, perl is just another language that people find useful - it's not got the 'write once, run anywhere' features (i.e. abstraction of most of the operating system). Compare it to C - you can write portable code, but there's quite a few little incompatibilites to with endedness, standard libraries etc - perl is and probably will be exactly the same. A largely portable core language with platform-specific modules.
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.
The "surrogate pair" concept, right? Well, it's not just CJK that's affected - languages with umlauts, Hebrew, and several other languages have to use them as well. Of course, the Unicode standard hasn't actually bothered to define what can be displayed with surrogate pairs and what can't, making them fairly pointless at the moment...
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.
Looking back at the history of products Microsoft has released, I cannot think of a single item which it has not "embraced and extended"... Witness J++, Visual C++, Visual Basic, etc...
It really isn't "a bit of a big step" to assume that Microsoft will do the same to Perl.
The perl's license has gives companies the right to do extend... However, extending a language to prevent server/code migration is not a good thing. From reading the FAQ, it sounds as though the main intent is to prevent people from switching from windows to another operating system. There were only 3 real useful features which were added.
All corporations and people have the right to make money... But limiting choice for the consumers (A Microsoft specialty) is not necessarily a good thing.
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.
JIT heavily speeds up Java programs. As for IE, well - it's basically a part of the OS (Wintendo) and is 'pre loaded' when you boot your machine. Java does allow dynamic change of code, use the Reflection API or just generate the code and compile it runtime
Unable to read configuration file '/bigassraid/htdig//conf/14229.conf'
Geocrawler error message.
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
>>Meaning code that was designed to be portable won't be.
How could this be possible in Perl? Either it's interpreted, and therefore it's exactly as portable as it's designed to be, or it's compiled and completely unportable. Your argument makes no sense.
LJS
Have you ever actually written Perl code on Win32, or Perl anywhere for that matter? Perl on all platforms is filled with opportunities to write non-portable code. Go to CPAN and you're immediately faced with module names like Mac/MacConversions Mac/MacFileSpecUnixish Mac/MacOSASimple Mail/MailCclient RADIUS/RADIUS RADIUS/RADIUSUserFileX11/XformsPerl X11/XFvwm X11/XMotifb X11/XProtocol X11/XWcl VMS/VMSLock_ VMS/VMSMonitor_ VMS/VMSPriv_ Tk/TkTreeGraph Tk/TkWaitBox Tk/vstadaf Tk/xdbfdump OS2/OSAttrib OS2/OSExtAttr_ OS2/OSFTP_, not to mention Emacs/EmacsLisp
Making modules to take advantage of platform-specific features is not only old news on Perl, it's one of the main points of the language. It's the whole idea.
Maybe you've never written a Windows program before, but Windows programmers are used to the idea that some of their programs will only work on Windows, and are willing to trade that off for optimal utilization of features on Windows, which is the most popular platform in the world. It's a rational decision and they don't do it unwittingly.
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
--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