We use it at my company for the vast majority of our web programming tasks, and it works very well for us. Reasons I personally like it:-
* Contorl. While PHP may do a lot more for you (e.g. form parsing), there have certainly been issues related to how it did things. In Perl you can do it as you want. If you put this in a module, as we did, then Perl is no more work than PHP beyond that one-off cost.
* I find the Perl database access model preferable to PHP. Correct me if I'm wrong, but it seems to me that a lot of people end up writing database classes to encapsulate the mysql_whatever or pgsql_whatever methods. In Perl it's OO from the start. Furthermore, if you change from using one database server to another, you only have to make the change in the connection string, and not to a load of function calls.
* Perl puts pattern matching tools right into your hands - it has an operator (//) specially for pattern matching. A lot of the security issues I see in web development come from improper validation. Pattern matching is a powerful tool for writing validation and Perl makes it easier to do than other languages I've seen.
* CPAN. Perl has modules for a wide range of things. Need to look at the headers of uploaded MP3 sound clips to check they were encoded properly? We found a module on CPAN to do this within minutes. CPAN is an amazing resource.
Just my few thoughts on why I belive Perl isn't dead for web programming by any means.:-)
One type of application that would need to take this into account would be JIT compilers, e.g. like that used in.Net. These create native code in memory to execute, with the objective of increasing performance. These apps simply need to state that they want the memory they allocate to be executable when they allocate it, then they can continue to work as before.
It's quite possible we'd see compilers for these languages in the future, yes. You just need someone crazy enough to implement it.:-)
As for functional language style stuff, Perl6 is going further than way, at least in some aspects it is. I've heard curried functions and lazy lists are to be expected. Perl has never had any problems taking the best bits from various paradigms.
Re:Quite possibly very naive question from a non-p
on
Perl's Extreme Makeover
·
· Score: 4, Informative
Parrot will be a virtual machine like the JVM and.NET runtime, yes. This means you can call functions and use objects from code written in the various different languages that target Parrot, compile stuff to bytecode that will run wherever Parrot will compile and more. Like.NET and JVM it uses JIT techniques to provide fast code execution.
The main difference between Parrot and.NET/JVM is that they are more targetted towards statically typed languages. Languages like Perl, Python, etc that are likely to target Parrot are dynamic languages. This isn't just related to dynamic typing, but also to dynamic languages needing their parsers to be available at runtime. You can also do more stuff at runtime that non-dynamic languages would prefer you didn't. Parrot is designed with this in mind, which means it can offer these sorts of languages better performance.
I have heard things along the lines of JVM and.NET bytecode to Parrot bytecode convertors, but I'm not sure how much speculation that is. I'm not really certain how easy it'd be, though my initial guess is "not very".
I have a small involvement with Parrot (e.g. I've contributed a few small, insignificant things, mainly fixes for Win32). It's not vaporware, it's just that designing a stable, efficient, multi-threaded virtual machine that runs on a wide range of different platforms isn't an easy task. You can go and do a CVS checkout of Parrot now and play with some of the toy compilers, or if you use Windows grab yourself the Parrot On Win32 compiled version:- http://www.jwcs.net/developers/perl/pow /
The 0.1 release may be coming by the end of this month - and if this release isn't 0.1, I'm pretty sure the next one will be. That means Parrot has objects, some of the threading stuff is in place, JIT is working on various platforms and more. There's a lot of hard work going in by a lot of very good developers (not me!), and I'm confident that Parrot will be completed and will be a hot target for dynamic languages.
Maybe I'm missing your point, but Perl certainly isn't having core revisions every year in terms of the language. Perl5 has been around for about 10 years now, and will probably still be pretty widespread in another 5 years. 15+ years isn't a really bad lifetime for a langauge, and it isn't like there are no plans to continue support for Perl5 code. Indeed, they are currently re-implementing Perl5 on top of the Parrot engine, so Perl5 and Perl6 code will be able to interact. This means systems can gradually move from Perl5 to Perl6 if they need to, without needing a full re-write.
Slashdot Mirror
Who uses Perl in web programming anymore?
:-)
We use it at my company for the vast majority of our web programming tasks, and it works very well for us. Reasons I personally like it:-
* Contorl. While PHP may do a lot more for you (e.g. form parsing), there have certainly been issues related to how it did things. In Perl you can do it as you want. If you put this in a module, as we did, then Perl is no more work than PHP beyond that one-off cost.
* I find the Perl database access model preferable to PHP. Correct me if I'm wrong, but it seems to me that a lot of people end up writing database classes to encapsulate the mysql_whatever or pgsql_whatever methods. In Perl it's OO from the start. Furthermore, if you change from using one database server to another, you only have to make the change in the connection string, and not to a load of function calls.
* Perl puts pattern matching tools right into your hands - it has an operator (//) specially for pattern matching. A lot of the security issues I see in web development come from improper validation. Pattern matching is a powerful tool for writing validation and Perl makes it easier to do than other languages I've seen.
* CPAN. Perl has modules for a wide range of things. Need to look at the headers of uploaded MP3 sound clips to check they were encoded properly? We found a module on CPAN to do this within minutes. CPAN is an amazing resource.
Just my few thoughts on why I belive Perl isn't dead for web programming by any means.
Jonathan
One type of application that would need to take this into account would be JIT compilers, e.g. like that used in .Net. These create native code in memory to execute, with the objective of increasing performance. These apps simply need to state that they want the memory they allocate to be executable when they allocate it, then they can continue to work as before.
It's quite possible we'd see compilers for these languages in the future, yes. You just need someone crazy enough to implement it. :-)
As for functional language style stuff, Perl6 is going further than way, at least in some aspects it is. I've heard curried functions and lazy lists are to be expected. Perl has never had any problems taking the best bits from various paradigms.
Parrot will be a virtual machine like the JVM and .NET runtime, yes. This means you can call functions and use objects from code written in the various different languages that target Parrot, compile stuff to bytecode that will run wherever Parrot will compile and more. Like .NET and JVM it uses JIT techniques to provide fast code execution.
.NET/JVM is that they are more targetted towards statically typed languages. Languages like Perl, Python, etc that are likely to target Parrot are dynamic languages. This isn't just related to dynamic typing, but also to dynamic languages needing their parsers to be available at runtime. You can also do more stuff at runtime that non-dynamic languages would prefer you didn't. Parrot is designed with this in mind, which means it can offer these sorts of languages better performance.
.NET bytecode to Parrot bytecode convertors, but I'm not sure how much speculation that is. I'm not really certain how easy it'd be, though my initial guess is "not very".
The main difference between Parrot and
I have heard things along the lines of JVM and
Hope this answers some of your questions.
I have a small involvement with Parrot (e.g. I've contributed a few small, insignificant things, mainly fixes for Win32). It's not vaporware, it's just that designing a stable, efficient, multi-threaded virtual machine that runs on a wide range of different platforms isn't an easy task. You can go and do a CVS checkout of Parrot now and play with some of the toy compilers, or if you use Windows grab yourself the Parrot On Win32 compiled version:-w /
http://www.jwcs.net/developers/perl/po
The 0.1 release may be coming by the end of this month - and if this release isn't 0.1, I'm pretty sure the next one will be. That means Parrot has objects, some of the threading stuff is in place, JIT is working on various platforms and more. There's a lot of hard work going in by a lot of very good developers (not me!), and I'm confident that Parrot will be completed and will be a hot target for dynamic languages.
Maybe I'm missing your point, but Perl certainly isn't having core revisions every year in terms of the language. Perl5 has been around for about 10 years now, and will probably still be pretty widespread in another 5 years. 15+ years isn't a really bad lifetime for a langauge, and it isn't like there are no plans to continue support for Perl5 code. Indeed, they are currently re-implementing Perl5 on top of the Parrot engine, so Perl5 and Perl6 code will be able to interact. This means systems can gradually move from Perl5 to Perl6 if they need to, without needing a full re-write.