4 ms·

Why can't they just start supporting a new extension that is pure PHP and both ways compatible? Like, no template tags, no global weirdly named functions (names

Why can't they just start supporting a new extension that is pure PHP and both ways compatible? Like, no template tags, no global weirdly named functions (namespaces!) and a total cleanup of the library? Also maybe drop the $ and use def or let or whatever? Perhaps add a tool to bundle the script with the interpreter, for reliable deployments? You know, for when you grow out of the "shared hosting" phase? That is MUCH but why not on the very long term? One can dream. Something like a disclaimer: Last time I seriously used PHP, rumors said that PHP 6 was going to be big. I actually fiddled a bit with PHP 7 too. I wrote a file sharing script (incredibly messy code because the minutes I spent on it are in the same order of magnitude of those I spent on this comment), which turned out to be damn fast and I am impressed. Saying this as a person who enjoys Rust and Go.

kyriakos 10y ago
It improved a lot since then, maybe you should give it another go. Both the actual language and the ecosystem around it evolved considerably since the times you describe.
Mahn 10y ago
> no template tags Why? Native PHP excels at html templating, that's what it was created for.
- scintill76 10y ago
  Native templating isn't easy/safe. Every time you want to embed a dynamic string, you'd better remember to escape it in the correct way for the context (attribute value, text, JSON), or you're vulnerable to HTML injection, or at least mangled output that doesn't render the way it should have. If they built syntax-aware templating in, that might be interesting, but AFAIK, for now you have to use a third-party template implementation to get something semi-enjoyable to use safely. It would be better to just throw out the "template" features because they encourage messy, unsafe code.
  - tyingq 10y ago
    As far as I know, most templating frameworks (php or otherwise) don't really solve this either. PHP's native templating is perhaps prone to more issues in this area, but template frameworks (for the most part) still allow you shoot yourself in the foot with data contained in strings.
    - combatentropy 10y ago
      Most templates I've seen escape HTML by default. You have to type something extra to unescape it.
florinutz 10y ago
> maybe drop the $ triggered
- sctb 10y ago
  Please stop posting unsubstantively like this. You've had plenty of time in-between comments to come up with something better.
organsnyder 10y ago
With those things removed, what would be PHP's differentiating features? As I see it, it really has two things going for it: 1. Ease of quick-and-dirty prototyping 2. Large application code-base (especially Wordpress) Your proposals would negate both of those selling points. What would be left to make it attractive? There are plenty of other languages that already meet your requirements.
aindhaden 10y ago
I've previously toyed with the idea of a "cleaned up" PHP. And each time I abandon it when I remember that Perl, Python and Ruby already exist.
- paulryanrogers 10y ago
  And both Perl and Python suffer/benefit from radical breaks that split the ecosystem.
olemartinorg 10y ago
I'm glad they don't go in the 'Python 3' direction, and as far as I've seen, the PHP core developers try very hard not to break too much of backwards compatibility at a time - which is a good thing. Disclaimer: Actually a PHP developer. I know for a fact that if your proposal caught on, my managers would not like us to spend time rewriting a million lines of code to what is practically a new language. That doesn't contribute to making money for anyone.
- egeozcan 10y ago
  Hey, I totally agree! That's why I said a new extension (not necessarily a language extension, maybe a file extension that switches to alternate parser like, hmm, ".phpx") and both ways compatible. Including the "new style" would be possible from "classic style" and vice versa.
  - jtreminio 10y ago
    Look at Hack. They would be easier to convince than PHP core. I for one love the $ and wish other languages had a clear identifier for human variables.
