Hi,
On 2011.05.10. 15:13, Ferenc Kovacs wrote:
<...>
so the problem is, that the userland is under-represented in the
development, because they usually not present on the mailing list and on
irc, where discussions and decisions happen, and they usually have different
priorities and expectations about the PHP language than the core devs.
to make things worse, they cannot write patches for the core, and the core
devs rarely work on something which they don't particularly need or like.
and I think that the only option where we can change that, is that us, the
php userland devs has to be more active on the mailing lists, irc, bug
tracking, writing RFCs etc.
I have a feeling that even though PHP's users are happen to be
developers, they won't do these. Or they might do, but they'd
practically become core developers.
Open Source users want shiny web42.0 interfaces where they can 'upvote'
ideas. And if every year the topmost idea would get implemented, they
would be happy. (It's just how humans work, in my opinion.)
PHP users might file bugs. Might read RFCs when linked to. Occasionally
read the mailing list to figure out What's cooking in Internals. But
after seeing endless pages about "get a perfect idea, write a patch,
document it in an RFC, wait for SVN account, and maybe we'll look at it"
they aren't likely to jump in.
And even though some parts of the userbase is quite engaged (
https://github.com/symfony/symfony/pulls
https://github.com/symfony/symfony/graphs/traffic - selection bias and
whatnot ), there's still a very big barrier between writing a pull
request on the off chance that some might incorporate it versus raging
on internals for months.
So, it's just not going to happen.
Thus I don't find it surprising that framework/library developers are
the ones hanging around and not the CompSci freshmen that stumbled upon
a PHP tutorial.
Also, PHP being in fact very flexible and fast, and well documented,
there aren't a lot of userland problems that would scream for immediate
divine core developer intervention. So that's an other factor why
there's little to no interaction with developers.
And when there are problems, they're usually very complex (unicode) or
solving them would require virtually shifting the whole language
(multi-threading support, from more opcode caching to pre-compiled
"binaries", long running persistent PHP apps to reduce class loading and
other initialization penalty). It looks like for most uses of PHP other
languages would be better suited, except they suck more for various
reasons (Java - plain old and full of bloated frameworks; Scala - too
much awesome packed into it results in a steep learning curve; ASP.NET -
Windows only).
And I haven't mentioned Python, because it gets used, it's growing (and
I suspect a lot of people are 'converting' to it):
http://www.go-hero.net/jam/11/languages
--
Pas
ps:
"Right now I think PHP has reached a milestone, where it is a need to
take a break from large feature developing"
your suggestions also contains really large features.
I would add the unicode and LFS support for that list.
they are both long requested features, and nothing really happening to solve
those.
Tyrael
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
