PHP As A Next-Generation Programming Language?

[Pajn]

The only way to make PHP good is to rename Python PHP.
And it's still not a next generation language if you talk web as server rendered solutions gives
users a very crappy experience. Web applications should be rendered on the client using
for example Javascript or Dart.

Oh god, no... python has the same pitfalls php has and many more. It's a nice language and has nice feature and data handling, but in my opinion it is completely unsuitable for large cooperative projects due to its characteristics (duck typing, dynamically and strongly typed). Also PHP is born to be used as a template language, python isn't at all.

Strongly typed is a great thing. Dynamic and duck typing is kind of a problem but with PyCharm it's pretty much solved anyway.
Not being a template language is the greatest feature of them all.

And no, it have nowhere near the amount of pitfalls as PHP and almost none are the same.

[niner]

Michael, please correct your post. There is no PERL7. The language is called Perl and the version Frank was talking about is Perl 6 and he is wrong. Perl 6 is compatible with Perl 5 and a smooth transition is possible. One can use Perl 5 modules from Perl 6 and vice versa and even mix Perl 5 and Perl 6 code in the same file.

I posted the same on Fank's blog but the comment is still awaiting moderation. Please let's not spread this misinformation further.

[KellyClowers]

Fix PHP? How about kill it off instead? Sounds like a better plan.

[xeekei]

It's entertaining to see people talk about their favourite languages like their opinions are facts.

[blackshard]

Strongly typed is a great thing. Dynamic and duck typing is kind of a problem but with PyCharm it's pretty much solved anyway.
Not being a template language is the greatest feature of them all.

And no, it have nowhere near the amount of pitfalls as PHP and almost none are the same.

So you're suggesting an IDE to solve the issues of a language? Sorry but I would prefer a radical solution, this is just hiding the problems and not solving them.

What is happening is that many scripting languages (like PHP, but also Javascript) are currently being pushed to a more formal and stricter form. Javascript recently got typed arrays, standard class notation. PHP is being evolved by facebook into Hack, which has static typing. I sense Java flavour in these things, and java is on the opposite side of python.

Anyway also python has its nice pitfalls, like

- mixed naming conventions (camel case and underscore names)
- no data type abstraction. Everything can access every attribute of everything else. Can be nice, but in a cooperative environment it is a pain in the ass
- try/except logic. Can be hard to master in complex situations (like nested try/except with various paths)
- presence of a (sort of) instance constructor, but absence of the corresponding destructor. You can initialize your class instance with __init__, but you can't deinitialize it when the instance is disposed (and no, __del__ is not doing that)
- presence of the GIL (at least in CPython) so no concurrent threads and presence of a shared interpreter state.
- not a template language. yes, why should you use a language for the web if you have to write tons of print statements, substituting template variables one at a time? Let the job being done by a fast syntax/lexical anaylizer

[zappa86]

Again, why not python for this? Just the strong typing of objects (not variables) seems like the way to go in the non static typed languages. It seems like an upgrade over everything in PHP.

Although, everytime I start something in Python, and it gets above 100 loc, I regret not using Java or C++. Frankly I find "flexibility" to be cumbersome and slow down development and just prefer the good ol' strongly typed static languages.

[akincer]

What improvements? PDO already satisfies 99% of use cases. It's not difficult to build an ORM to suit your needs on top.

I disagree. PDO was quite the quantum leap for PHP DB handling, but I've found it a bit muddled and the documentation lacking. Moreover, in order to make it work really well, you have to build in checks and such that you just shouldn't have to. Additionally, I would suggest that you shouldn't have to go the route you do in order to have statements prepared and binding parameters. It should be smart enough to prepare inline. If it does that, I've never found a way to do it.

Example:

$stmt = $dbh->prepare("SELECT foo FROM bar WHERE fooid = ?");
$stmt->bindParam(1, $fooid);

Compare that with:

$stmt = $dbh->prepare("SELECT foo FROM bar WHERE fooid = $fooid");

There's no reason it shouldn't be smart enough to prepare inline and save you from having to create unnecessarily complex code to deal with multiple prepared variables in a single query.

[riklaunim]

Oh god, no... python has the same pitfalls php has and many more. It's a nice language and has nice feature and data handling, but in my opinion it is completely unsuitable for large cooperative projects due to its characteristics (duck typing, dynamically and strongly typed). Also PHP is born to be used as a template language, python isn't at all.

Python is used in "large cooperative projects". Usually Git or whatnot is responsible for the cooperative part (for any $lang). You can find it as a scripting layer for some game engines, it's used by Google (Python was on App Engine much before PHP), NASA and others use it too and it's not something odd. It's kicking out old Fortran code from science calculations here and there. It's not corporate JAVA or Windows-centric .NET platform (although there is IronPython for .NET and Jython on the JVM), but still quite handy and versatile language.

I was PHP developer but as some point I migrated to Python as I wanted to do more than just web. Aside of Django the web framework I found PyQt4 and many other cool libraries. There were/are some GTK/Qt bindings for PHP but their activity is quite "low" compared to what Python bindings have. Now I can also script electronics with Python on pyboard, or single board computers like RPi, Beaglebone (there are some PHP bindings, but still, second tier).

