|
Re: Five Features Perl 5 Needs Now
by moritz (Cardinal) on Dec 19, 2008 at 11:40 UTC
|
It's also worth noting that chromatic also submitted a patch to p5p to introduce the class keyword, see for example here and many other recent threads on p5p. | [reply]
[d/l] |
|
|
Yes, but Rafael doesn't like it as it's now, as it adds very little to perl - it just adds syntax. I can't say I disagree with that.
| [reply] |
|
|
What's wrong with adding "just syntax" for now?
"Just syntax" is the difference between how you use the regex engine in Perl, and how you use it most other languages (where load a library, compile a pattern, and match it).
"Just syntax" is often the difference between a feature that's used very often, and one that's mostly avoided.
"Just syntax" is also what distinguishes Perl from most other languages, and Perl 6 from Lisp. (Ok, my last point about Perl 6 is not 100% serious, but you get the picture).
| [reply] |
|
|
|
|
Re: Five Features Perl 5 Needs Now
by JavaFan (Canon) on Dec 19, 2008 at 12:41 UTC
|
1. Regular releases
Yes, that would be very nice. But making a release is a lot of work. It has to work on all the platforms supported, not break any test, and there shouldn't be loose ends.
Unfortunally, making a release boils down to a lot of work done by very few people.
2. Moose, Mouse, and autobox.
While I think a better OO system for perl5 would have been wonderful 14 years ago, I don't think perl5 "needs" Moose or Mouse in the core. And they already exist on CPAN. I also don't think changing the OO system this late in the game is worthwhile. Nor do I think it's going to happen. Many people will say "yes". Much bikeshedding will go on. And noone will actually do it.
3. Python's ctypes.
Ah, yes, the old "XS is hard" argument. I can't argue with that. And it would be nice if someone invented something easier, and implemented it. Actually, someone already did, and called in Inline. Again, who's going to do the work?
4. Better CPAN integration.
Easier said then done. There's CPANPLUS and it took a lot of effort to get that integrated in the core. On the author side, there is Module::Build and a few other alternatives to Extutils.
5. mod_perlite
That seems to be an existing Apache module. What's the "need" for perl5?
Nicholas Clark is fond of saying "perl development is driven by people who haven an itch". Which basically means "something is only going to be added/changed if someone is motivated enough to do the work".
Perl5 isn't dead. And Perl5 won't die even if it doesn't implement any of the points mentioned by chromatic. 5.12 will happen. Probably even before perl6.
| [reply] |
|
|
But making a release is a lot of work.
We've seemed to manage it 24 months in a row for Parrot.
Much bikeshedding will go on. And noone will actually do it.
I ported a proof-of-concept of roles to Perl 5 several years ago, and I wrote the class patch for Perl 5 last week.
It would be nice if someone invented something easier, and implemented it. Actually, someone already did, and called in Inline. Again, who's going to do the work?
I backported Parrot's solution as a proof-of-concept for Perl 5, again several years ago.
What's the "need" for perl5?
CGI is dead-ish, and mod_perl isn't easy to configure or deploy, and it's a lot of overkill for a shared-hosting account. Somehow mod_php has managed to make thousands of PHP apps as easy to install as "Drop this file in a directory." Isn't ease of deployment important?
Nicholas Clark is fond of saying "perl development is driven by people who haven an itch". Which basically means "something is only going to be added/changed if someone is motivated enough to do the work".
How much more code do I have to write to earn the right to make suggestions?
| [reply] |
|
|
Nicholas Clark is fond of saying "perl development is driven by people who haven an itch". Which basically means "something is only going to be added/changed if someone is motivated enough to do the work".
s/do the work/maintain the work/
Proofs of concept are easy(ish), patches are harder, maintaining features/modules in core is harder yet. There are a lot of great suggestions that seem to stall for lack of volunteer labor. Oh, well, that's life.
I wish these kinds of threads could be more productive than this prototypical exchange:
Tweedledee: X would be a cool feature!
Tweedledum: X is hard/incompatible
Tweedledee: but if X could be done, it would be great!
Tweedledum: if you want X, then write the code
Tweedledee: !?!
Sometimes a wish list is just a wish list.
Maybe the original article should have been titled "Five Features I Wish Someone Would Commit to Adding and Maintaining in Perl 5" -- but that doesn't exactly have the same ring. ;-)
-xdg
Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.
| [reply]
[d/l]
[select] |
|
|
|
|
|
|
|
|
|
|
|
|
|
Easier said then done.
That's true of all these things. Saying it adds no information.
Perl5 isn't dead.
Then why are you so down on the idea of adding significant features, such as the above, to Perl 5?
You make it sound like it's too late. Like maybe p5p should only be concerned with bug fixes from here on?
Don't forget that Perl 5 has been moving toward Perl 6 for some time now. Should that trend stop? You seem to think so.
In any case, I think chromatic is in a pretty strong position to say what Perl needs now.
Between the mind which plans and the hands which build, there must be a mediator... and this mediator must be the heart.
| [reply] |
|
|
Then why are you so down on the idea of adding significant features, such as the above, to Perl 5?
I never said that. I don't think they are features that are needed now. Some of them are certainly nice. But perl5 will survive if they won't happen.
| [reply] |
|
|
|
|
Easier said then done. There's CPANPLUS and it took a lot of effort to get that integrated in the core. On the author side, there is Module::Build and a few other alternatives to Extutils.
That wasn't his point. He was suggesting that the build/test/install cycle is kludgy. Which is one reason why there is PPM. Of course, someone has to build and maintain PPM files and the latest and greatest releases aren't always available. Which is why some people still want to build/test/install direct from CPAN. (c.f. Strawberry Perl.)
-xdg
Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.
| [reply] |
|
|
| [reply] |
|
|
|
|
| [reply] |
|
|
I think this particular feature would clear the brush a bit, making it possible to actually see the trees.
/J
| [reply] |
|
|
Actually, someone already did, and called in Inline. Again, who's going to do the work?
The exact equivalent is Win32::API/C::DynaLib, but they're broke/old/unmaintained.
| [reply] |
Two more Features Perl 5 Maybe Needs
by LanX (Saint) on Dec 20, 2008 at 13:27 UTC
|
sub get_hash { my %h; ... ;return \%h}
my (*h2)= get_hash(); #I'm not sure about the best syntax
print keys %h2;
such that beginners don't need to learn dereferencing straight away, just because they have nested data structures or want to return them from a sub.
7. Introducing optional extra Sigils for Hashes and Arrays which behave like the sigils in perl6, that means representing the reference not the list!
¥hash{key1}{key2}=$hash{key1}{key2};
€arr1[0]=€arr2;
# =>
€arr1[0][0] == €arr2[0];
push €arr1[0], "string";
# =>
pop €arr2 == "string";
I know finding appropriate symbols in all charsets is complicated, but this could facilitate forward compability to perl6, if perl6 could then use these symbols as alternative aliases for @ and %.
just ideas ...
| [reply]
[d/l]
[select] |
|
|
I most wholeheartedly agree with the 6., but do not see any need for the 7. The sigils we have are great, the system works and makes sense (and the change in the system of sigils is gonna cause a heluva lot of wasted time while seasoned Perl5 developers struggle to relearn sigils working the Perl6 way), but there is no need to complicate it any more. BTW, IMnsHO the changes to sigils and the concatenation and method call operators were both bad ideas.
Besides, after a lot of thinking, I (hopefully correctly) inferred the intended meaning of the array examples, but still have no idea whatsoever what did you mean by the first line.
| [reply] |
|
|
--- New --- Internally
¥hr == $hr
¥hr{k1} == $hr->{k1}
¥hr{k1}=¥hr2 == $hr->{k1} = $hr2
keys ¥hr == keys %$hr
keys ¥hr{k1}{k2} == keys %{ $hr->{k1}{k2} }
print €ar[1] == print $ar->[1]
print @€ar[1] == print @{ $ar->[1] }
hope that's clearer ... Tomorrow I'll try to hack a codefilter as a proof of concept.
Actually if point 7 is realized, one don't really need point 6 any more ...
sub foo {
return ( [], {} )
}
my (€ar,¥hr) = foo();
But your right the first line was misleading! ... I got confused with the new idea of compability to perl6 syntax...but now I think that's far to complicated to achieve with the perl5 parser. | [reply]
[d/l]
[select] |
|
|
|
|
|
|
|
| [reply] |
|
|
32,300 Results for "perl beginner problem nested arrays".
</argument sarcasm=off>
| [reply] |
|
|
|
|
|
Re: Five Features Perl 5 Needs Now
by Jenda (Abbot) on Jan 16, 2009 at 02:06 UTC
|
| [reply] |
