Earlier quoted context omitted.
https://twig.sensiolabs.org/
I don't think there are implementations of twig outside of PHP, so this isn't useful for the op
there is I use JTwig with Java + Spring all time
same syntax
PHP 7 Virtual Machine
81–90 of 128 posts
Re: PHP 7 Virtual Machine
#82Earlier quoted context omitted.
Of course you can write safe code in PHP, it is a complete general purpose programming language. But just like one can blame C's design and standard library for many security bugs I also think it is fair to blame PHP's standard library and design. For example PHP's PDO library makes it less convenient to supply parameters to a query the safe way than it is to do it the unsafe way. This is not necessary as can be seen…
Most languages let you cut corners and code in a sloppy way. This is not limited to PHP. I think anyone can show anecdotes to support "coding in [language you don't like] is bad". Replace "unsafe" with "non-performant" and go back to early Rails days and you'll have plenty of examples where naive framework implementation led to programmers shooting themselves in the foot with the "easy way" in a different context.. L…
> Most languages let you cut corners and code in a sloppy way. This is not limited to PHP.
Completely true, but for years PHP made it extraordinarily easy to shoot yourself in the foot right out of the box. register_globals for example...
Re: PHP 7 Virtual Machine
#83Re: PHP 7 Virtual Machine
#84Earlier quoted context omitted.
Honestly. I think its main problem is it's not hipster enough. It's too popular. I bet if you made it difficult to use (for most people), added features that make certain aspects a nightmare to scale and gave it a weird name then it would do well here. Obviously don't let anyone know about the origin... say you built it at a series of obscure coding bootcamps.
> I bet if you made it difficult to use (for most people), added features that make certain aspects a nightmare to scale and gave it a weird name then it would do well here This is the same quality of vapid criticism that is often levied against PHP, just in reverse, all that's missing is a link to a 'fractal of bad design' type of post. I'm guessing you're going to try and justify your comment with some version of "…
You sound like a cunt
Re: PHP 7 Virtual Machine
#85Earlier quoted context omitted.
It's not what you can do, it's how hard it is. Just try pulling data from a database and inserting it into a page on a way that is vulnerable to XSS in Django, Jinja, or Rails. You obviously can do it, but I bet you'll need to spend half an hour reading the documentation before you succeed. The same happens for SQL injection, and session management issues, and a huge amount of other problems.
The fault in your argumentation is comparing a language (PHP) to a framework (Django, Jinja, Rails). Your argument is valid too for any PHP framework, it's hard to do XSS in laravel, symfony or zend framework.
You would have a point the frameworks you provided had that kind of protection by default (or if you could at least enable it project-wide), and if PHP development were mostly done on them, instead of wordpress and drupal.
Besides, there's more to security than SQL injections and XSS. The PHP tooling is overflowing with bad practices.
Re: PHP 7 Virtual Machine
#86It's always pleasant to see PHP occasionally get a positive moment in the limelight on HN. It's oft scorned yet powers a very large chunk of the web. With the work done on 7 it's also one of the fastest scripting languages around and deserves a little more credit if I'm honest.
Honestly. I think its main problem is it's not hipster enough. It's too popular. I bet if you made it difficult to use (for most people), added features that make certain aspects a nightmare to scale and gave it a weird name then it would do well here. Obviously don't let anyone know about the origin... say you built it at a series of obscure coding bootcamps.
On the contrary, I dislike PHP because I find it so difficult: its bad documentation, its badly designed standard API, the many badly designed and badly documented frameworks to replace the badly designed API, and the core language that goes out of its way to let buggy code through all combine to make writing medium-sized and above programs extremely difficult.
Supposedly it's better now. I'm skeptical.
Re: PHP 7 Virtual Machine
#87Earlier quoted context omitted.
nodejs is imho best suited for two groups of tasks: 1) APIs/programs relying on high concurrency and parallelism, especially where the handler(s) have to wait a lot for stuff like DB accesses 2) streaming (in the sense of websockets servers), PHP iirc can't even be used as a websocket server 3) Any API that can be implemented without needing too many async calls - you'll end up in callback hell or promise hell otherw…
Perl is WAY better for shell-scripty stuff. It also has yearly releases and backwards compatibility is much better than for PHP. I think YOUR perception of Perl is what is outdated here. And come on, for "job control" type scripts you should be fired for using PHP over Bash. Most things can be done in 1/10th of the LOC and OOP etc won't matter when your Bash script is one file and 150LOC instead of 5-10 files, object…
> I think YOUR perception of Perl is what is outdated here.
Next to no one uses Perl any more. You won't find people to maintain your homegrown stuff - and aside from maintaining an OTRS instance I have not seen Perl code in a decade.
> Most things can be done in 1/10th of the LOC and OOP etc won't matter when your Bash script is one file and 150LOC instead of 5-10 files, objects an methods that are called just one time etc, 1000+LOC PHP.
Well good luck with Bash if your batch script involves stuff like parsing JSON/XML or interacting with databases. I prefer to write quick one-offs in PHP than wasting hours with Bash scripting; and even if it's no one-off but a script that needs to be run regularly (e.g. via cron), you'll find a competent PHP programmer for maintenance way easier than a competent Bash programmer.
> And come on, for "job control" type scripts you should be fired for using PHP over Bash.
For plain job control, like an initscript, I fully agree with you. But not for anything more complex, for the reasons outlined above.
Re: PHP 7 Virtual Machine
#88Earlier quoted context omitted.
Honestly. I think its main problem is it's not hipster enough. It's too popular. I bet if you made it difficult to use (for most people), added features that make certain aspects a nightmare to scale and gave it a weird name then it would do well here. Obviously don't let anyone know about the origin... say you built it at a series of obscure coding bootcamps.
On the contrary, I dislike PHP because I find it so difficult: its bad documentation, its badly designed standard API, the many badly designed and badly documented frameworks to replace the badly designed API, and the core language that goes out of its way to let buggy code through all combine to make writing medium-sized and above programs extremely difficult. Supposedly it's better now. I'm skeptical.
I haven't used PHP for a number of years, but I have to disagree on the documentation. I found PHP's docs to be heads and shoulders better than other languages. It has expressive, sane examples, and allows comments that may help others with repeated questions regarding certain functionality.
Compare PHP with say, Python. Tell me which one you would rather refer to.
Re: PHP 7 Virtual Machine
#89Earlier quoted context omitted.
what would be a good hardware spec and server configuration to have 5000 users do long polling with a php backend?
If you care about performance and traffic, perhaps php isn't where you should start anyway.
Uh. You do realize that Mediawiki, powering nearly all wiki systems including Wikipedia, is written in PHP. Or Facebook, they were able to go with PHP for iirc 500 M users?
PHP is in any case a better choice, performance-wise, than Python or, god forbid, Java.
Re: PHP 7 Virtual Machine
#90Earlier quoted context omitted.
I would say it's unfair to compare a library to the basic PDO. If you want to compare apples to apples, try looking at Sequel versus Doctrine or some other third party SQL library. Just like any other template language (thinking of something like ColdFusion or ASP), of course one unescaped variable is going to be a headache. But you don't have to use it that way, and probably shouldn't. While PHP started as a templat…
I do not think it is an unfair comparison since Sequel has both basic parts on the same level as PDO, and then implements the more advanced features on top of these basic parts. The basic parts of Sequel has superior usability and safety to PDO. Sequel's right way: user = db['SELECT name FROM users WHERE id = ?', id].first Sequel's wrong way: user = db["SELECT name FROM users WHERE id = #{id}"].first PDO's right way:…
Compare Sequel to EasyDB then: https://github.com/paragonie/easydb