ptimmins writes "I wonder as I wander:
1. Why isn't Perl on every networked computer the way jdk or jre is?
2. Why can't I interact with this 'Perl VM' via some Perl code and GUI that runs in an Applet within any popular browser?
3. Why isn't a there subset of Perl that can be embedded in HTML and recognized by most browsers and executed?
4. Why aren't more pointy hairs aware of the significance of the role of Perl within their own organization?
I guess I'm interested in opinions regarding the validatity of the above statements, as well as any ideas about how to make each of them a dark and foggy memory of sillier days."
"I'll talk to myself, just in case no one else is interested:
1. OK, I suppose other than Win32 this is pretty much already the case, and maybe this is even starting to happen on Win32. It probably
would all have been a moot point by now had their been something running in a browser to drive it forward (see #2).
2. I can understand why Netscape wouldn't have been chomping at the bit in regard to something like this, but why did't MS ever seize (or 'sees':) the opportunity?
3. On the client side, I don't see why Netscape would have ever felt threatened by this. They could have still had their server-side javascript, but in the browser, they would only have made their client more popular by having something like this in addition to javascript. Similarly, why didn't MS ever do this? They could have forced Netscape's hand.
4. Speaking of hand, I wish someone would tell ActiveState about the invisible one, made famous by Adam Smith (The Wealth of Nations). Like pornography, I'm not sure how to define it, but I know it when I see it
I think the key point is the security sandbox, which I think Java has done better, especially WRT the fine-grained nature of control. Perl's control by opcode isn't quite the right level.
Both Netscape and Microsoft suffer from the NIH (Not Invented Here) syndrome. Perl wasn't invented by either Netscape or Microsoft. Furthermore, if either of Netscape or Microsoft implements something that they didn't invent, like Java, they insist of making it non-compatible with whatever is already outthere. But, to do that for Perl, they would have to make their own implementation of Perl. Not an easy task. Furthermore, Perl has never shown any signs to stabalize, things change and get added in each version. And while both Netscape and Microsoft don't want to be fully compatable, they cannot afford to be missing to many features. They would be forced to implement things due to a process that's outside of their control.
Chip already pointed out the technical problems with the "sandbox" model.
Another point is the licensing. Perl is available under GPL and the Artistic License. Accepting Perl under GPL would be impossible for either of Netscape and Microsoft, as they would need to open up the source of their browser if they would borrow even the slightest piece of code (remember that Netscape partially opening the source of their browser was only a relative recent event - for a long time, the Netscape browser was a binary you had to pay for). The Artistic License is at its best vague, not something that would make Netscape or Microsoft lawyers bouncing with joy.
Javascript is a special purpose language. It gives access to the parts of which a document consists. Perl, OTOH, is a general purpose language, which has absolutely no idea what HTML is. You'd have to build that in in your Perl compiler/interpreter as well.
Considering the coding qualities of the average web page constuctor, and that Perl isn't for the light of heart, Perl wouldn't be too popular as "scripting" language.
Grail with embedded Python never took off.
Conclusion: Perl just doesn't have to much to offer for commercial browser authors.
-- Abigail
Actually you can use Perl inside IE for a couple of years already. PerlScript as included in the ActivePerl distribution is nothing more than an ActiveX scripting language wrapper around the standard Perl DLL. It allows the same kind of client side scripting that VBScript and JScript does. Of course you need to have PerlScript installed on the client. You should only enable PerlScript for your trusted zone. Otherwise you'll allow everyone to execute arbitrary Perl code on your machine.
-Jan
Evidently Mozilla is going to support Perl scripting on the clientside. That'll be fun, except it's unlikely that IE will jump on the bandwagon. See http://www.mozillazine.org/ta lkback.html?article=1421
Chapter 20 of Advanced Perl Programming talks a bit about the difficulty of creating a byte-code translator, among other things. I suggest checking it out if you're interested....
Internet Explorer will allow you to exeute arbitrary embedded scripting languages, provided you have the correct Active Scripting host installed. When you install the full ActiveState (at least, it used to be this way) you got the PerlScript ASH installed if you had Windows Scripting Host installed already (WSH is a generaly purpose scripting framework, which supports JavaScript and *shudder* VBScript by default). So you could embed Perl, Python, or a made-up language into your HTML pages, provided your users have the appropriate scripting host installed.
JavaScript and VBScript are supported this way (as plugins to the scripting host), at least in IE4 and IE5. Adding other language support is as simple (?) as distributing your interpreter (on an Intranet for example).
darren
Perl isn't for the light of heart
Faint of heart perhaps - but I know plenty of lighthearted Perl programmers (and some fairly light headed ones too
For the same reason they're not aware of the significance of the roles of Sendmail, or BIND, or IOS. It's just not publicized, and probably should not be.
When it comes down to it, language choice is very often a matter of preference, and it's definitely an implementation detail -- nothing the general users of a product/service/system/whatever need to know about.
darren
Although this is certainly a longer term goal, the immediate development effort will concentrate on enabling Perl and Python to create XPCOM components. This will allow Mozilla components to be written in Perl/Python but doesn't make these languages available at the HTML level. The JavaScript integration seems to be pretty much hardcoded deep into the system and cannot easily be augmented to support additional languages. Changing this won't happen until after the first Mozilla release (AFAIK).
-Jan
