You can have a modern development framework for php. You guys should try http://laravel.com/ such a fresh air into php development.
PHP 5.5
91–100 of 112 posts
Re: PHP 5.5
#92Earlier quoted context omitted.
What would be valid choices for using PHP today if not for dealing with legacy code bases? It's the only thing you know? You don't have money to pay programmers for other languages? (PHP devs are commonly the cheapest)
There is not really a lot of substance in those assertions. There might be more legacy PHP codebases than, say, Ruby ones, but that's going to change as Ruby ages. The allegation that PHP is being used by people who don't know anything else is just subjective and wrong, and ultimately nothing but flamebait. You can get cheap PHP devs because PHP is so ubiquitous. You can also get really good ones. Same goes for RoR a…
> The allegation that PHP is being used by people who don't know anything else is just subjective and wrong, and ultimately nothing but flamebait.
That wasn't my allegation, though it's a good point you bring; PHP is sold as a language for novices, and novices tend to use it, despite being the most difficult language in common use due to its innumerable pitfalls, which isn't aided by the poor instruction material all over.
> You can get cheap PHP devs because PHP is so ubiquitous. You can also get really good ones.
No, but really, the pay is generally less. Being a good PHP dev is less profitable than being a good Java or Ruby one, if the same holds for other countries, then I guess that accounts even more for the reputation of the language (people who are actually good programmers tend to move to other languages for better pay among other things).
And, you know, this wasn't the point. With much better alternatives available, why choose PHP if not for familiarity or cheapness of labour?
Re: PHP 5.5
#93Am I the only one thinking PHP needs more stuff removed rather than added ?
Removing things from a language is a difficult proposition. I think increasingly a case could be made for a cleanup of many of the core functions, and I personally would remove some of the OO sugar coating added as of late. But that's probably more trouble than it's worth.
As core function naming and argument order is a pet peeve of mine, I would welcome a cleaned-up API2.0 if you will, while beginning the long phase-out of the old one.
I would agree though that some features should not have been added in the first place. But they're in now, and once they are in they should probably stay in for a while.
Re: PHP 5.5
#94Earlier quoted context omitted.
What would be valid choices for using PHP today if not for dealing with legacy code bases? It's the only thing you know? You don't have money to pay programmers for other languages? (PHP devs are commonly the cheapest)
You're living in a HN bubble if you seriously think no new projects are being created in PHP, or if you think there are no valid use cases for PHP in modern applications. Simply take a look at popular job sites - you don't even have to look at Monster. PHP devs may be the cheapest as a whole because there's so many. If you're dead-set on finding a Go programmer they will come at a cost because there's so few. Once yo…
> You're living in a HN bubble if you seriously think no new projects are being created in PHP, or if you think there are no valid use cases for PHP in modern applications.
I asked for reasons. You just told me it happens. I know it happens, I want to see a solid justification.
> Simply take a look at popular job sites - you don't even have to look at Monster.
For less pay.
> Once you get into the higher level of skill, though, it starts evening out. IIRC the average senior salary for Ruby/RoR devs is only ~$5,000 more than a PHP dev.
Why shouldn't I take the job with better pay and a better language?
Re: PHP 5.5
#95Earlier quoted context omitted.
> And what I still don't see is anything saying they are taking their performance problems seriously. Hmmm, you have heard about PHP-FPM right? And the built-in APC cache? And HipHop? Besides, in my experience performance problems will arise with other parts of your architecture a lot sooner that your application code (e.g. database if you're not clever about load balancing and caching), regardless of what language y…
I do respect the work they have done to the language, and I have also spent many hours contributing back to PHP and the various projects in the PHP community, however that doesn't change the fact that the _community_ collectively has a hard time dealing with the hard issues that need to be solved. Proof of that is the response you see right here on this forum. Mention how PHP's internals are lacking and get told how…
> Until PHP starts to take its core defects seriously I don't think it will ever make significant progress as a platform.
I'm sorry, but given that PHP the platform (forgetting about gripes with the language syntax for a moment) has been used on major projects for years, what more significant progress do you want?
Your talking about it as if it needs to prove itself as a viable technology, when clearly this is not the case.
Re: PHP 5.5
#96One of the most overlooked features of this release is the "::class" option. Using fully qualified string literals for type (class, interface, and trait) names has really hurt refactorability.
Re: PHP 5.5
#97Earlier quoted context omitted.
There is not really a lot of substance in those assertions. There might be more legacy PHP codebases than, say, Ruby ones, but that's going to change as Ruby ages. The allegation that PHP is being used by people who don't know anything else is just subjective and wrong, and ultimately nothing but flamebait. You can get cheap PHP devs because PHP is so ubiquitous. You can also get really good ones. Same goes for RoR a…
> The allegation that PHP is being used by people who don't know anything else is just subjective and wrong, and ultimately nothing but flamebait. That wasn't my allegation, though it's a good point you bring; PHP is sold as a language for novices, and novices tend to use it, despite being the most difficult language in common use due to its innumerable pitfalls, which isn't aided by the poor instruction material all…
[deleted]
Re: PHP 5.5
#98Earlier quoted context omitted.
There is not really a lot of substance in those assertions. There might be more legacy PHP codebases than, say, Ruby ones, but that's going to change as Ruby ages. The allegation that PHP is being used by people who don't know anything else is just subjective and wrong, and ultimately nothing but flamebait. You can get cheap PHP devs because PHP is so ubiquitous. You can also get really good ones. Same goes for RoR a…
> The allegation that PHP is being used by people who don't know anything else is just subjective and wrong, and ultimately nothing but flamebait. That wasn't my allegation, though it's a good point you bring; PHP is sold as a language for novices, and novices tend to use it, despite being the most difficult language in common use due to its innumerable pitfalls, which isn't aided by the poor instruction material all…
> PHP is sold as a language for novices, and novices tend to use it
These things are highly cyclical as I said, and I believe "PHP for absolute dummies"-style literature is already well past its heyday, being replaced by "RoR for absolute dummies" and, in time, other languages and frameworks. I agree about the pitfalls and that PHP is not a good language for beginners.
> Being a good PHP dev is less profitable than being a good Java or Ruby one
I don't know, it's possible. I look at this from an all-rounder's perspective, so the process is generally different. In most cases, language choice is something that happens after the project's needs have been identified. And yes, sometimes that does mean I suggest PHP when I think it's appropriate. It's never been an issue once, neither as far a client acceptance nor technical follow-through was concerned.
> why choose PHP if not for familiarity or cheapness of labour?
There are a few factors that influence this, and the developer's taste is always a big one. When in doubt I tend to avoid the application server pattern. But things that have moved me towards PHP in the past were pretty diverse. PHP's per-request execution model can have big advantages, especially when dealing with huge applications. Depending on the nature of the project, development speed can be faster. Sometimes I choose PHP over another solution because I know there will be less code to write (and I avoid it in situations where a PHP solution would be more complex). Server availability and access to support personnel can also be a factor.
Re: PHP 5.5
#99>Exceptions can be thrown into the generator using the Generator::throw() method.
>Rewinding a generator
...wut
Re: PHP 5.5
#100Earlier quoted context omitted.
Automatically updating someone else's code is more difficult than it seems. Any Python project of significant complexity will need manual adjustment before or after passing it through 2to3, and even then you'll need to perform a lot of tests to make sure that everything behaves as expected. Similarly, the upgrade wizard in .NET always breaks a thing or two. I would expect a PHP upgrade wizard to fare no better. For e…
> how would you update them automatically if you decided to change the way htmlspecialchars() works? I see two possible cases, the choice between which can be made by the converter developers or by the user (maybe via command-line flags to the converter): 1) If the new functionality is intended to be a drop-in replacement (e.g. it fixes a security bug), no change is necessary. 2) If we want existing programs to keep…
So your solution is to add more functions, like php7_htmlspecialchars(), php7_htmlentities(), etc. whenever a function needs to be deprecated, just like PHP historically added functions like mysql_escape_string(), mysql_real_escape_string(), etc.? I don't think that will help the language and its ecosystem at all. I can almost see the tutorials in my mind: "If you upgrade to PHP 8 and your function call suddenly starts spewing errors, just use php7_function and your problem is solved!" Then 3 years later: "just use php8_function!"
Anyway, my point was that static analysis, which an upgrade script needs to perform, has serious limitations when it comes to dynamic features. Callable variables are a good example of this. What if there are 100 places in your codebase where a variable is callable, but only one of them is ever going to contain a deprecated function? Static analysis can't tell which one it is, because at runtime, the variables might come from anywhere: user input, a database, a command-line argument, or the phase of the moon. The only bulletproof solution is to convert them all to php7_varcall(), even the 99 variables that don't need upgrading. But then your code just becomes unreadable, and therefore even more unmaintainable than before.