191–200 of 489 posts
Nevertheless, I would think that PHP is a hard sell for new projects and new enterprises. Unless you're a dyed-in-the-wool PHP junkie and you're bringing a team that is the same, there are a multitude of reasons why you'd want to choose a different language for web dev work.
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…
So, it's apparently a good reason to hate, but by no means a reason not to use PHP.
Fast, easy and flexible.
CakePHP is a wonderful framework and the community support is simply huge (orders of magnitude bigger than Java and C# for instance).
Don't forget that PHP runs 70% of internet (where also Wordpress and Magento are big helps)
Earlier quoted context omitted.
Well, github, just to name one:). Also shopify, digital ocean, stripe. I also worked on a large ruby app that was faster than another large Java app. Keep is mind that all these platforms handle a great deal of requests at any given time, so we're not talking simple web apps. In my experience bad software design, bad DB design and bad developers are the major cause for performance issues, you rarely get to that level…
github is terribly slow... or maybe it's just me?
From experience (did some code contributions to gitlab) when you work a lot with the filesystem, as is the case for platforms hosting git repos, you will have performance issues related to that, regardless of the programming language.
we host gitlab at my company for internal use, just switching from SSDs to HDDs made a big difference in terms of response time for big actions like opening a merge request, etc
I'm sure there are apps in the wild that get to that level of optimization where you need to decide on a different language. But what I've usually seen is you just slice that part out into a service and only rewrite that part.
I think stripe and others are basically doing this if they do hit the limits of ruby in very performance intensive workloads.
Earlier quoted context omitted.
> Is performance that much of a big deal for most people? For most people outside VC-funded startups, yes it is. It is also an environmental concern, imagine if 80% of the web was running on ruby.
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 :)
like, why the weird _ difference between strtok and str_split, why str_replace has the search first and string as third parameter but in strpos the source string is the first parameter and then the search term the second
it's all confusing and weird and while someone that's a specialist is maybe at ease with this, for a generalist going in and out the language as needed it's frustrating.
I'm hiring PHP developers in Boston! Doctrine, symfony, AWS, all backend API work.
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…