211–220 of 489 posts
And yet ~everything in https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/ is still true. All that's happened is that the language is even more complex, has even more baggage.
The PHP community has made a ton of improvements over the last few years, surely you can't criticise a project for improving?
As far as I'm concerned the bridges have burned a long time ago and I definitely can't see myself giving PHP a second chance. That being said, if I'm wrong and PHP has really managed to become a decent language (or at least something that's not completely insane) its defenders should focus on actually showing what modern PHP code looks like. Is performance that much of a big deal for most people? In a world where Rub…
What ended PHP were not the worst parts of its design, but upstream's unwillingness to simply change the language for better. See, as a commercial enterprise (begware as a business) all kinds of "foundations" and sponsorship pools surrounding the language already accumulated a big enough pool of clients who were happy enough with PHP as it was in 4.0 era. They had no intensive to progress. Especially if their busines…
Wow that could not be more wrong. PHP definitely changes things to make the language better, especially breaking changes. PHP5 changed objects from value types to reference types -- you don't get a bigger change than that.
But they don't just change things willy-nilly -- they do try to maintain backwards compatibility as much as is reasonable otherwise it wouldn't still be PHP.
As far as I'm concerned the bridges have burned a long time ago and I definitely can't see myself giving PHP a second chance. That being said, if I'm wrong and PHP has really managed to become a decent language (or at least something that's not completely insane) its defenders should focus on actually showing what modern PHP code looks like. Is performance that much of a big deal for most people? In a world where Rub…
Your comment reads as "I like ruby therefor php is dumb" > Is performance that much of a big deal for most people? Yes obviously. Performance is important no matter the language. > the counter-intuitive behaviour of '==' You should learn the languages type system instead of assuming it works how you think. Again this is true of every language. > I assume that these obsolete functions and operators still linger for ba…
> You should learn the languages type system instead of assuming it works how you think. Again this is true of every language.
A good language should have good ergonomics. Criticism that `123 == "123foo"` is not reasonable cannot be brushed away by claiming that users should RTFM (although arguably in this case it's less an issue with == than "123foo" being implicitly cast into an integer).
Maybe this has been fixed and is no longer relevant though (I'm citing the Fractal of Bad Design page).
And yet ~everything in https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/ is still true. All that's happened is that the language is even more complex, has even more baggage.
My rebuttal from 2012: https://news.ycombinator.com/item?id=3821029
Earlier quoted context omitted.
Well if 80% of the web was running on ruby there wouldn't be any difference. Most people don't understand that 99% of performance issues are not caused by language performance but by bad architecture and bad developers. Always choose the best tool for the job, you rarely get to that scale and quality of software design that only the raw language performance is left to be optimized :)
There absolutely would be a difference. IME, people take this "performance is not a major concern when choosing a stack" thing a little too far and apply it too broadly, often without ever having benchmarked anything. When I can handle 300+ requests per second in one implementation and only 50 in another on the same hardware, that's going to be a big difference in costs that matters for everyone except fledgling busi…
If you build a Rails or Laravel app in the same way you would build a Java app, the Rails/Laravel app will be dead slow. And I've seen that happen. But if you know what you're doing you with Rails/Laravel it will be a long time before you say: we should rewrite this in Go/Rust/Erlang.
The main criteria for me when choosing a tool for the job is: how well does the team know the tool? can they use it at full potential?
I've been involved in java project with 20k monthly cloud costs. Most of the workload is handled in the background by consumers that pull messages from RabbitMQ. I'm pretty sure I could rebuild that with any language while actually reducing the costs because the bottleneck is not the code but the architecture. Would it matter if I would rewrite it in Java instead pf Python or Ruby, in terms of performance, yes, if we need to consider other things, like speed of development, etc it gets complicated again. :)
Earlier quoted context omitted.
> You have some syntax to opt into a later release (e.g. doing ` imagine the exponential complexity as old behaviours need to be kept around for various levels of opting in.
I would see it as javascript's strict mode, and I think most devs would ok with a binary switch. The only fear I'd have is a lack of big entity committed to PHP. In the heydays there was Yahoo, facebook and other giant companies relying on PHP and guaranteeing that there would be enough man power to weather any type of changes. Now I wonder how many people are left to push through breaking changes and rewrite/moderni…
The thing that matters is language consistency... A language with a pure clean vision of itself in which the programmer can guess at syntax because they understand the general syntax principles to which the language adheres. Nothing here says PHP has been fixed in this regard. Python made the big leap and fixed some huge problems when it went to python 3 - yes it's migration approach was a total fail, but it further…
To be fair, we are talking about standard library consistency and not language consistency. PHP is a consistent language but it's standard library is very low-level. In Python, you don't call the mysql C library functions directly, you use an object-oriented abstraction. In PHP, you can call those mysql C library functions directly or you can use an object-oriented abstraction.
As far as I'm concerned the bridges have burned a long time ago and I definitely can't see myself giving PHP a second chance. That being said, if I'm wrong and PHP has really managed to become a decent language (or at least something that's not completely insane) its defenders should focus on actually showing what modern PHP code looks like. Is performance that much of a big deal for most people? In a world where Rub…
> ven assuming that "modern" PHP managed to come up with better ways to deal with all of this, I assume that these obsolete functions and operators still linger for backward compatibility? If so how do you avoid them? I think the "path of least resistance" is important: developers are time-constrained, understanding-constrained, lazy (if they're virtuous), etc. There's a big incentive to do whatever is easiest/quicke…
There - no XSS, no HTML, no class requirements.
Earlier quoted context omitted.
If laravel is the best we have were fucked. Laravel is fine for prototyping but it breaks backwards compat constantly, probably due to the massive amounts of over abstraction, not to mention layer upon layer of IOC hell.
Can you explain the IOC hell? isn't most IOC / Dependency Injection patterns suppose to help the software maintainability ?
Prior to Laravel, the PHP way was minimal indirection and simple execution flow. I think it was hard to do something something different with Laravel, and definitely hard to do it in a way that offers performance and security and any other good thing you might want in addition to pretty code.
One disadvantage IOC/DI carry in every language and particularly in PHP is difficulty with debugging. If you have a file of functions and a template that generates HTML you could just read through the code yourself or use prints, now it can be hard to know where to put the print when each page load may involve a couple dozen files.
That, I believe, is IOC hell. My belief is you get through it by learning the framework internals, which is a lot of work (especially if you also have to fit something like Wordpress, Angular, your family, or Photoshop in your mind as well).