Hacker News Reader

I used PHP for five years professionally, I consider myself as well positioned as many to have an informed opinion about PHP weaknesses and strengths. My diagnostic is that PHP weaknesses are structural, and no amount of guidance can fix that. If facing the choice, one should not choose PHP over other solutions. (It happens also that I am working in Chinese tech sphere, where many startup choose PHP just because it is used by Facebook and Wikipedia, which is really sad.)

However, I appreciate very well the need for such a guide when you have no other choice. I did not read all of it, but it is certainly necessary to have strong coding conventions and a defined set of "must do/musn't do". I remember we had even built a code checker that was forbiding the use of many php functions and syntax, and had a set of wrappers around basic functionalities like string functions or date functions.

He doesn't defend PHP as a language.

He is sharing some useful guidelines to approach it more properly and help people that are still using it.

I, for one, am a fan.

> I used PHP for five years professionally, I consider myself as well positioned as many to have an informed opinion about PHP weaknesses and strengths.

Yeah, that doesn't mean anything. In fact, to be frank, when I read that, I fill in the underlying context:

"I used PHP for fives years professionally, and the code was horrible. Granted, it was code I wrote because PHP let me write code that way..."

or

"I used PHP for fives years professionally, almost a decade ago..."

> I remember we had even built a code checker that was forbiding the use of many php functions and syntax, and had a set of wrappers around basic functionalities like string functions or date functions.

Yeah, that didn't do much to change my mind.

Any reason for the personal attack (based on unfounded assumptions)?...

No personal attack. You used your experience to justify your position, which really means nothing. You then went on to describe practices that, if written accurately aren't in anyone's book of good things to do.

If you take it personally, thats your issue, not mine,

I’m not the OP.

> A good portion of why people like to mock PHP is due to the way people end up using the language rather than the language's ugly parts.

Are you really going to trot out that old lie?

Why not read this, instead? http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-de...

Because huge swathes of that blog post have already been debunked ad infinitum (here on HN, no less).

Well… Javascript does suck. No one in their right mind defends the language.

They do.

http://www.joelonsoftware.com/items/2006/08/01.html

http://skilldrick.co.uk/2010/09/why-javascript-is-awesome/

Javascript is just Scheme with a C-like syntax and a limited number of bad design decisions (like automatic semicolon insertion and the == operator). PHP is a never-ending fountain of bad design decisions, because its core devs continue to make new ones.

What bad design decisions have been made in PHP in the last 5 years?

Using '\' as a namespace seperator? Just off the top of my head, there are probably loads more.

What makes that explicitly bad?

I've actually gotten used to it (and I rallied against it heavily). It's really not so bad; it's even somewhat nice it has a file-system like connotation. PHP's design precluded using any existing operators.

Based on how long it took to introduce the ability to say foo()["bar"], I'm guessing it's not the language so much as it's a set of poorly designed parser rules.

Also, magically, I can't use empty(functionResult()); but I can say $result = functionResult(); empty($result);

> I'm guessing it's not the language so much as it's a set of poorly designed parser rules.

There are poorly designed parser rules but the namespace operator is not due to that. It's due to the fact that a single PHP file will be compiled to byte code without knowing what the symbols represent until runtime. The separate operator is needed because names are resolved before execution begins and before the symbols are known.

> Also, magically, I can't use empty(functionResult()); but I can say $result = functionResult(); empty($result);

Empty is identical to the not (!) operator except that empty() can operate on undefined variables, undefinted array keys, or undefined properties. empty(functionResult()) doesn't make any sense because functionResult() can never be an undefined variable. You just use !functionResult().

really? add: floating point everywhere, objects that act like hashes but not exactly, fucked up scoping rules including global by default, the braindead Dom API, a severiously limited standard library, and brain damage coersions to the list...

I'd leave the DOM API out of it, that's not really the languages fault.

Well, its the first one hat offered it, isnt it?

No, Javascript is not "just scheme" with a few bad design decisions. They have significant differences.

Scheme has:

  call-with-current-continuation http://people.csail.mit.edu/jaffer/r4rs_8.html#IDX509
  Tail Call Optimisation
  A numeric tower http://people.csail.mit.edu/jaffer/r4rs_8.html#SEC50
  A Code/Data equivalence and therefore macros
  Ports

Javascript has:

  Prototypal inheritance
  Every 'object' is mutable bag of string indexed properties

There's a pile of differences, even just at the semantic level before you get into the syntax or the equivalence semantics.

I understand that if you take a specific subset of javascript, you can write code as-though it has some scheme semantics (minus call/cc and TCO), but that's true to a similar extent of any language with lexical scope, closures and anonymous functions.

It is actually a very strong language with a few very well known warts (like every other language on the planet has). The problem is that people try to use it as if it were Ruby, PHP, Python, Java. One can do that, but just know that it is an exercise in futility. It will cause frustration and one will come to the conclusion that JavaScript sucks when in fact, it is just that most people don't really take the time to _understand_ JavaScript.

JavaScript could stand to be a bit less verbose (look into CoffeeScript for some relief if you value your sanity and time) in some areas and type coercion should just go away; but if you use strict mode and strict equality, a huge amount of pain is alleviated.

If one take the time to learn about constructor functions, the prototype chain, and own properties; they are 70% there. Most people can get by on just that.

Yes, how dare he talk about the problems with PHP in the comments on a site dedicated to talking about how to avoid problems with PHP. Seriously, WTF? Are people actually offended that discussion of PHP's defects take place in a conversation about PHP best practices?

I think it is because we (as a community) should be past the piling-on stage and on to the constructive discussion stage. Snark doesn't add to the discussion.

I don't intend to jump into the ring, but as an observer, I don't think we're at that point yet. Here's the progression of the current anti-PHP flare up:

  Jeff Atwood says PHP sucks
   |- Says we should make other languages fill in on what PHP does best
   |- Post goes on HN
      |- PHP apologists say "No! PHP is fine, I've made a career out of it!"
      |- 'Atwoodians' continue to reject PHP, ruby/python need to be more accessible
      |- PHP apologists make reasonable arguments for why PHP isn't as bad as everyone says, while admitting its probably worse than python/ruby

There remains a conspicuous lack of response from the 'Atwoodian' camp regarding what could be done to add PHP's quick-start strengths to other languages so that PHP developers can develop similarly to how they currently do, just with a less wonky and problematic base language.

By no means, as an outsider, do I perceive the PHP apologists as having redeemed PHP to the point that the discussion should be about 'how to fix PHP' rather than 'how to discourage its propagation' as was originally put fourth in a fairly reasonable way by Atwood.

I realize why saying 'PHP apologists' is problematic, but I'm mostly seeing responses that are in themselves critical of PHP, while espousing its widespread use, quick-start capabilities, and developer intertia--and not espousing why the fundamentals of the language are better of the equals of ruby/python.

While I can't speak for others in the "Atwoodian camp," I for one think Atwood's article was that response, to a large degree: it pretty much said that his next big project is trying to bring those strengths to a platform built on another language.

Having said that, it seems to me that there's certainly a fair amount of work being done to make deploying apps in other languages pretty simple. With mod_passenger, for instance, setting up a Rails app under Apache isn't notably more difficult than setting up any other Apache virtual host. Deploying Python web applications isn't quite as simple yet (at least in my experience), but it's nothing that should be beyond the ken of someone who's figured out how to write a Python web application in the first place. And that, in turn, isn't really beyond the ken of anyone who's learned how to write reasonably good PHP MVC code.

Offended, no. Weary of rehashing the same arguments against using PHP at all, when that is clearly not the point of the discussion...absolutely.