Give the Language a Rest motion View as Markdown

Zeev Suraski schrieb:

we're still heatedly debating on adding new syntactical, core level
features.

Apart from namespaces, I can't think of any other "syntactical core
level feature" missing that could not be implemented as an extension.

Sara and Marcus have already shown (with the Operator and the SPL_Types
extensions, respectively) that new language features (operator
overloading and autoboxing, for example) can be added to PHP without
having to touch PHP itself.

--
Sebastian Bergmann http://www.sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69

I might be missing something here, but I thought the people
discussing things on this list are members of the user base. Thus,
they likely propose syntax changes and improvements because they need
them.

I have to say that I don't really get that argument some people bring
forward over and over again: "adding new features makes PHP more
difficult for beginners". Oh. Late static binding makes code
difficult to understand. Namespaces make code difficult to
understand. That's nonsense really. Take your average PHP beginner,
show him some code where iterators or __get/__set/__call are used and
ask him what's going on. You'd get the same answer.

The web is one of the most quickly changing areas in computer
technology. PHP, being primarily a language for web sites and
applications, has to change constantly in order to be able to remain
competitive. And it still has a long way to go. Unicode and
Namespaces/Packages support are absolutely essential in large
environments where interoperability is essential. Until that happens,
PHP won't be the language of choice for a good number of large (and
small) enterprises when it comes to implementing certain
applications. You can't solve this problem only by producing
frameworks or announcing one-click installers with Oracle support.
It's the language itself that also has to change so it can rise to
new challenges.

And last but not least, the pursuit of innovation, percection,
advancement is what defines mankind. You shouldn't really try to stop
that. It must be in the very interest of any language, even PHP, to
get better over time.

• David

Am 09.03.2006 um 11:57 schrieb Zeev Suraski:

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

Zeev Suraski wrote:

I'd like to raise a motion to 'Give the Language a Rest'.

+1

Brian Moon
dealnews.com

How to go broke saving money.
http://dealnews.com/

Sure, after you folks implement named parameters. :)

ducks and tries to hide

Jared

I'd like to raise a motion to 'Give the Language a Rest'.

I'd like to raise a motion to 'Give the Language a Rest'.

Tired inbox? :)

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.

I think that's a Good Thing[TM]. Today's cutting edge technology can easily
become tomorrow's partially-used banana in the pocket of history. Remember
the transputer?

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.

TBH I'd say generally this happens anyway. There isn't a lot of argument
over 'edge case' changes, although there might be a number of requests for
them (the perennial issue of memory usage in long-running CLI scripts
springs instantly to mind). It's pretty rare to see anything new go into the
Engine that comes under the heading of 'general-purpose language' rather
than 'language for the web'.

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.

We usually have you and Rasmus rather than a mechanism :) But let's assume
we didn't, let's say you wanted to drop out of PHP development altogether
and go raise chili peppers or whatever. The obvious thing would be to write
some charter in stone.

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.

This would be the problem when it came to writing some charter in stone.
Something that seems irrelevant now, might not be so in the future. Sara
pointed to Unicode and exceptions as being cases in point; I personally
don't have any vested interest in exceptions, but I know my life's going to
be made easier by having integral Unicode support, and I know a lot of other
PHP users are in that particular boat too. If there'd been a 'don't touch
the Engine' rule writ in stone, would that option even have come under
discussion? You're basically preventing evolution when you make hard rules.

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.

Perhaps there could be just the one hard rule. 'If it's possible to
implement it as an extension, do so.' There'd be nothing to prevent
co-opting essential functionality into the core, but also nothing preventing
fly-by-night technologies from having support in PHP. The biggest problem
there is that it doesn't give webhost users a fair crack because changing
hosts means you risk losing a package or two; and the ability to write
portable applications is affected in the same way. But this isn't about the
language itself any more...

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

FWIW, I support this motion.

I am never a fan of the software lifecycle that looks like
"here's a useful technology, now we just need this,
and this...etc. ad nausea". Why?

(1) Adds complexity
(2) You often get pulled out of your original design philosophy
which puts the code's architectural integrity at risk. Sometimes
this evolves into a proper code restructuring, but more often, it
does not. Throughout history we have seen that things are the
victim of their own success. This end may well be inevitable, but
continually adding features and growing the system would only serve
to expedite that end.
(3) I favor small, simple, highly expressive languages that focus on
productivity in a stated problem domain. Not large domain-independent
languages that do nothing exceptionally well.

I think the question needs to be asked repeatedly and often, "what
is our design philosophy for PHP, and is proposed feature X consistent
with that philosophy?" If not, no feature X.
(NOTE: it may be reasonable to separate PHP from Zend, or executor from
compiler, when asking this question. Consider MSFT's CLR model,
for example.)

PHP = "PHP: Hypertext Preprocessor"

I'll wager we have grown well beyond what that name suggests already.
And I'll ask the question, what the heck does jump have to do with that?
(not to insult any proponents, nor do I want to single that one out,
it's just the one I know at the moment)

To be quite frank, I'm not sure object orientation has a place in
scripting. Objects are great for organizing architectures (not necessary,
but useful). But should we be concerned about organizing architectures in
script languages? Aren't scripts supposed to be synonymous with "small set
of automation instructions" ? Reasonable question.

Why is PHP still in play in the industry? Because of it's perceived
productivity edge over Java (excluding ASP.NET at the moment since it's
single vendor status is the principal cause for it being ignored by
many companies). If that perception is lost, it's over (developers who
are fans will still cling to it for some time, but the industry will
move on).

Give the language a rest?...aye!
Focus on automation and productivity?...aye!

Cheers,
-Scott