Looks like it is time to forward this email from 2006 again:
---------- Forwarded message ----------
Date: Thu, 09 Mar 2006 12:57:32 +0200
From: Zeev Suraski zeev@zend.com
To: internals@lists.php.net
Subject: [PHP-DEV] Give the Language a Rest motion
I'd like to raise a motion to 'Give the Language a Rest'.
Almost a decade since we started with the 2nd iteration on the syntax (PHP 3),
and 2 more major versions since then, and we're still heatedly debating on
adding new syntactical, core level features.
Is it really necessary? I'd say in almost all cases the answer's no, and a
bunch of cases where a new feature could be useful does not constitute a good
enough reason to add a syntax level feature. We might have to account for new
technologies, or maybe new ways of thinking that might arise, but needless to
say, most of the stuff we've been dealing with in recent times doesn't exactly
fall in the category of cutting edge technology.
My motion is to make it much, much more difficult to add new syntax-level
features into PHP. Consider only features which have significant traction to a
large chunk of our userbase, and not something that could be useful in some
extremely specialized edge cases, usually of PHP being used for non web stuff.
How do we do it? Unfortunately, I can't come up with a real mechanism to
'enforce' a due process and reasoning for new features.
Instead, please take at least an hour to bounce this idea in the back of your
mind, preferably more. Make sure you think about the full context, the huge
audience out there, the consequences of making the learning curve steeper with
every new feature, and the scope of the goodness that those new features bring.
Consider how far we all come and how successful the PHP language is today, in
implementing all sorts of applications most of us would have never even thought
of when we created the language.
Once you're done thinking, decide for yourself. Does it make sense to be
discussing new language level features every other week? Or should we, perhaps,
invest more in other fronts, which would be beneficial for a far bigger
audience. The levels above - extensions to keep with the latest technologies,
foundation classes, etc. Pretty much, the same direction other mature languages
went to.
To be clear, and to give this motion higher chances of success, I'm not talking
about jump. PHP can live with jump, almost as well as it could live without it
:) I'm talking about the general sentiment.
Zeev
I would also say it us time for us to get back in sync with the communities
needs. I am not talking about the last days RFCs but in general.
Looks like it is time to forward this email from 2006 again:
---------- Forwarded message ----------
Date: Thu, 09 Mar 2006 12:57:32 +0200
From: Zeev Suraski zeev@zend.com
To: internals@lists.php.net
Subject: [PHP-DEV] Give the Language a Rest motionI'd like to raise a motion to 'Give the Language a Rest'.
Almost a decade since we started with the 2nd iteration on the syntax (PHP
3),
and 2 more major versions since then, and we're still heatedly debating on
adding new syntactical, core level features.Is it really necessary? I'd say in almost all cases the answer's no, and a
bunch of cases where a new feature could be useful does not constitute a
good
enough reason to add a syntax level feature. We might have to account for
new
technologies, or maybe new ways of thinking that might arise, but needless
to
say, most of the stuff we've been dealing with in recent times doesn't
exactly
fall in the category of cutting edge technology.My motion is to make it much, much more difficult to add new syntax-level
features into PHP. Consider only features which have significant traction
to a
large chunk of our userbase, and not something that could be useful in some
extremely specialized edge cases, usually of PHP being used for non web
stuff.How do we do it? Unfortunately, I can't come up with a real mechanism to
'enforce' a due process and reasoning for new features.Instead, please take at least an hour to bounce this idea in the back of
your
mind, preferably more. Make sure you think about the full context, the
huge
audience out there, the consequences of making the learning curve steeper
with
every new feature, and the scope of the goodness that those new features
bring.
Consider how far we all come and how successful the PHP language is today,
in
implementing all sorts of applications most of us would have never even
thought
of when we created the language.Once you're done thinking, decide for yourself. Does it make sense to be
discussing new language level features every other week? Or should we,
perhaps,
invest more in other fronts, which would be beneficial for a far bigger
audience. The levels above - extensions to keep with the latest
technologies,
foundation classes, etc. Pretty much, the same direction other mature
languages
went to.To be clear, and to give this motion higher chances of success, I'm not
talking
about jump. PHP can live with jump, almost as well as it could live
without it
:) I'm talking about the general sentiment.Zeev
As a general reply: I’d like to disagree, and here is why. Yes, we should not let half baked features in but we need to add more and more features, also syntax wise. For three reasons:
- Parity/expectations/me too: so you can do that in PHP as well
- Expressiveness: allow better ways to express the same idea in more concise ways
- Innovation: bring unexpected features to the language people didn’t even expect
Let’s recall a few of the latest additions:
- 5.3: namespaces. Provided the foundation for awesome stuff like PSR-1, which in turn provides the foundation for the even more awesome stuff composer is.
- 5.3: goto. A good thing we can do it. I'm not sure for what exactly but I am sure there is somebody out there :)
- 5.3: Closures, huge thing for us, a matter of parity to other languages. Really changes the face of a lot of APIs (see e.g. Doctrine transactional(), the whole micro framework movement, React)
- 5.4: Closures 2.0 with $this binding. Honestly, without it, Closures are a little meh. But it was good we waited and got it right.
- 5.4: Short array syntax. A parity/culture issue.
- 5.4: Traits, I am happy we got horizontal reuse right
- 5.4: array dereferencing. Very small but useful. To me it feels more like a bugfix
- 5.4: callable type hint. Small change with a huge impact
- 5.5: Generators, also a matter of parity and a matter of awesomeness
- 5.5: ClassName::class syntax. A really good improvement to the overall usability of namespaces. Just imagine how much shorter unit test setUp() methods will become
What we have on our list that, from my perspective, will sooner or later hit us:
- Property accessors in some form or another: a lot of people seem to like it.
- Annotation support: we would have a lot of customers for it.
- Autoboxing for primitives. Allows us to fix a lot of problems in ext/standard.
- Unicode. Obviously.
- Named parameters. A recurring topic might be a topic worth digging deeper.
- I'm positive the Generics discussion will arise at some point again.
… and these are just the changes on a syntax/semantics level, I'm not talking about all the awesome technologies (one of which you are working on) we need to integrate tighter and eventually bundle with core. I don’t believe we should let our users outgrow the language, quite the opposite, we should grow with our users and the broader web community, otherwise we will fail. PHP is nowadays used for tasks it never was intended to be used but that’s a good thing. We need to continuously adapt. What’s true for software projects is true for languages: stop improving actually reduces its value over time.
cu,
Lars
Am 20.02.2013 um 19:18 schrieb Derick Rethans derick@php.net:
Looks like it is time to forward this email from 2006 again:
---------- Forwarded message ----------
Date: Thu, 09 Mar 2006 12:57:32 +0200
From: Zeev Suraski zeev@zend.com
To: internals@lists.php.net
Subject: [PHP-DEV] Give the Language a Rest motionI'd like to raise a motion to 'Give the Language a Rest'.
Almost a decade since we started with the 2nd iteration on the syntax (PHP 3),
and 2 more major versions since then, and we're still heatedly debating on
adding new syntactical, core level features.Is it really necessary? I'd say in almost all cases the answer's no, and a
bunch of cases where a new feature could be useful does not constitute a good
enough reason to add a syntax level feature. We might have to account for new
technologies, or maybe new ways of thinking that might arise, but needless to
say, most of the stuff we've been dealing with in recent times doesn't exactly
fall in the category of cutting edge technology.My motion is to make it much, much more difficult to add new syntax-level
features into PHP. Consider only features which have significant traction to a
large chunk of our userbase, and not something that could be useful in some
extremely specialized edge cases, usually of PHP being used for non web stuff.How do we do it? Unfortunately, I can't come up with a real mechanism to
'enforce' a due process and reasoning for new features.Instead, please take at least an hour to bounce this idea in the back of your
mind, preferably more. Make sure you think about the full context, the huge
audience out there, the consequences of making the learning curve steeper with
every new feature, and the scope of the goodness that those new features bring.
Consider how far we all come and how successful the PHP language is today, in
implementing all sorts of applications most of us would have never even thought
of when we created the language.Once you're done thinking, decide for yourself. Does it make sense to be
discussing new language level features every other week? Or should we, perhaps,
invest more in other fronts, which would be beneficial for a far bigger
audience. The levels above - extensions to keep with the latest technologies,
foundation classes, etc. Pretty much, the same direction other mature languages
went to.To be clear, and to give this motion higher chances of success, I'm not talking
about jump. PHP can live with jump, almost as well as it could live without it
:) I'm talking about the general sentiment.Zeev
- 5.3: goto. A good thing we can do it. I'm not sure for what exactly but I am sure there is somebody out there :)
An associate of mine used it in his HTTP message parser. He's sure
glad it's there :)
Levi Morrison wrote:
- 5.3: goto. A good thing we can do it. I'm not sure for what exactly but I am sure there is somebody out there :)
An associate of mine used it in his HTTP message parser. He's sure
glad it's there :)
Conversely, I have two HTTP message parsers that I maintain, and neither
of them use goto. Certainly possible to avoid it there.
That said, I do think goto has legitimate uses, even if I don't need it.
--
Ryan McCue
<http://ryanmccue.info/
What you're bringing up is not at all about adapting. Adapting is
something we do at the extensions, frameworks and tools levels. I'm happy
to say PHP's ecosystem here is very healthy, in my opinion.
Adapting is not what we're dealing with here. We're talking about Adding.
By adding more and more, we're making the language more and more complex,
less and less accessible to both new and existing developers, thereby
hurting its #1 appeal - simplicity. As we thrust forward towards 5.5,
more than half of the community is still on 5.2. 5.4 is virtually
nonexistent in terms of real world usage, and yet we thrust forward to
5.5, as if the community at large cares about all these new features. The
community is voting with its feet, and that is probably the best survey
we're ever going to get.
I'm not saying we shouldn't add new features. But I am saying that we
shouldn't add many of them. The very few we should add - should have
exceptional 'return on investment'. To be clear, the investment isn't
just the effort to develop or even maintain the implementation - that's
not even the main point. It's the increased complexity that each and
every new language construct brings with it, whether we like it or not.
There used to be a language that was the Queen of the Web. It was full of
clever syntax. It prided itself on having a variety of expressive ways of
doing the same thing. You're on the mailing list of the language that
dethroned it.
Zeev
-----Original Message-----
From: Lars Strojny [mailto:lars@strojny.net]
Sent: Thursday, February 21, 2013 1:15 AM
To: Derick Rethans; PHP Developers Mailing List
Subject: Re: [PHP-DEV] Give the Language a Rest motion (fwd)As a general reply: I'd like to disagree, and here is why. Yes, we
should not let
half baked features in but we need to add more and more features, also
syntax
wise. For three reasons:
- Parity/expectations/me too: so you can do that in PHP as well
- Expressiveness: allow better ways to express the same idea in more
concise
ways- Innovation: bring unexpected features to the language people didn't
even
expectLet's recall a few of the latest additions:
- 5.3: namespaces. Provided the foundation for awesome stuff like
PSR-1,
which in turn provides the foundation for the even more awesome stuff
composer is.- 5.3: goto. A good thing we can do it. I'm not sure for what exactly
but I am
sure there is somebody out there :)- 5.3: Closures, huge thing for us, a matter of parity to other
languages. Really
changes the face of a lot of APIs (see e.g. Doctrine transactional(),
the whole
micro framework movement, React)- 5.4: Closures 2.0 with $this binding. Honestly, without it, Closures
are a little
meh. But it was good we waited and got it right.- 5.4: Short array syntax. A parity/culture issue.
- 5.4: Traits, I am happy we got horizontal reuse right
- 5.4: array dereferencing. Very small but useful. To me it feels more
like a
bugfix- 5.4: callable type hint. Small change with a huge impact
- 5.5: Generators, also a matter of parity and a matter of awesomeness
- 5.5: ClassName::class syntax. A really good improvement to the
overall
usability of namespaces. Just imagine how much shorter unit test setUp()
methods will becomeWhat we have on our list that, from my perspective, will sooner or later
hit us:
- Property accessors in some form or another: a lot of people seem to
like it.- Annotation support: we would have a lot of customers for it.
- Autoboxing for primitives. Allows us to fix a lot of problems in
ext/standard.- Unicode. Obviously.
- Named parameters. A recurring topic might be a topic worth digging
deeper.- I'm positive the Generics discussion will arise at some point again.
. and these are just the changes on a syntax/semantics level, I'm not
talking
about all the awesome technologies (one of which you are working on) we
need
to integrate tighter and eventually bundle with core. I don't believe we
should
let our users outgrow the language, quite the opposite, we should grow
with
our users and the broader web community, otherwise we will fail. PHP is
nowadays used for tasks it never was intended to be used but that's a
good
thing. We need to continuously adapt. What's true for software projects
is true
for languages: stop improving actually reduces its value over time.cu,
LarsAm 20.02.2013 um 19:18 schrieb Derick Rethans derick@php.net:
Looks like it is time to forward this email from 2006 again:
---------- Forwarded message ----------
Date: Thu, 09 Mar 2006 12:57:32 +0200
From: Zeev Suraski zeev@zend.com
To: internals@lists.php.net
Subject: [PHP-DEV] Give the Language a Rest motionI'd like to raise a motion to 'Give the Language a Rest'.
Almost a decade since we started with the 2nd iteration on the syntax
(PHP 3), and 2 more major versions since then, and we're still
heatedly debating on adding new syntactical, core level features.Is it really necessary? I'd say in almost all cases the answer's no,
and a bunch of cases where a new feature could be useful does not
constitute a good enough reason to add a syntax level feature. We
might have to account for new technologies, or maybe new ways of
thinking that might arise, but needless to say, most of the stuff
we've been dealing with in recent times doesn't exactly fall in the
category of
cutting edge technology.My motion is to make it much, much more difficult to add new
syntax-level features into PHP. Consider only features which have
significant traction to a large chunk of our userbase, and not
something that could be useful in some extremely specialized edge
cases,
usually of PHP being used for non web stuff.How do we do it? Unfortunately, I can't come up with a real mechanism
to 'enforce' a due process and reasoning for new features.Instead, please take at least an hour to bounce this idea in the back
of your mind, preferably more. Make sure you think about the full
context, the huge audience out there, the consequences of making the
learning curve steeper with every new feature, and the scope of the
goodness
that those new features bring.
Consider how far we all come and how successful the PHP language is
today, in implementing all sorts of applications most of us would have
never even thought of when we created the language.Once you're done thinking, decide for yourself. Does it make sense to
be discussing new language level features every other week? Or should
we, perhaps, invest more in other fronts, which would be beneficial
for a far bigger audience. The levels above - extensions to keep with
the latest technologies, foundation classes, etc. Pretty much, the
same direction other mature languages went to.To be clear, and to give this motion higher chances of success, I'm
not talking about jump. PHP can live with jump, almost as well as it
could live without it
:) I'm talking about the general sentiment.Zeev
--
To unsubscribe,
visit: http://www.php.net/unsub.php--
To unsubscribe,
visit: http://www.php.net/unsub.php--
To unsubscribe,
visit:
http://www.php.net/unsub.php
hi Zeev,
What you're bringing up is not at all about adapting. Adapting is
something we do at the extensions, frameworks and tools levels. I'm happy
to say PHP's ecosystem here is very healthy, in my opinion.
Yes, most of the time. But the language needs evolution, must have evolution.
F.e., how long have we been battled for annotations? With all
respects, it is about being blind and stubborn to say that PHP should
not have annotations. But due to some "I'm happy with what we have
now" way of doing things, we are very unlikely to have them any time
soon, even if any major projects out there are waiting for it, for
years. Even the ZendFramework leads want them now (changed their mind
since the last attempt).
This is not about borking the language with useless features. This is
not about being on the cutting edge. this is about catching up with
the competition.
Adapting is not what we're dealing with here. We're talking about Adding.
Adding? Surely a matter of wording. I'd to say evolve and catch up.
By adding more and more, we're making the language more and more complex,
less and less accessible to both new and existing developers, thereby
hurting its #1 appeal - simplicity.
I heard that in php 4 > 5 and OO, and all we rejected back then have
been introduced since then. Not sure what is the best way, trying to
stop with all four feet (to take your analogy) any kind of
additions/evolution/catching up and then still doing it but years
later, or trying to get a bit more open minded and listen to our
communities.
As we thrust forward towards 5.5,
more than half of the community is still on 5.2. 5.4 is virtually
nonexistent in terms of real world usage, and yet we thrust forward to
5.5, as if the community at large cares about all these new features. The
community is voting with its feet, and that is probably the best survey
we're ever going to get.
Excuse me? Voting with its feet? Dare to explain the underlying
meaning of this comment?
I'm not saying we shouldn't add new features. But I am saying that we
shouldn't add many of them. The very few we should add - should have
exceptional 'return on investment'. To be clear, the investment isn't
just the effort to develop or even maintain the implementation - that's
not even the main point. It's the increased complexity that each and
every new language construct brings with it, whether we like it or not.
Yes, totally agree here. Annotation and usable getter/setter syntax
have a huge ROI. Discuss with any application or framework
developers/users will bring you to the same conclusion.
There used to be a language that was the Queen of the Web. It was full of
clever syntax. It prided itself on having a variety of expressive ways of
doing the same thing. You're on the mailing list of the language that
dethroned it.
You are living in the past glory. We are not willing to make PHP more
complex or kill it. We are willing to make compromises between the
2000s simplicity and the needs of modern application developments.
These compromises are not only required but possible.
Cheers,
Pierre
@pierrejoye
Pierre,
People who think differently from you are not necessarily blind of
stubborn. I honestly think that those comments were completely out of
line in several different ways.
Regarding 'voting with feet', it's an idiom, look it up.
Zeev
-----Original Message-----
From: Pierre Joye [mailto:pierre.php@gmail.com]
Sent: Thursday, February 21, 2013 12:09 PM
To: Zeev Suraski
Cc: Lars Strojny; Derick Rethans; PHP Developers Mailing List
Subject: Re: [PHP-DEV] Give the Language a Rest motion (fwd)hi Zeev,
What you're bringing up is not at all about adapting. Adapting is
something we do at the extensions, frameworks and tools levels. I'm
happy to say PHP's ecosystem here is very healthy, in my opinion.Yes, most of the time. But the language needs evolution, must have
evolution.F.e., how long have we been battled for annotations? With all respects,
it is
about being blind and stubborn to say that PHP should not have
annotations.
But due to some "I'm happy with what we have now" way of doing things,
we
are very unlikely to have them any time soon, even if any major projects
out
there are waiting for it, for years. Even the ZendFramework leads want
them
now (changed their mind since the last attempt).This is not about borking the language with useless features. This is
not about
being on the cutting edge. this is about catching up with the
competition.Adapting is not what we're dealing with here. We're talking about
Adding.Adding? Surely a matter of wording. I'd to say evolve and catch up.
By adding more and more, we're making the language more and more
complex, less and less accessible to both new and existing developers,
thereby hurting its #1 appeal - simplicity.I heard that in php 4 > 5 and OO, and all we rejected back then have
been
introduced since then. Not sure what is the best way, trying to stop
with all four
feet (to take your analogy) any kind of additions/evolution/catching up
and then
still doing it but years later, or trying to get a bit more open minded
and listen to
our communities.As we thrust forward towards 5.5,
more than half of the community is still on 5.2. 5.4 is virtually
nonexistent in terms of real world usage, and yet we thrust forward to
5.5, as if the community at large cares about all these new features.
The community is voting with its feet, and that is probably the best
survey we're ever going to get.Excuse me? Voting with its feet? Dare to explain the underlying meaning
of this
comment?I'm not saying we shouldn't add new features. But I am saying that we
shouldn't add many of them. The very few we should add - should have
exceptional 'return on investment'. To be clear, the investment isn't
just the effort to develop or even maintain the implementation -
that's not even the main point. It's the increased complexity that
each and every new language construct brings with it, whether we like
it or
not.Yes, totally agree here. Annotation and usable getter/setter syntax have
a huge
ROI. Discuss with any application or framework developers/users will
bring you
to the same conclusion.There used to be a language that was the Queen of the Web. It was
full of clever syntax. It prided itself on having a variety of
expressive ways of doing the same thing. You're on the mailing list
of the language that dethroned it.You are living in the past glory. We are not willing to make PHP more
complex or
kill it. We are willing to make compromises between the 2000s simplicity
and the
needs of modern application developments.
These compromises are not only required but possible.Cheers,
Pierre
@pierrejoye
Zeev,
Pierre,
People who think differently from you are not necessarily blind of
stubborn. I honestly think that those comments were completely out of
line in several different ways.
It is not my opinion but a simple fact. Yes, you can disagree with an
idea or proposal, but the cost of such disagree, despite huge
community support, is too high and it is more than counter productive.
Hence this comment.
Regarding 'voting with feet', it's an idiom, look it up.
I know, still do not think it fits as comment either here.
--
Pierre
@pierrejoye
Pierre Joye wrote:
Regarding 'voting with feet', it's an idiom, look it up.
I know, still do not think it fits as comment either here.
I read this as simply "People are not leaving PHP in droves simply because it
does not have xxx" - actually the opposite, but that growth in use is not into
PHP5.4 ...
--
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
People who think differently from you are not necessarily blind of
stubborn. I honestly think that those comments were completely out of
line in several different ways.It is not my opinion but a simple fact.
That comment would have been funny if it wasn't sad. I'll leave it at
that.
Regarding 'voting with feet', it's an idiom, look it up.
I know, still do not think it fits as comment either here.
Of course it does.
Zeev
In the slice of the "community" where I spend most of my time,
medium-to-large companies using PHP with their own custom code on
hundreds to thousands or even 10's of thousands of servers, neither
annotations nor getter/setter are anywhere on their wishlist radar. What
they most desire is performance, robustness and security. They would
love to see a PHP release that had no syntax changes, no BC changes, but
was twice as fast and crashed half as much. I realize this is just one
(small?) slice of the community but so is the part of the community
wanting annotations. This is the balancing act we have to perform. It is
not stubbornness, nor living in the past, it is recognizing that each
and every major feature addition has a destabilizing effect on the
codebase and if the addition only serves a small slice of the userbase
we have to think long and hard about the merits of it.
Personally I would love to see more RFCs focusing on performance and
less on syntax changes. Of course, a syntax change RFC, and even the
initial (often shaky) implementation of a syntax-related change is much
much easier to whip up than the deep analysis, profiling and creativity
required to find and come up with ways to make a complex piece of code
faster or use less memory.
-Rasmus
In the slice of the "community" where I spend most of my time
No hard feelings, but it would be awesome if that part of the "community"
(the one that basically avoids social coding as far as I can see, not to be
taken as a sin, but still "meh") didn't just try to hold back PHP because
of business decisions based on obsolescence.
If there is some momentum to get change, I see these big brakes set by
people who don't even express their opinion nor get interested in newly
developed packages over here.
It would already be nice to have them provide their opinion, assuming it
goes a bit deeper than "YAGNI".
No BC changes is basically impossible if you want to get better software:
improvement comes always with changes.
I can absolutely understand that the core team does not have enough human
resources to think about new functionality, and probably not even
maintenance (I even feel like a stranger forcing his own ideas in here,
since I also have no C-fu), but why would this stop things from being
suggested?
If you don't have time for a feature, then that's perfectly ok: just vote
"NO".
Don't sell us the "YAGNI" or "additional complexity" story: annotations and
property accessors already demonstrated that there are use cases that even
bring performance improvements.
Marco Pivetta
No hard feelings, but it would be awesome if that part of the "community"
(the one that basically avoids social coding as far as I can see, not to be
taken as a sin, but still "meh") didn't just try to hold back PHP because
of business decisions based on obsolescence.
The quoted business decision was "We want something stable and fast", an
emphasis of fixing bugs over adding new ones. This sounds sane to me.
johannes
The quoted business decision was "We want something stable and fast", an
emphasis of fixing bugs over adding new ones. This sounds sane to me.johannes
Doesn't exclude new features then: so what is this all about?
Marco Pivetta
The quoted business decision was "We want something stable and fast", an
emphasis of fixing bugs over adding new ones. This sounds sane to me.
Doesn't exclude new features then: so what is this all about?
* We have limited development resources
* Developers can either fix bugs and tune code or add features
* All new features go through different rounds of fixing newly
introduced bugs
* All new features increase the amount of things to maintain
long-term
I'm not against new features, but sometimes I wonder about the focus.
johannes
The quoted business decision was "We want something stable and fast", an
emphasis of fixing bugs over adding new ones. This sounds sane to me.Doesn't exclude new features then: so what is this all about?
* We have limited development resources * Developers can either fix bugs and tune code or add features * All new features go through different rounds of fixing newly introduced bugs * All new features increase the amount of things to maintain long-termI'm not against new features, but sometimes I wonder about the focus.
Traits is a good example of that. We, and by we I mean Dmitry, are still
fixing problems with Traits and we are closing in on 5 years after the
initial proposal in 2008. And Traits is sort of middle of the road in
terms of complexity. We have had more complex things proposed and we
still only have one Dmitry.
-Rasmus
Hello List,
how about sort of Tick-Tock development model?
Tick = optimize/bugfix
Tock = shiny new features
e.g. http://en.wikipedia.org/wiki/Intel_Tick-Tock
cryptocompress
Personally I would love to see more RFCs focusing on performance and
less on syntax changes.
Some recent tests I performed indicate that JavaScript and Dart are
both significantly faster than PHP when working with just arrays and
numbers. If anyone is interested I can provide the test code for more
scrutiny. I'd like to see more performance enhancements but I am not
against other enhancements as well.
Personally I would love to see more RFCs focusing on performance and
less on syntax changes.Some recent tests I performed indicate that JavaScript and Dart are
both significantly faster than PHP when working with just arrays and
numbers. If anyone is interested I can provide the test code for more
scrutiny. I'd like to see more performance enhancements but I am not
against other enhancements as well.
That is expected. Both of them use JIT-compilation, which is not present in PHP.
There was some effort to implement PHP in PyPy/RPython, but it is not active
http://morepypy.blogspot.ru/2012/07/hello-everyone.html
Hello,
In the slice of the "community" where I spend most of my time,
medium-to-large companies using PHP with their own custom code on
hundreds to thousands or even 10's of thousands of servers, neither
annotations nor getter/setter are anywhere on their wishlist radar. What
they most desire is performance, robustness and security. They would
love to see a PHP release that had no syntax changes, no BC changes, but
was twice as fast and crashed half as much. I realize this is just one
(small?) slice of the community but so is the part of the community
wanting annotations. This is the balancing act we have to perform. It is
not stubbornness, nor living in the past, it is recognizing that each
and every major feature addition has a destabilizing effect on the
codebase and if the addition only serves a small slice of the userbase
we have to think long and hard about the merits of it.
I couldn't agree with you more. While the company that I'm working on
just hit the hundred limit, this is one of our concerns as well.
And like I've said, stability is a key factor for us. Speed is also critical
and I agree that everyone needs more speed any time you ask them.
The examples I gave where just examples, not something that I'm crying
that is not added to the language but my company is also trying to be
open to any new things that would make our lives easier and help us
code faster, easier, better and so on.
I think it would be helpful to have something like a roadmap with various
features and changes both in regards to language and features as well
as performance.
Also, having a clear line of when features will be deprecated then removed
will go a long way to help out users while writing their software. That way,
people would know what to expect from the language and when it would
be the time to upgrade.
You could use the example of JetBrains and how they manage their
products via their issue tracker, http://youtrack.jetbrains.com/issues/WI
in which everyone that is not part of the core team can 'vote' for a feature
or bug or what not and participate in a threaded discussion in a simpler
manner.
This would bring you a nicer interface that the current ones while being
able to also gauge the community interest in certain issues.
I think if the PHP group would ask JetBrains for their software for free,
they wouldn't say no and I gave them as an example because I'm using
their beta software since it the second is out on their download servers
and I'm reporting every crash that I can as they made it really easy for
me to help them out.
And yes, I do feel like the current software stack of PHP.net is a bit out
of sync with the modern tools that are already there, sorry if I offend
someone.
That's why I think that the next major version of PHP should happen
sooner rather that later. I'm a strong believer that the current engine is
hard to maintain and document and very few people know most of it.
PHP 5.5 should be the last 5.X release then you should announce that
PHP 6 needs more volunteers for a better (faster) parser, people who
can help you on documenting it and so on.
Just make PHP 6.0 a PHP 5.5 that's clean under the hood, maybe
even brings some performance improvements along the way and that's
it. You already know what are the requirements for everything, you
already have feedback on what the community wants in the future,
so why not help yourself by doing something that's clean and along
the way will help you get more contributors?
Also please see my other suggestions on how you could get more
support from the users.
Best regards.
Florin Patan
https://github.com/dlsniper
replying inline
I think it would be helpful to have something like a roadmap with various
features and changes both in regards to language and features as well
as performance.
We have discussed before and the problem is the nature of the project: it
is an open source project where the contribution comes from the spare time
of the volunters (with a couple of exceptions like people from Oracle
working on the mysql drivers/docs etc.).
So we can try and plan ahead, but in the end we can only release what we
have, and there are no guarantees that somebody will do the job (or do in
in a reasonable timeframe).
PHP6 was an example of a release where we didn't timeboxed, but
feature-boxed, and I think that even without the unicode part, it would
still take too long or would have to break some promises.
Some of the open source project do something in-between, not promising
exact features/ideas for a given release but selecting a couple of
areas/aspects where the release should improve on the current situation:
that could also work imo.
Also, having a clear line of when features will be deprecated then removed
will go a long way to help out users while writing their software. That
way,
people would know what to expect from the language and when it would
be the time to upgrade.
I think that it isn't necessary a bad thing that we aren't forced to tell
beforehand than a given deprecated version will be removed in which
version, because this way we can push the decision to a later date, when we
have more information to select the best option.
I think that Linus had a really good job explaining that in the first
chapter of
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=Documentation/ManagementStyle
You could use the example of JetBrains and how they manage their
products via their issue tracker, http://youtrack.jetbrains.com/issues/WI
in which everyone that is not part of the core team can 'vote' for a
feature
or bug or what not and participate in a threaded discussion in a simpler
manner.
This would bring you a nicer interface that the current ones while being
able to also gauge the community interest in certain issues.
We already have comments and voting (and ordering on the votes) in the
issue tracker, but if you think that you can improve on the interface, feel
free to send a pull request, I'm sure that there is much room for
improvements, especially in the UI/UX part.
I think if the PHP group would ask JetBrains for their software for free,
they wouldn't say no and I gave them as an example because I'm using
their beta software since it the second is out on their download servers
and I'm reporting every crash that I can as they made it really easy for
me to help them out.
Not sure how this is related to the discussion, but we already got some
licenses from JetBrains (AFAIR Shein Alexey handled that for the phpdoc
team).
And yes, I do feel like the current software stack of PHP.net is a bit out
of sync with the modern tools that are already there, sorry if I offend
someone.
it is, and it is a chicken and egg problem:
even though that the usual "my C-fu is weak" argument doesn't apply there,
we still lack contributors, and the archaic nature of the current codebase
doesn't really helps bringing in new people.
even if a newcomer would come around with a rewrite of the current
bugtracker based on some modern framework (ZF2/sf2/etc.), it would be a
hard decision, because who who knows what new bugs that codebase has and
there would be a real issue if the original author leaves and there would
be no people left having familiar with the codebase.
the current codebase sucks, but it had time for the bugs to surface, and
the people who work on it are familiar with it.
there is also an issue, that most of the php.net infrastructure is older
than any other framework lifecycle would provide, so switching to a 3rd
party framework would require more maintainence work (ofc. it would also
have advantages like better documentation and people outside of the project
would have an easier time to jump into contributing to it).
That's why I think that the next major version of PHP should happen
sooner rather that later. I'm a strong believer that the current engine is
hard to maintain and document and very few people know most of it.
I'm a little bit confused, so you are talking about the PHP.net software
stack or about the toolchain/stack used for the development of the language?
I think that the current documentation team is doing a fine job (ofc. there
is also room for improvement, like better/tigher integration/communication
between the php-core and the documentation team),
PHP 5.5 should be the last 5.X release then you should announce that
PHP 6 needs more volunteers for a better (faster) parser, people who
can help you on documenting it and so on.
I think that we definitely need to be more engaging for the possible
contributors, making it as easy as possible to participate, and I think
that the git/github move was a step in the good direction and the new
php.net layout also.
Closing the doors for 5.X without actually having something to release or
at least a plan/roadmap would be a bad idea imo and the announcement you
mentioned could be interpreted as a distress call, and maybe that is not
something what we have or want.
Just make PHP 6.0 a PHP 5.5 that's clean under the hood, maybe
even brings some performance improvements along the way and that's
it.
Yeah, that is something what everybody would agree to have. I mean who
wouldn't want more robust/stable and faster code.
You already know what are the requirements for everything, you
already have feedback on what the community wants in the future,
so why not help yourself by doing something that's clean and along
the way will help you get more contributors?
I'm not sure about this, some of the stuff that could/should be done
(unicode support, AST based parser, etc.) is pretty hard, so we still need
to research/prototype it, and we yet to find a way to get feedback from the
community at wide (even the framework users conference attendees active
community members are only a small part of the php ecosystem), there is
currently a separate thread discussing that topic and proposing using
surveys to solve this problem.
thanks for your feedback!
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Personally I would love to see more RFCs focusing on performance and
less on syntax changes. Of course, a syntax change RFC, and even the
initial (often shaky) implementation of a syntax-related change is much
much easier to whip up than the deep analysis, profiling and creativity
required to find and come up with ways to make a complex piece of code
faster or use less memory.
+1.
I think that the RFC process did the project very good and enabled new
people and their patches into the project. Nevertheless we should be
aware that a scripting language needs to be robust and fast. The more
language syntax we add, the more complex the language gets and therefore
it's quality as a very good beginners language. Also we just end up in the
troubles we had over the last years when one could just hope that xdebug
will catch up with new language changes (thanks to derick it usually does),
and one knew that APC will not work.
A lot of the language features in the last years didn't just make some
people happy but also made others unhappy as they couldn't use the new
language in production (and thats what counts). People are stuck with
5.3 atm because there is no opcode cache for 5.4 and the only good news
for them is that the ZO+ RFC focuses and robustness and performance so
the users will still have an opcache for a new version once 5.3 is EOL
(in a year). (and i am not even talking about the headache everyone is
already talking about because they used a lot of apc caching functions
in their code and therefore are stuck with 5.3 for another 2 years and
can just rely on distros for patching).
So plesae when one talks about the userbase, make sure you just dont
see you part of the bubble but all the others who are struggling
with recent changes already.
Hi!
F.e., how long have we been battled for annotations? With all
respects, it is about being blind and stubborn to say that PHP should
not have annotations. But due to some "I'm happy with what we have
It is about being blind and stubborn to hold opinion different than
yours. And this not an opinion but a fact. Got it.
This is not about borking the language with useless features. This is
not about being on the cutting edge. this is about catching up with
the competition.
"Keeping up with the Joneses" is not a good idea in personal life, and
is not a good idea in language design. Not everything Joneses have we
should have, just because they do. You have to have better reasons.
Sometimes there are better reasons, and we do borrow all the time. But
doing that just because they have it makes little sense. When we
decide that it makes sense for PHP, then we can look at how others do it
and see if it translates.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Zeev Suraski wrote:
There used to be a language that was the Queen of the Web. It was full of
clever syntax. It prided itself on having a variety of expressive ways of
doing the same thing. You're on the mailing list of the language that
dethroned it.
And the majority of END USERS are more than happy with the websites it is
serving up today! If you want to evolve the language then much more effort
should be put into providing tools that update the current user base rather than
simply throwing in switches which hide all the problems :( Having to manually
update sites on a case by case basis is what is currently holding things back -
and stopping ISP's switching to the 'latest and greatest'!
--
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
Hello,
This might sound as a rant but I assure you it's not.
It's just how I see the things from my perspective and that of
my colleagues/employer.
What you're bringing up is not at all about adapting. Adapting is
something we do at the extensions, frameworks and tools levels. I'm happy
to say PHP's ecosystem here is very healthy, in my opinion.
Could you please share how you measure that the ecosystem is healthy or
not? And What do you mean in terms it's healthy? Is it adoption rate of new
versions, penetration degree, influx of new people?
Adapting is not what we're dealing with here. We're talking about Adding.
I think that there are are cases where Adding is a mean for adapting. Like
for example, the desire to have built-in annotation support.
By adding more and more, we're making the language more and more complex,
less and less accessible to both new and existing developers, thereby
hurting its #1 appeal - simplicity. As we thrust forward towards 5.5,
more than half of the community is still on 5.2. 5.4 is virtually
nonexistent in terms of real world usage, and yet we thrust forward to
5.5, as if the community at large cares about all these new features. The
community is voting with its feet, and that is probably the best survey
we're ever going to get.
The adoption of PHP 5.4 has been next to 0 because of the various BC breaks
done, and even more, because APC has had a stable version only after about
one year. Enterprise users such as myself can't just go to work and say: Hey,
there's a new PHP version, it breaks some things for which we'll need time to
fix, it adds features that we could really use but we can live without them and
do workarounds like until now. Even if we'd had time to fix the broken things
there's a tiny issue, we can't be sure of how APC will work and if it's going to
crash our business or not.
Enterprise users want stability above all else, even if it means that their devs
will need to live without new features for a long time and work more in order
to develop their software.
Things that happened in PHP 5.4 should never happen again if you want to
have larger adoption rates. ISPs can't just upgrade their software stack
knowing that 99% of the sites they hold are at risk of not working due to
BC breaks between 5.X releases. Deprecating is one thing, removing is
another thing.
I'm not saying we shouldn't add new features. But I am saying that we
shouldn't add many of them. The very few we should add - should have
exceptional 'return on investment'. To be clear, the investment isn't
just the effort to develop or even maintain the implementation - that's
not even the main point. It's the increased complexity that each and
every new language construct brings with it, whether we like it or not.
I totally agree with you on this one. Maybe extensions bundled with
default distribution could be a good solution for adding new things that
could be disabled on demand via configuration options.
There used to be a language that was the Queen of the Web. It was full of
clever syntax. It prided itself on having a variety of expressive ways of
doing the same thing. You're on the mailing list of the language that
dethroned it.Zeev
Currently in PHP you can do the same thing about the same way.
The difference is that right now, there's a bunch of things missing
when compared to other languages and this is a push off.
Consider the following scenario: We are a team of 60 programmers
all with various PHP skills. We'll need say threading to better handle
some reporting application. We all know PHP and maybe 2 of us
know Erlang. Say we care about those who'll need to maintain the
application when we'll be out of office or at other companies. The
choice in this case is obvious for us. Use PHP. We simply can't
afford to have new people hired that are specialized in a language
that best fits our needs nor our colleagues might have time to learn
how to fix something in a critical system when we are not around.
Erlang should be the obvious choice in case of high concurrency
and threading but we can't just use another language.
Or have a look at annotations. Zend Framework 2 uses them (hint),
Symfony2 uses them, Doctrine uses them and so on. All major
players in the PHP world. It's frameworks and tools that also
drive the adoption of a language not just the features. Imho, if most
major players say they need something in order to build better
tools for their users then I guess they should be heard of by the
developers. Just like what happens when a end user of a framework
wants a new feature in the framework they use.
The problem with PHP is that it's written in C and even if it grew so
big in the past years, the users to contributors conversion is very
low. But then again, look at the website. There's nothing saying on
it about contributions. There are no Bug hunt days events. There's
no tutorial on how regular folks can learn the internals and help you
out with fixing bugs. There's no blog in which you can get in touch
with users and see what they feel about something. There's nothing
encouraging them to explore the internals and help you out.
Granted, when I've asked on the ML or #php.pecl none of my questions
remained without answers and people were really helpful in this
regard, but it's just because I'm curious enough to see what's
behind the scenes and I want to give back something to the language
that I've been using for the past seven years.
Do you want more people look past the PHP manual / front page and
help you out?
Why not encourage them to contribute by adding a link to a page on the
menu of every page? Why not organize Bug hunt days every month?
Or even better, try adding a related bugs on the top of the manual page
for certain functions/sections with something like: 'There's about X bugs
for this function/extension/section. Help us by contributing with reports
or fixes here.'
Rise funds for recording videos on how to install a version of PHP and
help out with debugging. Make it a easy process, provide Vagrant
machines so everyone can use them. Rise funds if needed to have
those things done.
At least this is how I see things improving, by rising the attention of the
end users about the problems that the language has and trying to
meet possible new contributors half way.
Best regards,
One userland member
Florin Patan
https://github.com/dlsniper
-----Original Message-----
From: Florin Razvan Patan [mailto:florinpatan@gmail.com]
Sent: Thursday, February 21, 2013 3:15 PM
To: Zeev Suraski
Cc: Lars Strojny; Derick Rethans; PHP Developers Mailing List
Subject: Re: [PHP-DEV] Give the Language a Rest motion (fwd)What you're bringing up is not at all about adapting. Adapting is
something we do at the extensions, frameworks and tools levels. I'm
happy to say PHP's ecosystem here is very healthy, in my opinion.Could you please share how you measure that the ecosystem is healthy or
not?
And What do you mean in terms it's healthy? Is it adoption rate of new
versions,
penetration degree, influx of new people?
We have a good solid set of extensions, including lots of activity on PECL.
We have flourishing framework ecosystems that are extremely active. We have
excellent support from tools, both free and commercial. That's how I
measure it.
Adapting is not what we're dealing with here. We're talking about
Adding.I think that there are are cases where Adding is a mean for adapting. Like
for
example, the desire to have built-in annotation support.
That's not adaptation in my book. That's addition. It's not the technology
landscape that changed that now you need annotations; It's that some people
consider this feature cool and useful, and want to import it into PHP
although it does not in fact enable you to do anything you can't do today,
while it does add a lot of complexity to the language.
By adding more and more, we're making the language more and more
complex, less and less accessible to both new and existing developers,
thereby hurting its #1 appeal - simplicity. As we thrust forward
towards 5.5, more than half of the community is still on 5.2. 5.4 is
virtually nonexistent in terms of real world usage, and yet we thrust
forward to 5.5, as if the community at large cares about all these new
features. The community is voting with its feet, and that is probably
the best survey we're ever going to get.The adoption of PHP 5.4 has been next to 0 because of the various BC
breaks
done, and even more, because APC has had a stable version only after about
one year. Enterprise users such as myself can't just go to work and say:
Hey,
there's a new PHP version, it breaks some things for which we'll need time
to fix,
it adds features that we could really use but we can live without them and
do
workarounds like until now. Even if we'd had time to fix the broken things
there's a tiny issue, we can't be sure of how APC will work and if it's
going to
crash our business or not.
PHP 5.4 actually brings very little BC breakage.
Most companies as well as private users I know haven't even gotten to
evaluate PHP 5.4 and even learn that APC doesn't work on it, because
honestly, they couldn't care less. For them, 5.3 or even 5.2 are good
enough, they don't even inquire into 5.4.
For the vast majority of companies/users, the motivation to upgrade PHP
would be coming from two places:
- If they need it in order to run their apps (5.3 is required by a growing
number of frameworks (ZF2, Sf2)). - If they're worried about security updates after the EOL.
The point is that "the sky is falling" mentality that was expressed here by
certain people could not be farther from reality. If we take a look at the
userbase at large, people are content with PHP's syntax, and the constant
drive for additions to it simply makes no sense.
Enterprise users want stability above all else, even if it means that
their devs will
need to live without new features for a long time and work more in order
to
develop their software.
It's not just enterprises, effectively it's anybody who uses PHP for
anything that’s' beyond a hobby.
I'm not saying we shouldn't add new features. But I am saying that we
shouldn't add many of them. The very few we should add - should have
exceptional 'return on investment'. To be clear, the investment isn't
just the effort to develop or even maintain the implementation -
that's not even the main point. It's the increased complexity that
each and every new language construct brings with it, whether we like it
or
not.I totally agree with you on this one. Maybe extensions bundled with
default
distribution could be a good solution for adding new things that could be
disabled on demand via configuration options.
Potentially; Although generally language syntax is typically hard or
impossible to implement through extensions.
Currently in PHP you can do the same thing about the same way.
The difference is that right now, there's a bunch of things missing when
compared to other languages and this is a push off.
Why does it matter that some features are 'missing'?
Do all other languages continuously replicate all of PHP's and other leading
languages feature sets too?
Different languages have different philosophies and syntax, and that's
absolutely fine. We need to resist the urge to turn PHP into an
everything-and-the-kitchen-sink language.
Or have a look at annotations. Zend Framework 2 uses them (hint),
Symfony2 uses them, Doctrine uses them and so on.
And they're all fairly complex pieces of software, that a great deal of the
PHP userbase would have a hard time using, let alone contributing to.
ZF2/Sf2/Doctrine contributors, who are 0.01% of the PHP userbase (assuming
roughly 500 people out of 5 million), can make do with implementing
annotations for their own needs, and leave the rest of the community a
cleaner, simpler language.
The problem with PHP is that it's written in C and even if it grew so big
in the
past years, the users to contributors conversion is very low. But then
again, look
at the website. There's nothing saying on it about contributions. There
are no
Bug hunt days events. There's no tutorial on how regular folks can learn
the
internals and help you out with fixing bugs. There's no blog in which you
can get
in touch with users and see what they feel about something. There's
nothing
encouraging them to explore the internals and help you out.
I guess I'm in a minority here, but I really don't think that the fact we
don't have annotations or any of the other features on the wishlist of some
people here, has anything at all to do with lack of contributors. They're
all fairly small features, that shouldn't take more than a few days or a
week or two to implement. That's not the issue - the issue is whether or
not they belong in PHP.
That said, other types of contributions - like fixing bugs, testing and
improving existing features - could definitely use more volunteers. That's
not something that can be done in a couple of days or a couple of weeks.
Why not encourage them to contribute by adding a link to a page on the
menu
of every page? Why not organize Bug hunt days every month?
Or even better, try adding a related bugs on the top of the manual page
for
certain functions/sections with something like: 'There's about X bugs for
this
function/extension/section. Help us by contributing with reports or fixes
here.'Rise funds for recording videos on how to install a version of PHP and
help out
with debugging. Make it a easy process, provide Vagrant machines so
everyone
can use them. Rise funds if needed to have those things done.At least this is how I see things improving, by rising the attention of
the end users
about the problems that the language has and trying to meet possible new
contributors half way.
I think you're proposing some excellent ideas. I for one would be happy to
see more volunteers working on those fronts, instead of wasting so much
energy on churn.
FWIW, this did not at all sound like rant, I think it was an excellent post.
Zeev
hi,
That's not adaptation in my book. That's addition. It's not the technology
landscape that changed that now you need annotations; It's that some people
consider this feature cool and useful, and want to import it into PHP
although it does not in fact enable you to do anything you can't do today,
while it does add a lot of complexity to the language.
I can do everything PHP does in assembler, but I do not implement web
apps in assembler.
Cheers,
Pierre
@pierrejoye
-----Original Message-----
From: Pierre Joye [mailto:pierre.php@gmail.com]
Sent: Thursday, February 21, 2013 4:08 PM
To: Zeev Suraski
Cc: Florin Razvan Patan; Lars Strojny; Derick Rethans; PHP Developers
Mailing
List
Subject: Re: [PHP-DEV] Give the Language a Rest motion (fwd)hi,
That's not adaptation in my book. That's addition. It's not the
technology landscape that changed that now you need annotations; It's
that some people consider this feature cool and useful, and want to
import it into PHP although it does not in fact enable you to do
anything you can't do today, while it does add a lot of complexity to
the
language.I can do everything PHP does in assembler, but I do not implement web
apps in
assembler.
Actually no, you can't. You won't live long enough to write a meaningful
web app in asm, even if you live to be exceptionally old, and I certainly
wish you well.
Zeev
There used to be a language that was the Queen of the Web. It was full of
clever syntax. It prided itself on having a variety of expressive ways of
doing the same thing. You're on the mailing list of the language that
dethroned it.
This needs to be printed and framed somewhere.
Your comments are great, but this last paragraph is magnificent.
+1
Hello, didn't read the whole thread, just a few messages at the start. But
because I'm replying to the starting message, it's not relevant :)
In principle, as a user-land developer, I agree with the motion. It's too
much fancy new shiny stuff lately and no actual improvement on the old
stuff that really needs fixing or updating/rewriting (PDO anyone? Years
behind every db driver extension there is in PHP, and as far as I'm
concerned - it should be dropped and concentrate on standardize the db
extension public API).
As far as I see, there is technical debt piling up and except the actual
core developers no one understands that - people just spawn RFC's like
crazy. As it was said countless times - PHP core team lacks resources to
fix many issues that are already there and new stuff just makes it worse.
Actually, if I was a core team member (sadly C is not my love and most of
the stuff I want to change requires actual coding), I would push a motion
to temporary suspend accepting RFC's that introduce new features and devote
release after 5.5 to fixing and rewriting the old stuff and bug fixing. And
that can prove to be a much more positive that just new features. I think
with last two releases there was ton of stuff added and it will take time
to actually grasp it and start using it. Hell, I like traits, but I can't
put a finger on how to use them at the moment. And it will take me some
considerable time to actually find a place for them and integrate them into
my work so that they fit just right. Late static binding? Hell, still
didn't use it at all. Anonymous functions - yeah, this one is all over my
code now (of course not just for the sake of it) and some other recent
stuff I use too.
Ok, I have to stop mumbling. What I wanted to say - it will take time for
developers, community, frameworks and hosting companies to catch up with
the stuff that was introduced in 5.3, 5.4 and will be in 5.5. To my opinion
there should be a pause in new additions and time taken to take care of the
old stuff that needs love, some need it desperately.
Thanks,
Arvids.
Arvids Godjuks wrote:
In principle, as a user-land developer, I agree with the motion. It's too
much fancy new shiny stuff lately and no actual improvement on the old
stuff that really needs fixing or updating/rewriting (PDO anyone? Years
behind every db driver extension there is in PHP, and as far as I'm
concerned - it should be dropped and concentrate on standardize the db
extension public API).
A BIG +1 on that ... there are a number of better options which would actually
be a step forward rather than dragging everything back to the past with PDO's
limited API !
--
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
2013/2/20 Derick Rethans derick@php.net:
Looks like it is time to forward this email from 2006 again:
---------- Forwarded message ----------
Date: Thu, 09 Mar 2006 12:57:32 +0200
From: Zeev Suraski zeev@zend.com
To: internals@lists.php.net
Subject: [PHP-DEV] Give the Language a Rest motionI'd like to raise a motion to 'Give the Language a Rest'.
Almost a decade since we started with the 2nd iteration on the syntax (PHP 3),
and 2 more major versions since then, and we're still heatedly debating on
adding new syntactical, core level features.Is it really necessary? I'd say in almost all cases the answer's no, and a
bunch of cases where a new feature could be useful does not constitute a good
enough reason to add a syntax level feature. We might have to account for new
technologies, or maybe new ways of thinking that might arise, but needless to
say, most of the stuff we've been dealing with in recent times doesn't exactly
fall in the category of cutting edge technology.My motion is to make it much, much more difficult to add new syntax-level
features into PHP. Consider only features which have significant traction to a
large chunk of our userbase, and not something that could be useful in some
extremely specialized edge cases, usually of PHP being used for non web stuff.How do we do it? Unfortunately, I can't come up with a real mechanism to
'enforce' a due process and reasoning for new features.Instead, please take at least an hour to bounce this idea in the back of your
mind, preferably more. Make sure you think about the full context, the huge
audience out there, the consequences of making the learning curve steeper with
every new feature, and the scope of the goodness that those new features bring.
Consider how far we all come and how successful the PHP language is today, in
implementing all sorts of applications most of us would have never even thought
of when we created the language.Once you're done thinking, decide for yourself. Does it make sense to be
discussing new language level features every other week? Or should we, perhaps,
invest more in other fronts, which would be beneficial for a far bigger
audience. The levels above - extensions to keep with the latest technologies,
foundation classes, etc. Pretty much, the same direction other mature languages
went to.To be clear, and to give this motion higher chances of success, I'm not talking
about jump. PHP can live with jump, almost as well as it could live without it
:) I'm talking about the general sentiment.Zeev
--
--
Agree. There are only a few core devs working daily in the PHP
internals. I would say please give the Language (and devs) a rest
motion, because there are a lot of bugs and work to be done but I'm
afraid that is more easy/funny to request a new feature/syntax than do
the grunt work :(
hi,
Agree. There are only a few core devs working daily in the PHP
internals. I would say please give the Language (and devs) a rest
motion, because there are a lot of bugs and work to be done but I'm
afraid that is more easy/funny to request a new feature/syntax than do
the grunt work :(
And those proposing new long awaited features are new contributors and
those actually doing the household job too, since quite some time. So
basically your last argument is contradicted by the reality.
Cheers,
Pierre
@pierrejoye
Once you're done thinking, decide for yourself. Does it make sense to be
discussing new language level features every other week? Or should we,
perhaps,
invest more in other fronts, which would be beneficial for a far bigger
audience. The levels above - extensions to keep with the latest
technologies,
foundation classes, etc. Pretty much, the same direction other mature
languages
went to.
Won't comment one the rest of this (to avoid more flame), but wanted to say
something about this: If you want more foundation classes / libraries, then
what PHP has to do is move more of it's standard library to PHP. C has a
large implementational overhead and an even larger entry barrier. To make
major advances on the library front, it needs to move to PHP. There are
some tough problems associated with this, but I think they can be solved
and PHP would benefit a lot from this.
Nikita