Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Taking PHP Seriously [pdf]

raw.github.com

Post reply on HN
Print view View original

111–120 of 155 posts

Re: Taking PHP Seriously [pdf]

#111

Post by Gigablah »

Sanddancer wrote: post #46
fsniper wrote: post #18

Earlier quoted context omitted.

It's PHP concatenation operator is ".". print $productid . 4;

You missed the point, and the problem. PHP tries way too hard to try to mangle input to kinda sorta work with the operators at hand. Were it a reasonable language, it would throw out a warning, or better yet, an error, to handle a fairly broken situation like this, rather than try to pick and choose the parts of the string it thinks is appropriate.

> a fairly broken situation

You missed the problem as well. Don't ask for trouble by creating broken situations.

Re: Taking PHP Seriously [pdf]

#112

Post by bencoder »

contingencies wrote: post #96
jtreminio wrote: post #90

Earlier quoted context omitted.

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 co…

Procedural testing isn't hard. All that dependency crap is only a result of your AbstractTestingFrameworkMethodFactoryClassMockMethodGenerator() and similarly useless abstractions, anyway. A simple module system can be implemented in a single function and referenced from test code as easily as: test_requires('module1','module2'); Purely procedural tests are as easy as: assert_equals(function_one('example_input'),'exp…

I think you've missed the point. If your procedure calls other procedures, how do you test its functionality individually? How do you know if the problem exists in the procedure itself or one of the procedures it calls. Without DI in some form you are stuck with your procedures being tightly coupled together.

Re: Taking PHP Seriously [pdf]

#113

Post by Joeri »

dribnet wrote: post #4

This was an interesting talk. My own interpretation was that PHP's strengths were claimed to be: 1) State => because endpoints have no persistent state 2) Concurrency => because there is no concurrency model 3) Transparency => (1) + (2) + fast reload = easy to understand These combined give the language nice programmer "ergonomics" (Keith's terminology). It also limits the collateral damage any particular change to t…

I think PHP's strength is that the default way of how sessions work makes you intuitively build shared-nothing architectures that parallellize easily and have session data that is hard to corrupt. Sessions are locked at the beginning of the request, and the changes are committed atomically at the end of the request. The next request by the same user is blocked until the session is unlocked. This means that any error causes a rollback to the last known valid session state, and that it is basically impossible to have concurrency bugs (though obviously a PHP server can handle more than one request at a time if they're coming from muliple user sessions). A PHP app that gets an error will typically recover just by pressing F5, whereas in other platforms often you have to log out to throw away corrupted session data. I had little appreciation for this myself until the PHP app I work on reached the point where it had both a large codebase and a large userbase.

Remember also that a large part of the reason why facebook won over its competitors (friendster and myspace) was technology. Both myspace and friendster had trouble scaling up their featureset at the same time as their userbase, whereas facebook pulled it off relatively well. It's hard to know without inside knowledge whether PHP had anything to do with that, but it obviously didn't prevent facebook from winning.

Re: Taking PHP Seriously [pdf]

#114

Post by deeepinit »

Joeri wrote: post #92
hyperpape wrote: post #52

Earlier quoted context omitted.

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.

Speaking as someone who works on a 2 million user enterprise app with standard PHP, i would have to counter that: 1) the footguns are easy to sidestep once you know them and are gradually getting removed, 2) standard php has traits and strict typing, but the typing is not for primitive types (which is what Hack adds) and 3) in nearly a decade i have had a single feature where i could have really used a faster php, wh…

I'm curious on how many servers does it run :)

Re: Taking PHP Seriously [pdf]

#115

Post by camus »

Joeri wrote: post #92
hyperpape wrote: post #52

Earlier quoted context omitted.

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.

Speaking as someone who works on a 2 million user enterprise app with standard PHP, i would have to counter that: 1) the footguns are easy to sidestep once you know them and are gradually getting removed, 2) standard php has traits and strict typing, but the typing is not for primitive types (which is what Hack adds) and 3) in nearly a decade i have had a single feature where i could have really used a faster php, wh…

PHP(.net) doesnt have strict typing ,but type hinting, which is not the same.

Re: Taking PHP Seriously [pdf]

#116

Post by sergiosgc »

jasonlotito wrote: post #37
jtreminio wrote: post #29

Earlier quoted context omitted.

That's because you're stuck writing crap code in crap libraries. Really, you judge PHP off of Wordpress and Joomla?

Ever notice how everyone who complains about PHP are usually complaining about WordPress, Joomla, or other such apps?

