Earlier quoted context omitted.
> a huge framework I contest the idea that sinatra-style frameworks are "huge". Python + flask is about as low-overhead as one can get. No need to set up any extra (apache || nginx). PHP's model of "just chug along returning null" by disabling most relevant errors is a massive antipattern in production code.
PHP has lower overhead still. You don't need to import, explicitly define route, etc. PHP Built-in dev server doesn't require anything extra either.
PHP 7 Virtual Machine
61–70 of 128 posts
Re: PHP 7 Virtual Machine
#62Earlier 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.
You hit the nail right on the head there. Some of the nightmarish build configurations to get some Javascript projects going are just beyond belief.
Re: PHP 7 Virtual Machine
#63Earlier quoted context omitted.
PHP is a whole lot more than just a templating engine. I think you would find that much more effort than is required just to make some templates.
I actually assumed this is a joke/trolling attempt, since it was a common joke to despisingly call PHP a "templating engine" a few years ago. But the follow-up seems so sincere that I don't even know what to think anymore...
Re: PHP 7 Virtual Machine
#64Earlier quoted context omitted.
> While useful, the problem was (and still is) that embedded PHP templating operates at the string level and has absolutely no concept of HTML-awareness so can't escape the strings it injects into HTML - it's trivially easy to build a PHP app taking user input where the user sends malicious tags and PHP placing it happily into generated HTML (eg. XSS attacks). > PHP apps typically also build up dynamic SQL from user…
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…
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 template language, it has clearly moved past that.
Re: PHP 7 Virtual Machine
#65Re: PHP 7 Virtual Machine
#66Earlier quoted context omitted.
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.
PHP is a web framework. It's just one that requires another framework on top to mitigate its shortcomings.
I think tpetry was pointing out the difference between a language and a framework built on that language.
(Replace language with whatever you think it is, it's still a subset just like Ruby on Rails is a subset of Ruby)
Re: PHP 7 Virtual Machine
#67Earlier quoted context omitted.
> PHP iirc can't even be used as a websocket server True, if you run it behind a web server like 99.999% of all users. If you run it as a cli script, you can implement pretty much anything. I saw a ftp server once. Crazy. Still, even on a normal web server, php can do long polling perfectly fine, which is often enough. > being able to write program flows without dozens of promises is a breeze It is a breeze with asyn…
what would be a good hardware spec and server configuration to have 5000 users do long polling with a php backend?
Re: PHP 7 Virtual Machine
#68It'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.
It has come a long way. My last job was at a big PHP shop, which had a heavy focus on doing PHP The Right Way. The result was a fairly decent, maintainable codebase. I came to really appreciate the flexibility and ability to just "make things work" that PHP has, while finally having a proper development environment with real dependency management and IDE support.
Re: PHP 7 Virtual Machine
#69Earlier quoted context omitted.
> While useful, the problem was (and still is) that embedded PHP templating operates at the string level and has absolutely no concept of HTML-awareness so can't escape the strings it injects into HTML - it's trivially easy to build a PHP app taking user input where the user sends malicious tags and PHP placing it happily into generated HTML (eg. XSS attacks). > PHP apps typically also build up dynamic SQL from user…
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…
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..
Like I said, all languages and frameworks have their caveats and learning to code properly is the developer's job, and the "right way" or "best way" is often a work in progress that evolves as the community develops best practices..
Re: PHP 7 Virtual Machine
#70Earlier quoted context omitted.
PHP is a web framework. It's just one that requires another framework on top to mitigate its shortcomings.
I use PHP quite a bit outside of the web. I think tpetry was pointing out the difference between a language and a framework built on that language. (Replace language with whatever you think it is, it's still a subset just like Ruby on Rails is a subset of Ruby)