Live data from Hacker News

Taking PHP Seriously

slack.engineering

521–530 of 673 posts

Re: Taking PHP Seriously

#521
post #402

Write an API for my client app which returns user's data as JSON (or render HTML page for profile); You: { mysql_connect("host", "pass"); mysql_select_db("users"); $uid = $_GET[ "uid" ]; $res = mysql_query( "select * from users where uid = $uid" ); $ar = mysql_fetch_assoc( $res ); echo "name: " . $ar["name"] . ","; echo "location: " . $ar["location"]; ?> } Just call it http://domain.com/api.php?uid=USER_ID ( Yeah I k…

The way you write code I wouldn't trust you with any language really. You give 6 lines of code and it has display of all the worst practices that I haven't seen since I read a 13year olds tutorial on the language back in 2003.

Hi, can you list all the worst practices you see in this code? Just curious of the full list

Re: Taking PHP Seriously

#522

Earlier quoted context omitted.

> It was consistent with the thing it inherited most of it's syntax from so that makes it inconsistent? It is also internally inconsistent in so many ways. Half the array functions take arrays as the first arg, the other half the last. explode and implode have different argument order requirements (one is strict, the other works either way). Functions have a grab-bag of errors from returning null to false to 0 to str…

C++ is a C-like language but C++ muddies up the difference between some operators due to operator overloading. This is an inconsistency. Do you support that? No one will ever be able to convince me that " >" make sense to be read and write.

It doesn't matter, we're talking about php not C++. But yeah, ">" are at fairly internally consistent within C++ and don't generally confuse programmers or cause significant bugs in my experience, so I don't find them problematic. They did seem a bit weird at first, but they didn't cause significant problems.

Perhaps they do for you, and I accept your complaint about those operators as valid actually, but it's on a whole different level of badness than php, and again, we're talking about php. Just because "other languages suck" doesn't mean php doesn't, so that's not a valid argument against anything I said.

Re: Taking PHP Seriously

#523

Earlier quoted context omitted.

> What framework was that `big php app` using? PHP is a framework. True it's not a particularly nice one, and some people build even more layers on top, but it comes with all manner of HTTP/url/DB/etc. stuff out of the box. It's also a templating language (that's what the "<?php" tags are for); although, again, not particularly great, and some people layer more abstractions on top.

In the sense of comparing PHP and Rails, then no PHP is not a framework. Codeignitor, Laraval, Cake, Yii; those are PHP frameworks and fair comparisons to Rails. I can (and have) just grabbed Rack and rolled most everything myself in Ruby and it has way less overhead and is much more performant than Rails. Ruby also has it's own templating language; ERB is part of Ruby core. So comparing PHP to Rails is a bit apples…

it's a business decision comparison, not a technical categorical comparison. you need something to receive http request and return http responses, and you're comparing different popular (because hiring, training, and available community / support resources) ways to do that. they might be apples and oranges but at that level you're concerned with comparing fruits.

Re: Taking PHP Seriously

#524

Earlier quoted context omitted.

Performance? You need to update your act. PHP7 is 3x faster than python and now faster than Java 8 . The only people that can call php slow are masochistic c++ web hacks. https://blog.famzah.net/2016/02/09/cpp-vs-python-vs-perl-vs-...

Funny that people complain about js performance. In this benchmark it was 3 times as fast as php7 and about 7 times as fast as java 8. Have not checked the details of the benchmark yet.

It's worth noting that it's compiled JavaScript vs. interpreted PHP. With something like HHVM the PHP version would likely be a lot faster.

Re: Taking PHP Seriously

#525

Earlier quoted context omitted.

Disclaimer I worked on a large php app server that ran on about 50 servers and I miss it. The documentation is really good. A model for programming language documentation. Process per request is really simple to understand and scale. Your servers almost never crash completely, you don't get threads silently dying or run out of memory or thrash the CPU doing garbage collection. It runs like a tank. It will, for better…

I stopped taking this seriously after "the documentation is really good". Not sure whether this is your real opinion or you are just making fun of people who say that.

We can't argue objectively about an opinion but take a look at this typical page of the php.net documentation:

http://php.net/manual/en/function.usort.php

It has everything I need to know about the function clearly laid out. The behaviour of sort when elements are the same. A list at the side of related functions that I may want to look at instead.

I also like documentation that includes user contributions as these often add useful caveats and usage examples that don't fit well in the general documentation.

Re: Taking PHP Seriously

#526
post #462
post #410

Earlier quoted context omitted.

> It did one thing and did it better than anything else of the same era I would argue that it still does. It's not a great language, but to just get something working I still can't think of anything better that doesn't require lots of planning or infrastructure

Getting up and running with Python + Flask is trivially easy. If you think it's not then there's something else going on you're not addressing...

Trivial for those who read HN perhaps.

Re: Taking PHP Seriously

#527
post #440
post #331

Earlier quoted context omitted.

Can you set up Python to have the same pattern as PHP? I've always had to proxy the web server to the Python process running HTTP.

Python via fastcgi, wscgi, etc, is the same pattern. Or mod_python inside Apache.

[deleted]

Re: Taking PHP Seriously

#528

Earlier quoted context omitted.

Love this comment. I'm a PHP dev. I do care about my code though. I think you can write niceish code, even with a shitty language.

PHP always reminds me of the Dijkstra quote: "It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration."

I never quite get these kind of comments.

Scores of developers that were raised on BASIC assert that knowledge of BASIC gives you brain damage. Presumably, they do not consider themselves to be brain-damaged. Similar things happen with, say, products of public schooling.

Which isn't to advance an, "I was spanked and I turned out fine..." kind of argument. Even if that's true, we can establish higher floors than "fine." It's the self-defeating hysterics around the presentation that make it come off the wrong way to me.

Re: Taking PHP Seriously

#529
post #406

Earlier quoted context omitted.

It is easy if you are just willing to spend more money on servers. Often it's worth it.

it's the "good problem". and the good problem can always be solved, though lack of reliability can seriously hurt your growth. but that doesn't mean that it's as easy as people make it out to be. i wrote and ran a big php app (Zynga's Mafia Wars). this is just about the app server (apache + php side), single-master MySQL will give you far greater problems at that scale. everyone is tearing away adding features, and t…

I think I sat next to you at zynga back in 2008 and remember your php struggles vividly.

Re: Taking PHP Seriously

#530
post #433

Earlier quoted context omitted.

> Only engineers care about programming languages. Seriously. That's it. No one else cares about them. So what? Who else could care for something apart from those professionals using it? Maintenance is the biggest part of software development. A wrong technological choice can turn my nice job into my worst nightmare. Why shouldn't I care?

> So what? I think the intention is: While they are important to us, languages are frequently distorted to the point that we believe that company success as a whole is dependent on it. Companies like Facebook flatly contradict that. I agree with you in spirit: Facebook would obviously prefer not PHP. But if the choice is: Learn something other than PHP or use language I know to test some idea, I think the latter is a…

Runaway successes like FB are outliers. Failed businesses OTOH are quite common and usually have a number of causes where bad technology choices can be at least a factor.

You call it poor management in retrospect, but it's succeeding in spite of the tools when you're still doing ok. There's a lot of companies that exist in between failure and "Facebook" who don't have hockey stick growth curves who also can't afford needlessly higher technology costs, whether that's in infrastructure or staffing or opportunity costs in getting features to market. If PHP does't incur a higher cost personally, go for it, but it might be a strategic disadvantage later if you don't hit it big.

Post reply on HN