Hacker News Reader

Comment by egeozcan | Hacker News Reader

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.

View on HN

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.

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.

> no-op if already defined

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).

Thanks!

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....

SE https://en.wikipedia.org/wiki/File:KB_Sweden.svg

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.

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.

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.

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.

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.

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.

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.

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

> no template tags

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

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.

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.

Most templates I've seen escape HTML by default. You have to type something extra to unescape it.

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.

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

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.

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.

Reply on news.ycombinator.com