# Give the Language a Rest motion - Thread: https://externals.io/message/22275 - Original archive: https://news-web.php.net/php.internals/22275 - Started by Zeev Suraski on 2006-03-09T10:57:32+00:00 - Messages: 17 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #22275 — Zeev Suraski — 2006-03-09T10:57:32+00:00 URL: https://externals.io/message/22275#22275 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 --- ## #22277 — Sebastian Bergmann — 2006-03-09T11:07:47+00:00 URL: https://externals.io/message/22275#22277 · In reply to: #22275 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 --- ## #22278 — Zeev Suraski — 2006-03-09T11:11:29+00:00 URL: https://externals.io/message/22275#22278 · In reply to: #22277 Good response, but it wasn't even 30 minutes :) Zeev At 13:07 09/03/2006, Sebastian Bergmann wrote: >Zeev Suraski schrieb: > > […] > > 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 --- ## #22279 — dz@bitxtender.com — 2006-03-09T11:35:05+00:00 URL: https://externals.io/message/22275#22279 · In reply to: #22275 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 --- ## #22288 — Brian Moon — 2006-03-09T15:32:28+00:00 URL: https://externals.io/message/22275#22288 · In reply to: #22275 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/ --- ## #22290 — Sara Golemon — 2006-03-09T17:04:02+00:00 URL: https://externals.io/message/22275#22290 · In reply to: #22277 > Apart from namespaces, I can't think of any other "syntactical core > level feature" missing that could not be implemented as an extension. > Goto can't... Well, okay fine. It can, but at a significantly greater cost and complexity. By that token namespaces can be done in an extension too (You just REALLY wouldn't like it). > I'd like to raise a motion to 'Give the Language a Rest'. > I have to disagree. Unicode support is a syntax level feature and that's the flagship feature of the PHP6 release. Exceptions are a syntax level feature and that was one of the shining points of PHP5. Perhaps what it's time for is recognizing that PHP is still an evolving language. Many (most) of these interminable threads are pointless deadends, but that doesn't make the one good idea in there not worth discussing. It also doesn't make the bad ideas not worth discussing because that's how you sort them out. > 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. > I couldn't agree more. That's why operator is an extension and not a proposed engine patch. However, while ZE does a commendable job at exposing its internals to manipulation there are some shortcomings. For example: My request last month for a modified or split comparison opcode to distinguish greater-than from less-than. You made some good points there about reconsidering how important it really was to know, and I do still plan to work those in, but this does serve as a good example of how the extension layer isn't _always_ enough. The inability to inject tokens and expressions into the lexer and parser is another limitation on what can be done from extensions in terms of syntax level features. Yes, I know this is more of a problem with bison and flex than with the design of ZE, but that doesn't make it any less bothersome. -Sara --- ## #22292 — Sebastian Bergmann — 2006-03-09T17:07:18+00:00 URL: https://externals.io/message/22275#22292 · In reply to: #22290 Sara Golemon schrieb: > The inability to inject tokens and expressions into the lexer and > parser is another limitation on what can be done from extensions in > terms of syntax level features. Yes, I know this is more of a problem > with bison and flex than with the design of ZE, but that doesn't make > it any less bothersome. Do other compiler tools allow this? -- Sebastian Bergmann http://www.sebastian-bergmann.de/ GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69 --- ## #22293 — Jared White — 2006-03-09T17:16:21+00:00 URL: https://externals.io/message/22275#22293 · In reply to: #22275 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'. --- ## #22297 — Sara Golemon — 2006-03-09T17:44:45+00:00 URL: https://externals.io/message/22275#22297 · In reply to: #22292 > > […] > > Do other compiler tools allow this? > I've heard second hand that lemon does. But I'm quite certain that rewriting the lexer/parser is not at the top of the list of productive ways to advance the language. -Sara --- ## #22298 — Stanislav Malyshev — 2006-03-09T17:47:55+00:00 URL: https://externals.io/message/22275#22298 · In reply to: #22279 DZ>>The web is one of the most quickly changing areas in computer technology. DZ>>PHP, being primarily a language for web sites and applications, has to DZ>>change constantly in order to be able to remain competitive. And it still I don't see any real connection between new Web technologies and changing PHP language. Most of the new technologies are not related to any language features. If you want to support AJAX, you don't need any change in the syntax of the language itself - you need good extension and yes, framework - or standard library - support, so it would be easy to implement this technology. I have yet to see one example of new Web technology that is not possible to implement using existing PHP syntax, especially if we talk about PHP5 OO capabilities. While there definitely can be improvements made to PHP (and I think, for example, packages issue is one of the areas this might happen), changing language is much more significant step than adding an extension and needs much more thorough thinking through. -- Stanislav Malyshev, Zend Products Engineer stas@zend.com http://www.zend.com/ +972-3-6139665 ext.115 --- ## #22301 — Steph Fox — 2006-03-09T18:50:57+00:00 URL: https://externals.io/message/22275#22301 · In reply to: #22275 > 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 --- ## #22304 — Benj Carson — 2006-03-09T19:27:25+00:00 URL: https://externals.io/message/22275#22304 · In reply to: #22301 > 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. One mechanism that the MapServer project[1] has adopted is that all "major" features require an RFC before they are accepted and implemented. Whoever is proposing the feature or change writes the RFC, which outlines what the impact of the change will be on users, how much code it touches, whether there are any BC breaks, etc. Once the RFC is finalised, the core group of developers vote on the RFC and if the vote carries the feature is implemented. (There's more to it than that, but this is the basic idea. See [2] for the full policy.) Writing the RFC helps the person requesting the feature to stop and think about the implications of the change and to identify any potential technical hurdles before plowing into the code. It also helps everyone else by having a concise, concrete description of the proposed feature that can be referred to during discussions. When the feature is debated on their dev list everyone is one the same page. Any changes or suggestions that come up during discussion can be included in the RFC. Another benefit of this policy is that it increases the legitimacy of the project in corporate settings. The so-called "Enterprise User" can point to it and say, "Hey, here's how these guys make decisions, it makes sense. My manager will like that". The drawback to this scheme is that not many programmers like writing design documents, and would much rather just bang away at code. This could have the effect of deterring potential contributors. (That said, I haven't personally had any problem submitting patches to Mapserver.) Anyway, just something to consider from a list-lurker... PHP is a much bigger project than MapServer, so having a process as structured as theirs might not be feasible. However, requiring RFCs for core language changes might be a good compromise between trying to implement any and every fancy new language feature and stopping core language development altogether. Benj Carson [1] http://mapserver.gis.umn.edu/ [2] http://mapserver.gis.umn.edu/development/rfc/ms-rfc-1/ --- ## #22310 — Lukas Smith — 2006-03-09T23:10:19+00:00 URL: https://externals.io/message/22275#22310 · In reply to: #22301 Steph Fox wrote: > 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... Actually there is a danger in making all too many different syntax enhancing extensions public: Language fragmentation. At some point some of these extensions might become incompatible with eachother. It just seems to me like a syntax adding extension is a different beast to handle than one that adds new syntax from system administrators/shared hosters perspective. regards, Lukas --- ## #22311 — Marcus Boerger — 2006-03-09T23:15:14+00:00 URL: https://externals.io/message/22275#22311 · In reply to: #22297 Hello Sara, but if we were moving from flex to re2c for that tokenizing scripts we'd get a nice speed boost, too. Typically re2c based scanners are 2 to 3 times faster than lex based ones. And oh-re2c allows unicode scanning (2 byte input) and you can use the same .re to generate two .c files if necessary. best regards matcus Thursday, March 9, 2006, 6:44:45 PM, you wrote: > > […] > I've heard second hand that lemon does. But I'm quite certain that > rewriting the lexer/parser is not at the top of the list of productive ways > to advance the language. > -Sara Best regards, Marcus --- ## #22312 — Zeev Suraski — 2006-03-09T23:26:20+00:00 URL: https://externals.io/message/22275#22312 · In reply to: #22311 No speed boost with opcode caches, which will be bundled in PHP 6 :) Zeev At 01:15 10/03/2006, Marcus Boerger wrote: >Hello Sara, > > but if we were moving from flex to re2c for that tokenizing scripts we'd >get a nice speed boost, too. Typically re2c based scanners are 2 to 3 times >faster than lex based ones. And oh-re2c allows unicode scanning (2 byte >input) and you can use the same .re to generate two .c files if necessary. > >best regards >matcus > >Thursday, March 9, 2006, 6:44:45 PM, you wrote: > > > […] > productive ways > > […] > > > […] > > > > >Best regards, > Marcus --- ## #22313 — Marcus Boerger — 2006-03-09T23:27:01+00:00 URL: https://externals.io/message/22275#22313 · In reply to: #22312 Hello Zeev, yeah! which is why there is no need to do anything on that front :-) marcus Friday, March 10, 2006, 12:26:20 AM, you wrote: > No speed boost with opcode caches, which will be bundled in PHP 6 :) > Zeev > At 01:15 10/03/2006, Marcus Boerger wrote: > > […] Best regards, Marcus --- ## #22381 — Scott A. Guyer — 2006-03-13T20:31:50+00:00 URL: https://externals.io/message/22275#22381 · In reply to: #22275 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