6 ms·
I used to feel the same way a lot of times, a shame it seems for being a PHP dev. Now, I don't care. I've been using it since 1999, and I use it to get stuff do
by leftnode 10y ago
I used to feel the same way a lot of times, a shame it seems for being a PHP dev. Now, I don't care. I've been using it since 1999, and I use it to get stuff done.
My customers and users of my applications don't care what it's written in.
But, you should definitely learn more languages as a programmer.
> And to anyone considering programming as a career, or trying to get into it... stay away from PHP.
This is the part I disagree with the most. The language is getting better and better with every release. It's incredibly fast, much safer to use (the Error exception type, scalar static type hints, all the garbage from the early 2000's has been removed), and easy to work with. The ecosystem (with the introduction of Composer) has _completely_ changed and reinvigorated the language. It's easily one of the best package managers out there. I definitely recommend giving PHP a look or a second change if you've written it off.
- emodendroket 10y agoIf you're doing it as a job, though, you probably end up having to work on a lot of legacy codebases with the old issues.
- 27182818284 10y agoThat, and I've noticed that the typical legacy PHP codebase is worse than the legacy codebase in other stacks.
- tluyben2 10y agoIt is far worse I would say. Legacy PHP code is some of the worst code I have seen in my life. Everyone with HTML/JS knowledge could also do PHP and they did. There are many production systems (banks, insurance etc included) running old style php with html mixed with php mixed with JS. And it runs fine, but if you need to fix something that broke or had to be changed...
- deleted 10y ago[deleted]
- collyw 10y agoI have seen some real crap in Python recently. Then I was asked to move a PHP app to a new server. A quick look at the code looked terrible - string concatenations for all the SQL. (Does PHP provide some way of making this safe, or should I warn management about potential SQL injection? I don't know a lot about PHP).
- emodendroket 10y agoI think PDO is the accepted way to do it but I'm not a PHP developer.
- 27182818284 10y agoPHP absolutely has right ways to do parameterized queries. Take a glance at http://www.phptherightway.com/ http://www.phptherightway.com/ to get started
- treehau5 10y agoUnfortunately, the issues aren't with "new" PHP, it's with the mountains of "old" PHP code that invariably finds its way into your project. Also, having had to maintain a Wordpress site the past few months, may God have mercy on all daily Wordpress devs. I truly admire your stalwartness now in putting up with that.
- tluyben2 10y agoThe problem is that clients really want WP a lot. Bigger and bigger companies currently and for most of their departmental sites. This is WP shoe-horned in a full site CMS function. The thing is, users seem to love it. I would wager that if you just rip out the guts of PHP and leave only the frontend (the /wp-admin part that is), but leave it 100% as it is and write a solid backend in Django/Rails, you have a winner. The problem is that when people attempt this, their own 'taste' comes in and it always ends up being a vastly different frontend which then users don't want as it's not 'the same as WP'. Before anyone says it; sure some users use WP for the themes and plugins; we use some of them but we are very careful using plugins. They have to be rocksolid for many years, actively supported and we have to have reviewed the code. Next to that they have to add something significant; installing a plugin for some social buttons is very much not worth the pain of updates / security breaches on a 100k+ (+ SLA) project. And so in the end we end up using 4-5 the same plugins for projects and the rest is either not needed or easy to implement anyway. So the hero implementing those guts in Django/Rails could also implement those plugins. I believe you would have something safe for the enterprise. Until then, they'll just use WP and trust admins/coders to fix the issues.
- mtberatwork 10y ago> I would wager that if you just rip out the guts of PHP and leave only the frontend (the /wp-admin part that is), but leave it 100% as it is and write a solid backend in Django/Rails, you have a winner. I would love for WP to exist as only an admin interface to a clean, backend data store. Unfortunately, the problem is the database schema that WP ships with and the way WP handles data. It's almost impossible to get data out of WP press without using its lackluster DB "abstraction" layer and running the fetched data through its many obscure filtering mechanisms. To top it off, WP smashes everything into a handful of tables and makes doing normal, straightforward relational looks up (as any sane schema would allow for) a complete nightmare. Alas, when you go the WP route, your data is very much dependent on WP (and by default PHP). Any organization that uses WP for an extended period of time and builds up a non-insignificant amount of data will run into this wall, guaranteed. If you truly value your data and your project is anything beyond a personal blog that you'll give up on in 6 months time, do yourself and your organization a favor and find an alternative solution. If you must use WP, use it as what it was originally intended for: a blog. It's not a framework to develop a complex application off of.
- ivyirwin 10y agoI understand that the negative pressure can have a long term effect. Personally that has never gotten to me and it's sad for the author that they have been slowly worn down over time to a breaking point. I totally agree with "But, you should definitely learn more languages as a programmer." In my current position I led a ground up build in Python/Django after 10 years of personally using PHP. I learned so much that I wanted to bring back to the PHP stack, only to find that the PHP community is already working on those things. It's really fun to see the parallels. I am a strong believer in coding fundamentals and try to preach language agnosticism to my team. Yes there is often a right tool for the job, but in many cases the major platforms will be able to achieve the problem at hand – at least for typical problems.
- jerf 10y agoIf you're a PHP dev, you really ought to add a complementary language, not one that, like Python, is really quite similar when it comes down to it in terms of performance, execution model, language features, etc. There's a lot of good options out there and there's more coming every year now. Go is a nice choice because it really nicely complements PHP, being good at some things that PHP is bad at, and PHP being good at some things Go is bad at. Rust might be a good choice with just a bit more web dev work on it. Erlang/Elixir, Clojure, something with a great concurrency story, an easier time getting to high performance, and some (good) static typing for when you're in the code where that's a good idea, that sort of thing. PHP->Python is not a bad thing necessarily, but it's not really "diversifying" very much.
- collyw 10y agoResume driven devlopment. As you say PHP and Django are similar in what you can use them for. I would choose either of the over Rust for a standard web app. Unless you have a specific need for concurrency, the PHP and Django are far more mature in the web app space.
- ebbv 10y agoI also disagree strongly with that piece of advice. Even though, as others have pointed out, if you become a PHP developer you're going to have to deal with nasty legacy code; there's nasty code written in Ruby, Java, Python, etc. too. It's just nasty in a different way. PHP is actually the language I do recommend people learn if they're interested in web development (obviously along with JavaScript), because PHP developers are in high demand. PHP developers can always find work, precisely because there is so much PHP out there.
- trjordan 10y agoThis is the point. The language is fine, the technical problems are solveable. The stigma remains. All other things being equal, choose a language where you're not going to have to fight this fight.