I hated PHP for the longest time (worked extensively with PHP5 and various homebrewed frameworks in the early 2010s), but I gotta admit, it's come a long way with PHP7+ and great frameworks like Laravel.
Taking PHP Seriously (2016)
81–90 of 150 posts
Re: Taking PHP Seriously (2016)
#82Earlier quoted context omitted.
FTA: "I claim that PHP’s simpler “think; edit; reload the page” cycle makes developers more productive. I agree wholeheartedly with this. I prefer statically-typed languages w/ a bit of local inference (I end up in java usually, but C# got it right) and I consistently see people in my world underestimate the edit/reload workflow. Even a small compilation step is enough to break flow and make development a chore, once…
It’s hard for me to relate, because I just don’t see “edit; reload” as being that important. I think the difference is I write tests. I usually code everything while writing/running tests. Then it always works the first time I run it, so there’s no need for “edit; reload”.
> I think the difference is I write tests. I usually code everything while writing/running tests. Then it always works the first time I run it, so there’s no need for “edit; reload”.
I write tests, too. I guess I'm not as good of a software developer - because just as my code has bugs and unexpected edge cases, so do my tests, and they don't catch every mistake I made, since I'm the one making them.
Re: Taking PHP Seriously (2016)
#83The best language for a startup is one the founders know the best. Every other discussion will at best make a 1% difference.
I espoused this sort of rhetoric until I worked at a PHP shop. Every other discussion was about problems posed by the shortcomings of the language, crossed with mistakes made by past staff. It's so easy to make assumptions about "good actors" and "reasonable developers" that just fly out the window with a team that picks PHP and/or doesn't know much else.
It depends on a lot of factors. I worked at a startup that used PHP and the initial code quality of Product A was godawful because some early hires didn't know how to properly structure their code. Over the next few years, as staff turned over, we were able to clean it up considerably, add a lot of good OO practices, and get to a point where new developers who didn't even have PHP experience could be very productive very quickly.
When we started a Product B about nine months into my time there, the new team wrote new, well-designed code from scratch, and was also very productive very quickly.
PHP lets you easily shoot yourself in the foot, but it also gives you all the tools you need to leave your feet in very good condition, and it's not difficult to do that either.
Re: Taking PHP Seriously (2016)
#84It's like an ugly C.
It's a perfectly reasonable choice for web development, just like a Chevy Caprice is a perfectly reasonable car for a taxi service (as evidenced by the thousands of them in NYC, still plodding along). You'd still rather ride in a Mercedes E430 taxi (long time European standard)... unless you had never experienced both, in which case you probably think the Caprice is just fine.
And if you knew Ruby, Python, Java, C#, Kotlin, or better yet F#, Clojure, or Elixir, you'd most likely enjoy using one of them rather than PHP.
There are three reasons to use PHP.
1. it works
2. it is well integrated with web servers
3. you can find some of the cheapest contract labor who know how to program in it (compared to other, less common/popular languages)
Bonus 4. you need to extend Wordpress by writing a plugin or theme (and Wordpress is the Caprice of CMSs...)
Re: Taking PHP Seriously (2016)
#85[deleted]
Re: Taking PHP Seriously (2016)
#86Earlier quoted context omitted.
This is strange to me because I’ve taken and succeeded at two positions now where I didn’t know the language going in.
I just wanted to clarify that I specifically called out how easy it is to hire for. A lot of developers are pretty quick when it comes to adapting to a new language and there are virtues that lean in favor of a language being easy to pickup: sharing a paradigm with popular language, sharing conventions with popular languages and good documentation. I have yet to work a day job in Rust, but I've worked in Java, C++ an…
Yeah, this is why I’ve concentrated on learning different kinds of languages in my free time, rather than learning the latest thing: if I know Python, Ruby is relatively easy to learn but Haskell is more difficult. So, it’s worth my time to learn Haskell rather than Ruby.
Re: Taking PHP Seriously (2016)
#87As a language i enjoy Python and Javascript a lot more than PHP. Especially the major PHP frameworks and libraries tend to be too complicated and Java-esque for my liking. There are some nice simpler alternatives, but they tend to get abandoned in favour of the larger projects.
But when looking at PHP in terms of deployment and making traditional SQL-based websites/API's it's unmatched. Just reading up on deploying Python code using uWSGI, or connecting to a SQL database gives me headaches, and the confusing package management and versioning system makes things even worse. Running Node feels unpredictable, with the server crashing because you forgot to catch an exception somewhere or having some weird state.
With PHP it's just: write the code, copy the files to a server and stuff (usually) just works. That's why i keep using it. Not that pretty, but it always gets the job done.
Re: Taking PHP Seriously (2016)
#88Earlier quoted context omitted.
Really depends on what the business is doing. Chewing through TBs of data every hour? Probably not a good idea to use Ruby. Doing a bunch of really heavy math? Probably not a good idea to choose PHP. Doing a SaaS service? C++ probably isn't a good choice. There are some really good general purpose languages that can fit most circumstances (Java, .Net languages, Go). However, I'd be careful to say that you could apply…
I hate to be "that guy" but I see no reason not to use PHP for all three of those things. PHP is faster than Ruby. [1] PHP from a local script does math just fine. It's the round trip of the request to a PHP server and back that you're associating with poor language performance. In a local scripting environment PHP7 is considerably faster than Python3. [2] PHP is an extremely popular language as the backend for SaaS,…
> PHP is faster than Ruby.
It's not helpful to be faster than the language that the parent implied wasn't fast enough.
I think the parent's point was that if the startup's raison d'etre involves "chew[ing] through TBs of data every hour", then choosing a language that can do that 10x faster than another might have a tremendous impact on cost and so the company's value. It might be the difference between successful or not.
More generally, "it depends".
Re: Taking PHP Seriously (2016)
#89The best language for a startup is one the founders know the best. Every other discussion will at best make a 1% difference.
The best language has an appropriate ecosystem as well - everybody hates PHP, but it's damn easy to plug in payments and .
Re: Taking PHP Seriously (2016)
#90The best language for a startup is one the founders know the best. Every other discussion will at best make a 1% difference.
I espoused this sort of rhetoric until I worked at a PHP shop. Every other discussion was about problems posed by the shortcomings of the language, crossed with mistakes made by past staff. It's so easy to make assumptions about "good actors" and "reasonable developers" that just fly out the window with a team that picks PHP and/or doesn't know much else.
I've worked at PHP shops - working on a PHP project for a consultancy right now - and there's 0 issues about 'shortcomings of the language'.
"past mistakes" are almost inevitable problems - I've been on both sides of this - creating things which likely caused someone else problems (learning to be better at tests and docs) - and inheriting problems created by someone see ( learning to demand better tests and docs from others when possible).
"past mistakes" have little to do with the language. Recently worked with a large Java codebase spanning back more than a decade. There's plenty of mistakes that have been made. And... there's plenty of 'language shortcomings' around Java too (go back to Java from 15 years ago, lots of shortcomings).
I was on a team that picked node for a project; the whole thing failed. Should I blame it on the language, or the people who made bad choices?
Perhaps the issue is mostly around people/teams that either aren't very good or more to the point don't have a structure in place to guide them and help them get better.