Stas,
On Wed, Jan 9, 2013 at 11:58 AM, Stas Malyshev smalyshev@sugarcrm.comwrote:
I seriously hope it never comes to this in PHP
Would you shut up with this rhetoric already? All it does is show that
you're completely and utterly out of touch with the reality of modern
development.
Frankly, I'm getting sick and tired of seeing these recurring themes of
"PHP is not java" and "I never want this". If you never want this, then
don't contribute to the discussions at all.
If you have solid feedback to provide, then provide it. But saying "We're
supposed to be simple language for doing cool stuff on the web" shows you
have no idea what people have been doing (or don't want to acknowledge)
with the language for the past 5 years.
And that brings us to the root of the problem. Discussion like this is due
to the fact that there's no clear "official" vision for PHP. Each
participant brings their own concept and vision, and treats it like it's
everyone else's vision as well (which is the exact reason for your reply).
The need for voting is a byproduct of this lack of vision, not a
requirement in its own right.
For all the problems that a Benevolent Dictator brings to a project, this
is not one of them. This is a case where a dictator that sets the vision in
clear and unambiguous terms would actually improve the process quite
significantly. Instead of worrying about voting or everyone doing what they
want, there's a benchmark to measure proposals against.
For example, imagine these different visions for PHP (which I know for a
fact are shared on this list):
- "PHP Should Strive To Be A Full Featured Object Oriented Language".
In this context frame, things like annotations, mixins, generators, etc
become the focus. As would moving the error handler to exceptions. And a
host of other changes (boxing primitive types when treated like an object,
etc). Adding functions like array_get_whatever would be frowned upon...
- "PHP Should Remain A Procedural Language WIth Some OO Features"
In this context frame, a lot of the stuff I said above goes away. And
adding new array functions would be the norm. And it's plain to tell that
exceptions shouldn't be implemented for errors.
- "PHP Should Be Implementation Neutral, and Support
All Paradigms Equally".
This is as close to the current implementation as we currently are. We
support procedural, OOP and functional constructs. But how deep does it go?
Where's the line.
PHP NEEDS a vision. It needs something to guide development. Not everyone
will agree with it. And that's the point. It levels the playing field for
contributions and discussions. Rather than every developer playing for
themselves and saying "I hope this never happens", it puts it in the
context of "I don't believe this fits our vision". Note the difference in
tone between them.
It's an ongoing joke about how abusive and unproductive the internals list
is. I for one am sick of it. And rather than keeping ignoring it (or
walking away), I'd rather see it fixed.
Anthony
PHP NEEDS a vision. It needs something to guide development. Not everyone
will agree with it. And that's the point. It levels the playing field for
contributions and discussions. Rather than every developer playing for
themselves and saying "I hope this never happens", it puts it in the
context of "I don't believe this fits our vision". Note the difference in
tone between them.
The vision has been the same for years. A general purpose scripting
language with a focus on web development. You are simply saying you want
the vision to be more specific than that because everyone has a
different view of what web development means. But even if we narrow the
vision, it will still be open to a lot interpretation. We try to strike
a balance between the different and changing views of web development
the same way we strike a balance between appealing to weekend warriors
and top-100 trafficed sites. No vision statement is going to answer the
question of whether annotations should be in docblocks or in the core
language. That's simply not what vision statements do.
-Rasmus
PHP NEEDS a vision. It needs something to guide development. Not everyone
will agree with it. And that's the point. It levels the playing field for
contributions and discussions. Rather than every developer playing for
themselves and saying "I hope this never happens", it puts it in the
context of "I don't believe this fits our vision". Note the difference in
tone between them.The vision has been the same for years. A general purpose scripting
language with a focus on web development. You are simply saying you want
the vision to be more specific than that because everyone has a
different view of what web development means. But even if we narrow the
vision, it will still be open to a lot interpretation. We try to strike
a balance between the different and changing views of web development
the same way we strike a balance between appealing to weekend warriors
and top-100 trafficed sites. No vision statement is going to answer the
question of whether annotations should be in docblocks or in the core
language. That's simply not what vision statements do.-Rasmus
Sure. A vision statement won't say "annotations FTW" or "Objects FTL".
But it provides a soft metric and rough target toward which to keep
moving, and we can all subjectively measure proposals against that
metric, rather than subjectively against our own personal metrics.
As a former member of the Board of Directors for the Drupal Association,
I feel having a formal visioning process is one of the best things we
ever did.
+1 to Anthony on needing an actual publicly-documented vision for the
PHP project. Even if it doesn't have a BDFL, having some clear standard
against which we measure the essence of proposals would be beneficial.
--Larry Garfield
2013/1/9 Anthony Ferrara ircmaxell@gmail.com
Stas,
Would you shut up with this rhetoric already? All it does is show that
you're completely and utterly out of touch with the reality of modern
development.Frankly, I'm getting sick and tired of seeing these recurring themes of
"PHP is not java" and "I never want this". If you never want this, then
don't contribute to the discussions at all.
What's the point? If only those who agree can talk, I'm not sure about the
result...
If Stas doesn't like the proposed syntax, how can he express his dislike in
a sufficiently positive manner? (it's a honest candid question; I'm asking
it even after receiving nice and harsh responses to my patch proposal last
summer)
PHP NEEDS a vision.
Rasmus' answer was about balance. I guess it's hard to strongly define what
a language should be; there is no drawable line. Each step is questionable
in some way, This balance is the strength of PHP, the root of its
flexibility.
But I totally understand your frustration.
Amaury,
Would you shut up with this rhetoric already? All it does is show that
you're completely and utterly out of touch with the reality of modern
development.Frankly, I'm getting sick and tired of seeing these recurring themes of
"PHP is not java" and "I never want this". If you never want this, then
don't contribute to the discussions at all.What's the point? If only those who agree can talk, I'm not sure about the
result...If Stas doesn't like the proposed syntax, how can he express his dislike
in a sufficiently positive manner? (it's a honest candid question; I'm
asking it even after receiving nice and harsh responses to my patch
proposal last summer)
Well, the point is that there are two ways of voicing your dislike. You can
say "I never want this" or other rhetoric, which helps nobody else but to
understand that you don't want it. Or you can be a little bit more civil
and reply detailing your concerns, and say "Based on that, I don't like
it".
There's a HUGE difference between the two. One puts a foot down on the
ground. The other shares concerns and lets people learn from why. To be
fair, Stas did do a good job in those threads voicing his concerns.
But IMHO the "I never want this" and similar rhetoric has no place on a
mailing list for a language in an Open Source project...
PHP NEEDS a vision.
Rasmus' answer was about balance. I guess it's hard to strongly define
what a language should be; there is no drawable line. Each step is
questionable in some way, This balance is the strength of PHP, the root of
its flexibility.
But I totally understand your frustration.
Well, I'm not saying we should "strongly define" the language. I'm just
saying a vision statement that's a little more specific than "web language"
would frame the discussions in a context that could make them significantly
more productive... But it shouldn't be so rigid that there's a drawable
line. But the line should be implied enough that the discussion around a
feature leads to the precise line. As it currently stands the discussion is
more akin to determining if a line exists, yet alone where it is...
Anthony
Well, the point is that there are two ways of voicing your dislike. You can
say "I never want this" or other rhetoric, which helps nobody else but to
understand that you don't want it. Or you can be a little bit more civil
and reply detailing your concerns, and say "Based on that, I don't like
it".
Amaury has a point, though.
Personally, I don't think annotations belong in PHP. Now, I can
explain why based on my use of Symfony and Doctrine, but that suggests
that I'm going to change my mind when truthfully, I'm almost certainly
not going to — it's a difference of philosophy, rather than something
specific to the RFC or the patch.
So my dilemma is this: how do I voice this (without simply a drive-by
-1 vote, which isn't really helpful either, and is overly discouraging
to the people who've put a lot of work in to polish the feature up)
without being shouted down for being unhelpful or uncivil?
Adam, who isn't touching the rest of this discussion with a ten foot pole.
Annotations are already a part of PHP. They are widely used in one of the
most prolific frameworks, Symfony, and it's ORM "counterpart" Doctrine.
Both of which are serious drivers of the PHP community. It's
even potentially spreading to Zend Framework:
http://zend-framework-community.634137.n4.nabble.com/Annotations-own-implementation-or-Doctrine-Commons-td4655427.html
To say "they shouldn't be part of PHP" is fine, but it's too late for that.
Annotations are already here. Are we going to just ignore this fact and
hold back what a very significant portion of the community wants to see
because it conflicts with some ambiguous master plan for PHP?
Cheers.
Well, the point is that there are two ways of voicing your dislike. You
can
say "I never want this" or other rhetoric, which helps nobody else but to
understand that you don't want it. Or you can be a little bit more civil
and reply detailing your concerns, and say "Based on that, I don't like
it".Amaury has a point, though.
Personally, I don't think annotations belong in PHP. Now, I can
explain why based on my use of Symfony and Doctrine, but that suggests
that I'm going to change my mind when truthfully, I'm almost certainly
not going to — it's a difference of philosophy, rather than something
specific to the RFC or the patch.So my dilemma is this: how do I voice this (without simply a drive-by
-1 vote, which isn't really helpful either, and is overly discouraging
to the people who've put a lot of work in to polish the feature up)
without being shouted down for being unhelpful or uncivil?Adam, who isn't touching the rest of this discussion with a ten foot pole.
Annotations are already a part of PHP. They are widely used in one of the
most prolific frameworks, Symfony, and it's ORM "counterpart" Doctrine.
Both of which are serious drivers of the PHP community. It's
even potentially spreading to Zend Framework:To say "they shouldn't be part of PHP" is fine, but it's too late for that.
Annotations are already here. Are we going to just ignore this fact and
hold back what a very significant portion of the community wants to see
because it conflicts with some ambiguous master plan for PHP?Cheers.
Well, the point is that there are two ways of voicing your dislike. You
can
say "I never want this" or other rhetoric, which helps nobody else but
to
understand that you don't want it. Or you can be a little bit more
civil
and reply detailing your concerns, and say "Based on that, I don't like
it".Amaury has a point, though.
Personally, I don't think annotations belong in PHP. Now, I can
explain why based on my use of Symfony and Doctrine, but that suggests
that I'm going to change my mind when truthfully, I'm almost certainly
not going to — it's a difference of philosophy, rather than something
specific to the RFC or the patch.So my dilemma is this: how do I voice this (without simply a drive-by
-1 vote, which isn't really helpful either, and is overly discouraging
to the people who've put a lot of work in to polish the feature up)
without being shouted down for being unhelpful or uncivil?Adam, who isn't touching the rest of this discussion with a ten foot
pole.--
You've touched the main point I think we should consider - we're
contributing for the community - if the community wish so much that
feature, that they've hacked some other (doccomment) in order to get their
desired result - I think that this is the best evidence that we should
include that in the language - the community really wish to have it.
Annotations are already a part of PHP. They are widely used in one of the
most prolific frameworks, Symfony, and it's ORM "counterpart" Doctrine.
To explain what I meant by "PHP", since I think we're arguing
semantics there: I mean php-src specifically, rather than the broader
userland community, since we're on Internals.
To say "they shouldn't be part of PHP" is fine, but it's too late for that.
Annotations are already here. Are we going to just ignore this fact and hold
back what a very significant portion of the community wants to see because
it conflicts with some ambiguous master plan for PHP?
I don't have a master plan (that would be the part of this thread I'm
not touching), but if it's a poorly thought out feature, sure. Pretty
much every major project out there uses a unit testing framework and
ORM: does that mean we should also be including equivalents for
PHPUnit and Doctrine in core?
Basically, I think the trend towards configuration as behaviour is an
antipattern that results in less readable, harder to debug code.
Having said that, the beauty of our userland being a set of
communities is that each community can make their own decisions —
since the good folks behind Doctrine have written an excellent
annotation parser, those who want to go that way can, but it doesn't
mean PHP has to go out of its way to encourage it.
Or, to put it another way, not everything has to be a language
feature. That way lies Perl.
Adam
Great points, Adam. I disagree with this one feature being excluded but I
do agree that just because something is in the userland doesn't necessarily
mean it should be in the core-- making my point rather moot.
Cheers.
Annotations are already a part of PHP. They are widely used in one of the
most prolific frameworks, Symfony, and it's ORM "counterpart" Doctrine.To explain what I meant by "PHP", since I think we're arguing
semantics there: I mean php-src specifically, rather than the broader
userland community, since we're on Internals.To say "they shouldn't be part of PHP" is fine, but it's too late for
that.
Annotations are already here. Are we going to just ignore this fact and
hold
back what a very significant portion of the community wants to see
because
it conflicts with some ambiguous master plan for PHP?I don't have a master plan (that would be the part of this thread I'm
not touching), but if it's a poorly thought out feature, sure. Pretty
much every major project out there uses a unit testing framework and
ORM: does that mean we should also be including equivalents for
PHPUnit and Doctrine in core?Basically, I think the trend towards configuration as behaviour is an
antipattern that results in less readable, harder to debug code.
Having said that, the beauty of our userland being a set of
communities is that each community can make their own decisions —
since the good folks behind Doctrine have written an excellent
annotation parser, those who want to go that way can, but it doesn't
mean PHP has to go out of its way to encourage it.Or, to put it another way, not everything has to be a language
feature. That way lies Perl.Adam
I'd love if Stas, Derick, Rasmus or Zeev comment here on criteria about
acceptance of new features.
You all claim that PHP is simple, that features include should be widely
used and only important functions, classes that have regular and extensive
usage would be in.
I wonder how Annotations is different from Traits or Aspects.
They all include new tokens on parser, they all "slow down" (as you keep
claiming everytime) and they all have specific niches to be used. Now I
wonder how Traits got IN, Aspects got rejected in 2007 and Annotations is
being a nightmare to you guys.
Or will you guys claim that Traits will be vastly used?
Also talking about widely used support, I wonder about how
SplDoubleLinkedList, SplInt, SplMaxHeap and all these classes that have
very specific usages, just like also data structure readers like
json_decode, parse_ini_file are part of the core while others also used as
much as these ones like yaml_file are out.
If this is a clear vision, sorry, I'm probably too dumb to understand.
OOP is a trend in PHP and no matter what you guys try to do, procedural
support is quite decent, OOP is getting there aswell as functional. We're
just trying to improve OOP, which lacks of many different features that
many users ask and keep hitting the wall.
You guys may now know, but 9 out of 10 most used frameworks are entirely
OO. It's a shame that because Yahoo code is procedural (worked at Yahoo
already), SugarCRM code has terrible OO decisions (I've seen its code),
adopting exceptions handling !!!in July 2012!!! that makes you guys say
there's no need to improve on OO features that community is claiming.
I implemented support in 2009, asked for this in 2010 and since then I've
seen only in this ML the same feature being asked not by me at least more
10 times. Isn't it a sign of a feature demand?
Great points, Adam. I disagree with this one feature being excluded but I
do agree that just because something is in the userland doesn't necessarily
mean it should be in the core-- making my point rather moot.Cheers.
Annotations are already a part of PHP. They are widely used in one of
the
most prolific frameworks, Symfony, and it's ORM "counterpart" Doctrine.To explain what I meant by "PHP", since I think we're arguing
semantics there: I mean php-src specifically, rather than the broader
userland community, since we're on Internals.To say "they shouldn't be part of PHP" is fine, but it's too late for
that.
Annotations are already here. Are we going to just ignore this fact and
hold
back what a very significant portion of the community wants to see
because
it conflicts with some ambiguous master plan for PHP?I don't have a master plan (that would be the part of this thread I'm
not touching), but if it's a poorly thought out feature, sure. Pretty
much every major project out there uses a unit testing framework and
ORM: does that mean we should also be including equivalents for
PHPUnit and Doctrine in core?Basically, I think the trend towards configuration as behaviour is an
antipattern that results in less readable, harder to debug code.
Having said that, the beauty of our userland being a set of
communities is that each community can make their own decisions —
since the good folks behind Doctrine have written an excellent
annotation parser, those who want to go that way can, but it doesn't
mean PHP has to go out of its way to encourage it.Or, to put it another way, not everything has to be a language
feature. That way lies Perl.Adam
--
Guilherme Blanco
MSN: guilhermeblanco@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada
Also talking about widely used support, I wonder about how
SplDoubleLinkedList, SplInt, SplMaxHeap and all these classes that have
very specific usages, just like also data structure readers like
json_decode, parse_ini_file are part of the core while others also used as
much as these ones like yaml_file are out.
A bit off-topic, but I'm wondering how the SPL datastructures ever
passed peer review . . . which does bring me to a relevant topic:
We need to make sure we release quality implementations of whatever it is we do.
Hi!
I'd love if Stas, Derick, Rasmus or Zeev comment here on criteria about
acceptance of new features.
I can answer only for myself of course, but I don't have any single
"criteria". I look at the feature, how it can be used, how it can be
abused, how it would be seen by experienced PHP developer, how it can be
seen by novice PHP developer, how easy is to understand what's going on,
how much impact it would make on performance and robustness of the
language, how easy or hard would be for tools to support it, etc. etc. -
and then discuss with authors and decide if I'd like to have such thing
or not.
I wonder how Annotations is different from Traits or Aspects.
I'm not sure what you mean by Aspects, but traits are different from
what was proposed as annotations because they are much simpler both
conceptually (you just put a couple of methods from one class to
another, same thing you do with inheritance but without full-blown OO
"is-a" contract) and syntactically. If annotations were at the same
level, I'd not have much problem with them, not at all. However, what is
proposed is more akin to sub-language, with its own syntax, complex
expressions, nested object instantiations and all this has to happen in
some weird space which is both code and not code. And of course it
should also have syntax that is both different from any other language
that does the same, looks like completely different syntax in at least
two other popular programming languages and two popular markup
languages, and is chosen by principle of "which symbol didn't we use
yet?". This seems to me a wrong way to do it. Not because I'm opposed to
the idea in principle, but because I'm opposed to how it is done.
Or will you guys claim that Traits will be vastly used?
I have no idea. We will see. How can I know what a million of people
will be doing?
Also talking about widely used support, I wonder about how
SplDoubleLinkedList, SplInt, SplMaxHeap and all these classes that have
very specific usages, just like also data structure readers like
json_decode, parse_ini_file are part of the core while others also used as
much as these ones like yaml_file are out.
I'm not sure what you're getting at here. If you think we need to add
YAML extension to core packages, please write an RFC, explain why is
this extension good enough and required, have a vote and we'll see. I'm
not sure why you're bringing it in this topic.
You guys may now know, but 9 out of 10 most used frameworks are entirely
OO. It's a shame that because Yahoo code is procedural (worked at Yahoo
already), SugarCRM code has terrible OO decisions (I've seen its code),
adopting exceptions handling !!!in July 2012!!! that makes you guys say
there's no need to improve on OO features that community is claiming.
And I can't even begin to understand what you are talking about here.
Nobody ever said there's no need to improve on OO features, and how
SugarCRM code has anything to do with anything it's just beyond my
comprehension. That doesn't mean we need to get anything any OO language
has into PHP. Some of it is good for PHP, some of it would be better
done differently.
10 times. Isn't it a sign of a feature demand?
I know that some folks want to have syntax like this:
@MyApp\Acl({
"allow"=@MyApp\Acl\Allow({"john"="read", "joe"="write"}),
"deny"=@OtherApp\Acl\Deny(default="*", log=true)
})
and even more complex to be part of PHP function and property
definitions. I think it is misguided on multiple levels. That does not
mean some metadata support won't be useful - it probably would be. But
not this way.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
guilhermeblanco@gmail.com wrote:
I'd love if Stas, Derick, Rasmus or Zeev comment here on criteria about
acceptance of new features.
You all claim that PHP is simple, that features include should be widely
used and only important functions, classes that have regular and extensive
usage would be in.
I'd use the past tense there ...
And I'll get beaten around the head again.
PHP is a very nicely modular 'framework' on top of which many other views of the
world have now been built. We DON'T need to load a lot of the recent
developments ... we don't need to use them. Personally I don't load any MySQL
related extensions since I don't have MySQL loaded. APC is replaced by
eaccelerator which continues to work well for me (currently!). I've use
phpdocumentor since I started with PHP because that was what all of the
libraries USED internally to model/document the API, and since I used Eclipse as
my IDE for C/C++ code, PHPEclipse was a natural progression and also uses the
docblock information to provide in-line type hinting and a lot of the
information that people are now clamouring to build in to the 'language'?
I can understand some of the drives to 'new features', but I know I'm not alone
in feeling rail-roaded into having to accept changes that are just detracting
from writing code. Perhaps we can ignore 'e_strict' but the fundamental problem
doing that is that moving 5.2 based code to 5.5 is simply not practical. Setting
up a system that will run 5.2 code cleanly on a 5.4 configuration is only
practical if you have a completely different set-up for clean 5.4 code! We
NEEDED a better vision 5 years ago :( Now we need to manage the fallout and I
know I keep banging on about it, but over 50% of user land are STILL using 5.2!
Only 1.8% have 5.4 running with the main movement over the last few months TO
5.3 simply because that is the easiest way for ISP's to support their customers.
( http://w3techs.com/technologies/details/pl-php/5/all )
Bolting more and more facilities into core because a few users have the backing
to force them in does not help the vast majority of user-land users who don't
need those facilities. The argument that they need to be in the core so that
ISP's will provide them probably highlights the whole problem? If your
application needs some particular 'extension' to work then shouldn't that be
part of the 'application' rather than the 'infrastructure'? Isn't the fact that
one can add to PHP your own view of the world the whole point here. However it's
also the Achilles heel so there ARE now large groups of people 'doing their own
thing' and pulling things in a lot of different ways? Not everybody wants the
Symphony/Doctrine/ORM view of the world. We are happy with using the database
engine as the persistence layer, and a good abstraction layer as the interface
... code written 10 years ago still works ... or should do :(
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
The usage statistic is easy explained...
Long time there was no planned "release cycle" so nobody could plan to
upgrade (especially hoster and linux distributions, ...)
Another reason why many people stick with the old version is poor written
software like WORDPRESS -.-.
I would also like to see a vision like it was for PHP6....unicode support,
namespaces, ...
For annotations i cannot "vote", because i won't use them.
Best regards
Martin
2013/1/10 Lester Caine lester@lsces.co.uk
guilhermeblanco@gmail.com wrote:
I'd love if Stas, Derick, Rasmus or Zeev comment here on criteria about
acceptance of new features.
You all claim that PHP is simple, that features include should be widely
used and only important functions, classes that have regular and extensive
usage would be in.I'd use the past tense there ...
And I'll get beaten around the head again.PHP is a very nicely modular 'framework' on top of which many other views
of the world have now been built. We DON'T need to load a lot of the recent
developments ... we don't need to use them. Personally I don't load any
MySQL related extensions since I don't have MySQL loaded. APC is replaced
by eaccelerator which continues to work well for me (currently!). I've use
phpdocumentor since I started with PHP because that was what all of the
libraries USED internally to model/document the API, and since I used
Eclipse as my IDE for C/C++ code, PHPEclipse was a natural progression and
also uses the docblock information to provide in-line type hinting and a
lot of the information that people are now clamouring to build in to the
'language'?I can understand some of the drives to 'new features', but I know I'm not
alone in feeling rail-roaded into having to accept changes that are just
detracting from writing code. Perhaps we can ignore 'e_strict' but the
fundamental problem doing that is that moving 5.2 based code to 5.5 is
simply not practical. Setting up a system that will run 5.2 code cleanly on
a 5.4 configuration is only practical if you have a completely different
set-up for clean 5.4 code! We NEEDED a better vision 5 years ago :( Now we
need to manage the fallout and I know I keep banging on about it, but over
50% of user land are STILL using 5.2! Only 1.8% have 5.4 running with the
main movement over the last few months TO 5.3 simply because that is the
easiest way for ISP's to support their customers. ( http://w3techs.com/**
technologies/details/pl-php/5/**allhttp://w3techs.com/technologies/details/pl-php/5/all)Bolting more and more facilities into core because a few users have the
backing to force them in does not help the vast majority of user-land users
who don't need those facilities. The argument that they need to be in the
core so that ISP's will provide them probably highlights the whole problem?
If your application needs some particular 'extension' to work then
shouldn't that be part of the 'application' rather than the
'infrastructure'? Isn't the fact that one can add to PHP your own view of
the world the whole point here. However it's also the Achilles heel so
there ARE now large groups of people 'doing their own thing' and pulling
things in a lot of different ways? Not everybody wants the
Symphony/Doctrine/ORM view of the world. We are happy with using the
database engine as the persistence layer, and a good abstraction layer as
the interface ... code written 10 years ago still works ... or should do :(--
Lester Caine - G8HFLContact - http://lsces.co.uk/wiki/?page=**contacthttp://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.**uk<http://rainbowdigitalmedia.co.uk
Martin Keckeis wrote:
The usage statistic is easy explained...
Long time there was no planned "release cycle" so nobody could plan to upgrade
(especially hoster and linux distributions, ...)
Please respect site etiquette and don't top post ...
Your view of things is wrong simply because it is the release cycle that has
caused the situation. The move to 5.3 was stalled because many ISP's found that
having changed too many older sites were broken and they had to roll back.
Things are improving, but the current upgrade path is STILL to PHP5.3 despite
the fact it is now being run down. There is still no well defined upgrade path
to bring legacy code forward other than 'switch off the warnings', and the move
to PHP5.3 to 5.4 can only be made by ISP's when their clients code base is all
upgraded TO 5.3 standards, so that a move to 5.4 does not add to the troubles.
Another reason why many people stick with the old version is poor written software like WORDPRESS -.-
That may be the case. What is important here is being able to bring both code
and more importantly content from older systems to the newer platform. If a site
has several years of live data and is working for it's target audience what is
the incentive to spend time and money porting it to a different platform that
does not add any value. Most end users ARE using 'old version is poor written
software' but in many cases they have no capability of fixing that problem
themselves. The project platforms are racing ahead of the platform that the end
users are restricted to using :(
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Martin Keckeis wrote:
The usage statistic is easy explained...
Long time there was no planned "release cycle" so nobody could plan to
upgrade (especially hoster and linux distributions, ...)Another reason why many people stick with the old version is poor written
software like WORDPRESS -.-.
Chicken-and-egg problem: we still have ~2/3 of users on PHP 5.2:
http://wordpress.org/about/stats/
WordPress' code quality is improving vastly, but we have to deal with
backwards compatibility for our internal APIs (which is a big reason for
not having switched to PDO yet, e.g., although it looks like that will
land in our next major version) and we can't use the newest features. It
doesn't help that many of the nice things we'd like to use (e.g.
DOMDocument) are disabled in some of the distro packages (Debian/CentOS,
IIRC), but we've dealt with this in the past and we'll continue to do so.
--
Ryan McCue
<http://ryanmccue.info/
So my dilemma is this: how do I voice this (without simply a drive-by
-1 vote, which isn't really helpful either, and is overly discouraging
to the people who've put a lot of work in to polish the feature up)
without being shouted down for being unhelpful or uncivil?
In my humble opinion, if your only "argument" is a -1, the don't be part of
the discussion, but
rather be a vote when (and if) the RFC goes to a vote.
There are 2 moments to express yourself: the discussion, the vote.
In the discussion phase I believe opinion should be expressed with solid
concerns. Performance issues, bad syntax, is it relevant or not, etc.
A simple "i don't like it" does not add, so it can be ommited.
The voting is where you can simply say: i don't want this regardless of the
syntax
intent or how many unicorns it provides.
That is what i do.
--
Rafael Dohms
PHP Evangelist and Community Leader
http://doh.ms
http://wwwamsterdamphp.nl
2013/1/10 Rafael Dohms listas@rafaeldohms.com.br
In my humble opinion, if your only "argument" is a -1, the don't be part of
the discussion, but rather be a vote when (and if) the RFC goes to a vote.There are 2 moments to express yourself: the discussion, the vote.
In the discussion phase I believe opinion should be expressed with solid
concerns. Performance issues, bad syntax, is it relevant or not, etc.
A simple "i don't like it" does not add, so it can be ommited.
«is it relevant or not» => If I can't express my dislike, how can I say
that I think something is not relevant?
Sorry, but if something seems not good for PHP, any of us should share his
thoughts. Because it is pointless to work on RFCs and to write patches if
everybody agreed that the functionality is not needed. Discussions are not
here just to push new functionalities as far as possible, without arguing
if we need them or not, waiting for the vote to be the last safeguard.
Well, it's my humble opinion.
2013/1/10 Tyler Sommer sommertm@gmail.com
Annotations are already a part of PHP. They are widely used in one of the
most prolific frameworks, Symfony, and it's ORM "counterpart" Doctrine.
Both of which are serious drivers of the PHP community. It's
even potentially spreading to Zend Framework:To say "they shouldn't be part of PHP" is fine, but it's too late for that.
Annotations are already here. Are we going to just ignore this fact and
hold back what a very significant portion of the community wants to see
because it conflicts with some ambiguous master plan for PHP?
Last summer, I heard a talk from Rasmus. He was presenting what's new in
PHP. I remember there was something (I don't remember what exactly, sorry)
that seems a bit useless. Roughly speaking, Rasmus said that this kind of
functionality will not be used by everybody, but the guys who are writing
frameworks will love it.
This kind of evolution is fine. No problem to add things inside PHP, even
if they will be used by few people, as long as it will not change anything
for the rest of us.
When PHP went OO, I guess everybody agreed. We knew that, from this point,
PHP programming will deeply change, because new extensions will be object
oriented; but it was not a problem. Yes, object programming became the new
proper way to code in PHP, but it was still possible to do without it.
When PHP5 went deeply OO, it was not a problem either. Yet it was the
beginning of new changes. For example, if I want to use SPL, I will surely
have to use objects, interfaces and exceptions. But nobody is forced to do
this.
When traits came in PHP, again it was not a problem. You can use it, but
it's not an obligation. And it doesn't change how everybody should code.
There is multiple problems with annotations:
-
It's a language in the language. A new syntax to learn. It's not in the
code, but without it the code have fat chance to work anymore. -
It's a parser in the parser. More code to maintain inside PHP engine.
Maybe some performance issues. -
More important, providing annotations as it is proposed will make them a
core feature of the language. It will be perceived like objects,
exceptions, interfaces or visibility. And the direct impact is that PHP
will be seen as a more complex language. A really. More. Complexe. Language.
Yes, I know that C# has a lot of good ideas. But I also know that C# is not
seen as flexible and "teach-me-how-to-code-I-will-use-you-professionally"
as PHP.
It's true that annotations are already used by frameworks and ORM. But it
is their choices, and usually annotations are one of many possibilities to
configure code-related stuff.
Annotations are not seen as the right way of writing PHP code just because
annotations are used by Symfony and Doctrine. But if you put them inside
the core of PHP, annotations will gain this status. And I don't know what
to say except "I don't like it".
One last thought about the "PHP is not Java" thing. Anthony is bored by
that. OK. But maybe it's not totally pointless.
Many stuff were taken from Java, in the PHP's OO model. OK. The generator
concept came from Python. OK. There is some interresting things in many
other languages (Ruby, Lua). I guess it's OK to take inspiration from them.
When the "yield" keyword appeared, I don't remember anything like "PHP is
not Python". Why? Because it's a cool new feature, but it doesn't change
PHP behaviour.
Annotations are maybe too much for PHP; on the wrong side of the line. Yes,
I know, the line is not defined, but still.
Sorry, but if something seems not good for PHP, any of us should share his
thoughts.
"I don't like" or "-1" have nothing to do with thinking or discussing.
That's Anthony's point (could have been slightly more diplomatic but
so it is :)
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Hi!
Stas,
On Wed, Jan 9, 2013 at 11:58 AM, Stas Malyshev <smalyshev@sugarcrm.com
mailto:smalyshev@sugarcrm.com> wrote:I seriously hope it never comes to this in PHPWould you shut up with this rhetoric already? All it does is show that
I admire your politeness and ability to discuss thing without resorting
to insults and personal attacks. No, I will definitely not shut up.
you're completely and utterly out of touch with the reality of modern
development.
Really. I was going to write a refutation to that but on the second
thought screw it. You are wrong, and you know it, and I'm not going to
waste time to dignify that with any more response.
Frankly, I'm getting sick and tired of seeing these recurring themes of
"PHP is not java" and "I never want this". If you never want this, then
don't contribute to the discussions at all.
It is a recurring theme because it's true. You are right that every
language needs a vision, and PHP's vision is being simple and practical
and focused on the web. PHP is what people use to get their first site
off the ground. PHP is what a web designer learns when he/she wants to
go into programming. PHP is what a random Joe uses when he needs to whip
up a page and he's in "do it yourself" mind. PHP is what you expect
everybody to be able to handle, and everything to be able to run. It is
not to serve everybody, every use case and every possible need. Yes, we
try to extend the boundaries and do clever things - but sometimes we
have to make a choice. You can not be everything to everybody. And if
the choice between some complicated use-case that will be used by maybe
1% of the users and even then will be buried in the guts of some huge
library and simplicity and accessibility of the language - I choose the
latter every time. Library writers are smart, they can work around it
and nobody but them will see it anyway. But turning the language into
Java wannabe would affect all the users. And most of them don't need
that, in my opinion.
That doesn't mean we should not improve and go forward. We should. But
we should do it consistent with yes - the vision of the language being
accessible and not overly complex. If you want rigid OO-pattern-driven
language - you have Java. If you want full mathematics power with full
mathematics complexity - you got Scala and Haskell and so on. There's
nothing wrong with them. They are just not PHP and PHP is not them. They
have their playground and we have ours. Having vision does mean
sometimes having to say "PHP is not X" and reject stuff because of that.
If you have solid feedback to provide, then provide it. But saying
"We're supposed to be simple language for doing cool stuff on the web"
shows you have no idea what people have been doing (or don't want
to acknowledge) with the language for the past 5 years.
I have feedback to provide and I provide it all the time. But if by
"solid" you mean agreeing with you, you're not getting that.
And that brings us to the root of the problem. Discussion like this is
due to the fact that there's no clear "official" vision for PHP. Each
participant brings their own concept and vision, and treats it like it's
everyone else's vision as well (which is the exact reason for your
reply). The need for voting is a byproduct of this lack of vision, not a
requirement in its own right.
We had the vision for quite a long time, even though we never officially
stated it. Maybe because there was a general consensus about it, maybe
because nobody asked. Now that there are many people in PHP with
different backgrounds - and make no mistake, it is a great thing -
people do disagree about what the vision is. I think we should keep with
the vision of being simple and accessible, even if the more complex use
cases will be a bit harder to implement. Some folks may disagree, and
while I think they are wrong, I accept that there can be legitimate
disagreement between us. I don't say "shut up" to them, I say "let's
find something that we all could agree on". If we can not, I'd rather
prefer the status quo than making it worse by making it too complex and
too convoluted.
- "PHP Should Strive To Be A Full Featured Object Oriented Language".
This is not a good vision, since nobody knows what is "full featured",
or everybody knows and it is different for everybody. Most of the things
you mention have very little to do with OO as such. Moreover, I see very
little value in PHP fitting somebody's definition of "full featured
language". I think our features should be driven by what is needed by
majority of users, while keeping in sight the overall spirit of not
overcomplicating things. Saying "we absolutely must have generators
because all cool boys have them" makes little sense to me. Saying "we
need generators because they make these frequent use cases easy and
here's how we can integrate it into the language in a way that does not
add unnecessary complications" - does make sense. Here we can disagree
how frequent the cases are, and there can be different opinions on it,
but at least we have a common ground on what we could have a common
ground :) Saying "do it as I say or PHP is not full-featured" is not a
good way to build common ground.
field for contributions and discussions. Rather than every developer
playing for themselves and saying "I hope this never happens", it puts
it in the context of "I don't believe this fits our vision". Note the
difference in tone between them.
If it makes it easier, please replace "I hope this never happens" with
"I don't believe this fits our vision" in my last response.
It's an ongoing joke about how abusive and unproductive the internals
list is. I for one am sick of it. And rather than keeping ignoring it
This is coming from a man that just told me to shut up? Did I ever tell
you to shut up? Did I publicly question your competence or assumed you
don't know anything about the matter discussed? You complain about the
list being abusive and yet you are the one who distributes abuse, as it
appears to me. I agree, this needs to be fixed. Please be part of the
solution, not of the problem.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Stas,
It is a recurring theme because it's true. You are right that every
language needs a vision, and PHP's vision is being simple and practical
and focused on the web. PHP is what people use to get their first site
off the ground. PHP is what a web designer learns when he/she wants to
go into programming. PHP is what a random Joe uses when he needs to whip
up a page and he's in "do it yourself" mind. PHP is what you expect
everybody to be able to handle, and everything to be able to run. It is
not to serve everybody, every use case and every possible need. Yes, we
try to extend the boundaries and do clever things - but sometimes we
have to make a choice. You can not be everything to everybody. And if
the choice between some complicated use-case that will be used by maybe
1% of the users and even then will be buried in the guts of some huge
library and simplicity and accessibility of the language - I choose the
latter every time. Library writers are smart, they can work around it
and nobody but them will see it anyway. But turning the language into
Java wannabe would affect all the users. And most of them don't need
that, in my opinion.
You just proved my point with your reply. PHP doesn't have a vision. The
two people in this thread who have provided what they thought were visions
don't agree. And that's a problem.
Rasmus: "A general purpose scripting language with a focus on web
development"
You: "being simple and practical and focused on the web"
While they both have "web" in them, they provide very different goals and
metrics with which to gauge contributions by. And that's the entire point
of my call for a single, consistent and official vision...
That doesn't mean we should not improve and go forward. We should. But
we should do it consistent with yes - the vision of the language being
accessible and not overly complex. If you want rigid OO-pattern-driven
language - you have Java. If you want full mathematics power with full
mathematics complexity - you got Scala and Haskell and so on. There's
nothing wrong with them. They are just not PHP and PHP is not them. They
have their playground and we have ours. Having vision does mean
sometimes having to say "PHP is not X" and reject stuff because of that.
Again, "PHP is not X" is rhetoric. Pure and simple. You could use that to
reject any feature that we didn't explicitly invent. Which is the
problem. I didn't hear that come up on the generators discussion ("PHP is
not Python"). And that's why it's not useful as an argument. When
discussing a specific feature, it's not a useful stick to measure by. And
that's why it's a bad argument to put forth.
I have feedback to provide and I provide it all the time. But if by
"solid" you mean agreeing with you, you're not getting that.
Yes you do! And quite often you do it in a very good and constructive way.
I applaud that. But you also provide it in a very destructive way at times.
And that's what I'm asking you to please stop. For example:
http://marc.info/?l=php-internals&m=135083835232016&w=2
While that's your opinion, the way you present it does not do anyone any
good.
We had the vision for quite a long time, even though we never
officially stated it.
Then it's not a vision in the context that I'm suggesting.
- "PHP Should Strive To Be A Full Featured Object Oriented Language".
This is not a good vision, since nobody knows what is "full featured",
or everybody knows and it is different for everybody.
It was an example of a possible vision statement. Nothing more. I wasn't
even suggesting it was a good one, or one we should adopt. Just something
to show as an example.
field for contributions and discussions. Rather than every developer
playing for themselves and saying "I hope this never happens", it puts
it in the context of "I don't believe this fits our vision". Note the
difference in tone between them.If it makes it easier, please replace "I hope this never happens" with
"I don't believe this fits our vision" in my last response.
I only think that makes sense if we have an official, stated vision. But
yes, that would make it far easier.
It's an ongoing joke about how abusive and unproductive the internals
list is. I for one am sick of it. And rather than keeping ignoring itThis is coming from a man that just told me to shut up? Did I ever tell
you to shut up? Did I publicly question your competence or assumed you
don't know anything about the matter discussed? You complain about the
list being abusive and yet you are the one who distributes abuse, as it
appears to me. I agree, this needs to be fixed. Please be part of the
solution, not of the problem.
I didn't tell you to shut up. I said to shut up with the rhetoric. There's
a difference.
I value your opinions. I really do. I quite often disagree, but that's fine
(good actually).
What I don't value at all are the BS remarks about "PHP is not java" and "I
never want to see this in PHP". They don't do any good but to dilute
constructive discussions. The reply thread that I quoted your line from has
some very good contributions by you to it. But that last one did not need
to be sent, as it provided absolutely nothing constructive to the post.
Am I guilty of being abusive? Absolutely. But I hope the abusiveness that I
portray at least tries to be constructive (if it's not always, I'm sorry).
I used that line to open this thread because it was something I am
passionate about. And because I see it as proof of the disconnect between
the people in the discussions. That's why I wrote this thread how I did.
One thing I will apologize for is the following note:
you're completely and utterly out of touch with the reality of modern
development.
While I do believe that you are out of touch with what's been going on in
the user-land of PHP trends over the past 5 years, the way I wrote it was
definitely not constraining to that area. So I'm sorry for making it sound
like you're separated from reality...
Anthony
Rasmus: "A general purpose scripting language with a focus on web
development"
You: "being simple and practical and focused on the web"While they both have "web" in them, they provide very different goals and
metrics with which to gauge contributions by. And that's the entire point
of my call for a single, consistent and official vision...
They don't seem different to me, and the first one is the documented
statement that has been the first thing people see on http://php.net for
years and years. You can add "simple and practical" to mine or add
"general purpose" to the Stas one and it doesn't conflict in any way.
-Rasmus
Rasmus,
Rasmus: "A general purpose scripting language with a focus on web
development"
You: "being simple and practical and focused on the web"While they both have "web" in them, they provide very different goals and
metrics with which to gauge contributions by. And that's the entire point
of my call for a single, consistent and official vision...They don't seem different to me, and the first one is the documented
statement that has been the first thing people see on http://php.net for
years and years. You can add "simple and practical" to mine or add
"general purpose" to the Stas one and it doesn't conflict in any way.
There's a difference between a byline and a vision. But even deeper, the
"vision" that you wrote widens the scope of PHP development into basically
all possible directions, as long as Web Development is a focus.
Stas's vision on the other hand narrows the scope quite significantly by
focusing on simple and practical implementations.
Here's an example of the difference. Let's say that an RFC came out to
introducelist comprehentions PHP. According to your vision, that's
completely on the table and is welcome. But Stas's stated vision would
counter that because it's not "simple".
And Stas's stated vision leads to things like this:
http://news.ycombinator.com/item?id=5034365 It is trivial to misinterpret
(or perhaps not so mis) it as "we can't do anything complex, because think
of the new people".
What I'm proposing here is a stated vision that clarifies and sets a
reasonably narrow vision for what development should do. I'm not saying it
needs to be a 100% "we can do this but never that", but something to guide
progress rather than the random thoughts of the people who just so happen
be reading the discussion at the time.
Something like: http://www.python.org/dev/peps/pep-0020/
Something to guide discussion that's applicable primarily to PHP...
Anthony
This could be very well be off-topic but I think it is something that
someone has to say it at some point. Don't worry, there's a vision
in there, near the end of this, please just have the patience of
reading this as a part rant, part wish :)
You all speak about new things, better userland code, gaining new
features, functionalities, getting a vision but you never speak about
the core.
There's a clear need for a change in the core but new features are
demanded every day...
Solving the core should be done with a major BC break after 5.5
and it should improve all the things that need to do be improved
while preparing the architecture for future changes/additions.
I think that Symfony2 should be a great example of this being a
good approach in terms of produced results. If you look at the code
it will provide both the cleanness and the flexibility needed to do
great things with it yet it allows it so be simple to pick up and
learned by new devs.
Maybe other projects, including PHP, should take this lesson and
see how they can make themselves better even if in the process
they'll break all user space.
For PHP strictly speaking now, I think that after 5.5 there should
be a pause of two-three months for devs, get a holiday or just
relax, then, sit with the community at a couple of meetings and
talk about how PHP 6, 6.1, 6.2 and so on could/should look like.
I'm not saying it's going to be an easy task, nor a pleasant one,
but this should be done sooner that later as it's bound to happen
at some point imho.
While we might not get cool new things like annotations, named
parameters or anything else that we, the users of PHP would like,
we could get:
- better internals which help adding those missing features faster;
- make APC easier to maintain if the parser/compiler are easier to
interact with; - get consistency in the whole haystack/needle problem :)
- possibly get a better extension system so that C extensions are
easier to write/maintain; - those missing things faster / easier to implement in PECL;
- maybe more :)
Redoing PHPs internals would help also getting a vision of the
language, that suddenly every one cries about, while getting cleaner
code for the core and help to increase the general numbers of core
contributors for it.
With such a large user base I still find it extremely surprising
that php-core is maybe a dozen people or so while projects like
Symfony/Zend Framework/Typo3/etc have hundreds of contributors.
Yes! We 'need' new cool stuff in PHP, that maybe will be forgotten
in two-three years or not, we find new ways to make the userland
code more easy to write, operate, read and above all faster!
But you can't build a 70 story skyscraper on top of a foundation
that's meant to support a five story building.
If you are going to ask the core devs to accept/do something that
you deem cool, why not thinking about doing the things better
all-around first, then add the coolness factor later?
And yes, annotations are cool but it's' by far a --must-- have or
something that gets in the way of developing new ideas to the
point where they just can't exist (as proven by Doctrine Common).
Have a nice day.
Florin Patan / @dlsniper
Rasmus,
Rasmus: "A general purpose scripting language with a focus on web
development"
You: "being simple and practical and focused on the web"While they both have "web" in them, they provide very different goals and
metrics with which to gauge contributions by. And that's the entire point
of my call for a single, consistent and official vision...They don't seem different to me, and the first one is the documented
statement that has been the first thing people see on http://php.net for
years and years. You can add "simple and practical" to mine or add
"general purpose" to the Stas one and it doesn't conflict in any way.There's a difference between a byline and a vision. But even deeper, the
"vision" that you wrote widens the scope of PHP development into basically
all possible directions, as long as Web Development is a focus.Stas's vision on the other hand narrows the scope quite significantly by
focusing on simple and practical implementations.Here's an example of the difference. Let's say that an RFC came out to
introducelist comprehentions PHP. According to your vision, that's
completely on the table and is welcome. But Stas's stated vision would
counter that because it's not "simple".And Stas's stated vision leads to things like this:
http://news.ycombinator.com/item?id=5034365 It is trivial to misinterpret
(or perhaps not so mis) it as "we can't do anything complex, because think
of the new people".What I'm proposing here is a stated vision that clarifies and sets a
reasonably narrow vision for what development should do. I'm not saying it
needs to be a 100% "we can do this but never that", but something to guide
progress rather than the random thoughts of the people who just so happen
be reading the discussion at the time.Something like: http://www.python.org/dev/peps/pep-0020/
Something to guide discussion that's applicable primarily to PHP...
Anthony
Am I guilty of being abusive? Absolutely. But I hope the abusiveness that I
portray at least tries to be constructive (if it's not always, I'm sorry).
From the Merriam-Webster dictionary:
a·bu·sive
/əˈbyo͞osiv/
(1) characterized by wrong or improper use or action; especially : corrupt
<abusive financial practices>
(2) using harsh insulting language <an angry and abusive crowd>;
characterized by or serving for abuse <abusive language>; physically
injurious <abusive behavior>
By what definition of the word could abusive ever be construed as
constructive?
I posit that you are far from constructive based on the nature of this
thread now revolving around your direct personal attack towards someone and
veering off from any real progress on internals matters.
One courtesy I will offer you that you -- yourself -- have not offered your
peers is the acknowledgement of your own contributions and opinions among
the rest of the contributors in an impartial manner.
You, like everyone contributing to PHP, have opinions, motives, and
convictions. That does not mean one should put their own opinions, motives,
and convictions above the group in order to make sure they are heard. This
is the equivalent of someone in the middle of a rioting crowd pushing
people out of the way in order to make sure they hear his plead for
calmness and order (do as I say not as I do). You certainly aren't setting
a good example if those are you motives.
This talk of BDFLs you are so incumbent to reiterate has been portrayed by
you in a biased light. You are forgetting to mention all the things BDFLs
in other open source projects do that you yourself are here asking us not
to do. Like using arguments such as "Language X is not language Y", which
I've heard Guido van Rossum say at a public talk on Python 3000. They also
have every right to "put their foot down" without allowing any room for
discussion as I've seen Linus Torvalds do on the Linux Kernel mailing list.
(Linus telling someone to STFU https://lkml.org/lkml/2012/12/23/75). You
seem to have dictatorship sorely confused with visionary leadership. If
even this were not the case then you should not be making those arguments
of vision and BDFLs interchangeably.
Anthony,
I appreciate your remarkable brilliance as a developer and I admire your
talent. However, one thing I've learned in my time as a developer is that
you never want the guy that's incredibly talented to stop asking questions
and start giving all the answers. There's a reason for this. You don't want
someone like that to get too cocky and believe they already know it all and
that all they can do now is teach others. It is true that you are
knowledgeable, but that does not preclude that you can't learn from others
on this list despite all of the shortcomings the list has to offer. It is
true that you are wise, but it does not mean that you have grown so wise
that you outwit the masses.
I hear people saying PHP has a vision that is web-centric and focused on
making it possible for both the "weekend-warrior" as well as the "9-to-5
guy" to make it in web development. You see that this vision is lacking, or
unrefined, or even completely diluted to the extent that it is not a vision
(and for whatever reason). That's fine. How are you solving this issue? I
don't hear anyone on this list backing you on this thought.
A good leader does not lead by wandering ahead of the crowd and telling
them what will come. A good leader walks among the crowd and asks them what
they want. I don't see any consensus gathering behind you. Perhaps these
group-thinks you allude to are really just people's honest opinion? Who
knows. The point is you should try to focus more on slowly building up
consensus if you feel your ideas are that valuable, and people will
ultimately follow if this is true. As opposed to making waves.
Sherif,
Mr. Always happy never grumpy!
Hi!
You just proved my point with your reply. PHP doesn't have a vision. The
two people in this thread who have provided what they thought were
visions don't agree. And that's a problem.
If you mean that there would be some "vision" document that prevents
disagreement and decides arguments once and for all, are you sure it is
what you want? It is clear we disagree on many things. Suppose I wrote a
document that describes how I see PHP should be, and it will be accepted
as a "vision". Would you then say it is the right thing to do and agree
with me completely as far as the "vision" document goes? Would you
expect everybody else to do so? Probably not.
So while we can have some vague "mission statement", there would always
be disagreement on specific questions, and only way you can avoid that
is to exclude some side of the debate. We can have a vision, but not one
that would be used to avoid disagreement and discussion.
While they both have "web" in them, they provide very different goals
and metrics with which to gauge contributions by. And that's the entire
point of my call for a single, consistent and official vision...
Can you give me some examples of modern languages like PHP having
"official visions" like that? I'd really like to understand what kind of
official vision you have in mind. Some document examples would help.
Again, "PHP is not X" is rhetoric. Pure and simple. You could use that
to reject any feature that we didn't explicitly invent. Which is the
Maybe I could, but I never did and never intend to, and you know that I
have supported and participated in discussions of number of features
that I did not explicitly invent. It is not about me. It is about what
is a good fit for PHP and what is not. I think some complex features are
not a good fit for PHP and that's my "vision".
Yes you do! And quite often you do it in a very good and constructive
way. I applaud that. But you also provide it in a very destructive way
at times. And that's what I'm asking you to please stop. For example:
I think the direction such changes take PHP is wrong, and I see no
reason why I need to stop saying that. I think adding such syntax would
make PHP code look convoluted and would significantly impair ability of
the developers to understand what's going on. It may be a perfect fit
for a couple of ORM-like use cases, but I think it's not enough to make
it part of the general PHP language. I hope we can find common ground
that can be useful for ORM folks but still not over-complicated and does
not develop into additional sub-language with some weird syntax driven
mainly by "which symbol didn't we use yet?" But if it is the only way to
do it, then I'd rather not.
While I do believe that you are out of touch with what's been going on
in the user-land of PHP trends over the past 5 years, the way I wrote it
Your belief is wrong, and let's leave it at that. It's really not about me.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Stas,
If you mean that there would be some "vision" document that prevents
disagreement and decides arguments once and for all, are you sure it is
what you want? It is clear we disagree on many things. Suppose I wrote a
document that describes how I see PHP should be, and it will be accepted
as a "vision". Would you then say it is the right thing to do and agree
with me completely as far as the "vision" document goes? Would you
expect everybody else to do so? Probably not.
So while we can have some vague "mission statement", there would always
be disagreement on specific questions, and only way you can avoid that
is to exclude some side of the debate. We can have a vision, but not one
that would be used to avoid disagreement and discussion.
I'm absolutely not talking about avoiding disagreement and discussion. I'm
talking about having a vision that can be used to frame them so that they
are productive. As it stands now, each person has their own mental vision
as to what PHP should be and do. When people discuss a feature, they are
discussing it relative to their own vision. By putting a shared common
vision, it can become easier to see what the common misgivings are, and
make it easier to communicate them.
While they both have "web" in them, they provide very different goals
and metrics with which to gauge contributions by. And that's the entire
point of my call for a single, consistent and official vision...Can you give me some examples of modern languages like PHP having
"official visions" like that? I'd really like to understand what kind of
official vision you have in mind. Some document examples would help.
Sure. Here you go. Here are two examples:
http://www.python.org/dev/peps/pep-0020/
http://www.perl6.org/archive/doc/design/apo/A01.html
Again, "PHP is not X" is rhetoric. Pure and simple. You could use that
to reject any feature that we didn't explicitly invent. Which is theMaybe I could, but I never did and never intend to, and you know that I
have supported and participated in discussions of number of features
that I did not explicitly invent. It is not about me. It is about what
is a good fit for PHP and what is not. I think some complex features are
not a good fit for PHP and that's my "vision".
Not so minor correction: It's about what is a good fit for PHP and what is
not should be It's about what I believe is a good fit for PHP and what is
not. You are not a BDFL. And we don't have a unified vision that we can
measure things against. Therefore, there is no such thing as a "good fit
for PHP" outside our own personal opinions. It may seem like a minor point,
but it's the exact thing I'm sitting here asking for (A unified vision).
Yes you do! And quite often you do it in a very good and constructive
way. I applaud that. But you also provide it in a very destructive way
at times. And that's what I'm asking you to please stop. For example:I think the direction such changes take PHP is wrong, and I see no
reason why I need to stop saying that. I think adding such syntax would
make PHP code look convoluted and would significantly impair ability of
the developers to understand what's going on. It may be a perfect fit
for a couple of ORM-like use cases, but I think it's not enough to make
it part of the general PHP language. I hope we can find common ground
that can be useful for ORM folks but still not over-complicated and does
not develop into additional sub-language with some weird syntax driven
mainly by "which symbol didn't we use yet?" But if it is the only way to
do it, then I'd rather not.
I'm not saying not to express that you think the direction is wrong. What
I'm saying is to express it in a better way than "PHP is not Java" and "I
don't ever want to see this". Those are terminal statements. There's no way
for people to learn and adjust what they are thinking. Instead, if you said
"This feature seems to me to be overly complex, and that the implementation
gains nothing for that complexity", then people may learn your point of
view. And they may be able to show you the gains. Or they may not, and your
point takes hold even further. But at least it frames a discussion rather
than putting a period in the middle of it...
Anthony
Hi!
Sure. Here you go. Here are two examples:
This is a nice text, but practical meaning of it is kind of unclear.
Even then, applying it to what we have now with annotations, I can see
they violate at least #1, #2, #3, #5 and #7 :) And possibly #17 too :)
Now, I'm not saying we need to accept exactly such rules, and I see how
you may disagree with my application of it - but that's exactly my
point. I do not see how having something like this would improve what
you want to improve.
Perl one is more practical, but it is a statement of opinion - even
though very influential one of a very smart man. Would you be willing to
accept such statement if it says something that you personally disagree
with? And out of many different opinion, how we choose one that deserves
to be "official", making all other ones "officially wrong"?
Not so minor correction: It's about what is a good fit for PHP and what
is not should be *It's about what I believe is a good fit for PHP and
You really need an explicit note that I express my opinion? Of course
it's mine, whose else opinion could I express?
what is not*. You are not a BDFL. And we don't have a unified vision
Neither are you. Yet I am not telling people to shut up, and you are.
Curious.
that we can measure things against. Therefore, there is no such thing as
a "good fit for PHP" outside our own personal opinions. It may seem like
I believe there is. Each language has a philosophy and internal
coherence, or at least it should strive to have it. In fact, PHP is
frequently criticized for being lacking on this front, and we do not
have anything written down formally, but I think it still exists.
Moreover, if it does not, and PHP is nothing but a hodgepodge of
somewhat useful tools without any coherent thought and system behind
them - it would be very bad for PHP project. And if it does exist, then
there are things which align with it, and there are things which do not.
I'm not saying not to express that you think the direction is wrong.
What I'm saying is to express it in a better way than "PHP is not Java"
and "I don't ever want to see this". Those are terminal statements.
I made kilobytes if not megabytes of comments on this topic for the past
years. So if you try to latch on one phrase which was a part of bigger
response and make it sound as if I never explained what I mean and
nobody else did the same, repeatedly, over the years - this is just
wrong. I did explain and I keep explaining it. You may not agree but
please do not make it sound as if I only actually said what I mean
instead of droning on with "PHP is not Java", maybe then you could
understand it... I said it many times - the syntax proposed is very
complex and hardly comprehensible, it creates a separate sub-language
inside PHP incompatible with what the rest of PHP is doing, it is not
readable and it is helpful only in very small subset of PHP uses. I am
not opposed to the idea in general, but I am opposed to the level of
complexity - both syntactical and conceptual - it currently involves.
Instead, if you said "This feature seems to me to be overly complex, and
that the implementation gains nothing for that complexity", then people
may learn your point of view. And they may be able to show you the
I said this many times. People just dismiss it saying "baloney, my ORM
needs exactly this level of complexity, and you just don't know first
thing about what real men do with real code". And then come back with
even more complex design.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
what is not*. You are not a BDFL. And we don't have a unified vision
Neither are you. Yet I am not telling people to shut up, and you are.
Curious.
I reiterate that there are other people besides Anthony who are
annoyed by your behavior, Stas. You've voiced your opinion, are you
done now?
Stas,
On Thu, Jan 10, 2013 at 3:16 PM, Stas Malyshev smalyshev@sugarcrm.comwrote:
Hi!
Sure. Here you go. Here are two examples:
This is a nice text, but practical meaning of it is kind of unclear.
Even then, applying it to what we have now with annotations, I can see
they violate at least #1, #2, #3, #5 and #7 :) And possibly #17 too :)
Now, I'm not saying we need to accept exactly such rules, and I see how
you may disagree with my application of it - but that's exactly my
point. I do not see how having something like this would improve what
you want to improve.
It would provide context. You saying that annotations violate #1, #2, #3,
#5 and #7 would be a PERFECT argument. It puts context into what's wrong
with the proposal, and not some ambiguous saying...
Perl one is more practical, but it is a statement of opinion - even
though very influential one of a very smart man. Would you be willing to
accept such statement if it says something that you personally disagree
with? And out of many different opinion, how we choose one that deserves
to be "official", making all other ones "officially wrong"?
Absolutely. I want A vision, not necessarily MY vision. I want a vision the
majority can agree with (considering the current state of the dev teams. As
far as how we choose, I would suggest using the RFC system.
Neither are you. Yet I am not telling people to shut up, and you are.
Curious.
I said to shut up with the rhetoric, not shut up in general.
Additionally, replies like the following ARE telling people to shut up IMHO:
http://marc.info/?l=php-internals&m=135083835232016&w=2
Hello, list. I want to propose generics.
Please no. If you need Java, you know where to find it. Java has a set
of great tools, great books, great community. And it's completely free.
Anybody who needs Java can just do it. I see no need to turn PHP into Java.
That's the type of thing I want to get rid of...
that we can measure things against. Therefore, there is no such thing as
a "good fit for PHP" outside our own personal opinions. It may seem like
I believe there is. Each language has a philosophy and internal
coherence, or at least it should strive to have it. In fact, PHP is
frequently criticized for being lacking on this front, and we do not
have anything written down formally, but I think it still exists.
Moreover, if it does not, and PHP is nothing but a hodgepodge of
somewhat useful tools without any coherent thought and system behind
them - it would be very bad for PHP project. And if it does exist, then
there are things which align with it, and there are things which do not.
s:/philosophy/vision/ and that's basically what I'm asking for. It does
exist informally as 1000 different versions right now (one or 4 per person
on this list).
And I do currently believe that PHP development currently IS nothing but a
hodgepodge (how you describe it). I feel it's been that way since at least
5.3 when progress on 6 stalled. Since then, it feels like things became
completely disjointed. The RFC and voting process was a sign of this
disjoint environment. I want to fix the underlying problem and give the
project direction again.
I'm not saying not to express that you think the direction is wrong.
What I'm saying is to express it in a better way than "PHP is not Java"
and "I don't ever want to see this". Those are terminal statements.I made kilobytes if not megabytes of comments on this topic for the past
years. So if you try to latch on one phrase which was a part of bigger
response and make it sound as if I never explained what I mean and
nobody else did the same, repeatedly, over the years - this is just
wrong. I did explain and I keep explaining it. You may not agree but
please do not make it sound as if I only actually said what I mean
instead of droning on with "PHP is not Java", maybe then you could
understand it... I said it many times - the syntax proposed is very
complex and hardly comprehensible, it creates a separate sub-language
inside PHP incompatible with what the rest of PHP is doing, it is not
readable and it is helpful only in very small subset of PHP uses. I am
not opposed to the idea in general, but I am opposed to the level of
complexity - both syntactical and conceptual - it currently involves.
And I appreciate (even if I usually disagree) the content you contribute.
BUt I can't stand when you go on those terminal remarks (PHP is not Java, I
never want to see this). They are demoralizing, deflating and do nothing
but shut people down. That's why even in your large reply I picked out one
phrase. Because that one phrase was more powerful than the rest of your
reply...
Anthony
On Thu, Jan 10, 2013 at 10:42 PM, Anthony Ferrara ircmaxell@gmail.comwrote:
Stas,
On Thu, Jan 10, 2013 at 3:16 PM, Stas Malyshev <smalyshev@sugarcrm.com
wrote:
Hi!
Sure. Here you go. Here are two examples:
This is a nice text, but practical meaning of it is kind of unclear.
Even then, applying it to what we have now with annotations, I can see
they violate at least #1, #2, #3, #5 and #7 :) And possibly #17 too :)
Now, I'm not saying we need to accept exactly such rules, and I see how
you may disagree with my application of it - but that's exactly my
point. I do not see how having something like this would improve what
you want to improve.It would provide context. You saying that annotations violate #1, #2, #3,
#5 and #7 would be a PERFECT argument. It puts context into what's wrong
with the proposal, and not some ambiguous saying...Perl one is more practical, but it is a statement of opinion - even
though very influential one of a very smart man. Would you be willing to
accept such statement if it says something that you personally disagree
with? And out of many different opinion, how we choose one that deserves
to be "official", making all other ones "officially wrong"?Absolutely. I want A vision, not necessarily MY vision. I want a vision the
majority can agree with (considering the current state of the dev teams. As
far as how we choose, I would suggest using the RFC system.Neither are you. Yet I am not telling people to shut up, and you are.
Curious.
I said to shut up with the rhetoric, not shut up in general.
Additionally, replies like the following ARE telling people to shut up
IMHO:http://marc.info/?l=php-internals&m=135083835232016&w=2
Hello, list. I want to propose generics.
Please no. If you need Java, you know where to find it. Java has a set
of great tools, great books, great community. And it's completely free.
Anybody who needs Java can just do it. I see no need to turn PHP into
Java.That's the type of thing I want to get rid of...
that we can measure things against. Therefore, there is no such thing as
a "good fit for PHP" outside our own personal opinions. It may seem
likeI believe there is. Each language has a philosophy and internal
coherence, or at least it should strive to have it. In fact, PHP is
frequently criticized for being lacking on this front, and we do not
have anything written down formally, but I think it still exists.
Moreover, if it does not, and PHP is nothing but a hodgepodge of
somewhat useful tools without any coherent thought and system behind
them - it would be very bad for PHP project. And if it does exist, then
there are things which align with it, and there are things which do not.s:/philosophy/vision/ and that's basically what I'm asking for. It does
exist informally as 1000 different versions right now (one or 4 per person
on this list).And I do currently believe that PHP development currently IS nothing but a
hodgepodge (how you describe it). I feel it's been that way since at least
5.3 when progress on 6 stalled. Since then, it feels like things became
completely disjointed. The RFC and voting process was a sign of this
disjoint environment. I want to fix the underlying problem and give the
project direction again.I'm not saying not to express that you think the direction is wrong.
What I'm saying is to express it in a better way than "PHP is not Java"
and "I don't ever want to see this". Those are terminal statements.I made kilobytes if not megabytes of comments on this topic for the past
years. So if you try to latch on one phrase which was a part of bigger
response and make it sound as if I never explained what I mean and
nobody else did the same, repeatedly, over the years - this is just
wrong. I did explain and I keep explaining it. You may not agree but
please do not make it sound as if I only actually said what I mean
instead of droning on with "PHP is not Java", maybe then you could
understand it... I said it many times - the syntax proposed is very
complex and hardly comprehensible, it creates a separate sub-language
inside PHP incompatible with what the rest of PHP is doing, it is not
readable and it is helpful only in very small subset of PHP uses. I am
not opposed to the idea in general, but I am opposed to the level of
complexity - both syntactical and conceptual - it currently involves.And I appreciate (even if I usually disagree) the content you contribute.
BUt I can't stand when you go on those terminal remarks (PHP is not Java, I
never want to see this). They are demoralizing, deflating and do nothing
but shut people down. That's why even in your large reply I picked out one
phrase. Because that one phrase was more powerful than the rest of your
reply...Anthony
Just a thought - if the main argument is about syntax - we can propose few
versions (Without implementing them) and then vote for
- No annotations (attributes) at all.
- Syntax #1
- Syntax #2
and so on.
What do you think?
Stas, perhaps you haven't noticed, but you are regularly derailing
discussions. I know that there are at least a few other people reading
the mailing list who tire of your behavior.
Stas,
On Wed, Jan 9, 2013 at 11:58 AM, Stas Malyshev smalyshev@sugarcrm.comwrote:
I seriously hope it never comes to this in PHP
Would you shut up with this rhetoric already? All it does is show that
you're completely and utterly out of touch with the reality of modern
development.
Anthony, I have a lot of respect for your expertise as a programmer (I
follow your blog, and I've appreciated your work on the password
hashing capabilities.) While I like your initiative, Stas was
providing feedback on a proposal, and your opening was directed at
him, personally. I doubt Stas is "out of touch with the reality of
modern development." What it does potentially speak to is the
difference in visions you both have for PHP.
If you have solid feedback to provide, then provide it. But saying "We're
supposed to be simple language for doing cool stuff on the web" shows you
have no idea what people have been doing (or don't want to acknowledge)
with the language for the past 5 years.
It seems like Stas responds to many, many emails every day. He was
even the ONE who provided commentary on my most recent idea (this
shows his diligence.) Quoting him on one quick excerpt he typed among
many to provide evidence that he has no idea what people have been
doing again seems unfair, as I see Stas devote much time to providing
feedback on internals threads.
Last, I would suggest that even feedback as simple as "I don't want
this in PHP" does have a place. Nothing comes for free. Every bit of
additional functionality has the potential to slow PHP, both in terms
of development, maintenance, and runtime. Declaring your belief that
some pieces of functionality are better integrated as extensions is
important feedback in terms of setting boundaries on the core
capabilities of PHP. The Lua mailing list frequently has this
sentiment expressed (as do many other mailing lists), and it doesn't
mean that its core developers are out of touch. It just means you have
to be working to set the boundaries somewhere.
This all said, creating a vision statement for PHP seems like a nice
idea to help guide the process. Perhaps that work would help guide
where the boundaries for core should be considered.
Again, thanks for the nice work on the password hashing API :)
Adam
Just a thought here, but perhaps what PHP needs now is a working group
that works together to do some basic management of PHP as a language,
take into account what the users are wanting, talking about, requesting
and setting a vision and direction and make plans for what will and
won't and when. In short I think PHP lacks direction because "everyone
has a voice" and "nobody has authority."
In the last two years of working on property accessors I think I have
found this to be the most dis-tasteful aspect of working on the project,
no person, document or group that leads.
Stas,
On Wed, Jan 9, 2013 at 11:58 AM, Stas Malyshev smalyshev@sugarcrm.comwrote:
I seriously hope it never comes to this in PHP
Would you shut up with this rhetoric already? All it does is show that
you're completely and utterly out of touch with the reality of modern
development.Frankly, I'm getting sick and tired of seeing these recurring themes of
"PHP is not java" and "I never want this". If you never want this, then
don't contribute to the discussions at all.If you have solid feedback to provide, then provide it. But saying "We're
supposed to be simple language for doing cool stuff on the web" shows you
have no idea what people have been doing (or don't want to acknowledge)
with the language for the past 5 years.And that brings us to the root of the problem. Discussion like this is due
to the fact that there's no clear "official" vision for PHP. Each
participant brings their own concept and vision, and treats it like it's
everyone else's vision as well (which is the exact reason for your reply).
The need for voting is a byproduct of this lack of vision, not a
requirement in its own right.For all the problems that a Benevolent Dictator brings to a project, this
is not one of them. This is a case where a dictator that sets the vision in
clear and unambiguous terms would actually improve the process quite
significantly. Instead of worrying about voting or everyone doing what they
want, there's a benchmark to measure proposals against.For example, imagine these different visions for PHP (which I know for a
fact are shared on this list):
- "PHP Should Strive To Be A Full Featured Object Oriented Language".
In this context frame, things like annotations, mixins, generators, etc
become the focus. As would moving the error handler to exceptions. And a
host of other changes (boxing primitive types when treated like an object,
etc). Adding functions like array_get_whatever would be frowned upon...
- "PHP Should Remain A Procedural Language WIth Some OO Features"
In this context frame, a lot of the stuff I said above goes away. And
adding new array functions would be the norm. And it's plain to tell that
exceptions shouldn't be implemented for errors.
- "PHP Should Be Implementation Neutral, and Support
All Paradigms Equally".This is as close to the current implementation as we currently are. We
support procedural, OOP and functional constructs. But how deep does it go?
Where's the line.PHP NEEDS a vision. It needs something to guide development. Not everyone
will agree with it. And that's the point. It levels the playing field for
contributions and discussions. Rather than every developer playing for
themselves and saying "I hope this never happens", it puts it in the
context of "I don't believe this fits our vision". Note the difference in
tone between them.It's an ongoing joke about how abusive and unproductive the internals list
is. I for one am sick of it. And rather than keeping ignoring it (or
walking away), I'd rather see it fixed.Anthony
--
-Clint
Just a thought here, but perhaps what PHP needs now is a working group
that works together to do some basic management of PHP as a language,
take into account what the users are wanting, talking about, requesting
and setting a vision and direction and make plans for what will and
won't and when. In short I think PHP lacks direction because "everyone
has a voice" and "nobody has authority."In the last two years of working on property accessors I think I have
found this to be the most dis-tasteful aspect of working on the project,
no person, document or group that leads.
Relevant:
http://www.jofreeman.com/joreen/tyranny.htm
--Larry Garfield