Front page | perl.perl5.porters |
Postings from June 2006
On 16 jun 2006, at 16.18, demerphq wrote: > On 6/16/06, Juerd <juerd@convolution.nl> wrote: >> demerphq skribis 2006-06-16 11:05 (+0200): >> > Lately I've been seeing comments in various forums along the >> following >> > lines: >> > 1. Perl 5 is a dead language >> > 2. Perl 5 is going to be replaced by Perl 6 so there is no >> point in >> > using Perl 5. >> >> The weird thing is, though, that this is expressed mostly by >> people who >> don't know much about Perl 6, or Perl 5 for that matter. >> >> > I think these are a serious problem for the language and the >> > community. When college teachers are saying that teaching PHP makes >> > more sense because Perl is a dead language there is a problem. When >> > the people who should know better think that Perl 5 is end-of-lifed >> > because of Perl 6 then there is a problem. When the internal >> politics >> > of the Perl community lead to more Fear, Uncertainty and Doubt >> than a >> > focused Microsoft attack campaign there is something wrong. >> >> Agreed, but do you have suggestions? > > Advertising, advertising, and more advertising. > > :-) Exactly why the reason for example Java has been such a success. It's not that Java in anyway is a better language but because there is a strong company behind promoting it in various ways. There are also much more tools such as IDE's that makes it easier for junior programmers to start using Java and, especially, maintaining already existing Java code. As with all (most) dynamic languages (with or without the problem of parsing without executing) there are problems with writing great tools but if we stop trying to achieve 100% perfection and instead aim for something realistic like the most-case-scenario we're at least on our way. Some may argue that programming using a plain-text editor gives the best result because the programmers must know what he/she/it is doing. But in the real world $money talks. Another thing I like with Java and dot-not is that they clearly state how to define APIs. Most (if not all) Java libraries I've been using has a feeling of consistency because they all useCamelCase. Yes, there is perlstyle, but honestly how many of the CPAN authors have actually read it or cares what it says. CPAN is a mess of various styles. Maybe there should be some TPF-approval stamp on modules that follows certain API guidelines setup by some group (maybe p5p) in order to narrow the diversity of styles. >> So the people who have this wrong impression of Perl 5 are, as far >> as I >> can tell, mostly outside "the community". That makes it very hard to >> reach them. I have no idea how this could be done effectively... > > I have some ideas. We need people like Chromatic from O'Reilly > publishing it as much as possible. We need people to write papers and > press releases about what our plan is. We need to publish milestones > and future plans that clearly indicate that the EOL of Perl5 is a long > long way off. We need to enhance the visibility of Perl in the > corporate sphere. We need to find useful features that the market > wants and start delivering them. We need to make it clear that if > people want to contribute to a project that Perl 5 is a worthy project > to contribute to. How does one define "the community"? p5p? Perl Mongers? CPAN authors? Again (Java) has what they call The Java Community Process (Program) which proposes enhancements to the core language and surrounding technologies which may be beneficial to the community in whole. http://www.jcp.org The Perl6 RFC was a great start but it was mostly about the language itself and not the stuff around it. Libraries are as important as the language itself IMHO. > I think we should also identify a plan for Perl 5, a long term plan > that doesnt necessarily involve being compliant with Perl 6 design > decisions. Second that /Claes