Live data from Hacker News

Taking PHP Seriously [pdf]

raw.github.com

81–90 of 155 posts

Re: Taking PHP Seriously [pdf]

#81
post #67

Earlier quoted context omitted.

The linked article explicitly states that the author has found (albeit anecdotally) that good engineers are very very productive in PHP. I've found this myself as long as you don't go writing code that sits in PHP's "hmm, what'll happen if I do this..." area.

AFAICT, "good engineers are productive in X" doesn't imply that they wouldn't be yet more productive in Y.

Also the Facebook mantra being "move fast and break things" (that anyone working with their API appreciate), it's easy to have a high productivity in most languages.

Re: Taking PHP Seriously [pdf]

#82
post #3

obligatory X is better than php flames on the way.. php just works.. end of story

$productid = "0x4zz5"; print $productid + 4; If printing "8" is your idea of a working interpretation of that code, then PHP is the language for you. If not, then PHP doesn't work. End of story.

Why does productid have weird number like that? Normal PI0x4zz5 instead of 0x4zz5 or just numeric figure

Re: Taking PHP Seriously [pdf]

#83
post #3

obligatory X is better than php flames on the way.. php just works.. end of story

$productid = "0x4zz5"; print $productid + 4; If printing "8" is your idea of a working interpretation of that code, then PHP is the language for you. If not, then PHP doesn't work. End of story.

Any programmer in almost any language who mixes types like that without understanding the implicit type conversion semantics is asking for trouble.

Implicit type conversion is evil, and I don't see how PHP's sin of favouring string -> number over number -> string is any worse than, say:

    // Javascript
    console.log(+(+!![]+(+[]+[]))); // outputs the number 10
Or:

    // C, Java

    float celsius, fahrenheit1, fahrenheit2;
    celsius = 100;

    fahrenheit1 = celsius * 9 / 5 + 32;
    fahrenheit2 = 9 / 5 * celsius + 32;

    assert(fahrenheit1 == 212); // OK
    assert(fahrenheit2 == 212); // Oops!  It's 132.  What happened?

Re: Taking PHP Seriously [pdf]

#84
post #44

At this point we almost need to stop saying facebook programs in PHP. I know this was defending PHP, but look at what is happening. Facebook ( big engineering firm, lots of developers and resources ) could not get php to work for them short of rewriting the core (HPHP ) and then adding on features to the language that most other languages have determined are useful enough to be baked into the language. Here is my TL;…

Yes and no.

As a matter of fact Facebook would probably have run into the same problems if they had used Ruby or Python. These problems are problems of massive scale most of us will never face. Twitter had problems running on Ruby/Rails and i bet theres a case to be made for Python too. All this says is that at the scale level of facebook you will encounter the limits of dynamic typing scripting languages, but its not a problem with PHP per se and also not a problem that should hold anyone back from choosing php/ruby/python because its premature optimization.

Re: Taking PHP Seriously [pdf]

#85

Earlier quoted context omitted.

could not get php to work for them short of rewriting the core (HPHP ) I've heard this argument before, but it's important to realize that Facebook was able to use standard PHP up until the point when they had roughly 500 million users. Unless your site has a half billion users you can't compare your use case to Facebook's.

They're making three sorts of changes: 1) removing/restricting the footguns in the language 2) adding interesting features taken from other languages (typing, traits, etc). 3) creating a new VM with better performance. As far as I can tell, only 3 is obviously something that only affects whether you can use the language once you have a certain number of users. The first two are really about changing the language.

they most probably would have made similar changes if they had used ruby or python. They have very specific problems brought on by massive scale which will expose the flaws in any scripting language.

Re: Taking PHP Seriously [pdf]

#86

Most of the criticism of php seems to contrast it with a language plus a framework. If you really want to compare, compare php with ruby or python, not Django or RoR. As for php encouraging shitty programming, a good bit of that is that so many more people program in php because its easier to get started with. This does not mean that just because php attracts shitty programmers that it doesn't have more or many aweso…

Methinks the argument that PHP encourages shitty programming has been effectively countered by the amount of crap legacy Ruby code that has appeared several years since Rails became "hip".

It should be quite obvious to anyone by now that when it comes to shitty programming, language is negligible factor once a language has hit the mainstream.

But I'm pretty sure 5 to 10 years from now someone manages to argue that Ruby is crap, Rails is to blame for encouraging a generation of developers to write bloated controllers full of spaghetti code, and that this attracts shitty programmers incapable of understanding software architecture.

Re: Taking PHP Seriously [pdf]

#87

Most of the criticism of php seems to contrast it with a language plus a framework. If you really want to compare, compare php with ruby or python, not Django or RoR. As for php encouraging shitty programming, a good bit of that is that so many more people program in php because its easier to get started with. This does not mean that just because php attracts shitty programmers that it doesn't have more or many aweso…

[deleted]

Re: Taking PHP Seriously [pdf]

#88
post #63

Earlier quoted context omitted.

Perhaps I'm missing something, what about static methods prevents you from having a mock AuthorizeNet class implementing the same interface but with a submit() method that just returns fake data? Perhaps there is something specific to the testing framework you use that makes this clunky? As far as static properties go, if you're mucking with those you're back into the world of storing state, which OO is more suitable…

I am completely against create actual files to make mocks. I use PHPUnit, the de facto standard for testing php code. To create a proper mock in it, you use getMockBuilder()

Why can't you use getMockBuilder() for static methods? (I don't know PHPUnit so maybe it's a stupid question.)

Re: Taking PHP Seriously [pdf]

#89
post #3

obligatory X is better than php flames on the way.. php just works.. end of story

$productid = "0x4zz5"; print $productid + 4; If printing "8" is your idea of a working interpretation of that code, then PHP is the language for you. If not, then PHP doesn't work. End of story.

How is that relevant to anything? What kind of projects do you work on where this is a problem?

Re: Taking PHP Seriously [pdf]

#90
post #88

Earlier quoted context omitted.

I am completely against create actual files to make mocks. I use PHPUnit, the de facto standard for testing php code. To create a proper mock in it, you use getMockBuilder()

Why can't you use getMockBuilder() for static methods? (I don't know PHPUnit so maybe it's a stupid question.)

These tools only work when:

1) You've implemented dependency injection, or

2) You're using a container

For example, in PHP you can't mock something like "$foo = new Bar();". The code is right there, it's saying exactly what it wants, you can't return a fake class (unless you do some ugly magic).

However, you can pass in an object that is_a Bar, either injecting it via DI or storing it and then retrieving it from a container.

With code like Foo::Bar() - that's it. You're tied to the Foo class, Bar() method and you can't change a thing about this.

Post reply on HN