fetbaffe 10y ago
Dollar ($) as prefix to variable names is actually quite good. You know instinctively what is a user created variable and not a language keyword. Easy to find variables when scanning large chunks of code and easy to use with string replacement to avoid string concatenation or sprintf. Opening tag at the beginning of file is not really worth of doing anything about. If you separate concerns in your code, you don't do HTML in your model code, therefore the only tag in a the vast majority of PHP files is the opening tag a the top of the file. Paradoxically, today you don't use PHP as templating language in modern PHP, because it is clunky. You use a templating language like mustache or twig. Standard library, yes. That ought to be fixed. My proposal to solve that is to implement function autoloading and support for callable types (parameter and return type signatures to callables). With that you could start implement outside of PHP core and start deprecating old core functions and supply a library shim for those who need it. And also with those two language features, it will be much easier to do functional programming instead of the now dominating OOP i the PHP community. PHP since 5.5 is quite good and with this release it is even better. It is flexible but at the same time rigid with very good performance. No built in state, which is perfect for stateless API:s.
- egeozcan 10y ago
  You convinced me generally, I can't agree with this only: > Dollar ($) as prefix to variable names is actually quite good. You know instinctively what is a user created variable and not a language keyword. Easy to find variables when scanning large chunks of code and easy to use with string replacement to avoid string concatenation or sprintf. Dollar prefix is hard to type with many keyboard layouts. You can also get the same effect with let/var/def/whatever and without the useless repetition. Also, any text editor with minimal support for your syntax would be able to highlight the definition/usages. The theoretical Utopian syntax would perhaps also allow $ in template strings. Further, $foo; is a bit ambiguous because in a REPL, it would output foo, error if foo is not defined; in source code, it would define foo, no-op if already defined. While `def foo;` would only be valid if foo isn't defined and that'd be creating the variable. foo, by itself, would have a consistent meaning.
  - piaste 10y ago
rpeden 10y ago
To cover the cases where I want to use something a bit cleaner while still interacting with the PHP ecosystem, I've been using Haxe and compiling it to PHP. I've found that it works quite well; it compiles into nice, readable code. I actually don't mind PHP 7+, though. It's much more pleasant to work with than it used to be. The bits of code that talk to native PHP functions will be platform specific, but I've been building up a little library of utilities that work with Haxe's other compilation targets - mainly JS, C++, Python, and C# for me. I've been especially impressed with its Javascript generation - it emits very readable and understandable JS, and its dead code elimination is quite smart; if you import a library and only use one method from one class, that's all you'll get in your compiled code.
- egeozcan 10y ago
  After reading your comment, I gave Haxe another look. Actually, I don't remember why I didn't use it in the first place. I'll perhaps give it a go.
  - rpeden 10y ago
    It's worth a try! If you're looking for a good editing environment for it, There's a good VS Code Haxe extension that works well - it has code completion and a few other nice features. And if you're ever unhappy with the language and want to jump in and wrangle the syntax tree yourself, it has a decent macro system.
TazeTSchnitzel 10y ago
Because then we'd have to maintain two languages rather than one.
mike503 10y ago
If you want something like that, why not just use a different language? Why should a language drop all of it's basic fundamental syntax? PHP should be PHP, not turn into VB/ASP.Net/ES6/Java whatever other syntax and notations and stuff people enjoy from other languages. That's like having a son, growing up as a male, maturing, and then saying "I want you to also be a female now" - if you want a daughter, have another child.

kyriakos 10y ago

It improved a lot since then, maybe you should give it another go. Both the actual language and the ecosystem around it evolved considerably since the times you describe.

Mahn 10y ago

> no template tags Why? Native PHP excels at html templating, that's what it was created for.

scintill76 10y ago
Native templating isn't easy/safe. Every time you want to embed a dynamic string, you'd better remember to escape it in the correct way for the context (attribute value, text, JSON), or you're vulnerable to HTML injection, or at least mangled output that doesn't render the way it should have. If they built syntax-aware templating in, that might be interesting, but AFAIK, for now you have to use a third-party template implementation to get something semi-enjoyable to use safely. It would be better to just throw out the "template" features because they encourage messy, unsafe code.
- tyingq 10y ago
  As far as I know, most templating frameworks (php or otherwise) don't really solve this either. PHP's native templating is perhaps prone to more issues in this area, but template frameworks (for the most part) still allow you shoot yourself in the foot with data contained in strings.
  - combatentropy 10y ago
    Most templates I've seen escape HTML by default. You have to type something extra to unescape it.

florinutz 10y ago

> maybe drop the $ triggered

sctb 10y ago
Please stop posting unsubstantively like this. You've had plenty of time in-between comments to come up with something better.

organsnyder 10y ago

With those things removed, what would be PHP's differentiating features? As I see it, it really has two things going for it: 1. Ease of quick-and-dirty prototyping 2. Large application code-base (especially Wordpress) Your proposals would negate both of those selling points. What would be left to make it attractive? There are plenty of other languages that already meet your requirements.

aindhaden 10y ago

I've previously toyed with the idea of a "cleaned up" PHP. And each time I abandon it when I remember that Perl, Python and Ruby already exist.