Because these apps exist. WordPress, for example, is unparalleled in other language domains. What is the WordPress of Ruby? And in python? Is it Django? Where's the plug-in directory for Django, equivalent to [1]?

I work with WP, I'm the first to recognize it's an old codebase with all defects this entails, but popularity has value. Value that PHP critics dismiss too lightly.

[1] http://wordpress.org/plugins/

Re: Taking PHP Seriously [pdf]

#117

Post by Joeri »

sil3ntmac wrote: post #108

> Facebook’s PHP Codebase > x * 105 files > y*107 LoC > 10 releases per week > Anecdotally, good engineers are astonishingly productive in PHP Erm... are you kidding me? LoC != productivity, not even close. And it goes downhill from there :( I really, really don't want to rail on PHP (people do that enough, it gets old, yada yada), but you're kinda asking for it here. The only useful point made is about state, althou…

That's a very unfavorable reading of that slide. Who are you to say they are wrong when they talk about their own anecdotal experience?

Speaking anecdotally, I got exposed to PHP before I did to Python. I tried Python after hearing how much more amazing than PHP it was. I understand why people say that now, because Python has a "flavor" that I suspect most programmers find more pleasing. I also learned another thing: I am not more productive in Python than PHP.

PHP, like JavaScript, is a language constructed out of good parts and bad parts. They both suffer from the same ailments. It is painfully easy to construct code examples of their horribleness, there are mountains of bad code floating around the internet, they lack essential facilities like strict typing, many facilities that they do provide should be carefully avoided, and the overall flavor of the language is just plain weird. However, PHP, like JavaScript, allows you to be remarkably productive.

JavaScript got out of the doghouse when Douglas Crockford wrote his book and converted the JS community to the jslint style of programming. JavaScript didn't change, but the perception and practice of it did. I think PHP needs a similar champion who is willing to say: PHP can be a good and proper language, provided you use it correctly, and btw here is a tool that tells you whether you're doing that in your code.

I am a PHP programmer, and to your high and mighty attitude I say: screw that. There's nothing wrong with being a PHP programmer.

Re: Taking PHP Seriously [pdf]

#118

Post by adamors »

kayoone wrote: post #84
dkhenry wrote: 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 no…

Both Youtube and Disqus (just to mention bigger names) started delegating heavier tasks to Go, instead of Python. So yes, this case can be made for most high level languages.

Re: Taking PHP Seriously [pdf]

#119

Post by adamors »

lmm wrote: post #103
ChikkaChiChi wrote: post #73

Can anyone please point me in the direction of an open source project on Github that can showcase to me the 'elegance' of all these other programming languages that have the scale and adoption of some of the more well-known PHP community pieces? I feel like so much of the bias towards PHP is either an unfair comparison (language to 'rails') or a bad taste left in the mouth because the person worked with a nasty domai…

> Can anyone please point me in the direction of an open source project on Github that can showcase to me the 'elegance' of all these other programming languages that have the scale and adoption of some of the more well-known PHP community pieces? Just look at MoinMoin's source and see how much more elegant it is than MediaWiki. > either an unfair comparison (language to 'rails') Why is that unfair? > a bad taste lef…

> Why is that unfair?

Because PHP isn't actually used like that. Most engineers use frameworks (like Symfony, Zend, Yii, Cake, Laravel etc.) or at least components of these frameworks if they work on something very complex. NIH is a thing of the past.

> If that's how PHP is used in practice then it's fair to complain about PHP.

If shitty developers use a language then it's fair to complain about said language? Really?

Re: Taking PHP Seriously [pdf]

#120

Post by adamors »

jrockway wrote: post #24
goshx wrote: post #12

Earlier quoted context omitted.

Just checking: do you have any experience with it? When was the last time you tried working with PHP in a team?

I've done more projects in PHP than I would care to admit. I ported the University of Chicago's "Uncommon Application" from Cold Fusion to PHP using an OO data access model, MVC, and explicit templates. (This was a long time ago before people realized that MVC was a bad idea.) I've also hacked up a bunch of open source projects (wordpress, joomla). No tests, so you never know what you've fucked up, and you spend more…

> If I were to summarize it with one anti-pattern, it's that PHP encourages people to mix unrelated parts of the program into one place, making testing, maintenance, and understanding nearly impossible.

Haha, you are actually the problem you complain about.

Half assed "developers" who try to build anything large scale with WP or Joomla, people who can't be bothered to keep up with the changes that happened in the past 5-10 years but still complain about how shitty everything is.

Post reply on HN