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
[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 of
