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.
> 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.Yes, a good text editor helps a lot, I use PHPStorm, which is the best IDE to use for PHP. But there are times when you just scan code like diffs or what not, then it helps. Or search/grep for that matter.
I type on a Swedish QWERTY keyboard layout, then you are used to use ALT-Gr for almost all special characters when coding, but I understand if you are on a US QWERTY then it can be a nuisance. Personally I find And ALT-Gr is easier to use then SHIFT.
US https://en.wikipedia.org/wiki/File:KB_United_States-NoAltGr....
Why shouldn't it be a compile-time error, in the same way as your suggested `def foo;`?
I can't think of a legitimate reason for wanting to write an intentional no-op (at least at the level of PHP; obviously assembly etc. is a different ballpark entirely).
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.
I for one love the $ and wish other languages had a clear identifier for human variables.
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.
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.
Why? Native PHP excels at html templating, that's what it was created for.
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.
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.
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.
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.
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.