Hacker News Reader

Comment by gbog | Hacker News Reader

PHP with these guidelines looks like JAVA to me, but without the relatively sane foundations.

It is fun how much a very old moralist sentence by Confucius applies well to PHP. He said 其本亂而末治者否矣 which can be translated, in software language development context, as "Build a nice, reliable language on shitty definition? Bullshit!".

(The word-by-word translation is "your - root - messy - and/but - leaves/result - governed/orderly - have ? not - hey!")

This sentence also resonates with the odd Turkish encoding PHPbug recently reported here: if you have so many wrong architecture decisions in the core of your product, no amount of patching and "under the rub" filling will save you.

Edit: added word-by-word translation + typo fixes.

View on HN

This illustrates very common problem with people trying to criticize PHP.

First you demand some "foundations". But if you look on virtually all existing popular languages, none of them were designed exactly in the form they are now. Java had tons of changes and additions, Python had object model change and now has new version that changed so much that it's not even backwards compatible, etc. etc. Does it mean they lacked "sane foundations"? No, it means requirements changed, so did they. PHP changes too. You want formal definition of PHP? But what would be the benefit of it? Who would benefit from it existence? Without answering these questions it is hard to expect anybody would create it.

Then you proceed to focus on some obscure bug that 99.9999% people couldn't care less about, with implication that since this bug is not fixed whole language is crap. I don't even know how to address this - do you seriously expect this be taken as an argument?

That bug is not a big deal by itself, but the circumstances surrounding it are a symptom of severe problems with how PHP is developed.

I don't see any "severe problems with how PHP is developed" that have any relation to this obscure issue, only importance of which is in its use for bashing PHP.

The ones I see:

1. Ad hoc language design process (if you can call it that at all) resulted in a serious lack of forethought in the language's case sensitivity rules. Somehow they ended up with about half of the language being case sensitive and half being case insensitive. Somehow they ended up not considering the implications of "case insensitive" with regards to internationalization, and thus ended up with utterly bizarre rules where code works or doesn't work depending on the locale it's run in.

2. Extreme emphasis on backwards compatibility means an unwillingness to fix the bug by e.g. making the language fully case sensitive, or regularizing the rules for case-insensitive comparisons among language identifiers to be locale-independent. This could be phased in over a long period of time with progressive deprecation to ensure that anyone relying on the old behavior has years of notice to fix it.

3. Somehow, the broken case insensitivity of these identifiers also breaks case identical lookups for certain names. Despite the bug existing and being discussed for ten years, this still doesn't work. No matter how bizarre your case-insensitive comparison rules are, there is absolutely no reason whatsoever that looking up a class using the exact same byte-for-byte name should fail. That this hasn't been fixed means that either the PHP team doesn't care, has no idea how to fix this, or the code base is too broken and crufty to make a fix practical. None of these alternatives says anything good.

The issue itself is not that important (unless you're Turkish, or running on Turkish servers, or somehow end up running in a Turkish locale), but the fact that it exists and has not been fixed in a decade means something is seriously wrong.

1. As opposed to what? Government-appointed committee with 20 volumes of bylaws? Open source design processes are ad-hoc in 99% of the cases, and from what I saw in business so are many of the successful ones in business too.

>> Somehow they ended up with about half of the language being case sensitive and half being case insensitive.

Why you think it's because of the "lack of forethought"? Case-insensitive methods/classes were decided to be so for a reason (since it made easier to write bigger projects in PHP). You may not like this decision, but it doesn't mean everything you disagree with is because nobody thought about it.

>> Somehow they ended up not considering the implications of "case insensitive" with regards to internationalization, and thus ended up with utterly bizarre rules where code works or doesn't work depending on the locale it's run in.

Again, the only reason why that bizzare situation with Turkish locale exists is because it wasn't noticed. There's no deep and mysterious reason rooting in flawed PHP design why it can't be fixed - as far as I can see, the fix is not hard either, it just that nobody got to fixing it.

2. Changing language implementation with potential of breaking of 99% of existing code is not a "bugfix". If you don't understand this, maybe it's too early for you to lecture people on how to design languages. It can be done, but there's no reason to - it would lead to massive breakage with no upside in any functionality.

3. "The issue itself is not that important" - BINGO! You said it. If the issue is not that important, why you're wasting time dwelling on it and make it sound as if this is the most important thing ever? You wrote a long post supposedly about deep flaws in PHP design and process - but the only thing you actually wrote about is an obscure bug that you yourself admit is not important! Maybe it's time to discuss something that is important then?

That quip would also be an argument against error-correcting codes. Whatever I think of PHP I'm not gonna look to Confucius for engineering advice. (Now Laozi on the other hand... :)

As far as arguments about ECC, I always enjoyed the parody of a saying attributed to JWZ: 'Someone has a problem and they think, I know, I'll use error-correcting codes! Now they either have 0 or 2 problems.'

Heh, I hadn't heard that one.

We get it, man. PHP sucks, you're cool/smarter/better because you use something else, and you need to remind us all about it by jumping in every time the letters P-H-P are seen in sequence to let us all know how it sucks by retreading the same old lines used by the last fifty guys who said the same thing but to your credit you really tried to be clever about it.

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. This guide is a great step toward pointing people in the right direction with the language. PHP has come a very long way and continues to improve. A big chunk of the battle is having decent guides to replace all the crap that's out there showing new PHP devs the wrong way. So why not talk about the merits of the guide rather than taking an easy opportunity to shit on PHP. It's really gotten old.

Hey, remember when JavaScript was like the worst language ever and everyone felt the need to remind everyone about that constantly? I do. And now all of them are writing blogs about how awesome node.js is.

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.

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..."

"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.

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.

> 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).

Reply on news.ycombinator.com