Re: decline and fall of modperl? (my last post on this subject)
Please do not reply to my comments. I think it's time to close this and move on. Ok, my personal summary on this topic: 1. The fact that so many people (including lurkers) responded to this email suggests that it is a subject that's important to them - be it personal, professional, or academic. Conclusion: It would be unwise to for anyone to attempt to conclude a question like this with short answers. The variety of the responses also suggests that Perl is used by many for many intents and purposes. 2. There were many good and interesting points brought up on the relavancy of Perl in today's context. There were anecdotes, personal experiences etc contributed by everyone. Conclusion: Not all points will be relavant in the context of every developer; business environments are not hetrogeneous in all parts of the world. Perl needs to present a 'face' that will work in each of these environments if it wants to remain relavant there. Generally it is doing a fairly good job in that aspect. 3. Throughout the discussion everyone remained reasonable rational, and attempt to comment on facts and personal beliefs. Conclusion: Compared to some other mailing lists I subscribe to, we Perlites are a fairly level headed bunch. Let's give ourselves a pat on the back on this. And stay that way please. Let's move on with new topics of interest please.
Re: decline and fall of modperl?
From: Joe Schaefer joe_schae...@yahoo.com A contribution to a *community* would be to offer gratis advice on a mailing list, ostensibly to help the community reach its objectives. Nothing I see in this thread looks like a contribution to the mod_perl community, sorry. The mod_perl community is also made of those who want to use mod_perl, and if somebody put questions regarding mod_perl, we should try to help him, no matter if he is interested about technical faces of mod_perl, or if he is interested to know how obsolete or modern it is, or if he is interested to know how many mod_perl programmers are available. Die is just an expression that wants to tell that the language is not used by more and more programmers, but by fewer. Usage statistics are irrelevent to the vitality of a language. What's relevant to the perl community is something like how many module maintainers have abandoned their codebases. Do you have any information about how many modules are on CPAN that are no longer supported? And to bring it back to mod_perl, how many of those are Apache modules? Nope, but I know that WxPython is much better developed than WxPerl, that Python can be used under Symbian, that Python can work better together with Java virtual machine, that Python is better than Perl for some tasks, and I gave an example of 2 screen readers made in python, one for Linux and one for Windows. I also know that even the Perl programmers prefer more and more fastcgi, because it has some advantages. I have never used fastcgi or fcgid, but only mod_perl, but this doesn't mean that we should present only the good parts of mod_perl and perl. Usage statistics are very relevant. In the christian part of the world, in churches the old greek and latin are considered great languages, with a big history, and some consider them more important languages for the world's civilisation than English or Spanish, but this is because for what those persons is important, those languages could be important, however for the rest of the world those languages are considered only dead languages, even if they have a longer history than English or Spanish. If perl will become better and better but for less and less users, it would become an alive language like latin. If we want to be more on-topic, it would be interesting to compare mod_perl with mod_php and mod_python and find if the other Apache modules have advantages, or why they are more and more used. And the number of current users is not so important as the rate of increase or decrease in the number of users and sites that use them. If there are say 1 million sites that use mod_perl but only 100 thousand that use mod_python, however the number of web sites that use mod_perl increases with 1% each year (or even decreases), and the number of sites that use mod_python increases with 10% each year, then the future doesn't sound very well for mod_perl. If this presumption is true or not, it would be helpful for us to know in any case. Octavian
Re: decline and fall of modperl?
On Sat, Mar 28, 2009 at 6:44 AM, Octavian Râsnita orasn...@gmail.comwrote: From: Joe Schaefer joe_schae...@yahoo.com A contribution to a *community* would be to offer gratis advice on a mailing list, ostensibly to help the community reach its objectives. Nothing I see in this thread looks like a contribution to the mod_perl community, sorry. The mod_perl community is also made of those who want to use mod_perl, and if somebody put questions regarding mod_perl, we should try to help him, no matter if he is interested about technical faces of mod_perl, or if he is interested to know how obsolete or modern it is, or if he is interested to know how many mod_perl programmers are available. Die is just an expression that wants to tell that the language is not used by more and more programmers, but by fewer. Usage statistics are irrelevent to the vitality of a language. What's relevant to the perl community is something like how many module maintainers have abandoned their codebases. Do you have any information about how many modules are on CPAN that are no longer supported? And to bring it back to mod_perl, how many of those are Apache modules? Nope, but I know that WxPython is much better developed than WxPerl, that Python can be used under Symbian, that Python can work better together with Java virtual machine, that Python is better than Perl for some tasks, and I gave an example of 2 screen readers made in python, one for Linux and one for Windows. I also know that even the Perl programmers prefer more and more fastcgi, because it has some advantages. I have never used fastcgi or fcgid, but only mod_perl, but this doesn't mean that we should present only the good parts of mod_perl and perl. Usage statistics are very relevant. In the christian part of the world, in churches the old greek and latin are considered great languages, with a big history, and some consider them more important languages for the world's civilisation than English or Spanish, but this is because for what those persons is important, those languages could be important, however for the rest of the world those languages are considered only dead languages, even if they have a longer history than English or Spanish. If perl will become better and better but for less and less users, it would become an alive language like latin. If we want to be more on-topic, it would be interesting to compare mod_perl with mod_php and mod_python and find if the other Apache modules have advantages, or why they are more and more used. And the number of current users is not so important as the rate of increase or decrease in the number of users and sites that use them. If there are say 1 million sites that use mod_perl but only 100 thousand that use mod_python, however the number of web sites that use mod_perl increases with 1% each year (or even decreases), and the number of sites that use mod_python increases with 10% each year, then the future doesn't sound very well for mod_perl. If this presumption is true or not, it would be helpful for us to know in any case. Octavian I do see Joe's point. The question I would ask though is what harm has this mail trail done?. It has generated a large amount of interest, even if the opinion to backed-by-objective-evidence ratio has been a little high at times. If someone isn't interested then surely they just won't follow the discussion?
modperl or php? Re: decline and fall of modperl?
My 2 cents. Based on daily traffic: 1 - 1000 unique sessions shared hosting, = CGI Perl (CGI.pm) = Php 1000 - 5000 unique sessions (fun sites) shared hosting (modperl is not available) = CGI Perl + mod_rewrite (to cache dynamic contents) = Php daily traffic: 5,000 - 20,000 unique sessions (small sites) single server = CGI + an efficient caching system, such as a customized C module = Php = modperl daily traffic: 20,000 - 100,000 unique sessions (medium sites) = Php + an efficient caching system = modperl, but not based on Mason or such application toolkits daily traffic: 100,000 - 500,000 unique sessions (medium to medium-large sites) = modperl in a cluster environment Php has two advatages over modperl: first, it is available everywhere, especially in a shared hosting plan; second, it runs with less system resources. Modperl's advantage is its direct access to the Apache API. Unfortunately, among modperl users, most are still programing on top of toolkits, never have explored the richness and power of the API. PV
Re:modperl or php? Re: decline and fall of modperl?
Message du 27/03/09 07:09 De : Phil Van A : modperl@perl.apache.org Copie à : Objet : modperl or php? Re: decline and fall of modperl? daily traffic: 100,000 - 500,000 unique sessions (medium to medium-large sites) = modperl in a cluster environment me again: modperl as well as FastCGI. Créez votre adresse électronique prenom@laposte.net 1 Go d'espace de stockage, anti-spam et anti-virus intégrés.
Re: modperl or php? Re: decline and fall of modperl?
Hi, daily traffic: 20,000 - 100,000 unique sessions (medium sites) = Php + an efficient caching system = modperl, but not based on Mason or such application toolkits I don't agree: I had a website running with 20.000 visitors/day, build with Mason (MasonX::Webapp), split into 180 frontend apache an 20 mod_perl backend apache , server load was below 1, on a 1 GB hardware. And I had no need to enable any of mason's caching or performance feature 9staice source etc). Rolf Schaufelberger
Re: decline and fall of modperl?
From: David Ihnen
en the newer perl modules on cpan started to use OOP, and I guess this is
because OOP is better, even though under perl it usually
makes the programs run slower.
Perl's speed, even under oop, is good enough. OOP makes the libraries
easier to maintain and extend. You should well be an advocate of
good-enough - thats what the php programmers are all about, right?
I know this, but the perl docs tell the truth that perl OOP is slower than
functional perl and the beginners don't like to hear that using OOP under Perl
make it slower. Of course that they don't benchmark to see if it is faster than
PHP. The PHP docs don't tell that using the OOP style makes the programs slower.
I have also heard from some programmers that they don't like to use perl,
because for doing some thing they need to use eval {...} because they've read
that eval makes the program slower. They don't understand that there is a
difference between eval ... and eval {...}, and even eval ... doesn't slow
so much the program anyway.
I can't believe you would say that the particular syntactical constructs
used in the object oriented declaration is even slightly relevant to the
usability of the language. saying 'package' instead of 'class'? Saying
'use' instead of 'import'? I'm agog. Any language transition involves
learning new syntactical constructs for the new environment you're in. And
thats the only real difference between The Java/C# 'style' and perl, is
Not the term is so important, but it shows that Perl is an archaic language
that doesn't follow the standards of the new languages. Even in perl we call
the classes classes, but the new programmers won't find classes, but
packages, and those classes are not extended as in other languages, using
extends, but use a totally different style.
A programmer that learns many languages and can program in
C/C++/Java/C#/PHP/Perl/Python/Ruby won't find that hard this different syntax,
but there are very very many PHP programmers that know only PHP.
That kind of programmers could find harder to learn a totally different
syntax, so the target audience of perl decreases.
we cannot do everything with perl. But that is okay. What is important
to remember is what we CAN do with perl. Even when you have a
high-performance graphical processor module written in C/C++/Java, the business
rules, glue, and associated logic that is not fine-grained performance
critical are best implemented in a scripting language just like Perl.
I've seen that most of the software companies use a single language for a
single project. They use either Java or DotNet, either PHP, but not mix more
languages because they would depend on programmers that know well more
languages, and they are harder to find, and more expensive.
Octavian
Re: decline and fall of modperl?
From: Chris Prather perig...@gmail.com Perl is a funny animal. It doesn't have a formal support for interfaces, but it suppports multiple class inheritance. It also has - for a very long time now - support for closures, which I find very interesting (few Java developers even heard of it). Moose supports Roles which can functionally act like Interfaces as a special case, but can in the more general case perform *much* more powerfully. I refer you to Ovid's recent set of blog posts on use.perl.org about re-writing his MI class hierarchy to use Roles. If the language doesn't force the programmer to follow standards and interfaces, it is much harder to be used in very big teams that have members in more countries, with different cultures and styles of programming. I also like perl because it is flexible and doesn't force us to do anything, but we should agree that this is also one of the biggest disadvantage, and reason why it is not used by very big teams. Agreeably, Perl is neutral enough to let bad boys ignore the 'contracts' aka interfaces. But I would say that it's more of a feature (some would use the word 'beauty'). I do acknowledge there's some pain in this philosophy though. There's always a workaround to enforce things if you want it to. This could be interesting. Can you give some more details? (About what a big team of perl programmers should do to 0enforce a certain style of programming, and respecting interfaces) - It can create portable programs that can run everywhere, under Windows, Mac, Linux, shared hosting web sites that don't offer root and shell access... Lose out to expensive marketing folks from Java. Perl can and does do this. And has been doing this for over a decade. They call it CGI, and it's slow but it works. It is slow, it works, but I see fewer and fewer web sites that use CGI with perl and there should be a reason why. Movable Type uses CGI, but it is great because it create static files, so the CGI speed penalty is not an issue. It can be also installed without requiring shell and root access. But there are no very many perl programs that use this style. The recommendation is to install the modules from CPAN... The fact that Perl source is available is in my opinion a bonus because it means that you can in fact alter the source if your Vendor dissappears. Do you know how many legacy C/C++/Fortran/Cobol applications exist out there that have no source anymore? Have you ever had to maintain something like that? The software companies usually don't care what happends with their code if they disappear from the market, but they do care to protect their code when they try to sell it to someone else. I don't say that they are right, or that they are really protected and criticize perl that doesn't help to do the right way. I am sure that if all the source code of all the custom - created programs for some clients would be opened, 99.999% of the clients won't give that source code to someone else, and won't try to modify it and sell it, but the truth doesn't matter. It matters what the owners of the software companies think. Hiding the source simply put means that you're doing it wrong when it comes to software sales. If your business model depends on forcing people to be honest, you're gonna lose. See also RIAA/MPAA's efforts to block mp3 sharing. Well, and in that case what would be the recommendation when you know that the clients are not honest? Can a software company trust another company which is its client, when it sees that the client use pirated Windows, Office, Corel Draw, AutoCad and don't even try to hide that they steal that software? Don't make business with such companies? But what if more than 50% of the local market are companies that use pirated software? Other people have listed a bunch of large companies, I can add Reuters, Microsoft, Sun, Yahoo, and Google to the mix from personal conversations with developers at each of them. If their web pages end with .py and .php or .jsp, the students will see which are the languages used by big companies, and they will learn them first, and not perl. I like the URLS that look like /user/create/ and not like /user/create.php, but I also know that those extensions are a very good marketing tool. Reuters uses Perl to run all of their Fixed Income Pricing. HTTP::Engine is a webserver written in Perl that performs decently well, Catalyst::Engine::Prefork is another. Somone pointed to Siesta which was a mailing list manager but those aren't really very popular I guess there aren't very many students that know what software uses Reuters or Google on their backends. HTTP::Engine depends on IPC::ShareLite and if a user tries to install it under Windows, he receives the message IPC::ShareLite doesn't work under Windows Catalyst::Engine::Prefork also doesn't work under Windows... ... let's see Stock Exchange Trading I havent heard of myself so you I am talking
Re: decline and fall of modperl?
From: David Ihnen dav...@norchemlab.com Why it is bad that a language like PHP is more useful for more programmers? Because then they start thinking they're software engineers instead of just programmers. They get credibility, without having earned it through good engineering. They propagate their half-baked concepts and good enough for what I did before hackery into areas that hurt their clients, cause loss of money, success, and jobs, furthermore lowering the reputation of anybody who claims the title software engineer. This is very true, and this means that PHP creates damage to the good software world, but most programmers don't care about creating good software, and having credibility, but earning money on a short term. It seems that Perl is beaten by this new atitude, and the fact that it is a better language doesn't help too much. You may disagree, or think that is not important. I think it is important on a far deeper cultural level. Of course I agree, but I just tell that Perl doesn't have tools for fighting this. Nobody cares about a contracts for software licences in my country. EXACTLY. So trying to make money on contracts and software licenses is useless. Obfuscating does nothing but try to enforce a software license that will be ignored anyway - so what value does it provide? If the program is hard enough protected, most users won't be able to get its clear source code, so we can say that it is protected. But if we protect it by just a licence, nothing would stop the user to sell it to someone else (theoreticly, of course, not that this thing really happends). The target audience should be the students, the future possible perl programmers. How do you get their ear? Using the same techniques used by PHP, Python... Making it able to run on free shared hosting sites with no root and shell access, and beeing more interested in Windows portability. Perl could be also used in commercial proprietary programs, and unfortunately in some countries it is very hard to earn money from open source. You sell them a solution. This is where the money is. And then you will see that many other users also use it, without paying you money. This is why I said that the software companies prefer Java, because nobody considers that it is something bad if a program made in Java is not open source. Until the company they bought it from vanishes, the source code is lost, they need to make a slight but critical change to the functionality, and find that it is almost completely undoable because its compiled. Most companies don't have an IT department which would be able to understand a source code, and they won't find perl programmers very easy if that code is made in perl anyway. Octavian
Re: [OT] Advocacy (was Re: decline and fall of modperl?)
You are right. Sorry for the last few messages. I think that we all know that there are differences between the software market in different countries, and that it is much harder to promote perl in the countries which are not so much developed. Octavian -- Octavian - Original Message - From: Joe Schaefer To: David Ihnen ; Octavian Râsnita Cc: modperl Sent: Thursday, March 26, 2009 11:20 PM Subject: [OT] Advocacy (was Re: decline and fall of modperl?) Could we PLEASE move this lovely conversation to the advoc...@perl.apache.org mailing list? We have an entire mailing list dedicated to baloney of this sort; please use it so the rest of us trying to provide this little community with meaningful software and support don't have to wade through it. Thanks! -- From: David Ihnen dav...@norchemlab.com To: Octavian Râsnita orasn...@gmail.com Cc: modperl modperl@perl.apache.org Sent: Thursday, March 26, 2009 5:10:58 PM Subject: Re: decline and fall of modperl? Octavian Râsnita wrote: From: Rolf Banting Functions are first class citizens in Perl - so you get functional programming built in. You don't in Java. Even the newer perl modules on cpan started to use OOP, and I guess this is because OOP is better, even though under perl it usually makes the programs run slower. Perl's speed, even under oop, is good enough. OOP makes the libraries easier to maintain and extend. You should well be an advocate of good-enough - thats what the php programmers are all about, right? How are standards of OO quantified and compared? Simple. They should follow the modern standards, standards made by those who have the power to promote their way - Sun, Oracle, IBM, Microsoft. This is because if a student learns C#, and learns Java, he will find easier to learn an OOP style similar to that from Java than a way like the one used in Perl. I can't believe you would say that the particular syntactical constructs used in the object oriented declaration is even slightly relevant to the usability of the language. saying 'package' instead of 'class'? Saying 'use' instead of 'import'? I'm agog. Any language transition involves learning new syntactical constructs for the new environment you're in. And thats the only real difference between The Java/C# 'style' and perl, is it not? THe keyword syntaxes? As for design patterns, perl does them with fewer hoops than the other languages - which is what a learning student needs to learn. And anyway, for the beginners, this is not a big problem. The biggest problem is that perl is harder to learn. The programmers might want to learn a language for a year, and get a job, and after this they hope that they will find time to learn the chosen language better while they have a job. Harder to learn than what? Is there any evidence for this? Yes. Most PHP programmers I know, that also tried to learn Perl told me that PHP is more easy to learn and to use. And C is easier to use than C++, but you don't see anybody going around saying that they should use C to write enterprise applications these days. Unfortunately I think some are trying to be written in php. There are very many recent books that teach Perl. Why is recent important? The language features haven't changed much so why would the learning resources? Because Catalyst is very fast changing, DBIx::Class the same, HTML::FormFu the same, CGI::Application the same, because Moose appeared, but there are no very many books that talk about them (or other modules). The moment a fast-changing thing is documented, the documentation is out of date. Its a fundamental problem with dead-tree editions of anything. I'm not surprised that there aren't books on these things. Mostly because the documentation is readily available online and anything written is obsolete before it hits the presses. Perl is great, but I think it will remain a niche language for a long period, even though we know that we can do everything with it. The truth is that we can't do really everything with it. There are applications made in Java that do annimation, graphic games, search engines, and many other things that we can't do only by using perl, without C or other languages. Yes, we cannot do everything with perl. But that is okay. What is important to remember is what we CAN do with perl. Even when you have a high-performance graphical processor module written in C/C++/Java, the business rules, glue, and associated logic that is not fine-grained performance critical are best implemented in a scripting language just like Perl. Implementing your application in C++ because you need *some* fine-grained performance critical code is, in my experience, foolish. Yes, implement your critical code in a tight
Re: decline and fall of modperl?
Octavian Rasnita wrote: It seems that Perl is beaten by this new atitude, and the fact that it is a better language doesn't help too much. Haven't we all learnt from Bush, that the best people don't always make President? If the program is hard enough protected, most users won't be able to get its clear source code, so we can say that it is protected. But if we protect it by just a licence, nothing would stop the user to sell it to someone else (theoreticly, of course, not that this thing really happends). I think we should just agree that there are 2 styles of businesses: 1. Linux-style: devalue the privacy of your source code. Let people buy your product because of the code quality, and the ability to make minor changes on your own responsibility. 2. Windows-style: your code is mystery, but your program works anyway and your support is good. And that's good enough for people to buy your product. Using Perl doesn't mean we must adopt Linux-style biz. There are other environments, which thrive on Windows-style biz. Luckily Perl does support this to some extend.
Re: modperl or php? Re: decline and fall of modperl?
Great to hear that! My experience, that programs written in application frameworks usually take more memory and CPU resources to run, is based on old versions. The new ones may have been improved very much in this area. PV On Fri, Mar 27, 2009 at 1:21 AM, Rolf Schaufelberger r...@plusw.de wrote: Hi, daily traffic: 20,000 - 100,000 unique sessions (medium sites) = Php + an efficient caching system = modperl, but not based on Mason or such application toolkits Am I don't agree: I had a website running with 20.000 visitors/day, build with Mason (MasonX::Webapp), split into 180 frontend apache an 20 mod_perl backend apache , server load was below 1, on a 1 GB hardware. And I had no need to enable any of mason's caching or performance feature 9staice source etc). Rolf Schaufelberger
Re: decline and fall of modperl?
FWIW, I'm enjoying this diverting discussion and think it should stay here. Clearly, its an organic outgrowth meeting a need of the other business in this list. On Fri, 2009-03-27 at 10:35 +0200, Octavian Rasnita wrote: From: David Ihnen en the newer perl modules on cpan started to use OOP, and I guess this is because OOP is better, even though under perl it usually makes the programs run slower. Perl's speed, even under oop, is good enough. OOP makes the libraries easier to maintain and extend. You should well be an advocate of good-enough - thats what the php programmers are all about, right? I know this, but the perl docs tell the truth that perl OOP is slower than functional perl and the beginners don't like to hear that using OOP under Perl make it slower. Its also worth noting that it is often the case that using an efficient OO package of, say 500 lines of code, will obviate the need for maybe 1,000 lines of procedural code that might be needed to do the same thing. Its not always a simple comparison. Doing y = x + y in OO perl is certainly a losing strategy, but manipulating a large XML document in OO perl is almost certainly better than a procedural approach. Somewhat off topic, I've noticed that nobody has yet mentioned Perl's fabulous Inline module. On more than one occasion I've had to resort to Inline::Java to take advantage of some proprietary jar or standard java class that does some obscure jiggery-pokery so deeply buried in vast tangled class hierarchies that it can't be found, fathomed or faked by mortal man. Just write a simple java shim to massage data transfer between java and perl domains and you're off to the races! If the off-loaded work is big enough the performance hit is negligible. (The first hit takes some time to instantiate a java interpreter thread but everything after that runs quick as a bunny.) I've also had to invoke perl inside php on occasion because the available php html parser was just too clunky to do what I needed. (that was in a Drupal site) Once I learned that trick my toughest php programming challenge was to not use it everywhere. :-) The barriers between languages aren't insuperable; you needn't swing a project to one language just to use some key package you need/want in that language. One last gratuitous point in passing is that one of my chief gripes about php (chiefly, but also Java with its ever-growing uncountable infinity of classes and interfaces) is that php is TOO function-rich. I find I spend a lot of time thumbing through documentation looking for which of the two dozen regex thingies to use in a particular case instead of thinking about the program I'm writing. Perl only has one, really. Although there are more than one way to do things in both perl and php, it seems to me that in perl you can often do it by something as simple as rearranging your brackets while in php you have to suss out the best reserved special function for that particular task if you want to benefit from its inherent efficiencies. My point is that discussions of how easy/difficult it is to learn one language or another rarely come to grips with the real finite cognitive limit of the human mind to keep more than 5 balls in the air at one time. Its really hard to be think creatively about evaluating 5 different strategies when you're forever changing mental contexts to look up a dozen damned functions in some damned index. I've been writing php and perl for about the same length of time but I have never once felt that I understood php. On the other hand I haven't had to consult my Programming Perl book more than a dozen times in the past few years. There needs to be an objective and quantitative measure of ease-of-learning based on empirical measures of how badly beaten up your copy of Programming Perl/PHP/Java/* is per line of code written over time. -- john edstrom edst...@teleport.com
Re: decline and fall of modperl?
- Original Message From: john edstrom edst...@teleport.com To: Octavian Rasnita orasn...@gmail.com Cc: modperl modperl@perl.apache.org Sent: Friday, March 27, 2009 1:13:18 PM Subject: Re: decline and fall of modperl? FWIW, I'm enjoying this diverting discussion and think it should stay here. Clearly, its an organic outgrowth meeting a need of the other business in this list. Anybody whose been here a couple of years knows this discussion is 100% offtopic for this mailing list. Hell, it isn't even topical of the Subject header. That won't stop people who have nothing else to offer the list except for their opinion to mutter onwards, because we tend not to boot people off the list who abuse it unless it is obviously habitual. Comparative analysis of programming languages has nothing whatsoever to do with modperl, or even anything to do with the real needs of this community of users. It's simply an exercise in argumentation based on personal experience alone by people who have absolutely no knowledge of any actual relevant statistics on the subject (assuming there even *are* any such things). On Fri, 2009-03-27 at 10:35 +0200, Octavian Rasnita wrote: From: David Ihnen en the newer perl modules on cpan started to use OOP, and I guess this is because OOP is better, even though under perl it usually makes the programs run slower. Perl's speed, even under oop, is good enough. OOP makes the libraries easier to maintain and extend. You should well be an advocate of good-enough - thats what the php programmers are all about, right? I know this, but the perl docs tell the truth that perl OOP is slower than functional perl and the beginners don't like to hear that using OOP under Perl make it slower. Its also worth noting that it is often the case that using an efficient OO package of, say 500 lines of code, will obviate the need for maybe 1,000 lines of procedural code that might be needed to do the same thing. Its not always a simple comparison. Doing y = x + y in OO perl is certainly a losing strategy, but manipulating a large XML document in OO perl is almost certainly better than a procedural approach. Somewhat off topic, I've noticed that nobody has yet mentioned Perl's fabulous Inline module. On more than one occasion I've had to resort to Inline::Java to take advantage of some proprietary jar or standard java class that does some obscure jiggery-pokery so deeply buried in vast tangled class hierarchies that it can't be found, fathomed or faked by mortal man. Just write a simple java shim to massage data transfer between java and perl domains and you're off to the races! If the off-loaded work is big enough the performance hit is negligible. (The first hit takes some time to instantiate a java interpreter thread but everything after that runs quick as a bunny.) I've also had to invoke perl inside php on occasion because the available php html parser was just too clunky to do what I needed. (that was in a Drupal site) Once I learned that trick my toughest php programming challenge was to not use it everywhere. :-) The barriers between languages aren't insuperable; you needn't swing a project to one language just to use some key package you need/want in that language. One last gratuitous point in passing is that one of my chief gripes about php (chiefly, but also Java with its ever-growing uncountable infinity of classes and interfaces) is that php is TOO function-rich. I find I spend a lot of time thumbing through documentation looking for which of the two dozen regex thingies to use in a particular case instead of thinking about the program I'm writing. Perl only has one, really. Although there are more than one way to do things in both perl and php, it seems to me that in perl you can often do it by something as simple as rearranging your brackets while in php you have to suss out the best reserved special function for that particular task if you want to benefit from its inherent efficiencies. My point is that discussions of how easy/difficult it is to learn one language or another rarely come to grips with the real finite cognitive limit of the human mind to keep more than 5 balls in the air at one time. Its really hard to be think creatively about evaluating 5 different strategies when you're forever changing mental contexts to look up a dozen damned functions in some damned index. I've been writing php and perl for about the same length of time but I have never once felt that I understood php. On the other hand I haven't had to consult my Programming Perl book more than a dozen times in the past few years. There needs to be an objective and quantitative measure of ease-of-learning based on empirical measures of how badly beaten up your copy of Programming
Re: decline and fall of modperl?
- Original Message From: john edstrom edst...@teleport.com To: Joe Schaefer joe_schae...@yahoo.com Sent: Friday, March 27, 2009 2:21:08 PM Subject: Re: decline and fall of modperl? If you say so. I'll respect that, but I don't agree with it. I already subscribe to about 30 mail lists and won't subscribe to the advocacy list because I have no particular interest in advocacy per se. Seeing it discussed in a context I care about does interest me though. Apache operates on the notion of people volunteering to help make the community's goals come to fruition. The utility of this particular list is that users can communicate with one another to solve common problems, and maybe even offer a patch for the developers to incorporate into the next release. That sort of activity has all but dried up here, and I don't know what the reasons for that are. It could be that the codebase is too good, in the sense that there isn't a lot of stuff that people need fixed. That has happened to other projects at the ASF, and knowing all the hard work Stas Bekman and company put into this project, it may very well be true here. The goal of modperl is to provide access to httpd's guts so people with advanced needs can tweak httpd using a scripting language. Speed is a nice bonus, but not the full story. For example, every email sent to apache.org passes through a mail server that's implemented in mod_perl2. That's very cool IMO; it solved a major scaling problem for Apache, and it's the type of application that wasn't even remotely possible with the 1.x codebase.
Re: decline and fall of modperl?
From: Joe Schaefer joe_schae...@yahoo.com Comparative analysis of programming languages has nothing whatsoever to do with modperl, or even anything to do with the real needs of this community of users. It's simply an exercise in argumentation based on personal experience alone by people who have absolutely no knowledge of any actual relevant statistics on the subject (assuming there even *are* any such things). The original message that started this thread was: One of our customers is doing a detailed review of a mason/modperl ERP app we've built for them since 2001. Prodded by some buzzword-compliant consultants they are expressing concerns that the app's underlying technologies - perl, modperl and mason - are becoming obsolete. They feel that a web application framework must have 'rails' or some other buzzword in its name. Of course this question should be answered with language comparisons, and of course that those answers should be based on our opinions and experience, because if there would be very scientific studies that show which of the languages are modern and which are obsolete, which are good and which are bad, it could be very simple to find the sites with those scientific studies using Google and it wouldn't need to be asked on a mailing list. Here is a good article written by Ovid - Perl 5 is dying: http://use.perl.org/~Ovid/journal/38010?from=rss We should also remember that somebody discovered that perl 5 is dying 9 years ago, and this was the thing that created the idea of perl 6, that should be totally different. Octavian
Re: decline and fall of modperl?
- Original Message From: Octavian Râsnita orasn...@gmail.com To: modperl modperl@perl.apache.org Sent: Friday, March 27, 2009 3:25:44 PM Subject: Re: decline and fall of modperl? From: Joe Schaefer Comparative analysis of programming languages has nothing whatsoever to do with modperl, or even anything to do with the real needs of this community of users. It's simply an exercise in argumentation based on personal experience alone by people who have absolutely no knowledge of any actual relevant statistics on the subject (assuming there even *are* any such things). The original message that started this thread was: One of our customers is doing a detailed review of a mason/modperl ERP app we've built for them since 2001. Prodded by some buzzword-compliant consultants they are expressing concerns that the app's underlying technologies - perl, modperl and mason - are becoming obsolete. They feel that a web application framework must have 'rails' or some other buzzword in its name. Consultants who don't contribute anything to this community aren't our concern- nor should they be. Of course this question should be answered with language comparisons, Hardly. What matters is the quality of the software and whether or not it meets the customer's needs. There's nothing wrong with recommending the right tool for the job, even if the right tool isn't implemented in perl. and of course that those answers should be based on our opinions and experience, because if there would be very scientific studies that show which of the languages are modern and which are obsolete, which are good and which are bad, it could be very simple to find the sites with those scientific studies using Google and it wouldn't need to be asked on a mailing list. Here is a good article written by Ovid - Perl 5 is dying: http://use.perl.org/~Ovid/journal/38010?from=rss We should also remember that somebody discovered that perl 5 is dying 9 years ago, and this was the thing that created the idea of perl 6, that should be totally different. Languages don't die, they aren't people. People will continue to use perl5 for the forseeable future, even after perl 6 is finally released.
Re: decline and fall of modperl?
From: Joe Schaefer joe_schae...@yahoo.com The original message that started this thread was: One of our customers is doing a detailed review of a mason/modperl ERP app we've built for them since 2001. Prodded by some buzzword-compliant consultants they are expressing concerns that the app's underlying technologies - perl, modperl and mason - are becoming obsolete. They feel that a web application framework must have 'rails' or some other buzzword in its name. Consultants who don't contribute anything to this community aren't our concern- nor should they be. If they are consultants, it means that they contribute. The contribution is not only made of code and POD documentation or translations, but also of answers to the questions put by others. Of course this question should be answered with language comparisons, Hardly. What matters is the quality of the software and whether or not it meets the customer's needs. There's nothing wrong with recommending the right tool for the job, even if the right tool isn't implemented in perl. The question wasn't about the quality of perl, but the poster wanted to know if Perl/Mason/mod_perl are obsolete. A language could be very good but obsolete because there are other better tools, or because other tools are prefered even if they are not so good, and it could be easier to find programmers that use those new tools. and of course that those answers should be based on our opinions and experience, because if there would be very scientific studies that show which of the languages are modern and which are obsolete, which are good and which are bad, it could be very simple to find the sites with those scientific studies using Google and it wouldn't need to be asked on a mailing list. Here is a good article written by Ovid - Perl 5 is dying: http://use.perl.org/~Ovid/journal/38010?from=rss We should also remember that somebody discovered that perl 5 is dying 9 years ago, and this was the thing that created the idea of perl 6, that should be totally different. Languages don't die, they aren't people. People will continue to use perl5 for the forseeable future, even after perl 6 is finally released. Die is just an expression that wants to tell that the language is not used by more and more programmers, but by fewer. Octavian
Re: decline and fall of modperl?
- Original Message From: Octavian Râsnita orasn...@gmail.com To: modperl modperl@perl.apache.org Sent: Friday, March 27, 2009 5:26:43 PM Subject: Re: decline and fall of modperl? From: Joe Schaefer The original message that started this thread was: One of our customers is doing a detailed review of a mason/modperl ERP app we've built for them since 2001. Prodded by some buzzword-compliant consultants they are expressing concerns that the app's underlying technologies - perl, modperl and mason - are becoming obsolete. They feel that a web application framework must have 'rails' or some other buzzword in its name. Consultants who don't contribute anything to this community aren't our concern- nor should they be. If they are consultants, it means that they contribute. The contribution is not only made of code and POD documentation or translations, but also of answers to the questions put by others. You're not even in the ballpark. Consultants are hired and fired based on the quality and relevance of the information they provide. They're supposed to make recommendations based on what is in their client's best interests. That's not a contribution to this community nor any other, it is a *paid for* service. A contribution to a *community* would be to offer gratis advice on a mailing list, ostensibly to help the community reach its objectives. Nothing I see in this thread looks like a contribution to the mod_perl community, sorry. Of course this question should be answered with language comparisons, Hardly. What matters is the quality of the software and whether or not it meets the customer's needs. There's nothing wrong with recommending the right tool for the job, even if the right tool isn't implemented in perl. The question wasn't about the quality of perl, but the poster wanted to know if Perl/Mason/mod_perl are obsolete. A language could be very good but obsolete because there are other better tools, or because other tools are prefered even if they are not so good, and it could be easier to find programmers that use those new tools. and of course that those answers should be based on our opinions and experience, because if there would be very scientific studies that show which of the languages are modern and which are obsolete, which are good and which are bad, it could be very simple to find the sites with those scientific studies using Google and it wouldn't need to be asked on a mailing list. Here is a good article written by Ovid - Perl 5 is dying: http://use.perl.org/~Ovid/journal/38010?from=rss We should also remember that somebody discovered that perl 5 is dying 9 years ago, and this was the thing that created the idea of perl 6, that should be totally different. Languages don't die, they aren't people. People will continue to use perl5 for the forseeable future, even after perl 6 is finally released. Die is just an expression that wants to tell that the language is not used by more and more programmers, but by fewer. Usage statistics are irrelevent to the vitality of a language. What's relevant to the perl community is something like how many module maintainers have abandoned their codebases. Do you have any information about how many modules are on CPAN that are no longer supported? And to bring it back to mod_perl, how many of those are Apache modules?
Re: decline and fall of modperl?
On Mar 27, 2009, at 5:08 PM, Joe Schaefer wrote: - Original Message From: Octavian Râsnita orasn...@gmail.com To: modperl modperl@perl.apache.org Sent: Friday, March 27, 2009 5:26:43 PM Subject: Re: decline and fall of modperl? From: Joe Schaefer The original message that started this thread was: One of our customers is doing a detailed review of a mason/ modperl ERP app we've built for them since 2001. Prodded by some buzzword-compliant consultants they are expressing concerns that the app's underlying technologies - perl, modperl and mason - are becoming obsolete. They feel that a web application framework must have 'rails' or some other buzzword in its name. Consultants who don't contribute anything to this community aren't our concern- nor should they be. If they are consultants, it means that they contribute. The contribution is not only made of code and POD documentation or translations, but also of answers to the questions put by others. You're not even in the ballpark. Consultants are hired and fired based on the quality and relevance of the information they provide. They're supposed to make recommendations based on what is in their client's best interests. That's not a contribution to this community nor any other, it is a *paid for* service. A contribution to a *community* would be to offer gratis advice on a mailing list, ostensibly to help the community reach its objectives. Nothing I see in this thread looks like a contribution to the mod_perl community, sorry. I'm not really sure why it wouldn't be a good idea to try and educate consultants about the value of Perl / mod_perl. It seems to be consultants have a lot of influence over what tools get used for projects they work on. The fact that many don't have much if any exposure/knowledge of Perl and mod_perl certainly hurts the Perl community. Discussing the advantages / disadvantages of Perl and mod_perl so that we can all help educate the consultants and institutions we work with about how mod_perl can benefit certain projects seems like a rather important task. Of course this question should be answered with language comparisons, Hardly. What matters is the quality of the software and whether or not it meets the customer's needs. There's nothing wrong with recommending the right tool for the job, even if the right tool isn't implemented in perl. The question wasn't about the quality of perl, but the poster wanted to know if Perl/Mason/mod_perl are obsolete. A language could be very good but obsolete because there are other better tools, or because other tools are prefered even if they are not so good, and it could be easier to find programmers that use those new tools. and of course that those answers should be based on our opinions and experience, because if there would be very scientific studies that show which of the languages are modern and which are obsolete, which are good and which are bad, it could be very simple to find the sites with those scientific studies using Google and it wouldn't need to be asked on a mailing list. Here is a good article written by Ovid - Perl 5 is dying: http://use.perl.org/~Ovid/journal/38010?from=rss We should also remember that somebody discovered that perl 5 is dying 9 years ago, and this was the thing that created the idea of perl 6, that should be totally different. Languages don't die, they aren't people. People will continue to use perl5 for the forseeable future, even after perl 6 is finally released. Die is just an expression that wants to tell that the language is not used by more and more programmers, but by fewer. Usage statistics are irrelevent to the vitality of a language. What's relevant to the perl community is something like how many module maintainers have abandoned their codebases. Do you have any information about how many modules are on CPAN that are no longer supported? And to bring it back to mod_perl, how many of those are Apache modules? It's hard to argue that Latin is on the same footing as English when Latin is only spoken by a tiny handful of people even though it has a lot of great history. Technology, like language, generally lives and dies by its user-base. Usage is also directly related to developer enthusiasm in most cases. A developer isn't going to want to spend time maintaining a module if no one is using it. It's a lot easier to justify spending weeks or months getting a module ready for CPAN if you have some reasonable expectation that a lot of people are going to benefit from it.
Re: decline and fall of modperl?
- Original Message From: David Stewart david.stew...@eviesays.com To: modperl modperl@perl.apache.org Sent: Friday, March 27, 2009 6:39:08 PM Subject: Re: decline and fall of modperl? I'm not really sure why it wouldn't be a good idea to try and educate consultants about the value of Perl / mod_perl. That's called advocacy, and as I said before, there's a mailing list set up for that for people who actually want to *do* some of that instead of issue general gripes on a thread called decline and fall of mod_perl. I don't mean to suggest that such activity is unimportant, just to point out again that it's not topical on a user support list like this one. It seems to be consultants have a lot of influence over what tools get used for projects they work on. The fact that many don't have much if any exposure/knowledge of Perl and mod_perl certainly hurts the Perl community. Discussing the advantages / disadvantages of Perl and mod_perl so that we can all help educate the consultants and institutions we work with about how mod_perl can benefit certain projects seems like a rather important task. [...more advocacy stuff...] It's hard to argue that Latin is on the same footing as English when Latin is only spoken by a tiny handful of people even though it has a lot of great history. Technology, like language, generally lives and dies by its user-base. Usage is also directly related to developer enthusiasm in most cases. A developer isn't going to want to spend time maintaining a module if no one is using it. Having lots of users of your code doesn't necessarily translate to putting food on a developer's dinner table. TicketMaster funded a lot of the work that went into mod_perl2, largely out of their own self- interest, but that is a *contribution* that many of us are thankful for. It's a lot easier to justify spending weeks or months getting a module ready for CPAN if you have some reasonable expectation that a lot of people are going to benefit from it. I would like to think that ego stroking isn't what motivates developers to write perl code. They do it because the perl community is still by and large a gift culture, and if you want to be a full partner in the community you really should pony up to the table and contribute something. Whether or not 10 people use your code or 100,000, if your users are happy and you are approachable regarding bug reports, then the fact that you are *contributing* to intellectual assets a user community means something.
Re: decline and fall of modperl?
On Mar 27, 2009, at 6:17 PM, Joe Schaefer wrote: That's called advocacy, and as I said before, there's a mailing list set up for that for people who actually want to *do* some of that instead of issue general gripes on a thread called decline and fall of mod_perl. I don't mean to suggest that such activity is unimportant, just to point out again that it's not topical on a user support list like this one. Just to clarify, this list is not just for user support, it is a general mod_perl list (as explained in the posting guidelines). There is a separate list for advocacy, but that doesn't mean that these sorts of threads aren't appropriate to be posted here. In fact the posting guidelines specifically ask that people not bring up issues of whether advocacy should be in another list or not. In the end it may be more appropriate to have more technical discussions, such as this, in this list as it will likely attract more informed opinions (as people subscribed here are theoretically practicing mod_perl users). Having lots of users of your code doesn't necessarily translate to putting food on a developer's dinner table. TicketMaster funded a lot of the work that went into mod_perl2, largely out of their own self- interest, but that is a *contribution* that many of us are thankful for. That's certainly true and I was actually thinking about bringing up just this point in my previous post. Another reason to be clear about the technical issues and advantages/disadvantages of mod_perl is to be able get corporate support for continued development. If you've got consultants going around with misguided opinions of mod_perl then there is almost certainly going to be less chance for someone like Ticketmaster to adopt and champion it. I would like to think that ego stroking isn't what motivates developers to write perl code. They do it because the perl community is still by and large a gift culture, and if you want to be a full partner in the community you really should pony up to the table and contribute something. Whether or not 10 people use your code or 100,000, if your users are happy and you are approachable regarding bug reports, then the fact that you are *contributing* to intellectual assets a user community means something. Well, whatever you'd like to think, ego is a big part of a lot of development, however this goes beyond ego. It's more a question of how best to spend your time. Developing well laid-out generalized modules suitable for reuse is almost always much more time consuming than a one-off hack. If you are the only one using the code, then often the one-off hack is going to be the best use of your time. However, if you know a lot of others could benefit with a little (or a lot of) extra work on your part, then you will likely be willing to put in that extra time. I had a professor who helped write one of the lexical analyzers generators. He joked that he had spend five years writing a program to do automatically what it took him two hours to do by hand. He would have been better off for himself to just do it by hand, but creating the general purpose tool was a way to help out the wider community. Such projects aren't sensible if that community isn't large enough to make the investment in time worthwhile.
Re: decline and fall of modperl?
Foo JH wrote: In the academia the general directive in choosing a language would be something to this effect: 1. teach modern language concepts, such as OO 2. minimise the learning curve by way of something easy to teach, easy to learn without having to figure out all the details of programming 3. introduce the students to a language that will make them attractive to the general market You probably have a feel why Perl isn't a strong choice given these objectives. On points 1 2: 1. Perl supports more programming paradigms than Java. 2. You write fewer lines of perl to get things done than you do in Java. There is empirical evidence of this - anyone seen the Software Productivity Group research on programming languages? In general: C - 6 x more productive than assembler Java/C++ - 3 x more productive than C Perl/Python (Ruby/javascript not represented) - 2-3 x more productive than Java/C++ Results are consistent over 2 studies a decade or so apart. Point 3 does scream Java but take a look at this: http://lambda-the-ultimate.org/node/2941 The author laments the ubiquity of Java as the language of choice in education (despite having advocated it himself). On balance he'd go for python but doesn't dismiss Perl out of hand either. I can't convince my own colleagues of the benefits of perl despite the fact I continually produce decent quality s/w faster than they can, when given the opportunity. Folk will see what they expect to see. This was demonstrated by a psychology experiment in the 90's. Subjects were asked to look at a video of 2 football teams passing a football around and count how many times the ball was passed. When asked at the end of the video the answers were pretty accurate. Then they were asked What about the gorilla?. In the middle of the video someone in a gorilla suit walks on, bangs on its chest and walks off. Hardly anyone spots the gorilla.
Re: decline and fall of modperl?
From: David Ihnen dav...@norchemlab.com They know it because everybody tell them so. Most web sites are done in PHP, most job offer for web programmers ask for PHP experience... Then they don't know, they just repeat what others say. So I guess all we can do is repeat what we know from experience, and hope that others repeat it too...? Yes of course, but I usually receive responses like oh, perl, that ugly language? Python's much nicer and Ruby too. Can you do with perl what you can do with Python? And I know that there is a screen reader for Windows and another one for Linux/Solaris which is made in Python, but it would be much harder to do the same thing with perl, so I can't say anything. I think that Perl is the best for web programming and system admins, but Python is better for interacting with the operating systems, especially with Windows, and with programs made in DotNet and Java. So who should pay those PHP programmers in order to motivate them? Somebody who wants a program, and is smart enough to know that the engineers are better choosers of the software language than they are. I don't know too many companies of this kind... And finally, the management of those companies could tell ok, let's use Perl, but they will find that there are no perl programmers available, so they'll be convinced that perl is a language which is not used very much in these days, and that it would cost them more if they would like to create perl programs. Who cares? Hiding source code is valueless. Maybe in your country. In my country 10 euro means too much and actually even 1 euro means too much if the same thing can be got for free, legally or not. You taking it and using it doesn't impact anything, and the companies have to understand that. Its just some ideas and organization, pretending you can keep other people from knowing how you did something just makes it less supportable by anybody - good software can be bad software just because its obfuscated like that. Those who matter will actually pay for your software because they want the support and customization that comes with it. If they're not going to pay up front, they're more likely to pay later - keeping them from using the software at all won't help. So why obfuscate or worry about it? Because the clients pay once when they receive the program, and because the programmers usually don't trust their clients. They think that the IT guys of the client could just get the program, change it and sell it to another company. You get what you pay for I guess. Well, they can get a free support offered for Zend Optimizer (or how it is called the Zend Decoder). Free support as in open-source community stuff? Or as in a commercial company spending their time to help you with something that they don't get paid for? Zend is paid for, because they offer the Zend Optimizer for free and ask for money just for the Zend Encoder, so those programmers that want protection should buy it from Zend, but if they want this, they could have support for it from the hosting companies. A perl programmer doesn't need to pay for Filter::Crypto. He could use it for free, but the hosting companies won't offer support for it. Of course they care. If the same thing can be done cheaper using PHP, they will surely choose PHP. (The quality doesn't matter, because here the things are so fast changing, and the easiness of maintenance doesn't matter for most, because who knows what will happen after a few years. Experience says in a few years, you'll want to augment and enhance your application. But they don't have the experience, eh? Well, if they want throw-away programs they'll get throw-away programs. And have to pay for them over and over again. The savings are false. The companies who chose wisely will get further. But that is a subtle pressure in the market - perhaps even less so than the idea being implemented - thus making our advocacy more or less moot. A working program is all that matters to an end user, not a good or badly engineered program. How can we convince them that the underlying engineering is important? Short of organized crime techniques at least. :) That's true. The languages that don't require wiseness for beeing appreciated have a big advantage these days. Without wiseness, perl can't be appreciated, and this is a big minus, because these days there are much more programmers and much more applications users than 15 years ago, and the inteligence level of all the programmers of the world decreases if the number of them increases. I've seen that the newbies always want recommendations, and think that there should be a recommended way of doing things, a best way. Do you think there is a way to stop them from thinking that? Yes, by offering them not a single solution like Python pretends to do, but a few solutions, with recommendations for each
Re: decline and fall of modperl?
hey On 3/25/2009 11:24 PM, Foo JH wrote: You probably have a feel why Perl isn't a strong choice given these objectives. hmm ... i'm not sure about your second point. it's a somewhat arbitrary example, but look at a 'hello world' in several languages. perl is definitely on the easy side to teach [and understand]. of course, once you get to TMTOWTDI, it's like teaching creative writing ... There's outright protection, there's deterrance, and there's leaving the door open for every bad boy to muck it up. well, sometimes leaving the door open means that someone else will fix something too. it does happen that the glass is half full sometimes ... -- \js
Re: decline and fall of modperl?
On Thu, 26 Mar 2009 08:55:45 -0400, john saylor jsay...@liaison-intl.com wrote: of course, once you get to TMTOWTDI, it's like teaching creative writing And thus, the beauty of it. :) -- ispy++
Re: decline and fall of modperl?
From: Rolf Banting Foo JH wrote: In the academia the general directive in choosing a language would be something to this effect: 1. teach modern language concepts, such as OO 2. minimise the learning curve by way of something easy to teach, easy to learn without having to figure out all the details of programming 3. introduce the students to a language that will make them attractive to the general market You probably have a feel why Perl isn't a strong choice given these objectives. On points 1 2: 1. Perl supports more programming paradigms than Java. 2. You write fewer lines of perl to get things done than you do in Java. 1. I don't know what it means that perl supports more paradigms than Java, but I know that the Java / C# OOP style is usually considered a much complete and better standard than one used by Perl. Java / DotNet support interfaces, so the classes they create respect the contracts better, while in perl world, the programmer is free, and nobody points a shotgun to him in order to force him to do it. Java and C# uses a dot notation for separating the classes when using the OOP style, and even Template-Toolkit uses it, but perl uses something else. 2. It is right that perl is probably one of the most productive languages, because it requires to write very little code, for doing very many things. But for doing the same thing, Ruby and Python can use sometimes even less code, because they don't use so much punctuation and funny chars. And anyway, for the beginners, this is not a big problem. The biggest problem is that perl is harder to learn. The programmers might want to learn a language for a year, and get a job, and after this they hope that they will find time to learn the chosen language better while they have a job. We could say that perl would be really great for these days if we could say about it something like: - It is the most easy to learn language even by the most stupid programmers. - It can create portable programs that can run everywhere, under Windows, Mac, Linux, shared hosting web sites that don't offer root and shell access... - The source code of the programs can be hidden. - There are very many recent books that teach Perl. - Perl is chosen by bigger companies like IBM, Oracle, Microsoft, Sun, Yahoo, Google, SAP. - The popular sites like Twitter, Digg, Facebook, MySpace, Wikipedia, are powered by perl. - There are important other software made in Perl which are used much these days, like a mailing list manager, a web server, financial charting software, stock exchange trading applications, etc. ...and other things like these. But unfortunately in the last years I've seen only reports about the decreasing number of sites that use Perl. Octavian
Re: decline and fall of modperl?
Foo JH wrote: David Ihnen wrote: I think you've got it right there. We've got to get perl taught in schools. That means perl experts need to be in teaching. And I have a suspicion that perl doesn't appeal to the pure computer scientist very well - these are the people who invented hard typed languages, after all. In the academia the general directive in choosing a language would be something to this effect: 1. teach modern language concepts, such as OO 2. minimise the learning curve by way of something easy to teach, easy to learn without having to figure out all the details of programming 3. introduce the students to a language that will make them attractive to the general market You probably have a feel why Perl isn't a strong choice given these objectives. 1. Perl does OO quite well. 2. Perl doesn't force you to learn all about typing and match all that together, which is admittedly what gives me the biggest problems in typed languages (admittedly because i'm such a experienced loosely typed programmer) Thus making the language a shorter learning curve, IMO. A misplaced ; is as much a problem in most any language, for details. 3. The general market will find perl more attractive with more trained perl programmers entering the market... if whoever has the most leverage wins we're dooomed, DOOMED I TELL YOU! no, not really. ;) I want to see people starting new companies and new technologies with perl, instead of the likes of Java and PHP. Set up the students to make their own market - not fit into the slots of the current one - the academia is always behind the time there. Maybe it was better when they taught things like Modula-2 - not because they think you're going to use it in your job - but because you need to learn the patterns and processes of programming. Perl was popular in the days when the people who go into software courses do it for the sake of pure interest. These are the people who are contented with Emacs or VIM, as long as they get to work with the codes. I suppose we need more programmers than those programmers who are just interested in coding? I never met a good programmer who wasn't intrinsically interested in it. Half of today's CompSci students are people who stumble in because they haven't figured things out in life. The problem is made worse by Visual Studio and Eclipse. I remember how Java was a painful experience before someone finally put up a IDE that aids code visualisation and object description. Do we need to help those half of students into programming? Hm. Wash'm out! My personal belief is that Perl MUST move with the times. It's an incredibly uphill task to change the market's mindset without a commercial budget. I Agree. Who has the time when not being paid? I place my bets on Perl6. It's regrettably a slow process, but it's the only sexy thing available on hand. I agree. I have great optomism for perl 6's hit on the market and how it will refresh the image of perl worldwide. Pay them to do it in perl, and after they get through the learning curve they'll probably be much happier with it. Half the developers aren't the type who can appreciate a good language. They can develop intensively for 5 years and they STILL haven't figured out what is Regex. Trust me on this! *cries* Say it ain't so, man! Who cares? Hiding source code is valueless. You haven't met the China folks have you? :) No. What do they do in China with open code like open source code? There's outright protection, there's deterrance, and there's leaving the door open for every bad boy to muck it up. Being able to analyze and apply a direct fix to code that is malfunctioning is of such high value that making it impossible is a serious handicap. I keep thinking they're ashamed of their code thats why they want to hide it. David
Re: decline and fall of modperl?
On Thu, Mar 26, 2009 at 3:44 PM, Octavian Râsnita orasn...@gmail.comwrote: *From:* Rolf Banting rolf.b...@gmail.com Foo JH wrote: In the academia the general directive in choosing a language would be something to this effect: 1. teach modern language concepts, such as OO 2. minimise the learning curve by way of something easy to teach, easy to learn without having to figure out all the details of programming 3. introduce the students to a language that will make them attractive to the general market You probably have a feel why Perl isn't a strong choice given these objectives. On points 1 2: 1. Perl supports more programming paradigms than Java. 2. You write fewer lines of perl to get things done than you do in Java. 1. I don't know what it means that perl supports more paradigms than Java, but I know that the Java / C# OOP style is usually considered a much complete and better standard than one used by Perl. Functions are first class citizens in Perl - so you get functional programming built in. You don't in Java. How are standards of OO quantified and compared? Java / DotNet support interfaces, so the classes they create respect the contracts better, while in perl world, the programmer is free, and nobody points a shotgun to him in order to force him to do it. Java and C# uses a dot notation for separating the classes when using the OOP style, and even Template-Toolkit uses it, but perl uses something else. C++ uses '::' 2. It is right that perl is probably one of the most productive languages, because it requires to write very little code, for doing very many things. But for doing the same thing, Ruby and Python can use sometimes even less code, because they don't use so much punctuation and funny char And anyway, for the beginners, this is not a big problem. The biggest problem is that perl is harder to learn. The programmers might want to learn a language for a year, and get a job, and after this they hope that they will find time to learn the chosen language better while they have a job. Harder to learn than what? Is there any evidence for this? We could say that perl would be really great for these days if we could say about it something like: - It is the most easy to learn language even by the most stupid programmers. It is easy to learn! - It can create portable programs that can run everywhere, under Windows, Mac, Linux, shared hosting web sites that don't offer root and shell access. - The source code of the programs can be hidden. - There are very many recent books that teach Perl. Why is recent important? The language features haven't changed much so why would the learning resources? - Perl is chosen by bigger companies like IBM, Oracle, Microsoft, Sun, Yahoo, Google, SAP. - The popular sites like Twitter, Digg, Facebook, MySpace, Wikipedia, are powered by perl. - There are important other software made in Perl which are used much these days, like a mailing list manager, a web server, financial charting software, stock exchange trading applications, etc. I know of perl CORBA applications that have been responsible for charging literally millions of real-time short messages in telecomms networks in Latin America. ...and other things like these. But unfortunately in the last years I've seen only reports about the decreasing number of sites that use Perl. Octavian Use of perl is declining - but not due to lack of technical merit. Fashions change.
Re: [m_p] Re: decline and fall of modperl?
From: Walter Pienciak wpien...@thunderdome.ieee.org I usually lurk on this list, but I could not disagree more with this assertion that perl is somehow harder to learn. This might be because you are thinking to the american or western european market. But think about those many programmers that don't know english, and don't have books translated in their languages, but do have very many books for Java, PHP and DotNet translated. Do you still think that Perl is so easy to learn? I'm not a language ideologue; I use Perl because it lets me get my job done with a minimum of baggage -- and because it's proven itself: it doesn't get in the way of getting actual work done. I also use perl for this reason, but as I said, we, the perl programmers have good reasons for loving perl, so we are not very interesting in this discussion. What would be more interesting would be to find why the new kiddies that intend to learn programming are not extraordinary excited about Perl, but love more PHP, Ruby, Python. I've not come across a language that is better at allowing someone to be quickly productive in it. I believe that's due to the flexibility of syntax that we all know. Declarative, object-oriented, sub main(), spaces/tabs, style -- hey, it's all good. Vi, emacs, pico, ex, Notepad, Eclipse -- whatever. Just pick up your favorite environment and go to work! This is also true for C#, Java, PHP, Python, Ruby, but some of them have a nicer and powerful OOP, and they can be also used with Notepad and executed/compiled in a command line, but some of them also have better editors. My experience is that a person's early Perl work is often structured and coded in ways that map closely to the person's background in other languages -- and leans heavily on constructs already familiar to them -- but that as time goes by, a more Perlish flow develops as they learn more details of the language. The Perl community is also an open one, and that culture is desirable to me as something consistent with our team culture. Too bad that Perl's dependent on more other things like C code, because many cpan modules use C code, and it is hard to find their bugs if they can't pass all the tests. Perl also requires Unix knowledge even for those who use it only under Windows. There are very many programmers that know only to make programs with PHP, without even knowing how to configure crontab, and of course, without knowing C or too many things about Linux. They just know how to upload their code on an FTP site, and they can do their job fine. If a perl programmer would know just perl, and how to upload the files on an FTP server... I don't think that programmer will be able to do something useful. This is not an advantage of Perl. Perl is targeted to more inteligent programmers so for the others it is not a very good tool. Is it all things for all folks? Oh, hell no. If I had to lead a multi-hundred-person team of widely varying or potentially dubious experience -- perhaps on another continent -- coding a single large project . . . well, at that point the flexibility arguably becomes an issue. If you need to rigoriously control the minutiae to keep a large team and its output consistent -- variable and method naming SHALL be done this exact way, for example -- or your CIO religiously/blindly follows some research firm that says this or that is enterprise class, well, okay. Aha. Well, very many (if not the majority) of the software companies in my country do outsourcing for other software companies from USA and other western european countries. They need to cooperate with the branches of those american companies from all over the world. They need to work in wide temporary teams with people they don't know, that have another native language, and make sure they all create a good product. I think it could be very hard to promote Perl in those companies. Octavian
Re: decline and fall of modperl?
From: Rolf Banting Functions are first class citizens in Perl - so you get functional programming built in. You don't in Java. Even the newer perl modules on cpan started to use OOP, and I guess this is because OOP is better, even though under perl it usually makes the programs run slower. I guess that today there are no many students that are taught in schools that the functional type of programming is good... How are standards of OO quantified and compared? Simple. They should follow the modern standards, standards made by those who have the power to promote their way - Sun, Oracle, IBM, Microsoft. This is because if a student learns C#, and learns Java, he will find easier to learn an OOP style similar to that from Java than a way like the one used in Perl. And anyway, for the beginners, this is not a big problem. The biggest problem is that perl is harder to learn. The programmers might want to learn a language for a year, and get a job, and after this they hope that they will find time to learn the chosen language better while they have a job. Harder to learn than what? Is there any evidence for this? Yes. Most PHP programmers I know, that also tried to learn Perl told me that PHP is more easy to learn and to use. We could say that perl would be really great for these days if we could say about it something like: - It is the most easy to learn language even by the most stupid programmers. It is easy to learn! The core language, yes, but in order to prove its advantage, the programmer also needs to know how to use hundreads of CPAN modules, and with all those modules, it is much harder to learn, because it requires to learn how to get them, how to compile them, how to fix the errors they give when trying to install them, and finally the programmer will find that some of the good and recommended perl modules from CPAN aren't even portable under Windows. Without the CPAN modules, perl is much lower level than PHP, and it isn't so productive anymore. There are very many recent books that teach Perl. Why is recent important? The language features haven't changed much so why would the learning resources? Because Catalyst is very fast changing, DBIx::Class the same, HTML::FormFu the same, CGI::Application the same, because Moose appeared, but there are no very many books that talk about them (or other modules). There are however very many perl books that teach how to use CGI.pm, how to print Content-Type: text/html\n\n;... and of course that if a beginner programmer will start to read them, he will think that perl is obsolete, even though it is not true. - There are important other software made in Perl which are used much these days, like a mailing list manager, a web server, financial charting software, stock exchange trading applications, etc. I know of perl CORBA applications that have been responsible for charging literally millions of real-time short messages in telecomms networks in Latin America. From the point of view of students, this is very little relevant. Is that company very well known? Does it has advertising on MTV? or at least CNN to be well known in the entire world? Because if it is not, the students will see that some pages from google.com have an url that ends with .py and not .pl, and this means a lot for them and for the language they will choose. Perl is great, but I think it will remain a niche language for a long period, even though we know that we can do everything with it. The truth is that we can't do really everything with it. There are applications made in Java that do annimation, graphic games, search engines, and many other things that we can't do only by using perl, without C or other languages. Octavian
Re: decline and fall of modperl?
From: Joel Bernstein j...@fysh.org - It is the most easy to learn language even by the most stupid programmers. I'd rather it were optimised for competent programmers. Sorry, I just don't see the value here. Stupid programmers are part of the problem. I don't understand. What is the problem? That perl is useless for most programmers because they are stupid? The majority of programmers will be always less intelligent than those few very inteligent ones. Why it is bad that a language like PHP is more useful for more programmers? - It can create portable programs that can run everywhere, under Windows, Mac, Linux, shared hosting web sites that don't offer root and shell access... Perl programs are typically extremely portable, and perl runs on many more platforms than those you have listed. Shared hosting websites ought to be able to run Perl applications uploaded with a local::lib tree and so on. I've tried to install some perl modules under Windows and I couldn't do it. Then I found that they can't run under Windows. This doesn't mean portability. I have also tried to use Local::Lib but very many modules use to give errors when trying to install them using -MCPAN -e ... and I didn't know how to use this syntax but also use force like in cpan force install ModuleName (Please tell me if you know how) - The source code of the programs can be hidden. No. This issue needs to be solved through contractual means. There are options to limit the ease with which your code can be recovered but they don't raise the bar very far. And more importantly they aren't solving the right problem. If you can't make money on new development, support contracts, training etc, maybe your business model is flawed. You don't know how things work in other countries. Nobody cares about a contracts for software licences in my country. - Perl is chosen by bigger companies like IBM, Oracle, Microsoft, Sun, Yahoo, Google, SAP. This one's solved. More than half of those companies are publicly documented to use Perl. Possibly not to support their core products, but still, Perl. Maybe, but who knows this? The target audience should be the students, the future possible perl programmers. - The popular sites like Twitter, Digg, Facebook, MySpace, Wikipedia, are powered by perl. There are popular sites like BBC News, Vox, Ticketmaster, Shopzilla, Takkle, BBC iPlayer, Editgrid, IUseThis, YouPorn, MighTyV and so on. Mostly using Catalyst. Some of those definitely exist in the web 2.0 space you seem to be focussing on. Is there some cognitive dissonance here on my part, in that the sites you list are mostly particularly news-worthy ones? I think the list I put out is pretty impressive and is certainly not exhaustive. Yes, as I said, if we want perl to be really the best for most programmers, it would be important to promote it for the new programmers, and they are the teenagers, and those sites target to them. For them perl shouldn't appear as classic mahogany furniture, but as cool nice coloured plastic, because otherwise it would appear as old and boring while RoR and Python will sound much better. - There are important other software made in Perl which are used much these days, like a mailing list manager, a web server, financial charting software, stock exchange trading applications, etc. Not sure how to address these. I've seen a MLM in Perl (Siesta) but people didn't want to hack on it. Mailman works well enough for most people's needs. Oh yes, but it is made in Python, and some programmers might find that even in the field of mailing list managers we passed from Majordomo made in perl to Mailmain made in Python... maybe because Python is better... not? There's also good charting support on the CPAN, etc. Can you give examples of open source financial analysis, stock trading etc applications in other languages? Why should they be open source? Perl could be also used in commercial proprietary programs, and unfortunately in some countries it is very hard to earn money from open source. This is why I said that the software companies prefer Java, because nobody considers that it is something bad if a program made in Java is not open source. Octavian
Re: decline and fall of modperl?
Octavian Râsnita wrote: *From:* Rolf Banting mailto:rolf.b...@gmail.com Functions are first class citizens in Perl - so you get functional programming built in. You don't in Java. Even the newer perl modules on cpan started to use OOP, and I guess this is because OOP is better, even though under perl it usually makes the programs run slower. Perl's speed, even under oop, is good enough. OOP makes the libraries easier to maintain and extend. You should well be an advocate of good-enough - thats what the php programmers are all about, right? How are standards of OO quantified and compared? Simple. They should follow the modern standards, standards made by those who have the power to promote their way - Sun, Oracle, IBM, Microsoft. This is because if a student learns C#, and learns Java, he will find easier to learn an OOP style similar to that from Java than a way like the one used in Perl. I can't believe you would say that the particular syntactical constructs used in the object oriented declaration is even slightly relevant to the usability of the language. saying 'package' instead of 'class'? Saying 'use' instead of 'import'? I'm agog. Any language transition involves learning new syntactical constructs for the new environment you're in. And thats the only real difference between The Java/C# 'style' and perl, is it not? THe keyword syntaxes? As for design patterns, perl does them with fewer hoops than the other languages - which is what a learning student needs to learn. And anyway, for the beginners, this is not a big problem. The biggest problem is that perl is harder to learn. The programmers might want to learn a language for a year, and get a job, and after this they hope that they will find time to learn the chosen language better while they have a job. Harder to learn than what? Is there any evidence for this? Yes. Most PHP programmers I know, that also tried to learn Perl told me that PHP is more easy to learn and to use. And C is easier to use than C++, but you don't see anybody going around saying that they should use C to write enterprise applications these days. Unfortunately I think some are trying to be written in php. There are very many recent books that teach Perl. Why is recent important? The language features haven't changed much so why would the learning resources? Because Catalyst is very fast changing, DBIx::Class the same, HTML::FormFu the same, CGI::Application the same, because Moose appeared, but there are no very many books that talk about them (or other modules). The moment a fast-changing thing is documented, the documentation is out of date. Its a fundamental problem with dead-tree editions of anything. I'm not surprised that there aren't books on these things. Mostly because the documentation is readily available online and anything written is obsolete before it hits the presses. Perl is great, but I think it will remain a niche language for a long period, even though we know that we can do everything with it. The truth is that we can't do really everything with it. There are applications made in Java that do annimation, graphic games, search engines, and many other things that we can't do only by using perl, without C or other languages. Yes, we cannot do everything with perl. But that is okay. What is important to remember is what we CAN do with perl. Even when you have a high-performance graphical processor module written in C/C++/Java, the business rules, glue, and associated logic that is not fine-grained performance critical are best implemented in a scripting language just like Perl. Implementing your application in C++ because you need *some* fine-grained performance critical code is, in my experience, foolish. Yes, implement your critical code in a tight language. But when most of the application just comes down to glue, field name translation, and rules checking - this is better scripted than coded in a compiled language. I've wasted tens of thousands of dollars of my employers time compiling and debugging because of the application's shortsighted architecture put many of the business rules in C++ instead of a script like perl! (it was all the worse because at an arbitrary divider, some of the rules WERE in a not-quite-perl like configuration language - if they had taken it all the way a job of months would have taken weeks) It was quite a mind-blow when I realized that the c++ application that took a gig of memory *per process* to run that I and my coworkers struggled with making behave for so long came down to something that could have been implemented with daemontools, a WSDL checker module, DBI::Oracle, and a passel of business rule implementation classes. (Turns out the windows on that building don't open...) Playing nicely with other applications is merely
[OT] Advocacy (was Re: decline and fall of modperl?)
Could we PLEASE move this lovely conversation to the advoc...@perl.apache.org mailing list? We have an entire mailing list dedicated to baloney of this sort; please use it so the rest of us trying to provide this little community with meaningful software and support don't have to wade through it. Thanks! From: David Ihnen dav...@norchemlab.com To: Octavian Râsnita orasn...@gmail.com Cc: modperl modperl@perl.apache.org Sent: Thursday, March 26, 2009 5:10:58 PM Subject: Re: decline and fall of modperl? Octavian Râsnita wrote: From: Rolf Banting Functions are first class citizens in Perl - so you get functional programming built in. You don't in Java. Even the newer perl modules on cpan started to use OOP, and I guess this is because OOP is better, even though under perl it usually makes the programs run slower. Perl's speed, even under oop, is good enough. OOP makes the libraries easier to maintain and extend. You should well be an advocate of good-enough - thats what the php programmers are all about, right? How are standards of OO quantified and compared? Simple. They should follow the modern standards, standards made by those who have the power to promote their way - Sun, Oracle, IBM, Microsoft. This is because if a student learns C#, and learns Java, he will find easier to learn an OOP style similar to that from Java than a way like the one used in Perl. I can't believe you would say that the particular syntactical constructs used in the object oriented declaration is even slightly relevant to the usability of the language. saying 'package' instead of 'class'? Saying 'use' instead of 'import'? I'm agog. Any language transition involves learning new syntactical constructs for the new environment you're in. And thats the only real difference between The Java/C# 'style' and perl, is it not? THe keyword syntaxes? As for design patterns, perl does them with fewer hoops than the other languages - which is what a learning student needs to learn. And anyway, for the beginners, this is not a big problem. The biggest problem is that perl is harder to learn. The programmers might want to learn a language for a year, and get a job, and after this they hope that they will find time to learn the chosen language better while they have a job. Harder to learn than what? Is there any evidence for this? Yes. Most PHP programmers I know, that also tried to learn Perl told me that PHP is more easy to learn and to use. And C is easier to use than C++, but you don't see anybody going around saying that they should use C to write enterprise applications these days. Unfortunately I think some are trying to be written in php. There are very many recent books that teach Perl. Why is recent important? The language features haven't changed much so why would the learning resources? Because Catalyst is very fast changing, DBIx::Class the same, HTML::FormFu the same, CGI::Application the same, because Moose appeared, but there are no very many books that talk about them (or other modules). The moment a fast-changing thing is documented, the documentation is out of date. Its a fundamental problem with dead-tree editions of anything. I'm not surprised that there aren't books on these things. Mostly because the documentation is readily available online and anything written is obsolete before it hits the presses. Perl is great, but I think it will remain a niche language for a long period, even though we know that we can do everything with it. The truth is that we can't do really everything with it. There are applications made in Java that do annimation, graphic games, search engines, and many other things that we can't do only by using perl, without C or other languages. Yes, we cannot do everything with perl. But that is okay. What is important to remember is what we CAN do with perl. Even when you have a high-performance graphical processor module written in C/C++/Java, the business rules, glue, and associated logic that is not fine-grained performance critical are best implemented in a scripting language just like Perl. Implementing your application in C++ because you need *some* fine-grained performance critical code is, in my experience, foolish. Yes, implement your critical code in a tight language. But when most of the application just comes down to glue, field name translation, and rules checking - this is better scripted than coded in a compiled language. I've wasted tens of thousands of dollars of my employers time compiling and debugging because of the application's shortsighted architecture put many of the business rules in C++ instead of a script like perl! (it was all the worse because at an arbitrary divider, some of the rules WERE in a not-quite-perl like configuration language - if they had taken it all the way a job of months would have taken weeks) It was quite a mind-blow when I realized that the c++ application that took a gig
Re: decline and fall of modperl?
Rolf Banting wrote: 1. Perl supports more programming paradigms than Java. Agreed. The problem is with perception. People identify Perl as a procedural language, and strongly typed languages (ie C#, Java) as modern languages enforcing modern concepts. We all know that's isn't entirely true of course. But that's the perception. 2. You write fewer lines of perl to get things done than you do in Java. I probably should have elaborated on this point. By way of 'minimise the learning curve', I mean an elaborate IDE which helps the user focus on key algorithms. Without the IDE, I would think programming Java is more unwieldy than Perl. But suddenly with Eclipse, it's all about click here and there, and having the system figure out some of the minor stuff for you. Point 3 does scream Java but take a look at this: I could be mistaken here, since I'm only writing from the perspective of my local context. It's like the old buy-IBM mentality: nobody gets fired for buying IBM and have it fail. Here, no lecturer will be blamed if he were to train students on VB.NET/ Java, only to see the language fall out of favour.
Re: decline and fall of modperl?
Octavian Râsnita wrote: 1. I don't know what it means that perl supports more paradigms than Java, but I know that the Java / C# OOP style is usually considered a much complete and better standard than one used by Perl. Java / DotNet support interfaces, so the classes they create respect the contracts better, while in perl world, the programmer is free, and nobody points a shotgun to him in order to force him to do it. Perl is a funny animal. It doesn't have a formal support for interfaces, but it suppports multiple class inheritance. It also has - for a very long time now - support for closures, which I find very interesting (few Java developers even heard of it). Agreeably, Perl is neutral enough to let bad boys ignore the 'contracts' aka interfaces. But I would say that it's more of a feature (some would use the word 'beauty'). I do acknowledge there's some pain in this philosophy though. There's always a workaround to enforce things if you want it to. One of the things I really like about Perl's classes is how there is more than 1 way to mark a class: 1. As a reference to a hash 2. As a reference to a scalar 3. I think there's more, but I can't remember offhand. Each of them has its own advantages. Java and C# uses a dot notation for separating the classes when using the OOP style, and even Template-Toolkit uses it, but perl uses something else. There's a worse one I hear about. PHP is going to use '/'! Personally, I would think little whether the language uses . or ::. It's like saying cars in Japanese adverts are white, and so are Korean. So Chinese cars should be so. As long as they dun use some garish colour, we should all hold hands and sing Auld Lang Syne. And anyway, for the beginners, this is not a big problem. The biggest problem is that perl is harder to learn. The programmers might want to learn a language for a year, and get a job, and after this they hope that they will find time to learn the chosen language better while they have a job. Human mentality will usually opt for the path of least resistance. In other words, if they learn Java today, they will look for a bigger Java job tomorrow. Only bosses have the power to wave their hands and say 'You do not want Java. You want to master Perl'. We could say that perl would be really great for these days if we could say about it something like: - It is the most easy to learn language even by the most stupid programmers. They have already done that. It's called Visual Basic. :) - It can create portable programs that can run everywhere, under Windows, Mac, Linux, shared hosting web sites that don't offer root and shell access... Lose out to expensive marketing folks from Java. - The source code of the programs can be hidden. Tough argument. No dynamic language can boast the same ease of 'hidden' codes like Java/ C#. There's hope via Komodo though. - There are very many recent books that teach Perl. Not recent enough. Wrox releases new C# books as soon as Microsoft finds a new reason to launch a new .Net framework. - Perl is chosen by bigger companies like IBM, Oracle, Microsoft, Sun, Yahoo, Google, SAP. And Blackboard too! - There are important other software made in Perl which are used much these days, like a mailing list manager, a web server, financial charting software, stock exchange trading applications, etc. I know it works, but the exe file created is huge, compared to a C# executable. It also takes longer to execute too. The truth of the matter is: the bulk of C#'s libraries are happily hidden away in the Windows folder. We need to find a way to do the same for Perl, like a Perl 5.10 Runtime.
Re: decline and fall of modperl?
David Ihnen wrote: I suppose we need more programmers than those programmers who are just interested in coding? I never met a good programmer who wasn't intrinsically interested in it. They like to program, then they realise that being a programmer means been strangled by middle management. Then they start to aspire to BE the middle management (if not higher). The problem in a way is not really about interest, but rather the fact that s/w dev is commoditised to a higher degree, more than other engineering positions. It's a nasty feeling when your job is constantly challenged by half-priced (in some places it's quarter-priced) off-shore devs. Yes we all know the pain in outsourcing. But tell that to managers who spend more time cutting costs than increasing revenue to increase bottom line. Who cares? Hiding source code is valueless. You haven't met the China folks have you? :) No. What do they do in China with open code like open source code? Probably the same thing as with the iPhone: open it up: muck ard with a few trivial items, change the product name, sell it at half price. There's a name for this rising trend in China. It's called ShanZai; loosely translating to 'Mountain Fortress'. And they're damn proud of it. Being able to analyze and apply a direct fix to code that is malfunctioning is of such high value that making it impossible is a serious handicap. Agreed. Assuming you have the pro dev in your team. I keep thinking they're ashamed of their code thats why they want to hide it. Now you're just getting personal... :)
Re: Re: decline and fall of modperl?
From: Mike Bourdon The hidden message here is “the more available senior developers, the more likely available jobs”, an expanding talent pool will lead to an expanding job market. I fully agree. What happends in the regions where there are extremely few perl programmers, no matter if they are good or bad... we can imagine. What can we do in order to promote perl in those countries/regions? There are almost no translated books for learning perl in my country, and the editors are not very interested in printing perl books because they won't sell well enough, and those few which would be interested would probably pirate them. Without books and without funds for promoting perl for beeing taught in schools, perl won't have any chance in face of DotNet or Java. In my humble opinion the perl community needs to embrace the concept of self propagation. For the most part perl/oo perl/mod_perl developers are self taught. Junior or mid level talent (a majority of the talent pool) is passed over as not enough experience. Perhaps this is because they do not push themselves or the roles they come from are User Interface or system ops, people that did not make it in those roles. This where as an investment of time and effort can go a long way into building the pool of perl/oo perl/mod_perl developers. Too often everyone is looking for the instant gratification of a senior level skill set. True, but how to do this practicly? I tried to convince some programmers that Perl is better than PHP, but without any success. Can perl programs run on share hosting web sites? There are some such hosting companies that don't even offer perl support, and those who offer it, offer just the standard Perl distribution, which don't offer a web framework, or templating systems, or ORMS, or form processors, and in these conditions I can't tell that perl is so great. Can they hide the source code? (Because who knows who can get it from those free hosting web sites) I found that they can hide it, but only after installing Open SSL and a perl module, which they can't do, because those sites don't offer root access and neither shell access. In order to show them how good is perl, I told them that they would need to have a dedicated server, or a VPS, but the cheapest VPS costs much more than a shared hosting solution, so in this case perl has another disadvantage. They've also told me that they know that perl is harder to learn than PHP. What can I tell them? That it is not true? Of course that I could have told them that for real good big projects, perl is easier to use than PHP, but most of the PHP users don't care about that kind of projects. They care about simple projects created from scratch, that don't even use a web framework or an ORM or a form processor. But finally those poor PHP programmers find more jobs than a perl programmer. Octavian
Re: decline and fall of modperl?
Perrin Harkins wrote: TicketMaster is Perl. Ticketmaster switched their UK operation from MS technologies to mod_perl a couple of years back too. (Brought it inline with the US side.) There's a couple of biggies that haven't been mentioned... BBC YouPorn (although I don't think they use mod_perl) You could also ask the question of why Twitter has a shelf of perl books: http://twitter.com/jobs ;-) Carl
Re: decline and fall of modperl?
Carl Johnstone wrote: Perrin Harkins wrote: TicketMaster is Perl. Ticketmaster switched their UK operation from MS technologies to mod_perl a couple of years back too. (Brought it inline with the US side.) There's a couple of biggies that haven't been mentioned... BBC YouPorn (although I don't think they use mod_perl) You could also ask the question of why Twitter has a shelf of perl books: http://twitter.com/jobs facebook mirrors CPAN at http://mirror.facebook.com/ so it seems pretty likely that they are using it there too at least for sysadmin type stuff. Adam
Re: decline and fall of modperl?
Octavian Râşniţă wrote: From: Mike Bourdon The hidden message here is “the more available senior developers, the more likely available jobs”, an expanding talent pool will lead to an expanding job market. I fully agree. What happends in the regions where there are extremely few perl programmers, no matter if they are good or bad... we can imagine. What can we do in order to promote perl in those countries/regions? A programmers guild? Providing training, guidance, and advocacy in the market? There are almost no translated books for learning perl in my country, and the editors are not very interested in printing perl books because they won't sell well enough, and those few which would be interested would probably pirate them. Without books and without funds for promoting perl for beeing taught in schools, perl won't have any chance in face of DotNet or Java. I think you've got it right there. We've got to get perl taught in schools. That means perl experts need to be in teaching. And I have a suspicion that perl doesn't appeal to the pure computer scientist very well - these are the people who invented hard typed languages, after all. In my humble opinion the perl community needs to embrace the concept of self propagation. For the most part perl/oo perl/mod_perl developers are self taught. Junior or mid level talent (a majority of the talent pool) is passed over as not enough experience. Perhaps this is because they do not push themselves or the roles they come from are User Interface or system ops, people that did not make it in those roles. This where as an investment of time and effort can go a long way into building the pool of perl/oo perl/mod_perl developers. Too often everyone is looking for the instant gratification of a senior level skill set. True, but how to do this practicly? I tried to convince some programmers that Perl is better than PHP, but without any success. How could they know, if they have never used it? I was far less convinced that PHP was a blight on the face of scripting science until I got a job working in it, after all. Pay them to do it in perl, and after they get through the learning curve they'll probably be much happier with it. Can perl programs run on share hosting web sites? There are some such hosting companies that don't even offer perl support, and those who offer it, offer just the standard Perl distribution, which don't offer a web framework, or templating systems, or ORMS, or form processors, and in these conditions I can't tell that perl is so great. Isn't that to the denigration of the hosting company? Not supporting the framework is no way to support your user base. As long as the dollar is more important than the feature, there's not much we can do about this. These are not things that should be built into the core distribution of a language, its the main reason PHP is so awful. Can they hide the source code? (Because who knows who can get it from those free hosting web sites) Who cares? Hiding source code is valueless. I found that they can hide it, but only after installing Open SSL and a perl module, which they can't do, because those sites don't offer root access and neither shell access. You get what you pay for I guess. In order to show them how good is perl, I told them that they would need to have a dedicated server, or a VPS, but the cheapest VPS costs much more than a shared hosting solution, so in this case perl has another disadvantage. If they care that much about a few $ on a monthly fee for their web site, they're not going to pay enough to get a skilled programmer in ANY language, to do the programming. They've also told me that they know that perl is harder to learn than PHP. What can I tell them? That it is not true? Yes, but you may or may not be right. We all agree that coming into perl is confusing - too much old data about how to do things is out there in the world. That makes it harder to learn - not because the language is harder to learn - but because its not clear what the proper way to learn it is. Of course that I could have told them that for real good big projects, perl is easier to use than PHP, but most of the PHP users don't care about that kind of projects. They care about simple projects created from scratch, that don't even use a web framework or an ORM or a form processor. Sounds like the people who buy expensive fixed-lense cameras, then the moment they get interested in photography discover that they could have bought an SLR, more capable and flexible, for the same price. But they swore they didn't need the capability to do that when they bought the original cameras, so now they're screwed. The value is that you start with something that will scale, because believe it or not, its going to grow - either the one you're working on or the next one you're going to work on, leveraging what you learned in this job. But not everybody sees
Re: decline and fall of modperl?
Octavian Râşniţă wrote: *From:* David Ihnen mailto:dav...@norchemlab.com I tried to convince some programmers that Perl is better than PHP, but without any success. How could they know, if they have never used it? I was far less convinced that PHP was a blight on the face of scripting science until I got a job working in it, after all. They know it because everybody tell them so. Most web sites are done in PHP, most job offer for web programmers ask for PHP experience... Then they don't know, they just repeat what others say. So I guess all we can do is repeat what we know from experience, and hope that others repeat it too...? Pay them to do it in perl, and after they get through the learning curve they'll probably be much happier with it. I can't tell that in my country there are no software companies specialized in perl programming because I don't know all the software companies, but if there are some, they could be counted on fingers, and they aren't probably very big. So who should pay those PHP programmers in order to motivate them? Somebody who wants a program, and is smart enough to know that the engineers are better choosers of the software language than they are. Any consultant, firm, company, consultant, or contractor can pay, and spend his time, to learn perl. They simply have to make the decision to do so. Perhaps you could do so. Can perl programs run on share hosting web sites? There are some such hosting companies that don't even offer perl support, and those who offer it, offer just the standard Perl distribution, which don't offer a web framework, or templating systems, or ORMS, or form processors, and in these conditions I can't tell that perl is so great. Isn't that to the denigration of the hosting company? Not supporting the framework is no way to support your user base. As long as the dollar is more important than the feature, there's not much we can do about this. These are not things that should be built into the core distribution of a language, its the main reason PHP is so awful. I agree that those things shouldn't be built in the core distribution, but there could be more distributions, like the one offered by ActiveState, or Strawberry Perl or others, just as the Zend PHP distribution contains the Zend Framework. It could be helpful to have a perl distribution that includes the latest versions of Template-Toolkit, HTML::Template, Mason, Catalyst, CGI::Application, DBIx::Class, Moose, HTML::FormFu and other helpful cpan modules. A hosting company may want to install that distribution, and it would really offer a much better support than the one offered by PHP. Yes, those modules won't be updated frequently, but it would be much better than simply a CGI.pm support. Now you're talking about something that just about anybody (even you) could do if they put their mind to it, don't you think? Its just creating a distribution, after all. Its just not a very perlish thing to do to limit. Maybe it would be cool if you could have an interface that lets you request and install the latest CPAN module on the shared servers without having root or shell. It might be even better, not limiting anything. Can they hide the source code? (Because who knows who can get it from those free hosting web sites) Who cares? Hiding source code is valueless. Maybe in your country. In my country 10 euro means too much and actually even 1 euro means too much if the same thing can be got for free, legally or not. You taking it and using it doesn't impact anything, and the companies have to understand that. Its just some ideas and organization, pretending you can keep other people from knowing how you did something just makes it less supportable by anybody - good software can be bad software just because its obfuscated like that. Those who matter will actually pay for your software because they want the support and customization that comes with it. If they're not going to pay up front, they're more likely to pay later - keeping them from using the software at all won't help. So why obfuscate or worry about it? I found that they can hide it, but only after installing Open SSL and a perl module, which they can't do, because those sites don't offer root access and neither shell access. You get what you pay for I guess. Well, they can get a free support offered for Zend Optimizer (or how it is called the Zend Decoder). Free support as in open-source community stuff? Or as in a commercial company spending their time to help you with something that they don't get paid for? In order to show them how good is perl, I told them that they would need to have a dedicated server, or a VPS, but the cheapest VPS costs much more than a shared hosting solution, so in this case perl has another disadvantage.
Re: decline and fall of modperl?
David Ihnen wrote: I think you've got it right there. We've got to get perl taught in schools. That means perl experts need to be in teaching. And I have a suspicion that perl doesn't appeal to the pure computer scientist very well - these are the people who invented hard typed languages, after all. In the academia the general directive in choosing a language would be something to this effect: 1. teach modern language concepts, such as OO 2. minimise the learning curve by way of something easy to teach, easy to learn without having to figure out all the details of programming 3. introduce the students to a language that will make them attractive to the general market You probably have a feel why Perl isn't a strong choice given these objectives. Perl was popular in the days when the people who go into software courses do it for the sake of pure interest. These are the people who are contented with Emacs or VIM, as long as they get to work with the codes. Half of today's CompSci students are people who stumble in because they haven't figured things out in life. The problem is made worse by Visual Studio and Eclipse. I remember how Java was a painful experience before someone finally put up a IDE that aids code visualisation and object description. My personal belief is that Perl MUST move with the times. It's an incredibly uphill task to change the market's mindset without a commercial budget. I place my bets on Perl6. It's regrettably a slow process, but it's the only sexy thing available on hand. Pay them to do it in perl, and after they get through the learning curve they'll probably be much happier with it. Half the developers aren't the type who can appreciate a good language. They can develop intensively for 5 years and they STILL haven't figured out what is Regex. Trust me on this! Who cares? Hiding source code is valueless. You haven't met the China folks have you? :) There's outright protection, there's deterrance, and there's leaving the door open for every bad boy to muck it up.
Re: decline and fall of modperl?
Alexandr Ciornii wrote: PHP, C#, Java are much more prefered, because the programs created with them can hide the source code much better, while this is not possible with Perl. This is a big reason why the software companies that create custom programs for their clients prefer to use those languages and not perl. Not because perl is bad. I would like to add that it seems ridiculously simple to decompile Java classes. I find this a bad argument. My company - admittedly small - sells services and software to customers. 90% of our software is written in Perl, and we supply it in source format. None of our customers in their right mind would even think of stealing the code, although it is extremely well-commented throughout. If they had the time to do that, then they would not have asked us to supply the service in the first place. Ultimately, and back to the OP's orginal question, these are the two or three main arguments in this debate, mainly already provided by other contributors : 1) if you have a customer and you provide a good service to this customer, and you have provided it for years, and you provide it at a fair price, then why should they listen to a fresh-landed consultant instead of listening to you ? If they listen to the consultant and ignore your advice, then the problem is not in the programming language you use. 2) it is easy for anyone to use words like obsolete, but what to these words really mean ? is something that hasn't much changed in 10 years automatically obsolete ? if yes, then the WWW is obsolete, and the decision-maker at your customer company is also obsolete. Something becomes really obsolete the day when something else is available, and it performs the same function better and at a lower cost. Is that the case here ? 3) it is true that perl has somehow become less in vogue, consistently over the last few years. The (apparently aging) perl community is largely aware of the fact and deplores it. The critics to perl always seem to rehash the same things (the funny variable prefixes, the possibility of writing bad code, the write-only aspect - you can never re-read the code, and so on). Mostly these critics are people who do not really know the language. But it is not because there are comparatively fewer perl programmers available that perl is an inferior language. There are thousands of so-called MS-Windows or PHP experts available, yet you have to hire ten and then fire nine, to keep the one who is really competent. That's always more expensive than getting the right person from the start. Anyway, I am not so sure that there are really less perl programmers, and less perl-based projects or sites. It may just be that whatever those people do, they do it quietly, competently and without fuss; and that the projects or sites which are based on perl are less in the news because they don't crash and don't overrun their budgets. It seems a bit like turning things on their head. I mean if there are a lot of job adverts for PHP or Java developers, it must mean that PHP or Java projects need a lot of manpower, no ? So conversely..
RE: decline and fall of modperl?
Hi, if nobody did already, please have a look at the Perl Miths presentation by Tim Bunce: http://timbunce.files.wordpress.com/2008/03/perl-myths-200802-with-notes.pdf Now my personal view: I'm committed to perl since 1996, and, although I work since that date in a quite big software company (250 employees, and Microsoft certified partner), I remember to have had very seldom problems convincing customers about technology issues like which language to use. Regarding your experience, I would not confuse the future of Mason with the future of perl in the web programming sector at large. There are similar experiences in other technologies: in the J2EE domain, Jetspeed is almost dead, this doesn't mean J2EE is dead (but it really means you will have problems convincing a system architect to adopt Jetspeed for the next web portal). I'm involved in web programming since 1999 and at that time there were really little choices. We started building our own LAMP (Linux+Apache+ModPerl !) framework that now is the backbone of our solutions anytime the customer gives us the freedom to choose. Sometimes the customer has other technologies in mind, but we always convince him with an unbeatable time-to-market using our own tools. In spite of being a 'simple scripting language' we do not see major problems in mantaining and evolving our framework of 500+ perl modules. Moreover I mind you that there are sectors where perl is still one of the best choice to pick (Natural Language Processing, web crawling, data mungling at large...). The long history of Perl means also that it is much more common to find it at your customers sites than what you could immagine. Some times I talk about Perl admittedly with a little fear, only to find that most of the clients know it already and have already used it at least in the past. So personally I still love Perl and I'm still happy to have learnt it some 13 years ago, and I'm happy that now it is seen as an 'obsolete' technology: for me it only means that is rock solid and that I learnt once in the past, exploiting my knowledge for several years without the need to switch. I think this goes for the most of perl programmers out there. The problem is that Perl is not able to attract new programmers as other tecnologies (Java/.NET) are. One issue being the lack of a common and powerfull development framework as other technology have (MS Visualstudio/NetBeans). And, of course, the not-so-fast transition between Perl 5 and Perl 6 could also be an issue. Finally, regarding the issue of not being forced to deploy the source code: sometimes we deployed perl bytecode for the ByteLoader, and I found the level of security is almost the same than with java bytecode (if you know how to deparse one, you are able to find how to do with the other...). Best, Marco. - Original Message - From: Louis-David Mitterrand [mailto:vindex+lists-modp...@apartia.org] To: modperl@perl.apache.org Sent: Mon, 23 Mar 2009 14:07:31 +0100 Subject: decline and fall of modperl? Hi and sorry for the provocative title of my post :) One of our customers is doing a detailed review of a mason/modperl ERP app we've built for them since 2001. Prodded by some buzzword-compliant consultants they are expressing concerns that the app's underlying technologies - perl, modperl and mason - are becoming obsolete. They feel that a web application framework must have 'rails' or some other buzzword in its name. But their main argument is that perl is declining as a web developement language. Also they rightly feel that competent perl developers are becoming harder to find. What arguements could I use to address these concerns and convince them that their initial investement in perl is still safe and won't be obsolete in 10 years? The client's local developers (who maintain the app we've built) feel that mason gives too much freedom to write messy code and badly structure a web app. Indeed mason has very little constraints, maybe just slightly more than straight modperl. So it requires experienced, self-disciplined devs, which are few and far between. So my second question is, what perl web development framework should we recommend to our client? Catalyst looks like a winner, but maybe there are others? Thanks for your insights,
Re: decline and fall of modperl?
Marilyn Burgess schrieb: From a fellow lurker to another, I would be interested in reading your perspective. - Marilyn me too, Axel
Re: decline and fall of modperl?
André Warnier wrote: I would like to add that it seems ridiculously simple to decompile Java classes. Agreed. With the popularity of bytecode languages such as Java and .Net, suddenly nobody talks about the ease of obtaining source code in the flesh. As Andre mentioned, it's trivial to decompile .Net DLLs. I tried to recover an old perl app packaged by ActivePerl some time back. It was impossible to do this, and the good guys at AP verified my pain. If anything I'd say that I feel confident my (AP-packaged) products will not fare any worse than any commercial Java/ .Net executables in the wild.
Re: decline and fall of modperl?
Perrin Harkins wrote: On Mon, Mar 23, 2009 at 11:30 AM, Octavian Râsnita orasn...@gmail.com wrote: ...and in most parts of the world it is hard to find competent perl programmers. ...The job listings for Perl are strong. They're huge compared to those for Ruby. Of course Java is massively more popular than either of them, but that doesn't make the perl market small. I wouldn't use the word 'most', but here in Southeast Asia it's a real challenge to find a Perl developer with significant experience in Perl/ modperl. Those who do use it as a minor scripting tool in their unix administration. Having run a Perl and Java based technology company in Singapore myself for a chunk of time in the early 2000s, I agree that there is some truth to that. We did run into that as an issue and did end up importing Perl and mod_perl talent overseas including some people who post here relatively regularly who were able to enjoy a stay in SE Asia. However, some markets are going to be a bit different. I think what you are saying reflects also what a search of a Singaporean jobs database has in it. Whereas in USA and Europe PHP = Perl in # of jobs, even in Singapore, the number of Perl jobs is less than half of PHP and both small than Java. From jobstreet.com.sg, Perl:18, PHP:51, Java: 210 With that said, that forms a relatively small n looking at one country -- although I imagine there should be little difference in Malysia etc. At the risk of sounding American-centric, the number of jobs in America and Europe is nonetheless a good chunk of the technology development in the world so I believe the statistics are still compelling on those job sites about relative use of the technology -- Gunther
Fw: Re: decline and fall of modperl?
I have received a fair amount of affirmatives. So here goes Let me first begin by stating that my observations are anecdotal. They are however based on direct conversations with hiring managers / senior developers at my clients/prospects. I have also interviewed well over 400 perl/oo perl/mod_perl developers in the last 4 years. I have an extremely detailed code vetting process that allows an accurate skill level rating. I am sure there will be plenty of situational disparity between what I write and what you may have personally experienced. The “job” market… Most large scale shops (more than a few perl/oo perl/mod_perl developers) have code bases that where developed in the late 90’s (hence a resistance to moved towards more robust but yet unproven versions). These companies have survived the dot com blowup and grown in their respective market places, usually internet/web commerce centric. Most new startups/companies (there are exceptions) are not perl/oo perl/mod_perl shops. The jobs are literally spread across the country. In each geographical area, shops know most of the “local” perl/oo perl/mod_perl developers/coders. They have already worked with these coders or interviewed them at some point in time. In some cases they have current employees that have worked with and know of them. For whatever reasons they are deemed not technically or chemistry qualified. When they do talk to Java/J2ee / MS .net developers (who accept perl only as a procedural language used for the most part by Linux sysads) it is very rare there will be any ship jumping. It’s like the McCoys and the Hatfields. In other words the talent pool doesn’t expand. The Southern Ca market has the highest geographical concentration of large scale perl/oo perl/mod_perl shops (although relatively quite at the moment in terms of hiring). It is arguably the center of the universe as it relates to media/content/advertising and the merging of these with web portals. Southern Ca is also a relocation destination. This lends itself to more “local” talent and therefore more perl/oo perl/mod_perl start ups. The hidden message here is “the more available senior developers, the more likely available jobs”, an expanding talent pool will lead to an expanding job market. In my humble opinion the perl community needs to embrace the concept of self propagation. For the most part perl/oo perl/mod_perl developers are self taught. Junior or mid level talent (a majority of the talent pool) is passed over as not enough experience. Perhaps this is because they do not push themselves or the roles they come from are User Interface or system ops, people that did not make it in those roles. This where as an investment of time and effort can go a long way into building the pool of perl/oo perl/mod_perl developers. Too often everyone is looking for the instant gratification of a senior level skill set. Believe it or not, there is a perception that senior perl/oo perl/mod_perl developers do not play well with others. An active mentoring role played by senior developers and gurus needs to be taken. Reach out and take a junior person under your wing and actively work to raise their level of coding skill set. Perl/oo perl/mod_perl’s community and your future may depend on it. --- On Mon, 3/23/09, Mike Bourdon perl_fin...@yahoo.com wrote: From: Mike Bourdon perl_fin...@yahoo.com Subject: Re: decline and fall of modperl? To: Louis-David Mitterrand vindex+lists-modp...@apartia.org Cc: modperl@perl.apache.org Date: Monday, March 23, 2009, 7:26 PM Very interesting topic, byline and responses. For the last 5 years I have been Perl recruiter (24 years overall as a technical headhunter) based out of Southern Ca. Many on this list have talked/worked with me, most however would not recognize this screen name. I would be more than happy to share my insights as it relates to the job / candidate market conditions. If there are enough affirmative replies I will in the near future post a more detailed dissertation. If not, I will continue to lurk in the shadows. Long live PERL --- On Mon, 3/23/09, Louis-David Mitterrand vindex+lists-modp...@apartia.org wrote: From: Louis-David Mitterrand vindex+lists-modp...@apartia.org Subject: decline and fall of modperl? To: modperl@perl.apache.org Date: Monday, March 23, 2009, 6:07 AM -Inline Attachment Follows- Hi and sorry for the provocative title of my post :) One of our customers is doing a detailed review of a mason/modperl ERP app we've built for them since 2001. Prodded by some buzzword-compliant consultants they are expressing concerns that the app's underlying technologies - perl, modperl and mason - are becoming obsolete. They feel that a web application framework must have 'rails' or some other buzzword in its name. But their main argument is that perl is declining as a web developement language. Also
Re: Fw: Re: decline and fall of modperl?
Mike Bourdon wrote: In my humble opinion the perl community needs to embrace the concept of self propagation. For the most part perl/oo perl/mod_perl developers are self taught. Junior or mid level talent (a majority of the talent pool) is passed over as not enough experience. Perhaps this is because they do not push themselves or the roles they come from are User Interface or system ops, people that did not make it in those roles. This where as an investment of time and effort can go a long way into building the pool of perl/oo perl/mod_perl developers. Too often everyone is looking for the instant gratification of a senior level skill set. Believe it or not, there is a perception that senior perl/oo perl/mod_perl developers do not play well with others. An active mentoring role played by senior developers and gurus needs to be taken. Reach out and take a junior person under your wing and actively work to raise their level of coding skill set. Perl/oo perl/mod_perl’s community and your future may depend on it. I completely agree with what you're saying here. At my previous employer (i changed jobs in august) we found it pretty much impossible to find entry/mid level perl people, so what we did was hire entry level people straight out of school that had maybe a little bit of perl, but displayed the chops to be able to learn what we needed them to learn. This worked out great for us, and i know it's been the way that at least a couple of other small perl shops in Toronto have been building their teams. If you can find a good programmer, it easy to turn them into a good perl programmer if they are willing. Right now, in Toronto if you're looking to hire a senior level perl programmer you're looking at 75K plus CAD. There are a couple of well funded shops in the city that will throw 6 figures at the right candidate. The mentoring thing is huge though. Perl generally isn't taught in schools, and if you're building a team from the ground up, you're going to have to teach. Which is in a lot of ways actually a good thing, because you can hopefully teach people Modern Perl, instead of the formmail.pl style perl ;) This is part of the reason why i'd love to see more tutorial style documentation on perl.apache.org. Adam
Re: Fw: Re: decline and fall of modperl?
In my humble opinion the perl community needs to embrace the concept
of self propagation. For the most part perl/oo perl/mod_perl
developers are self taught. Junior or mid level talent (a majority
of the talent pool) is passed over as not enough experience.
It is interesting for me to hear that developed countries are also
having difficulties finding Perl-savvy developers out of the varsities.
I do agree that not being able to find 'Perl-ready' graduates should not
be a deterrant - I myself being a brainwashed Java advocate for a while
before stumbling onto Perl.
In my local context, deciding on Perl/ PHP/ Ruby requires a great deal
of support on the business side:
1. The average turnover rate is about 3 years. That means every 3 years
you have to retrain a new guy to take over relatively established code.
Since we have to accept the fact that it's extremely difficult to hire
an experienced Perl dev, the quality and experience of the dev team
halts at about 5-6 years.
- New strategies will be have to be formed to distinguish the core
engine from the customisable. The company must recognise the business
viability in retaining the core team, while accepting that the mediocre
will move on in time. The core team itself has to develop good mentoring
and training skills to induct the new intake.
2. Selling to clients who only understand .NET and Java ('modern'
languages) will be a challenge. Governments and large enterprises
generally (and mistakeably) associate other languages to be an
investment risk.
- Nobody asks about the innards of an appliance or a product. As long as
it runs, runs well and affordably, it's good enough.
Sounds reasonable enough, but it's a lot work to get there...
Re: decline and fall of modperl?
On Mon, Mar 23, 2009 at 9:07 AM, Louis-David Mitterrand vindex+lists-modp...@apartia.org wrote: One of our customers is doing a detailed review of a mason/modperl ERP app we've built for them since 2001. Prodded by some buzzword-compliant consultants they are expressing concerns that the app's underlying technologies - perl, modperl and mason - are becoming obsolete. They feel that a web application framework must have 'rails' or some other buzzword in its name. I believe that the right developers can make good sites with Rails, but Ruby is a risky choice compared to Perl. It has a much smaller base of developers and hasn't been used for any large websites except the notoriously unreliable twitter.com. But their main argument is that perl is declining as a web developement language. Also they rightly feel that competent perl developers are becoming harder to find. http://blog.timbunce.org/2008/03/08/perl-myths/ What arguements could I use to address these concerns and convince them that their initial investement in perl is still safe and won't be obsolete in 10 years? Probably none if they've already made up their minds, as it sounds like they have. You might find out why they don't write it themselves if they know so much about the future of software development tools. The client's local developers (who maintain the app we've built) feel that mason gives too much freedom to write messy code and badly structure a web app. It gives a lot of freedom, and if you have reckless developers and/or no development standards, you will end up with bad code. So my second question is, what perl web development framework should we recommend to our client? If you want to use Mason, you might mention to them that Amazon.com uses it for all of their pages and they don't seem to have gone under yet. But really, this is a marketing decision. Using another framework won't prevent people from writing bad code. Only good dev practices can do that. - Perrin
Re: decline and fall of modperl?
On Mon, Mar 23, 2009 at 9:07 AM, Louis-David Mitterrand vindex+lists-modp...@apartia.org wrote: One of our customers is doing a detailed review of a mason/modperl ERP app we've built for them since 2001. Prodded by some buzzword-compliant consultants they are expressing concerns that the app's underlying technologies - perl, modperl and mason - are becoming obsolete. They feel that a web application framework must have 'rails' or some other buzzword in its name. I believe that the right developers can make good sites with Rails, but Ruby is a risky choice compared to Perl. It has a much smaller base of developers and hasn't been used for any large websites except the notoriously unreliable twitter.com. RoR is very good for simple web apps, and most web apps start as simple apps, but it is much more difficult to develop an application made with RoR if you'll need it to do complicated things. But their main argument is that perl is declining as a web developement language. Also they rightly feel that competent perl developers are becoming harder to find. This is true. Less and less programmers use perl, and in most parts of the world it is hard to find competent perl programmers. I know that this could be finally the most important point for a company owner, because he might don't care which of the language is better if he would need to pay more for finding programmers, or can't find at all. What arguements could I use to address these concerns and convince them that their initial investement in perl is still safe and won't be obsolete in 10 years? There are fewer and fewer perl programmers because perl is not promoted by a company like 37 Signals, or Zend, or Sun, or Microsoft, and there are already some very well written books for teaching perl, so the perl programmers don't need other books to learn perl basics, so the editors don't like that, and unfortunately almost all the perl books that teach about how to create a web app teach about the old CGI style which is not a good style anymore. A new perl programmer doesn't know what he should do to make a good application in perl, because there are no books that helps him to decide what framework or perl modules to choose, so he doesn't know if the best solution is Catalyst framework, or CGI::Application, or Mason, or Gantry or another framework, he doesn't know if the templating system he should start learning is Template-Toolkit, or HTML::Template, or Mason, or something else, or if he should use an ORM like DBIx::Class, or Rose::DB or better use just DBI. When a new perl programmer will want to learn to use the OOP style of programming, there would be no book to tell him to use Moose or Mouse, but he will be taught only to use the old style and there could be many such examples. So the programmer would be surely confused, and prefer to use a unique-style language like Python or Ruby, but this doesn't matter that they are better. Maybe Python is better than Perl for creating desktop apps and interacting with the OS, especially under Windows, but not for creating web apps. When the beginners compare the languages, they compare what the installation packages offer them, but well perl doesn't offer too much. Perl is good if we consider many other good-written modules that can be found on CPAN. Some advantages of perl are: - Catalyst framework is much better than the frameworks that can be used in Python, Ruby and PHP, and it has very many advantages from the flexibility of the dispatcher, the ease of use (even though it might not be easy to learn it), the possibility of using more templating systems, more ORMS, more form processors, more type of authentication/authorization modules.. - Although it might not be so elegant, Mason offers a very high flexibility for creating templates. - DBIx::Class ORM offers very many features and it can work very well with Catalyst, and HTML::FormFu form processor. - There are more form processors that can be used in a perl project, and some of them create even the Javascript code used for client side validation. - There are modules that can be used for including JS widgets that use AJAX in a perl app, some of them don't even require to know Javascript. - There are more modules that can be used for creating custom wikis included in an app. - Even Movable Type app for blogging is made in perl, and from I've recently seen from a matrix that compares the blog apps, it is much better than WordPress. So my second question is, what perl web development framework should we recommend to our client? I found that Catalyst framework creates a much more elegant web app than Mason. Of course, if the developer insists, he can create bad code with any language or any framework. Octavian
Re: decline and fall of modperl?
On Monday, 2009-03-23 at 11:55:46 -0400, Perrin Harkins wrote: On Mon, Mar 23, 2009 at 11:30 AM, Octavian Râsnita orasn...@gmail.com wrote: This is true. Less and less programmers use perl, and in most parts of the world it is hard to find competent perl programmers. Unless you have some evidence of this, stop spreading FUD. The job listings for Perl are strong. They're huge compared to those for Ruby. Of course Java is massively more popular than either of them, but that doesn't make the perl market small. Figures from the German freelancer market, Gulp (www.gulp.de): CVs (called profiles, a total of 60823 are available) with: Perl 5470 Ruby 234 Java 11261 About two Java programmers perl Perl programmer. About 23 Perl programmers per Ruby programmer. (Germans are known to be conservative...) Projects (total 1317) mentioning Perl 54 Ruby 4 Java 153 The programmer-to-project ratios are: Perl 101 Ruby 58 Java 73 So, yes, Perl is a bad choice. It is the language with the most competition. Go for Ruby! There may be only four projetcs, but you have less competition to fear! :-) Lupe Christoph -- | There is no substitute for bad design except worse design. | | /me |
Re: decline and fall of modperl?
Louis-David Mitterrand wrote: Hi and sorry for the provocative title of my post :) What better way to get a response? What you have is better than what you don't, so sticking with a tech you already have is often the most pragmatic path. I agree with the others, in that if the company hires a good programmer, they will get good code out. In the end, all I really want to add to what people have said is this: Perl has been relatively static for a long time, without many changes. The new version of perl in the works is going to change that. I fully expect perl to become far more interesting to the programming community with that upgrade. Perl will move from the old one to the latest one, and then it WILL be a buzzword again. Least, thats what I think. David
Re: decline and fall of modperl?
From: David Ihnen dav...@norchemlab.com The new version of perl in the works is going to change that. I fully expect perl to become far more interesting to the programming community with that upgrade. Perl will move from the old one to the latest one, and then it WILL be a buzzword again. Least, thats what I think. That's what I also hope, but I don't think it will happen too soon. PHP, C#, Java are much more prefered, because the programs created with them can hide the source code much better, while this is not possible with Perl. This is a big reason why the software companies that create custom programs for their clients prefer to use those languages and not perl. Not because perl is bad. I hope Perl 6 will also solve this issue... Octavian
Re: decline and fall of modperl?
It amazes me that this entire thread neglects to mention PHP. Granted, it started with a discussion about web frameworks, for which PHP does not have a strong footing, unless of course you count Drupal and Wordpress and the like among such frameworks. But still, PHP cannot and should not be ignored. In my experience in working on Movable Type, PHP is the single biggest source of competition on the market because it has the lowest barrier to entry and has the largest mind share. Say what you will about PHP developers, but they are a dime a dozen these days and they are about as ubiquitous as HTML/CSS developers. We were frequently confronted with this question/challenge by MT customers: we can't find *affordable* Perl developers to help us, or worse, we already have 10 people on staff who know PHP. What it boils down to for most companies is can I develop this thing with the staff I have, or do I have to open up job reqs to get the talent I need? or put simple, how much is this going to cost me? Put into these terms, PHP always looks cheaper on paper because chances are there are people on staff who already know PHP, or the cost of hiring a good Perl programmer is too high. Byrne On Mar 23, 2009, at 10:05 AM, Lupe Christoph wrote: On Monday, 2009-03-23 at 11:55:46 -0400, Perrin Harkins wrote: On Mon, Mar 23, 2009 at 11:30 AM, Octavian Râsnita orasn...@gmail.com wrote: This is true. Less and less programmers use perl, and in most parts of the world it is hard to find competent perl programmers. Unless you have some evidence of this, stop spreading FUD. The job listings for Perl are strong. They're huge compared to those for Ruby. Of course Java is massively more popular than either of them, but that doesn't make the perl market small. Figures from the German freelancer market, Gulp (www.gulp.de): CVs (called profiles, a total of 60823 are available) with: Perl 5470 Ruby 234 Java 11261 About two Java programmers perl Perl programmer. About 23 Perl programmers per Ruby programmer. (Germans are known to be conservative...) Projects (total 1317) mentioning Perl 54 Ruby 4 Java 153 The programmer-to-project ratios are: Perl 101 Ruby 58 Java 73 So, yes, Perl is a bad choice. It is the language with the most competition. Go for Ruby! There may be only four projetcs, but you have less competition to fear! :-) Lupe Christoph -- | There is no substitute for bad design except worse design. | | / me |
Re: decline and fall of modperl?
On Monday, 2009-03-23 at 10:54:59 -0700, Byrne Reese wrote: It amazes me that this entire thread neglects to mention PHP. OK, I'll add PHP... Figures from the German freelancer market, Gulp (www.gulp.de): CVs (called profiles, a total of 60823 are available) with: Perl 5470 Ruby 234 Java 11261 PHP 6047 About two Java programmers per Perl programmer. About 23 Perl programmers per Ruby programmer. (Germans are known to be conservative...) Roughly the same number of PHP people as Perl people. Projects (total 1317) mentioning Perl 54 Ruby 4 Java 153 PHP 34 The programmer-to-project ratios are: Perl 101 Ruby 58 Java 73 PHP 178 So, yes, Perl is a bad choice. It is the language with the most competition. Go for Ruby! There may be only four projetcs, but you have less competition to fear! :-) And you should avoid PHP, too. Turns out, the numbers for PHP aren't that different from those for Perl. I have to admit that I'm surprised. By the dearth of PHP projects as well as the number of PHP people. Lupe Christoph -- | There is no substitute for bad design except worse design. | | /me |
Re: decline and fall of modperl?
Alright, I don't want to quibble, but I would question any conclusions you can draw from the numbers based upon the sole fact that it is based upon how developer self-identify. I know that Wordpress and Drupal freelancers do not position themselves as PHP programmers, but rather WordPress and Drupal programmers. The same may very well be true for Plone, Movable Type and any number of reputable application and CMS frameworks on the market - where much of web development is happening these days. Who knows maybe we are talking about two different things. Byrne On Mar 23, 2009, at 11:32 AM, Lupe Christoph wrote: On Monday, 2009-03-23 at 10:54:59 -0700, Byrne Reese wrote: It amazes me that this entire thread neglects to mention PHP. OK, I'll add PHP... Figures from the German freelancer market, Gulp (www.gulp.de): CVs (called profiles, a total of 60823 are available) with: Perl 5470 Ruby 234 Java 11261 PHP 6047 About two Java programmers per Perl programmer. About 23 Perl programmers per Ruby programmer. (Germans are known to be conservative...) Roughly the same number of PHP people as Perl people. Projects (total 1317) mentioning Perl 54 Ruby 4 Java 153 PHP 34 The programmer-to-project ratios are: Perl 101 Ruby 58 Java 73 PHP 178 So, yes, Perl is a bad choice. It is the language with the most competition. Go for Ruby! There may be only four projetcs, but you have less competition to fear! :-) And you should avoid PHP, too. Turns out, the numbers for PHP aren't that different from those for Perl. I have to admit that I'm surprised. By the dearth of PHP projects as well as the number of PHP people. Lupe Christoph -- | There is no substitute for bad design except worse design. | | / me |
Re: decline and fall of modperl?
From: Byrne Reese by...@majordojo.comIt amazes me that this entire thread neglects to mention PHP. Granted, it started with a discussion about web frameworks, for which PHP does not have a strong footing, unless of course you count Drupal and Wordpress and the like among such frameworks. But still, PHP cannot and should not be ignored. Well, Drupal is not a framework but a CMS, and WordPress is a kind of CMS used for creating blogs. I have tested more PHP frameworks but most of them really sucks. I think that CodeIgniter was the one I liked the most, but it is still very far behind Catalyst. The ORM it uses is not so advanced as DBIx::Class, and it doesn't allow using other ORMS, it doesn't have features for using more templating systems easy, it has a strange and hard to use form processor, the URL dispatching is more limited and harder to use... In my experience in working on Movable Type, PHP is the single biggest source of competition on the market because it has the lowest barrier to entry and has the largest mind share. Say what you will about PHP developers, but they are a dime a dozen these days and they are about as ubiquitous as HTML/CSS developers. That's true, but Perl programmers, especially those who create advanced programs don't usually compete with those PHP programmers you are talking about. Perl still has some big issues if we want it to compete with PHP for that kind of programs that can be easily installed on servers that offer web hosting for free or for 3 dollars a month, because CPAN modules are not built in the Perl package and are harder to install, or impossible to install without root and shell access. The problem is that maybe 99% of the web sites are that kind of web sites that don't have their own server, or VPS, but use shared hosting, and less and less free web hosting servers offer support for Perl because it can't be really used anyway. We were frequently confronted with this question/challenge by MT customers: we can't find *affordable* Perl developers to help us, or worse, we already have 10 people on staff who know PHP. What it boils down to for most companies is can I develop this thing with the staff I have, or do I have to open up job reqs to get the talent I need? or put simple, how much is this going to cost me? Put into these terms, PHP always looks cheaper on paper because chances are there are people on staff who already know PHP, or the cost of hiring a good Perl programmer is too high. Byrne For most of the web sites, this is very true. If somebody who wants to make a web site that will be hosted on a share hosting server for 5 dollars a month comes to me and asks me how much I ask for making his web site, I can tell him that I can't make that web site because I can't install a Perl framework on that server, I can't install other perl modules I might need, and if he wants me to create the site for him, he should pay 30 or 40 dollars per month for a VPS. Well, in that case only this will mean too much, before telling him how much it costs. A PHP programmer even if he wants to use a framework on a free hosting web site, he could do it because he might find frameworks that can be installed by just unarchiving a file, so even if that framework won't be as good as Catalyst, it would be surely much better than what I can install on that server. So... Perl programmers target only bigger businesses and more important web sites and this is a reason why the statistics are not very relevant. If a site like Amazon uses Perl, it is just one web site, but it has a traffic like a few thousands other small web sites. The problem is that there are no very many big sites that use perl either. I knew that Amazon used Perl, than tried to use Java, than... I don't know what they use now. Google uses Python, Yahoo uses PHP, Microsoft probably uses DotNet and Sun probably uses Java. I don't know other important sites that use Perl. Even on www.perl.com, the link Perl success stories wasn't updated and points to an O'Reilly web page that advertises some perl books. There is a Perl success stories on O'Reilly's web site, but somewhere else, and those success stories seem to be pretty old, much before the so called Web 2.0 era. If I'd need to compare Perl with a company, I'd say that his technical department is very disorganized, but that it has the best results, however its marketing and financial departments are dead. And by the way, this company doesn't really follow the new standards that other companies use. (And I am talking about the web services which aren't really compatible with those offered by DotNet and Java, about the dot notation for separating classes and objects, and even about the dollars and @, % signs that might seem strange in these days because other languages don't use them.) Octavian
Re: decline and fall of modperl?
Hire Dave Rolsky (who wrote the Mason book, and maintains HTML-Mason), he's apparently looking for work: http://blog.urth.org/2009/03/need-a-programmer.html You'll be hard pressed to find anyone more competent, but he might want to re-implement the whole system, you never know... Adam
Re: decline and fall of modperl?
The problem is that there are no very many big sites that use perl either. I knew that Amazon used Perl, than tried to use Java, than... I don't know what they use now. Google uses Python, Yahoo uses PHP, Microsoft probably uses DotNet and Sun probably uses Java. I will add: * LiveJournal * TypePad * Vox * Popular MT sites like: - Huffington Post - Gothamist - Talking Points Memo - many, many, many more of course
Re: decline and fall of modperl?
Alright, I don't want to quibble, but I would question any conclusions you can draw from the numbers based upon the sole fact that it is based upon how developer self-identify. Every language has it's own sub-languages or frameworks that they identify themselves as. So I suspect the statistics Lupe posted are OK on average and reflecting the general reality and representation of job availability. Adding onto what Lupe has posted, I can confirm my own quick search on www.monster.com (nationwide). Keywords: Perl, PHP, Java, Ruby yield the following as of 5 minutes ago. Perl (1795), PHP (1145), Java (4940), and Ruby (318) If you wish to add Drupal or other keywords, you may want to consider doing so rather than leaving open speculation. If PHP is a skill needed for the job, I suspect it will appear *somewhere* in the job description. If you search Drupal on monster.com for example you will see a lot of PHP overlap. Addressing some other themes I've seen here (not a direct response to you) - Perl has been around a long time without much change I am not sure why anyone thinks that is a bad thing. The fact that it is a stable language seems 'good' to me. It hasn't changed because it does it's job really well for what it does. - That the amount of tools that exist for Perl are 'confusing' I am not sure that is the case. The # of tools that exist does offer choice and it can be a bit difficult to weed through the bad stuff to get to the more useful tools, but that's what a mailing list like this can help with. Someone can easily post saying I need something to do X Y and Z and I am interested in the underlying power of mod-perl or perl, can you guys help me and there's always posts where people do help guide. Still though, it's not like it's really that hard. People here on the mailing list like Perrin have written up talks comparing different toolkits which can inform the community as well. And even without those resources, if you are used to working with open source tools you can usually visit and website and within 5 minutes figure out if it's active and booming community or a dead horse. So I see little problem really. In fact, the choice is a great thing. As Perrin I think said earlier (I'm paraphrasing liberally I suspect), if a company has already made up their mind ahead of time to use or not use a technology, it's pretty easy to bash whatever you want. That's why I liked Lupe's statistics on German job market, and I can back up the ratios of jobs with the USA www.monster.com website which makes me comfortable that his #s are probably reasonable representation of job market reality without FUD getting in the way. Best regards, Gunther
Re: decline and fall of modperl?
On Mon, Mar 23, 2009 at 3:07 PM, Octavian Râsnita orasn...@gmail.com wrote: I knew that Amazon used Perl, than tried to use Java, than... I don't know what they use now. Please stop with the FUD! Amazon uses Perl for their front-end development. Check their job ads. Google uses Python, Yahoo uses PHP, Microsoft probably uses DotNet and Sun probably uses Java. Yahoo uses plenty of Perl on their back-end, and PHP for their front-end pages. TicketMaster is Perl. IMDB is Perl. LiveJournal is Perl. No one cares what Sun and Microsoft run on their websites. The original poster asked for help winning a contract that he wants to use Perl for. So far, you're not contributing. - Perrin
Re: decline and fall of modperl?
On Mon, 23 Mar 2009 15:16:59 -0400, Byrne Reese by...@majordojo.com wrote: I will add: * LiveJournal * TypePad * Vox * Popular MT sites like: - Huffington Post - Gothamist - Talking Points Memo - many, many, many more of course Let's not forget ticketmaster... of which many mod_perl developers have worked for.
Re: decline and fall of modperl?
Hi. It possible to encrypt perl sources with same safety as with PHP - with possibility of source decryption. But Perl developers are in general more advanced than PHP developers so they know how to decrypt it, in contrast to PHP developers that do not know that encrypted PHP sources can easily be decrypted. There are also some bytecode compilers for Perl (alpha stage). 2009/3/23 Octavian Râsnita orasn...@gmail.com: PHP, C#, Java are much more prefered, because the programs created with them can hide the source code much better, while this is not possible with Perl. This is a big reason why the software companies that create custom programs for their clients prefer to use those languages and not perl. Not because perl is bad. -- Alexandr Ciornii, http://chorny.net
Re: decline and fall of modperl?
I believe Craigslist and Slashdot are both entirely done in perl/mod_perl. On Mon, Mar 23, 2009 at 2:49 PM, Dan Stephenson ispyhuman...@gmail.comwrote: On Mon, 23 Mar 2009 15:16:59 -0400, Byrne Reese by...@majordojo.com wrote: I will add: * LiveJournal * TypePad * Vox * Popular MT sites like: - Huffington Post - Gothamist - Talking Points Memo - many, many, many more of course Let's not forget ticketmaster... of which many mod_perl developers have worked for.
Re: decline and fall of modperl?
From: Byrne Reese by...@majordojo.com The problem is that there are no very many big sites that use perl either. I knew that Amazon used Perl, than tried to use Java, than... I don't know what they use now. Google uses Python, Yahoo uses PHP, Microsoft probably uses DotNet and Sun probably uses Java. I will add: * LiveJournal * TypePad * Vox * Popular MT sites like: - Huffington Post - Gothamist - Talking Points Memo - many, many, many more of course Do you know other sites that don't use Movable Type? :-) But even if we talk about Movable Type... I've seen that WordPress is known much better than MovableType. Gues why. MovableType has much more features than WordPress, however WordPress is better known. Maybe because there are much much more interface translations for WordPress than for MovableType, or maybe because it uses PHP and there are much more PHP programmers. If I need to choose 2 wikis, or 2 programs that can be used for creating blogs, I would choose one made in Perl, because I use perl, even though I know that I would probably just use that program and don't make any change in it. MovableType is a big success of Perl. Too bad that there is no program for creating wikis that has the same success. (I've tried TWiki and I found that even though it has many features, it has too much bugs, so finally I started to use MediaWiki which is much better, but unfortunately it is not made in perl. I hope MovableType doesn't have the same issues.) Octavian
Re: decline and fall of modperl?
From: Alexandr Ciornii alexcho...@gmail.com Hi. It possible to encrypt perl sources with same safety as with PHP - with possibility of source decryption. But Perl developers are in general more advanced than PHP developers so they know how to decrypt it, in contrast to PHP developers that do not know that encrypted PHP I heard this theory for more times but nobody was able to give an example. Can you re-create the clear PHP source code from an encoded PHP file that was encoded with ZendEncoder? Can you give an example of a program or module that can do the same type of encryption for perl? sources can easily be decrypted. There are also some bytecode compilers for Perl (alpha stage). Alpha stage means something useless for the present time. Can I encrypt some .pm modules in such a way that they couldn't be decrypted easier than the PHP files encrypted by Zend Encoder? If yes, please tell us how, because it would be a really important information for the perl developers. Octavian
Re: decline and fall of modperl?
From: Perrin Harkins per...@elem.com The original poster asked for help winning a contract that he wants to use Perl for. So far, you're not contributing. - Perrin I presented more advantages of perl, in one of my previous message so I contributed, but I don't like to hear that Perl is everywhere and hear about a lot of statistics that shows that it is much more used than PHP while I see that most of the web sites are made with PHP and most of the new programmers become interested in Python not in Perl. Octavian
Re: decline and fall of modperl?
At 11:34 PM +0200 3/23/09, Octavian Râsnita wrote: From: Byrne Reese by...@majordojo.com The problem is that there are no very many big sites that use perl either. I knew that Amazon used Perl, than tried to use Java, than... I don't know what they use now. Google uses Python, Yahoo uses PHP, Microsoft probably uses DotNet and Sun probably uses Java. I will add: * LiveJournal * TypePad * Vox * Popular MT sites like: - Huffington Post - Gothamist - Talking Points Memo - many, many, many more of course Do you know other sites that don't use Movable Type? :-) http://www.booking.com http://www.hospitalitynet.org Liz
Re: decline and fall of modperl?
Do you know other sites that don't use Movable Type? :-) Not as extensively. :) But even if we talk about Movable Type... I've seen that WordPress is known much better than MovableType. Gues why. MovableType has much more features than WordPress, however WordPress is better known. Maybe because there are much much more interface translations for WordPress than for MovableType, or maybe because it uses PHP and there are much more PHP programmers. I won't belabor this thread with a competitive analysis of WordPress' mindshare over MT as the answer to that question is multifaceted. But I will say that the fact that WP is written in PHP has A LOT to do with it. It also has an incredibly liberal commit/patch policy, lending to both the speed of its advancement and negatively to its security; but most importantly to its success in recruiting new developers to the platform. MovableType is a big success of Perl. That is great to hear. I am working on a project hopefully that will get the folks from this community perhaps more actively engaged in the development and advancement of MT. I am very proud of MT and remain committed to its success. Byrne
Re: decline and fall of modperl?
Byrne Reese wrote: The problem is that there are no very many big sites that use perl either. I knew that Amazon used Perl, than tried to use Java, than... I don't know what they use now. Google uses Python, Yahoo uses PHP, Microsoft probably uses DotNet and Sun probably uses Java. I will add: * LiveJournal * TypePad * Vox * Popular MT sites like: - Huffington Post - Gothamist - Talking Points Memo - many, many, many more of course As far as I know, these sites also use Perl or mod_perl: o Internet Movie Database (Amazon) o TicketMaster (last I checked, but that was a couple of years ago and they were recently sold or bought or something) o CitySearch.com o ArtToday.com o PBS Online I also know that a very large international cosmetics company uses mod_perl quite extensively. I've done some work for them and I don't know if or how they would care for their name being mentioned here, so I won't, but... If you want large -- they define large. - I wouldn't count a company that uses a Perl product or CMS or some sort (such as MT) as a perl site in the strict sense of the word. Some of the techies at places like Huffington Post may be aware of the underlying technology, but I doubt very much that Perl itself drove the decision as much as the great work that Ben and Mena Trott did at SixApart.com in creating such a product. - And I have to chime in and say I've seen plenty of ugly, ridiculous code written in every language imaginable (everyone's precious Java and JEE very much included.) It's not a product of the language as much as the language bearer. Sorry. That's always been the case. Margin for error on a tight mountain road doesn't automatically a bad driver make -- only the one who will not heed the type of road and car he's in in the situation. Anyone can zoom through an intersection full of traffic on a wide-open, flat country road as well. The road being the intent and direction and the car being Perl (and pretty cotton-pickin' good one, I might add), I don't see the correlation here. Again, this is clever smoke and mirrors by consultants with a different agenda and product to sell. The craft of programming and development are only slightly impacted by these kinds of things. -pj
Re: decline and fall of modperl?
Alexandr Ciornii wrote: Hi. It possible to encrypt perl sources with same safety as with PHP - with possibility of source decryption. But Perl developers are in general more advanced than PHP developers so they know how to decrypt it, in contrast to PHP developers that do not know that encrypted PHP sources can easily be decrypted. There are also some bytecode compilers for Perl (alpha stage). 2009/3/23 Octavian Râsnita orasn...@gmail.com: PHP, C#, Java are much more prefered, because the programs created with them can hide the source code much better, while this is not possible with Perl. This is a big reason why the software companies that create custom programs for their clients prefer to use those languages and not perl. Not because perl is bad. Not to keep the PHP thing going, but I would tend to de-classify about 30% of the people who call themselves PHP developers. There is a VERY high propensity among many in this community to go out and borrow code and retrofit it. I'm not saying Perl developers don't do this, but I don't believe there are very many heavily invested in the Perl community who have this bent -- many are devoted to the craft of true, honest to goodness OO development. I also left out a very important and I would say very well known Perl *powerhouse* in corporate America: WhitePages.com Some of the best of the best work there. You can't even get a sniff from them (eg. interview) without being in the upper crust of Perl development. No Perl wanna-bes allowed there. All very solid OO development only. -pj
Re: decline and fall of modperl?
Hi. Filter::Crypto on CPAN. It even works with PAR. And it is free. 2009/3/23 Octavian Râsnita orasn...@gmail.com: Can I encrypt some .pm modules in such a way that they couldn't be decrypted easier than the PHP files encrypted by Zend Encoder? If yes, please tell us how, because it would be a really important information for the perl developers. -- Alexandr Ciornii, http://chorny.net
Re: decline and fall of modperl?
Perrin Harkins wrote: On Mon, Mar 23, 2009 at 11:30 AM, Octavian Râsnita orasn...@gmail.com wrote: ...and in most parts of the world it is hard to find competent perl programmers. ...The job listings for Perl are strong. They're huge compared to those for Ruby. Of course Java is massively more popular than either of them, but that doesn't make the perl market small. I wouldn't use the word 'most', but here in Southeast Asia it's a real challenge to find a Perl developer with significant experience in Perl/ modperl. Those who do use it as a minor scripting tool in their unix administration. There are still jobs requiring Perl of course, but it's usually in the context of having Perl as a secondary proficiency, with Java/ .NET as the primary. We have a real problem getting the average freshie to appreciate the beauty of dynamic languages. Sorry guys.
Re: decline and fall of modperl?
From a fellow lurker to another, I would be interested in reading your perspective. - Marilyn On Mon, Mar 23, 2009 at 7:26 PM, Mike Bourdon perl_fin...@yahoo.com wrote: Very interesting topic, byline and responses. For the last 5 years I have been Perl recruiter (24 years overall as a technical headhunter) based out of Southern Ca. Many on this list have talked/worked with me, most however would not recognize this screen name. I would be more than happy to share my insights as it relates to the job / candidate market conditions. If there are enough affirmative replies I will in the near future post a more detailed dissertation. If not, I will continue to lurk in the shadows. Long live PERL --- On *Mon, 3/23/09, Louis-David Mitterrand vindex+lists-modp...@apartia.org vindex%2blists-modp...@apartia.org*wrote: From: Louis-David Mitterrand vindex+lists-modp...@apartia.orgvindex%2blists-modp...@apartia.org Subject: decline and fall of modperl? To: modperl@perl.apache.org Date: Monday, March 23, 2009, 6:07 AM -Inline Attachment Follows- Hi and sorry for the provocative title of my post :) One of our customers is doing a detailed review of a mason/modperl ERP app we've built for them since 2001. Prodded by some buzzword-compliant consultants they are expressing concerns that the app's underlying technologies - perl, modperl and mason - are becoming obsolete. They feel that a web application framework must have 'rails' or some other buzzword in its name. But their main argument is that perl is declining as a web developement language. Also they rightly feel that competent perl developers are becoming harder to find. What arguements could I use to address these concerns and convince them that their initial investement in perl is still safe and won't be obsolete in 10 years? The client's local developers (who maintain the app we've built) feel that mason gives too much freedom to write messy code and badly structure a web app. Indeed mason has very little constraints, maybe just slightly more than straight modperl. So it requires experienced, self-disciplined devs, which are few and far between. So my second question is, what perl web development framework should we recommend to our client? Catalyst looks like a winner, but maybe there are others? Thanks for your insights,
Re: decline and fall of modperl?
On Mon, 23 Mar 2009 22:26:10 -0400, Mike Bourdon perl_fin...@yahoo.com wrote: I would be more than happy to share my insights as it relates to the job / candidate market conditions. If there are enough affirmative replies I will in the near future post a more detailed dissertation. If not, I will continue to lurk in the shadows. Long live PERL Affirmative. -- ispy++
