"Perhaps backwards compatibility is cannibalizing usage from current"
I agree with this.
Python had a totally different approach and it seems that it was a good
idea.
It would be nice to have a Perl with strict and warnings enabled by default
that could be disabled on request
This way the maintained old projects could be easily modified to continue to
work but the unmaintained poor scripts that could be found on the net will
stop working and they won't promote an old and bad programming style.
I also think that Perl 5 would have been a little more successfully if Perl
6 didn't exist at all.
Not because the work force was consumed on Perl 6 instead of Perl 5, but
because after announcing that Perl 5 is not a language for the future so the
world needs Perl 6 which practically will be another language, the world
understood that Perl 5 is dead, and it doesn't matter too much that since
that day Perl 5 evolved.
And regarding about what we need from a new Perl 5 core, I think that the
improvements like given/when or even some operators like defined or are not
something extraordinary, because they are just syntaxes that can be done in
very old Perl versions, using other keywords. Maybe not so nice and short,
but it could be done and very clear.
The weak points of Perl is that it is less powerful than Python for
interacting with Windows, which will be the most used OS for a long time
from now on, and most members of the Perl community don't even care about
Windows and the compatibility with this OS.
Yeah, ActiveState done a very good job, however I've seen that in most of
their announcements in the last time, the order of the languages they
support are Python, Perl, ... and it is very normal for a company to be
interested by the bigger market.
Perl also doesn't support real threads under Windows which is also a very
bad thing because it is more complicated to use shared variables with the
current threads, and those variables consume more memory, and the threads
are huge anyway.
Yes, I know that the recommendations are to not use threads, but events or
other ways, but in desktop apps it would be more natural and easy to use
more threads, and in most of these apps it is compulsory to have a distinct
thread that manages the interface and other threads that do the work.
Another Perl disadvantage is CPAN. Yes, this great advantage can be a
disadvantage sometimes.
If all the modules on CPAN would have a version that could be packed into a
.zip archive, so the developer would just need to unarchive the distribution
they need it somewhere in the free hosting server they use, without needing
to compile C code, without needing to understand and debug C errors, without
needing to have shell access, Perl would have been more successful.
The CPAN modules are easy to install, but they depend very much one on
another so very many distributions on CPAN which would have been working
fine, can't be installed due to a dependency that cannot compile on some
platforms.
This doesn't look like a stable system of deploying modules...
Somebody asked a few weeks ago on a blog comment which were the success
apps/modules made in the last time for Perl, that were also ported to other
languages.
Well, because of CPAN and the many levels of dependencies, it is very hard
to port a Perl project to another language.
As well as Perl wants to maintain a backward compatibility for decades, it
insists to be compatible with zillions operating systems, but the result is
that very many modules are not compatible with Windows which has a larger
user base than many other systems together.
But this almost perfect compatibility with Unix/Linux/Windows/Mac is just
like a dream now, because until Perl won't be able to use a virtual
machine, it won't be possible.
I don't have enough data, but I think that the average age of Perl
programmers is higher than the average age of Python programmers, or C#/Java
programmers also.
This is a problem, because a higher age not only that involves less time to
study and a smaller desire for changes, but it also involves many production
programs done and working fine that should be maintained, while new
programmers don't care about the backward compatibility nor about the future
of their old programs. They are even very glad to change things and let the
changes destroy the past, because this is their chance to show their talent
and let the old apps and languages die.
Let's see, why are there so many PHP programmers? Because the language is
simple to use, of course. But would it be so successful if PHP would also
have just a few built in functions and all other modules need to be
downloaded/compiled/installed from a repository like CPAN?
Python is much better than PHP, and why is it more and more successful in
the last time if it doesn't have such a great thing like CPAN? Yes, because
Google promotes it, but why doesn't Google promote Perl?
The answers to these questions are the answers to the question "What do we
need from a new Perl core?".
- TIMTOWTDI, but Perl should crash with an error when the recommended way is
not used - for example it could use something like Perl::Critic/Perl::Tidy
as default pragmas, not as external apps. This was a very good idea I found
in an interview made by Randal;
- Perl support for threads (real thin threads that share the memory) and not
huge processes that work like treads;
- Better support for operating systems (not only for Windows);
- Better support for desktop apps (There are very few developers for
WxPerl);
- An easier deployment of any apps, even on shared hosting servers, without
shell access;
--Octavian
----- Original Message -----
From: "flebber" <flebber.c...@gmail.com>
To: <beginners@perl.org>
Sent: Friday, November 18, 2011 4:49 AM
Subject: Chromatics - Why is funding Perl So Hard
I was reading chromatics article on his thoughts on why perl funding
was so hard.
It can be found here
http://www.modernperlbooks.com/mt/2011/11/why-is-funding-perl-core-development-so-difficult.html
Though i had other things to do, it sort of got to me. Couldn't stop
thinking about it in the back of my mind. Above all chromatic listed
10 points he was weighing up regarding the issue.
I needed more information, the key thing I kept thinking was "Are we
asking?" if we are do they say no and why. I tried to find evidence of
us asking, I found the charities committte the perl foundation
http://www.perlfoundation.org/press_releases after reviewing the page
and its docs(all very professional) I still had the same concern. More
so that whilst the committee may be asking are they clear in what they
were asking for, the page beyond saying help perl it doesn't ask for
anything in particular. There is no "Help Perl achieve x goal and this
will provide y benefit to you!" In my summation of life people don't
usually give unless they see something in it for them.
So I searched google "perl what do people want". I found this recent
post by Leon Timmermans
http://blogs.perl.org/users/leon_timmermans/2011/10/why-do-you-want-new-major-features-in-core.html
. It's an interesting article, whilst it doesn't directly answer the
question it does raise a question my head as a newbie to Perl. It
appears that it could be said that 5.10 introduced several "trinkety"
features (see Leon's article). Hmm if I had invested money in perl
development at this time would I feel it wasn't well spent or
directed? Would I then want to invest again?
The pumpking has proposed several improvements and perhaps a certain
level of breakage in backwards compatibility by flagging using use
5.16 for the upcoming perl release.
Perhaps the best thing Perl funding could benefit from is openly
asking those who would/could invest for feedback on what they want
from Perl? What would make them want to invest in upgrading from
5.6/5.8 to 5.16 say?
Maybe the journey could be started by identifying "trinkety" and
unused features in Perl and getting consensus on their removal. By
removing cruft it would allow Perl the people and the charities
committee to highlight the positive language enhancements that have
been made since perl 5.6. It reduce the amount of new effort required
in developing and it could insure a new killer feature such as
class:MOP may successfully make it into 5.16.
Rather than being a revolution 5.16 could be Perl "Smart Evolution" a
line in the sand with a clearer focus smart new language features and
a solid base for new development. Could it provide the catfor old
alyst for new tutorials, books that can focus on "Perl Now" and not
have concern for old code for which there already exists a plethora of
resources.
New books, new tutorials means more Perl Buzzzz which means more
interest and more money and fundng!! Or does it?
Sayth
--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/
--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/
