The name "Pumpkin" isn't necessarily my favorite, but I'm pretty sure that's just pure personal opinion; I can't think of any real objections to it, nor can I think of a better suggestion. There's certainly nothing wrong with it.
I do still like the idea of year-based versioning, ideally along with the name change. If you're going to do releases based on a scheduled time-table, it makes sense to match your versions to it. However, that's something that can be considered in the future.
I'm feeling good about this change.
]]>However, if the "powers that be" decide that we are not making any major changes to the versioning, I'd rather 5.2013.1 style versioning than to see us continue with our current style.
]]>As it stands, people who know Perl have grown accustom to a very (some would say overly) strict policy towards maintaining backwards compatibility to an almost extreme degree. I don't think year-based versioning would give the impression of constant compatibility breaking changes, although I do think it would make it easier to introduce those changes and get people to accept them.
With the current versioning, and its traditional Major.Minor.Patch style, many (most?) people familiar with that versioning scheme assume that backwards compatibility will be maintained across Major versions. That means that as long as we're still making releases that are Perl 5.x.y, people will expect that it will never change. I don't think we should start breaking things because we can, but I also don't think we should still be supporting deprecated features from Perl 4.
]]>I think this would be an excellent change for Perl. One issue I regularly run into is the huge disconnect between Perl versions and their age. Perl 5.6.0 is 13 years old; Perl 5.8.0 is almost 11 years old; Perl 5.10.0 is over 5 years old. People in the Perl community know that Perl 5.6.x is ancient and that 5.8.x is old. But people outside of the Perl community don't see that. They see it all as "Perl".
I'm really liking this idea.
]]>I decided to write up my response here, as it got a bit long for a comment on their site. Consider it an open letter to people writing about Perl based on poor research or outdated information.
Mr. Venezia,
I'm not surprised that you received some responses that disagreed with your article, nor that some of them were a bit blunt with their disagreement. I know I personally considered responding, although I eventually decided it wasn't worth my time.
My problem with your article was that it felt poorly researched and drew conclusions in excess of what could be supported. On top of that, the only real evidence offered was the TIOBE report, and I don't know of anyone who actually considers TIOBE to be accurate or reliable. In fact, it is widely considered to be barely above a joke. There are numerous articles that dig into their methodology and show how weak it is.
Unfortunately, this article isn't much of an improvement. It has the feeling of someone who has a lot of experience with Perl, but unfortunately has let themselves get woefully out of date. I'm curious, when was the last time you looked into any recent developments in the Perl world? Do you still write Perl the same way that you did a decade ago? Do you think that the only way to write web applications with Perl is CGI?
You mention that, "there are better languages for developing Web applications", and that those languages, "are much more in tune with the specific needs of Web applications", although you fail to provide any evidence or even explanation for your sweeping generalization. Later you specifically call out Python for having, "better Web chops than Perl", although again without anything at all to support your statement.
These comments are why I feel that you are seriously out of touch with Perl. You seem to view it as Perl of 2005, instead of Perl of today. There are some great web frameworks for Python, and Ruby's strongest claim to fame is Ruby on Rails. But, if you'd do a little research, talk to people that are writing web applications with Perl, you'd find that there are web frameworks for Perl that rival anything in the Python or Ruby world. The heavy hitters are Catalyst, Mojolicious, and Dancer. Any one of them can be used to build a large-scale web application just as easily as Django in Python, or Ruby on Rails.
I appreciate your claims that you are not "anti-perl", and that you are cheering for Perl's continued usage, but your articles perpetuate the myths you claim to be against. If you want to see Perl continue on as the strong and vibrant language that it is, stop looking at it today through the lens of its past. Don't paint it into your outdated and incorrect view of what it is and what it can do. Spend a few minutes reading about the Modern Perl movement. Notice that the last year or two has seen new editions of many of Perl's best known books (Programming Perl (Camel book), Learning Perl (llama book), Intermediate Perl, and Effective Perl).
The Perl community is still alive and vibrant, you just have to open your eyes to it.
]]>Stickey Notes - http://www.sayakbanerjee.com/sticky-notes/
It's written in PHP, but it's the nicest and easiest one I could find when I was looking for one to deploy for primarily personal use.
]]>stringByReplacingOccurrencesOfString
is a joke and not a real method/function name from what I assume is a standard library?
Seeing things like that makes me want to beat people over the head with their keyboards (specifically, people who come up with method/function/variable names like that).
]]>find2perl
(translates a find-style command line into equivalent Perl code). All the power of Perl, with the rapid development and flexibility of the find
command line.]]>