Perl 6 and trend towards web-based applications

[kiat]

Hi monks,

I have read articles that predicted the trend towards more and more web-based applications. I'm very encouraged by this trend. I was at a bank recently to open an account and I noted with enthusiasm that the bank assistant was processing my application from a web-based interface.

A while ago, I was at a hospital to visit a friend and had to register my visit. There, too, the staff were using a browser interface to register visits.

Another good sign :)

I'm wondering whether Perl 6 is well-poised to take advantage of this trend. PHP came into the scene later than Perl but became popular in its niche as a tool for building dynamic web sites.

I'm aware of the fact that the programming languages are merely tools serving specific needs. So, as a tool, what specific niches will Perl 6 be targetting at?

Thanks in advance for reading and sharing :)

[Thilosophy]

So, as a tool, what specific niches will Perl 6 be targetting at?

Unlike PHP, which is a tool just to make web sites, Perl (5 or 6) is a general-purpose programming language suitable for many different tasks and targets no specific niche.

That is not to say that it is not a great tool for web apps, especially because as a "scripting language" it allows rapid prototyping and make it easy to create "glue code" to pull together systems (such as an HTML form and a DB backend) and through the more specialized extensions/modules that target that particular "niche" (templating engines, mod_perl, CGI frameworks, the DBI and so on).

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.

[Revelation]

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.

[Anonymous Monk]

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. :-)

[szabgab]

In this regard I'd ask a different question:

Will it be possile to write Parrot Applets that would run in a web browser ?

[Mr. Muskrat]

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.

[hardburn]

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.

[thor]

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.

[grinder]

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.

[Tanktalus]

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.

[dpavlin]

I would gleadly forget all XS stuff, even in perl5 if P5NCI is working good enough (another well-hidden gem by chromatic).

[Errto]

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.

[dimar]

Here's a prediction for you, soon the term "web-based application" will be considered too vague, indistinct, and passe. Much like the terms "MSDOS-based application" or "Windows-based application".

PHP peddlers, Python purveyors, and Perl proponents love to duke it out amongst themselves every now and again, but there's a plethora of platforms out there, that don't even start with the letter "P" ... case in point, there's Laszlo that uses XML and Java to Generate Flash SWF.http://www.openlaszlo.org

This stuff is getting too mixed up and heterogenous for the term "web based application" to hold much weight anymore.

[wolfger]

Here's a prediction for you, soon the term "web-based application" will be considered too vague
...
PHP peddlers, Python purveyors, and Perl proponents love to duke it out

So perhaps the new term will be "P-based applications"?

my $tongue=$cheek->firmly;

[Anonymous Monk]

Pascal? PL/I? Plankalkül? Prolog? Portia? PEARL?

[Daruma]

Greetings!

I too have seen many more web/browser based interfaces in use throughout the companies I visit. Specifically, I consult for utility companies and have seen a trend towards the browser for a multitude of systems they are implementing.

Some software vendors are using perl purely as a multi-platform capable shell scripting tool for behind the scenes job and file processing. I have not seen many using perl for actual database connections to their back end CIS/CRM systems. Nor have a seen a embrace of PHP in the industry... yet...

For the most part, I am involved in the implementation of these systems, and to some degree, I get to apply my perl knowledge for quick fixed and slight modifications to make their systems more usable and applicable to the utility's business needs. These modifications rarely make it into the core application.

-Daruma

[Anonymous Monk]

Having worked for both banks, and a company that writes software for hospitals (including stuff like you watched), I can confirm that there's the move towards the web. But it's mostly used as a deployment mechanism. Having to roll out a new version of software to hundreds or thousands of workstations is hard. But it becomes much easier if the web is used - it brings the software to the user.

However, neither Perl nor PHP is going to play any major role in this. Application servers like Websphere, Tomcat and others will do most of the work. With applets, beans or whatever you may call it written in India using Java or .NET.