Re: Can Perl do anything Java can do?

Replies are listed 'Best First'.
Re^2: Can Perl do anything Java can do? by afoken (Chancellor) on Jul 20, 2017 at 20:08 UTC
No. Java can run in the user's browser. Perl can do that, too. (If any are still fool enough to have that insecure crap enabled.) Well, enabling ActiveX controls (required for that) fall into the same category, if not in a worse one. Update: Link broken less then 12 hours after my post. See Re^4: Can Perl do anything Java can do?. Alexander -- Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)	[reply]
Re^3: Can Perl do anything Java can do? by BrowserUk (Patriarch) on Jul 20, 2017 at 20:53 UTC
Perl can do that, too. Let's see what's required: Run your commercial website on IIS. Uh huh! (Not even MS will do that.) Persuade all your users to install ActiveState Perl; and ActiveState PerlScript. Right! (Wanna buy our bagles? Okay just find, download and learn how to install this 5GB of sofware. (And then install a C compiler and learn how to use it once AS take the repository for whichever version you installed off-line.)) Persuade all your customers that it is safe to enable ActiveX controls. You mean that ancient, long deprecated, technology that has has 330 vulnerabilities in the last 10 years (and 2 in this month alone; and probably 1000s if you still find the infor mation for the preceeding 10 years.) Mmmmmmmmmm. Find an insurance company willing to insure your business. Maybe you could get funding for the premium from that new kickstarter style site run by philanthopic law firms: FIFFLE. (Funding Idiots For Future Lawyer Employement). Riiiight. DCUW(N)CU. With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday' Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". The enemy of (IT) success is complexity. In the absence of evidence, opinion is indistinguishable from prejudice. Suck that fhit	[reply]
Re^4: Can Perl do anything Java can do? by afoken (Chancellor) on Jul 21, 2017 at 07:26 UTC
Let's see what's required: 0. Read the documentation. OK, harder than I thought, because ActiveState seems to have changed the documentation significantly in the past 12 hours. Interesting. My link from my previous post now returns a 404 page, but Google still has a cached version. Alternatively, download and unpack ActivePerl. http://docs.activestate.com/activeperl/5.24/get/windows/ promises a ZIP package, but the download page does not list that any more. The real download server http://downloads.activestate.com/ActivePerl/releases/ does not list any ZIP file for ActivePerl. Great. Another case of bad documentation. But: You can download a Linux package in .tar.gz format and unpack it. This will extract tons of stuff and a file named `ActivePerl-5.24.1.2402-x86_64-linux-glibc-2.15-401614/perl/html/Components/Windows/PerlScript.html` that contains the documentation. Yes, it's completely useless for a Linux system, but still packaged. This also works for the other Linux archives (5.24.0.2401, 5.22.3.2204, 5.22.2.2203). 7-zip can unpack .tar.gz archives on Windows, on Linux and other Unixes, `tar -xzf ActivePerl-5.24.0.2401-x86_64-linux-glibc-2.15-401614.tar.gz` should be sufficient. Quoting the relevant parts: Client-side PerlScript Client-Side PerlScript is Perl embedded within your HTML documents. All PerlScript code must be contained between `<script language="PerlScript">` and `</script>` tags. Client-Side PerlScript also has the added requirement that both ActivePerl and PerlScript must be installed on each computer that will be loading PerlScript pages. Client-side Perlscript should only be used if you can control the configuration of the computers on which it will be run. If your goal is to build an application that will be used by a large number of users, server-side PerlScript is considerably more practical. To display something in the browser, use the document object method `write()`. You can use the `write()` method with `$windows->document->write('any old text')`. The sample below is another Hello World variation, but this time using client-side PerlScript: `<html> <head> <title>PerlScript Hello World!</title> </head> <body bgcolor="#ffffff"> <h2>PerlScript Hello world!</h2> <script language="PerlScript"> $window->document->write('Hello world!'); </script> </body> </html>` [download] How can I configure client-side PerlScript security? PerlScript in IE 4.0 and higher can be enabled/disabled by zones `HKEY_LOCAL_MACHINE\SOFTWARE\ActiveState\PerlScript\1.0 REG_DWORD: EnabledZones = 0x0010 (default)` [download] Values `Enable All 0x0001 Enable Local 0x0010 Enable Internet 0x0020 Enable Trusted 0x0040` [download] Note: By default, PerlScript is only enabled in IE's Local zone. Enabling PerlScript any other zones is not recommended. It allows websites to execute Perl code on the local machine as the current user. 1. Run your commercial website on IIS. Wrong. Client-side perl scripting works with every webserver, and even from HTML documents read from the filesystem or from any other source (like an FTP server). And by default, it is enabled only for the "Local Intranet" zone. So, this is obviously designed for use in an intranet, not for commercial websites. 2. Persuade all your users to install ActiveState Perl; and ActiveState PerlScript. In an intranet environment, this is quite easy. You usually have a software distribution system that can easily force a software installation on all client systems. Or, you include it in the installation image. Or, worst case, you make people call the IT helpdesk to have any missing software installed on their system. Remember: Those poor corporate drones that are neither developers nor admins have to accept whatever the IT department forces on their systems. 3. Persuade all your customers that it is safe to enable ActiveX controls. Not customers, corporate drones. And no one has to be persuaded, the IT department simply enforces that via the software distribution system or domain policies. I've seen much scarier setups to integrate poorly written server software, Internet Exploder, MS Office, and custom software into something that might look like a cool web application in a powerpoint presentation. 4. Find an insurance company willing to insure your business. As long as this scary stuff is limited to the intranet, no insurance company will complain or refuse to insure the business. Guess how the insurance company's intranet works. You mean that ancient, long deprecated, technology that has has 330 vulnerabilities in the last 10 years (and 2 in this month alone; and probably 1000s if you still find the information for the preceeding 10 years.) I never said it was a good idea. I only said that perl can be run in the browser. I agree that it is at least as stupid as any other ActiveX stuff or running native code in the browser and on the same level as running Java applets in the browser. Update: reformatted links, broke my second paragraph into two parts (after "Interesting."). Added info about documentation in the downloadable files. Alexander -- Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)	[reply] [d/l] [select]