paulryanrogers 10y ago
And both Perl and Python suffer/benefit from radical breaks that split the ecosystem.

olemartinorg 10y ago

I'm glad they don't go in the 'Python 3' direction, and as far as I've seen, the PHP core developers try very hard not to break too much of backwards compatibility at a time - which is a good thing. Disclaimer: Actually a PHP developer. I know for a fact that if your proposal caught on, my managers would not like us to spend time rewriting a million lines of code to what is practically a new language. That doesn't contribute to making money for anyone.

egeozcan 10y ago
Hey, I totally agree! That's why I said a new extension (not necessarily a language extension, maybe a file extension that switches to alternate parser like, hmm, ".phpx") and both ways compatible. Including the "new style" would be possible from "classic style" and vice versa.
- jtreminio 10y ago
  Look at Hack. They would be easier to convince than PHP core. I for one love the $ and wish other languages had a clear identifier for human variables.

fetbaffe 10y ago

Dollar ($) as prefix to variable names is actually quite good. You know instinctively what is a user created variable and not a language keyword. Easy to find variables when scanning large chunks of code and easy to use with string replacement to avoid string concatenation or sprintf. Opening tag at the beginning of file is not really worth of doing anything about. If you separate concerns in your code, you don't do HTML in your model code, therefore the only tag in a the vast majority of PHP files is the opening tag a the top of the file. Paradoxically, today you don't use PHP as templating language in modern PHP, because it is clunky. You use a templating language like mustache or twig. Standard library, yes. That ought to be fixed. My proposal to solve that is to implement function autoloading and support for callable types (parameter and return type signatures to callables). With that you could start implement outside of PHP core and start deprecating old core functions and supply a library shim for those who need it. And also with those two language features, it will be much easier to do functional programming instead of the now dominating OOP i the PHP community. PHP since 5.5 is quite good and with this release it is even better. It is flexible but at the same time rigid with very good performance. No built in state, which is perfect for stateless API:s.

egeozcan 10y ago
You convinced me generally, I can't agree with this only: > Dollar ($) as prefix to variable names is actually quite good. You know instinctively what is a user created variable and not a language keyword. Easy to find variables when scanning large chunks of code and easy to use with string replacement to avoid string concatenation or sprintf. Dollar prefix is hard to type with many keyboard layouts. You can also get the same effect with let/var/def/whatever and without the useless repetition. Also, any text editor with minimal support for your syntax would be able to highlight the definition/usages. The theoretical Utopian syntax would perhaps also allow $ in template strings. Further, $foo; is a bit ambiguous because in a REPL, it would output foo, error if foo is not defined; in source code, it would define foo, no-op if already defined. While `def foo;` would only be valid if foo isn't defined and that'd be creating the variable. foo, by itself, would have a consistent meaning.
- piaste 10y ago

rpeden 10y ago

To cover the cases where I want to use something a bit cleaner while still interacting with the PHP ecosystem, I've been using Haxe and compiling it to PHP. I've found that it works quite well; it compiles into nice, readable code. I actually don't mind PHP 7+, though. It's much more pleasant to work with than it used to be. The bits of code that talk to native PHP functions will be platform specific, but I've been building up a little library of utilities that work with Haxe's other compilation targets - mainly JS, C++, Python, and C# for me. I've been especially impressed with its Javascript generation - it emits very readable and understandable JS, and its dead code elimination is quite smart; if you import a library and only use one method from one class, that's all you'll get in your compiled code.

egeozcan 10y ago
After reading your comment, I gave Haxe another look. Actually, I don't remember why I didn't use it in the first place. I'll perhaps give it a go.
- rpeden 10y ago
  It's worth a try! If you're looking for a good editing environment for it, There's a good VS Code Haxe extension that works well - it has code completion and a few other nice features. And if you're ever unhappy with the language and want to jump in and wrangle the syntax tree yourself, it has a decent macro system.

TazeTSchnitzel 10y ago

Because then we'd have to maintain two languages rather than one.

mike503 10y ago

If you want something like that, why not just use a different language? Why should a language drop all of it's basic fundamental syntax? PHP should be PHP, not turn into VB/ASP.Net/ES6/Java whatever other syntax and notations and stuff people enjoy from other languages. That's like having a son, growing up as a male, maturing, and then saying "I want you to also be a female now" - if you want a daughter, have another child.