And that's the problem with PHP - it's not versatile and not taken seriously It will be hard to provide similar range of good libraries and tools as well as changing what developers think about PHP in general and what is the average knowledge of new PHP developers. Many years needed.

[riklaunim]

- mixed naming conventions (camel case and underscore names)

CamelCase is quite common for class names I would say. It's not JavaScript-one-style though.

- try/except logic. Can be hard to master in complex situations (like nested try/except with various paths)

Nested try/except in any language means you have bad code. Printing PHP4 style warnings instead of breaking code execution isn't a good thing to do either.

- presence of a (sort of) instance constructor, but absence of the corresponding destructor. You can initialize your class instance with __init__, but you can't deinitialize it when the instance is disposed (and no, __del__ is not doing that)

There are "with" and "finally" statements if needed. Plus it's better to be explicit.

- presence of the GIL (at least in CPython) so no concurrent threads and presence of a shared interpreter state.

There are other solutions/implementations for that if you need it I didn't had any GIL problems with my code.

- not a template language. yes, why should you use a language for the web if you have to write tons of print statements, substituting template variables one at a time? Let the job being done by a fast syntax/lexical anaylizer

PHP is not Smarty or $other template language too. Mixing server side with frontend side code give very poor codebase and no one should do that. PHP, Python and $everyone_other sane framework separates those things. Not to mention ember.js or Angular JS frameworks on the rise that make the separation even stronger where frontend and backend can be on separate servers communicating with REST over HTTP.

[DrYak]

Example:

$stmt = $dbh->prepare("SELECT foo FROM bar WHERE fooid = ?");
$stmt->bindParam(1, $fooid);

Compare that with:

$stmt = $dbh->prepare("SELECT foo FROM bar WHERE fooid = $fooid");

There's no reason it shouldn't be smart enough to prepare inline and save you from having to create unnecessarily complex code to deal with multiple prepared variables in a single query.

There is a VERY PRECISE reason why this is so:
The problem is that a "dollar sign between double quotes" has already a well defined befaviour in PHP - namely expanding the content of the $variable inside the string. Whatever the content of $fooid, it will get dumped at the end of the string in your exemple.
See xkcd for what happens if the content of the variable $fooid has not been sanitized.

By using the "bindParam" approach, you clearly state what you mean, and PHP take care to make it so the SQL actually does what you want including all the behind the scene handling (properly escape the content of $fooid, and construct the SQL request such as even in the event depicted in the XKCD commic, the request will actually search for a name called "bobby tables" instead of injecting an SQL attack to trash the whole database).


The only alternative would be to have two very distinct behaviour for the same situation:
- for every single other situation: $ in quotes behave as usual, and the variable content is expanded inside the string.
- for DB requests: $ in quotes should NOT be expanded, instead proper SQL handling should kick in so request behaves as wished and SQL injection attacks are avoided.

And it's usually bad to have behavious varying in this way.


The last alternative is having "$" always expand, but having "clean/dirty" tracking at the language level.
A variable coming from user output should be tagged "dirty". Expanding a dirty variable marks the string itself dirty. DB request refuse to accept "dirty" strings as argument. Then the only way to do the above example would be to first sanitize the variable (escaping or pattern-format checking produce variable tagged as "clean").

PHP is simple enough in this regard. Primitive strings are signed int addressable everything else is signed long or double.

You, sir, deserve to die !

More details: equality works in an entirely weird way with numbers when dealing with floating point because of the way rounding works:
Printing "$bar" says "2" on the screen, but "if ($bar == 2)" is false. WTF?
- That's because number output are always reasonably rounded (rounded to the nest few decimal, so the number rounds to 2.0 when printing)
- ...but internally during all the previous calculation, a rounding might have happened in the "wrong direction" in the last bit of the of the variable in memory. The actual value could be 2 - 1/2**24 (of by the last bit of the mantissa) and comparing with 2.0 will return false.

(Also, due to mantissa format, float can express a very wide range of number... but can't have a resolution of more that 2**24. If you manipulate numbers that are bigger than 16 million (file/memory sizes, populations, etc.), either you're going to have lots of rounding at the single unit level, or you need to be using 64 bit float eberywhere. Which in turn can only hold up to 2**53 in its mantissa. Making it still impractical for handling, for example, 64 bits checksum as simple numeric type and requiring you instead to treat checksum as strings. And hope 0-terminator C-string problems won't pop in)

So either:
- you need to reinterpret every single comparison and make it ranged ( so "if ($bar == 2)" is internally interpreted as "$bar in range(2 - epsilon, 2 + epsilon)" or "abs($bar - 2.0) < epsilon" with small enough value of espilon.
Which is cumbersome, slower and opens another can of worm

- you only do floats and expect very simple integer check to randomly fail

- you also implement integers and a meaningful way for both numeric type to work together in a dynamically typed language.