|
Re^2: Perl 6 and trend towards web-based applications
by Revelation (Deacon) on Jan 15, 2005 at 06:19 UTC
|
Unlike PHP, which is a tool just to make web sites
This is completely untrue. PHP has a command line interface much like perl's. What is true is that PHP caters to easy web development for small tasks. PHP successfully targets the niche of programmers most interested in creating small websites, and thus is rather prevalent in the "anybody's internet" world.
Now, it's important to note that web-based applications and websites are two largely different markets. To me, the success of Perl should be predicated upon its success as an all purpose language as well as a viable (and hopefully primary option) for web-based applications and larger websites. While one might see a lot of small websites, "Bob's Family Picture Site" that use PHP, Perl's success with larger websites should drive the language's online presence. Right now, for larger projects, Perl is a more than viable option. Template Toolkit, Text::Template, etc. make creating a website that separates html and code rather easy. I think that for Perl to grow its userbase a more viable alternative to PHPBB needs to be created as does a more viable alternative to PHPnuke and Postnuke. Perl programmers have a tendancy to create huge code reserves; for instance, Slashcode and Everything Engine are not easily installable for a Perl novice, who wants simply the functionality of the current PHP solutions. Thus, Perl looses these people. While I see this as a problem, I see the packages such as Slashcode that are made as boons to the Perl community. They demonstrate Perl's success in terms of larger web application, past the simple forum (and yes, sourceforge is mostly PHP, but I've found that the a larger number of big web application-like sites are Perl.)
I think that if Perl borrows from PHP in terms of its approach to the internet, it should continue to do so "like Perl." A critical element of PHP's online success has been that it's natural to embed code into websites, making PHP ideal for small tasks; I don't think that Perl should try and copy this--perhaps one could create mod_embedperl to do so, but I don't think this should be natural. Moreover, I think that some of PHP's simplicities (such as built-in session management) could perhaps be served by some sort of pragma, use PHPishPerl; which would load these constructs in some sort of transparent manner. Otherwise, I think Perl successfully deals with the internet being part of the set of problems posed to a Perl programmer, not natively needed.
Finally, I think it's important to note the difference in development models. CPAN arms Perl with a great resource; however, it also lets Perl's userbase dictate its functionality. Coming back to session management, while Ruby has CGI::Session by mattz and PHP has built in Session management this is handled in Perl by a module constructed by a programmer, most concerned with flexibility. I have found that Perl, in general, takes more parameters of input, because it is based off of Unix's tool and filter philosophy, where the flexibility of the base is essential. Thus, the learning curve for Perl is higher, because one needs to learn how to manipulate his tools, rather than only how to use them.
In addition, this has made Perl a strong all purpose tool, that is especially strong for designing web applications, and command line applications quickly, as well as one liners to complete a task. I envision Perl 6 making it easier to design larger command line applications, extending Perl's model, enhancing Perl's OO capabilities, cleaning up the language's internals, making less stuff core, and adding functionality to the language. I don't see it making Perl a niche language--Perl is neither PHP which is oriented towards the web, mathematica, which is oriented towards mathematical problems, or C, which is faster computationally. It's just Perl.
I guess I'm rambling.
| [reply] |
|
|
Unlike PHP, which is a tool just to make web sites
This is completely untrue. PHP has a command line interface much like perl's.
The OP might have overstated things saying PHP is "just to make web sites," but only slightly. It's true that PHP has a command line interface, but it's still geared towards websites. Sure, it can be used to do other things, but so can PostScript. :-)
| [reply] |
Re^2: Perl 6 and trend towards web-based applications
by szabgab (Priest) on Jan 15, 2005 at 09:50 UTC
|
| [reply] |
|
|
Will it be possile to write Parrot Applets that would run in a web browser ?
Yes. There is even an embedded version of Parrot that runs under Apache. It's called, surprisingly enough, mod_parrot. http://perl.com ran an article on it last month. (Or am I misunderstanding what you are asking?)
update: Added the sentence after "Yes" and the question at the end.
| [reply] |
|
|
(Or am I misunderstanding what you are asking?)
Maybe not, but I interpreted it to mean something different - namely, whether it will be possible to run client-side Parrot code as embedded objects within the browser itself, as is now possible with Java applets. I have not heard any discussion of this, but I assume it is on the agenda. Of course, you can use Perl in the browser today (though ironically, only on MSIE for Win32) by installing ActiveState Perl and the PerlScript hooks for WSH.
| [reply] |
|
|
|
|
It takes a huge security framework to do that safely. Especially when your VM wasn't orginally designed to do it (it's hard enough when it is).
Further, is this really a large application domain? If we take Sun's marketting department circa 1996 at face value, the web should running on Java applets by now. I rarely see them outside some cute arcade games. The applet market is almost non-existant, and Java has settled its success on the server-side.
So Parrot Applets would take a large effort and would run into territority others have failed to take. I don't think it's worth it.
"There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.
| [reply] |
|
|
Yeah, and if we take Perl's marketing department circa 2000 at face value, we'd all be using perl6 now. ;-).
I've seen large commercial (expensive, niche-market (banks)) application been rewritten or replaced with Java applets. Succesfully. With large improvements for the customer and/or vendor.
Granted, I don't see many Java applets on the public web. Nor do I really want to.
| [reply] |
Re^2: Perl 6 and trend towards web-based applications
by thor (Priest) on Jan 15, 2005 at 15:51 UTC
|
It easy to create "glue code"
Slightly off topic, but I wonder how true this will be in Perl 6. Part of the beauty of Perl 5 (in my opinion) is that it has XS. Not that XS is pretty, but it allows one to write code that allows perl to interface with existing C libraries. I may be speaking out of ignorance, but with XS going away in Perl 6, will we still have that ability? If not, I see Perl's ability as glue greatly diminished.
thor
Feel the white light, the light within
Be your own disciple, fan the sparks of will
For all of us waiting, your kingdom will come
| [reply] |
|
|
will we still have that ability [...] to interface with existing C libraries
Of course we will, and it will be much, much easier. For starters, check out Parrot's Foreign Library Access. You can open a shared library, DLL or whatever, and then just start using it. Parrot already has a fair amount of smarts to let you specify the calling conventions. Many XS problems will simply vanish because of the level of support that Parrot provides intrinsically.
And if Parrot can do that, you can be sure it will be easy to tap from Perl. And it will be Good.
- another intruder with the mooring in the heart of the Perl
| [reply] |
|
|
Hmm...somehow, I doubt that it will be as easy as the doc you pointed to suggests. If it were that easy, why haven't C compilers gotten rid of the need for header files? Something tells me that you'll at least need the header file.
thor
Feel the white light, the light within
Be your own disciple, fan the sparks of will
For all of us waiting, your kingdom will come
| [reply] |
|
|
|
|
|
|
|
I can't imagine it - even the Java purists put in JNI, albeit somewhat reluctantly (at least the way I heard it). I can't currently find the reference, but I'm pretty sure that when I read that XS was "going away", it was being replaced with something simpler. Which would be quite welcome here - the learning curve for XS has been a bit too much for my tastes so far.
| [reply] |
|
|
I would gleadly forget all XS stuff, even in perl5 if P5NCI is working good enough (another well-hidden gem by chromatic).
| [reply] |
Re^2: Perl 6 and trend towards web-based applications
by Errto (Vicar) on Jan 16, 2005 at 03:19 UTC
|
And as a side note, I hope the trend towards web-based applications comes to an end soon, at least as far pure HTML-based solutions are concerned. While they are obviously much easier to deploy and maintain, the user experience with a "fat" client is much better, I think. Maybe Java applets or XUL can improve this somewhat.
First of all, it depends whether you're talking about all applications that use the web as a delivery mechanism or only those that use HTML/CSS/Javascript for their interface. For the former, I don't see that going away any time soon, nor should it. Someone may propose a better mehanism, but no one has that I've seen.
For the latter, I agree with you that an open, portable platform for delivering rich client interfaces on the web would be very nice. XUL has the potential, but the market has not yet borne it out. But I don't think the current picture is so bleak that we need to either sit around waiting for this change to happen, or give up and start writing ActiveX controls in Visual Basic. The fact is, innovation in user interface design with dynamic HTML is not dead. Just look at Google: in both Gmail and Google Suggest they've built creative new interfaces using only standard web techniques, and in Google Desktop they've demonstrated the viability of using embedded web servers as a tool for desktop apps.
| [reply] |