PHP a "fractal of bad design"? Hardly

Devshed User Jacques' signature has been recently changed to:

 

PHP is a fractal of bad design. Use Ruby or Python.

As I've seen this article a number of times, I'd like to go through it to see what everyone has to say on the subject.  Warning:  This is just stupidly, ludicrously long.  it takes an existing 5-page article and tears it apart nearly sentence-by-sentence.

 

First, let me say that PHP isn't perfect.  There's a lot of weirdness to it, a lot of examples of a language that grew organically by a large multinational team instead of being designed by a small committee of English-speaking developers.  But that doesn't mean it's bad design, just that there's quirks, like any well used system. 

 

Now, onto the article itself.  We're first presented with his toolbox analogy.  This ridiculous piece of prose seems to be insinuating that the basic control structures of PHP are somehow non-standard and don't work like every other language.  A hammer with a peen on both ends?  A screwdriver which only works with specialty screws?  How is this an analogy for the most popular web language in the world?  He goes on to say that the builders who use these tools make things that don't work and fall down at the slighest provocation.  Now, having read this before, I know that he goes into defense mode over this statement later, but I'll go ahead and attack it now:  Show me the faults in facebook.  Show me where wikipedia falls down when you touch it.  Find the design flaws in vbulletin, wordpress, or any of the other toolsets that would be at all analogous to a house "where every room is a pentagon and the roof is upside-down. And you knock on the front door and it just collapses inwards."

 

Stance

 

After his analogy, we get his stances.  These are almost all wrong, and illustrate his basic misunderstanding of languages in general.  He believes languages shoudld be:

 

Predictable - The author states that it's the language's responsibility to be understood by everyone who uses it, rather than the builder's responsibility to understand their tools.  He doesn't understand why PHP does something, so instead of investigating and learning more, he declares PHP "broken" and "badly designed."  This is a recurring theme in the article.  Much of his problems with PHP stem from him not understanding symbol tables or loosely typed languages.  Just look at his list of "surprises":  mysql_real_escape_string?  OH MY GOD!  SHOCKING!  What the hell is he talking about?  And E_ALL?  How is a constant name (which resolves to -1 anyway) a "surprise"?  The list of error-level constants is in the manual.  they all begin with E_ and then give what they describe.  E_ALL is all.  E_STRICT is strict.  E_WARNING is warings.  This is surprising?  This guy should stay away from haunted houses.

 

Consistent - Apparently things that look the same should work the same in a programming language?  And if you know one part you should be able to understand other parts?  This appears to be a dig at PHP's ecclectic naming conventions, and I will certainly give him that.  htmlentities should have underscores like its counterpart, html_entity_decode.  Of course, the counterpart of every function is in that function's manual page, but "the manual is right there and it's free and it's integrated into the free IDEs" still isn't an excuse.  The language needs to be cleaned up from a naming perspective.  He gets one point.

 

Concise - He makes statements about "boilerplate" a number of times, but never defines the term or tells us what he's talking about.  PHP is very concise.  It includes time-saving functions like usort(), file_get_contents(), and other functions which in C++ would take pages of code.  Of course, it also requires error checking, which seems to be what he's complaining about.  He lists error-checking as boilerplate.  I don't know how Python handles it, but generally as a programmer I'd like to know if a file operation failed.  His point here seems to be that low-level functions return false instead of throwing an exception, which is honestly a holdover from when PHP was young and didn't have exceptions.  However, which is more boilerplate: if ( !( $file = fopen('file.txt', 'w') ) ) or a try-catch block? 

 

Reliable - This, again, is him assuming that it's the language's responsibility to be understood, rather than his responsibility to understand it.  He goes into what he considers "gotcha" events later in the article, but (spoiler alert) they all stem from his fundamental misunderstanding of the language.  You can tell because his two examples perfectly illustrate his misunderstanding.  The == operator is listed as "flaky."  The == operator is the core of loosely typed languages, and is immensely powerful.  He thinks it's flaky because he can't wrap his brain around loose comparisons.  His second example is a by-ref loop, something which exists in all programming languages.  The only "gotcha" here is that his understanding of the way variables work in this language is simply wrong.

 

Debuggable - Now this I'll give him.  PHP's error handling is atrocious.  I mean, look at the errors some of these new users are getting on PHPFreaks.  Who can solve any problem when given just the error type, line number, function name, data type, prose description of the error, and potential fix?  That's ridiculous!  [/sarcasm]  Maybe Python's error handling is much more robust than I remember, but PHP's has thus far been fine for me.  Better than the error handling of things like Oracle, with 'cannot bind' being the only error I got yesterday.  His examples require a stack trace, which I guess could be handy some of the time, but honestly I've rarely used the stack traces we build into our error-handling at work (which is easily overridden in the PHP core with a set_error_handler call)

 

Arguments

 

Now, our author goes into a list of arguments he automatically discards.  Luckily, my argument of "you don't understand PHP and it's not PHP's job to get into your brain and force you to understand things you choose not to" isn't on the list.  He does say that it's not his responsibility to "memorize a thousand strange exceptions."  I agree with him on that, strpos should be renamed.  However, it is his responsibility to come to an understanding of how programming languages work, and he has failed to do so.  He also uses a wonderful straw man with "you should just use C if PHP handles 5% of its operations the way C does."  Just because fopen returns false in C and in PHP doesn't mean PHP is a net loss.  Finally, his argument of "the largest and most popular websites in the world, designed and written by the smartest programmers in the world, don't prove anything" is laughable.  The conscious choices of almost every single web engineering team worth a damn do, in fact, count as proof that the tool they've chosen is worthwhile.  (He also says not to argue with him at all, because he's just stomping his little feet and nothing will change his mind.  I'm writing this for the PHPFreaks community, not this guy who can't figure out how PHP works.)

 

 

Philosophy

 

PHP was designed to be easy to understand, because at the time the thought of full-featured web applications was silly.  An item's source doesn't discredit what it's become.  What if someone told you "America was founded to be a colony (and, reading between the lines, not a country); it has not well escaped its roots.  This is why I believe nobody should take America seriously as a country."  Stupid, right?  Good, glad we agree.

 

PHP is built to keep chugging along at all costs.

MY GOD!  HOW LUDICROUS!  PHP is a web language with very little ability to recover from a crash the way you would in a desktop environment.  It will keep doing its best and instead of a blank screen (or a blue one) maybe a bad programmer will get her site's navigation bar with some errors underneath it.  But she WILL get something.  The fact that PHP doesn't crash and burn as easily as the other languages doesn't have me crying myself to sleep at night.

 

There?s no clear design philosophy.

Yes, we know.  He still has one point.

 

PHP takes vast amounts of inspiration from other languages, yet still manages to be incomprehensible to anyone who knows those languages. (int) looks like C, but int doesn?t exist. Namespaces use \. The new array syntax results in [key => value], unique among every language with hash literals.

So wait...you're telling me...different languages can build on each other, but an expert in one isn't automatically an expert in the other?  Alert NASA, we have a breakthrough in human understanding.  Languages are different.  That's the point of making new languages.  Sorry if Perl's regex format is confusing to a C guru.  Perhaps he should learn Perl before complaining that the syntax of a language he doesn't know is confusing.

 

Weak typing (i.e., silent automatic conversion between strings/numbers/et al) is so complex that whatever minor programmer effort is saved is by no means worth it.

This is the closest he comes to outright saying "I don't understand it and therefore it's wrong."  If you want to understand how weak typing conversions work, you could look in the manual for the chart, or you could read my article on it.

 

Little new functionality is implemented as new syntax;

From the man who complained about the syntax of arrays, namespaces, and type conversions literally 2 sentences prior.

 

Code example: fopen

 

First of all, let me start by saying that when he said the line he discovered was "somewhere in the manual," it was deep into the manual entry for complex system-level error-handling functions and was specifically designed to suppress errors in a weird way so that you could see how error-screaming works.  The fact that he pulled this frankly BS example out of a manual entry on weird and complex error handling shows just how hard he was reaching to make a point, but since his misunderstanding of PHP is well illustrated here I'll continue.

 

(Docs don?t say what ?won?t work? means; returns null, throws exception?) [...] If allow_url_fopen is disabled in php.ini, this still won?t work. (How? No idea.)

Except the docs DO say what happens when the function fopen fails: it returns false.  It's in a nice blue box labeled "returns."  Can't miss it.

 

Because of the @, the warning about the non-existent file won?t be printed.

Line-level error suppression is a powerful feature, I'm glad to use a language which supports it.

 

But it will be printed if scream.enabled is set in php.ini.

System-level forcing of all errors is another powerful feature, I'm glad I don't have to go find ever @ sign in my code when I'm debugging something weird.

 

If it is printed, exactly where it goes depends on display_errors

I'm beginning to think he's never used a programming language at all.  Is it just me, or should every web language have server-level error reporting configuration?  What does Python do?  Just spit all errors to the screen no matter what?  If you want to log to a file, you have to do that by hand for every error?  That sounds awful.  Or he's full of it.

 

Back to individual complaints

 

The language is full of global and implicit state

Server-level configurations are pretty handy and remove a lot of boilerplate, don't you think?  Good thing removing boilerplate was one of his biggest criteria back at the beginning.

 

register_tick_function sets a global function to run every tick?what?!

Shame the manual on that function isn't 4 pages with explanations and usage examples or he might learn something.

 

There is no threading support whatsoever.

It's purely a web language, and nothing else.  Websites don't need threads, because if they take longer than a second to run they've failed.  Again, fundamental lack of understanding.

 

json_decode returns null for invalid input, even though null is also a perfectly valid object for JSON to decode to?this function is completely unreliable unless you also call json_last_error every time you use it.

He gets another point here, json_decode really should throw an exception. Though to be fair, if I ever get a json object which resolves to null, I'm going to handle it as an error regardless. 

 

array_search, strpos, and similar functions return 0 if they find the needle at position zero, but false if they don?t find it at all.

Once again, if this person would take 10 minutes to attempt to understand loosely typed languages, this would all make sense.  These functions return the index of the item found.  if no item is found, they return false.  That sounds really powerful, and I'm not sure why it's even a complaint.  Luckily for the reader, he goes on to explain his ignorance:

 

In C, functions like strpos return -1 if the item isn?t found. If you don?t check for that case and try to use that as an index, you?ll hit junk memory and your program will blow up. [...] In, say, Python, the equivalent .index methods will raise an exception if the item isn?t found. If you don?t check for that case, your program will blow up.

C and Python crash fatally, potentially destroying the memory space of other programs.  Got it.

 

In PHP, these functions return false. If you use FALSE as an index, or do much of anything with it except compare with ===, PHP will silently convert it to 0 for you. Your program will not blow up; it will, instead, do the wrong thing with no warning, unless you remember to include the right boilerplate around every place you use strpos and certain other functions.

So basically, if you don't include the right boilerplate around other languages, they fatally crash and destroy their state, potentially also destroying neighboring programs in memory.  However, if you do the same erroneous code in PHP, it continues to work with slightly unexpected results.  Tell me again why "keeps working" is a problem?  Plus, for what might be the 10th time, he just plain doesn't understand loosely typed languages.  Yes, false == zero.  That's actually an incredibly powerful feature of the language.  The boilerplate he's comparing about isn't exactly onerous either.  Look, here it is: "!== false".  Oh man, look out.  That nearly broke my fingers I typed for so long.

 

So I have to fit this in here, because it bears repeating: PHP is a community of amateurs.

And they're all stupid heads and not invited to my birthday party.  I love how he "had to fit in" an ad hominem attack against an entire community of developers.  He even states further up in the article that facebook and wikipedia run PHP, and still manages to claim that those people are amateurs.

 

"Back to the facts" (and by "facts" we mean "opinions borne of fundamental misunderstandings")

 

== is useless [...] Comparison isn?t much better.

Blah blah doesn't understand loosely typed blah.

 

PHP does not overload +

Quite literally damned if you do, damned if you don't.  He simultaneously complains about PHP doing something, then not doing that same thing.

 

There is no way to declare a variable.

I really should make a hotkey for "he doesn't understand loosely typed languages."

 

Global variables need a global declaration before they can be used. This is a natural consequence of the above, so it would be perfectly reasonable, except that globals can?t even be read without an explicit declaration?PHP will quietly create a local with the same name, instead. I?m not aware of another language with similar scoping issues.

PHP has strict function scope, and globals aren't automatically imported for reading and writing.  His complaint seems to be that all globals aren't read-only inside all functions, which I personally think is confusing if it's done that way.  Why should I be able to read $foo but not write to it?  Doesn't that seem more confusing?

 

There are no references. What PHP calls references are really aliases; there?s nothing that?s a step back, like Perl?s references, and there?s no pass-by-object identity like in Python.

His second fundamental misunderstanding finally rears its head here:  Symbol tables.  PHP doesn't use variables like other languages, it uses symbol tables.  PHP does in fact have references, and pass-by-identity (objects are always passed by reference). 

 

Once a variable is made a reference (which can happen anywhere), it?s stuck as a reference. There?s no obvious way to detect this and un-referencing requires nuking the variable entirely.

I'm willing to grant him another point here (which makes three).  If you, for instance, make $a a reference to the third item in array $b, then any modifications to $a modify the inner structure of $b, though $a still looks like a stand-alone variable.  Perhaps another symbol would be good, but then you get into the problem of perl, where $a and #a and &a are all confusing and conflicting things.  Difficult problem to solve, but most programmers just don't use references unless they need them.

 

(integer) is a synonym for (int). There?s also (bool)/(boolean) and (float)/(double)/(real). [...]  There?s redundant syntax for blocks: if (...): ... endif;, etc.

"PHP is too confusing, I have to memorize so many things! Waaaaaah!  In addition, there's aliases for things so if I forget and use the wrong one it will still work!  PHP IS AWFUL!!"

 

Most error handling is in the form of printing a line to a server log nobody reads and carrying on.

"I don't read my log files, what kind of programmer would ever use error logs to debug?  That's stupid!  My website should just die with a white screen and a 'Sorry!' message whenever there's an error so I know to go try to remember where I put the error logs"

 

E_STRICT is a thing, but it doesn?t seem to actually prevent much and there?s no documentation on what it actually does.

As stated above, E_STRICT is an error-level constant (hence the E_) and is well defined in the manual.

 

Weirdly inconsistent about what?s allowed and what isn?t.

The things he listed as "silent" are not errors in the least, they're all valid PHP operations.  He seems to think E_STRICT should mean "work more like another programming language."  Probably because he doesn't understand PHP.

 

PHP errors and PHP exceptions are completely different beasts

Are there interpreted languages which throw in-application exceptions instead of language-level errors when they encounter fatal or parse errors?  I don't think there are, I think the author doesn't understand interpreted languages vs compiled ones.

 

Some built-in functions interact with reference-returning functions in, er, a strange way.

The one example he has of this shows someone attempting to create an anonymous (unreferenced) array, put a variable in it, and then have it immediately destroyed.  Not sure why that's even something someone would do, but...err...you got me.

 

OO

 

I?ve yet to find a global function that even has a capital letter in its name

Anyone else feel like scrolling up to where he complains about function names being case-insensitive?  No?

 

Perl, Python, and Ruby all have some concept of ?property? access via code; PHP has only the clunky __get and friends. (The documentation inexplicably refers to such special methods as ?overloading?.)

Our dear author has not yet discovered the simplicity of $foo->bar.  Either that or he has absolutely no understanding of how objects work in ANY language.

 

Classes have something like variable declaration (var and const) for class attributes, whereas the procedural part of the language does not.

Aside from demonstrating the "var" syntax (deprecated over a decade ago), this doesn't understand the complexities of designing a real system in PHP. 

 

Despite the heavy influence from C++/Java, where objects are fairly opaque, PHP often treats objects like fancy hashes?for example, the default behavior of foreach ($obj as $key => $value) is to iterate over every accessible attribute of the object.

Still not getting why he complains about additional functionality he doesn't even have to use.  So you can foreach over an obect to get its public variables (or, if it implements arrayaccess, some other variable of the author's choosing).  If you don't like that, don't use it.  It's like saying "unlike C, Python allows me to have tuples."  So? 

 

Object attributes are $obj->foo, but class attributes are Class::$foo. ($obj::$foo will try to stringify $obj and use it as a class name.) Class attributes can?t be accessed via objects; the namespaces are completely separate, making class attributes completely useless for polymorphism.

None of this makes any sense at all.  I'm willing to give him the benefit of the doubt and assume he hit his head or something.

 

I?m aware this is more personal taste, but I don?t know why this stuff is necessary in a dynamic language?in C++ most of it?s about compilation and compile-time name resolution.

Wow, that's an excellent point.  I'm glad we're talking about a compiled language and not, for instance, PHP.

 

Arrays

 

Despite that this is the language?s only data structure, there is no shortcut syntax for it

Once again, who wants to volunteer to scroll up to where he complained about the shortcut array syntax?  It's like this article was written in 2004, and then he updated it with more complaints, many of the complaints being about the fixes to his previous complaints.  It's like the room is filthy, and the maid used floor polish that smells too strongly.  One or the other.

 

it?s the only language in its niche that has no vetted way to create a hash without quoting string keys.

Because it's a loosely typed language perhaps?  Because it's possible to use a variable without defining it, even constants, and therefore an unquoted bare string literal is assumed to be an undefined constant?  Becuase you don't understand loosely typed languages?

 

Missing Features

 

No XSS filter. No, ?remember to use htmlspecialchars? is not an XSS filter.  This is.

So "remember to use htmlspecialchars" doesn't count, but "remember to use marksupsafe" does?  Gotcha.  Good to know that the criteria for language functionality can just change mid-sentence.

 

No CSRF protection. You get to do it yourself.

Because his last example was a function call you had to wrap arounde every string, I'm going to go ahead and assume that's what he'd use to "prove" this point as well, if such a library is even available.

 

No generic standard database API. Stuff like PDO has to wrap every individual database?s API to abstract the differences away.

There's no standard database API.  Except for the standard one.  But that one doesn't count because deep down below where you can see it, it doesn't call the same functions for each database. 

 

No authentication or authorization.

This one I actually know nothing about.  Do other languages have built-in user authentication which can work as a login system?  So if I want to write a web login system in Python, there's a built-in language core module for that?

 

Security

 

PHP?s poor security reputation is largely because it will take arbitrary data from one language and dump it into another. This is a bad idea. "<script>" may not mean anything in SQL, but it sure does in HTML.

Again, I'm going to have to ask how Python does that.  Does Python automatically sanitize plaintext output?  How would you print a <script> tag in python if that's the case?  Or is this, like most of his complaints, just how languages work?

 

PHP outright encourages ?sanitizing?: there?s an entire data filtering extension for doing it.

Could this be because PHP interacts with half a dozen other languages?  Sure, you can use "placeholders" (bound parameters) with SQL, but can you use "placeholders" with HTML forms?  No, you need to sanitize your output.  Good thing PHP includes those functions.

 

register_globals. It?s been off by default for a while by now, and it?s gone in 5.4. I don?t care. This is an embarrassment.

PHP was originally written to be super easy to use.  As the featureset grew, they disabled some of the easier things.  Register_globals is stupid today, which is why it's been deprecated for 10 years.

 

include accepting HTTP URLs. Likewise.

There's a PHP.ini command to disable this, which is off by default.  He even complained about a similar command above.

 

Conclusion

 

If you got all the way down here, I assumed you agreed with me before you started

Or you had a morbid fascination with the awful arguments being presented and were unable to turn away, like a car crash.

 

Right forum? :-P I kid I kid. (Edit: by which I meant php coding help vs misc, not here vs devshed).

 

I'd read the article before, I thought it was pretty lame. I'm going to actually read your post now.

 

...

Done reading. Entertaining

I love that panel

At least I wrote it during normal business hours.  Not like last time, when I argued about it on reddit until like 3am.

XKCD just isn't the same without title text.

 

One thing to add - object iteration, and the Iterator interface is so incredibly powerful. I'm not sure it's the cleanest implementation (perhaps using magic methods rather than an interface?) but my god it's cool to foreach through an object containing data and helper functions without having to worry about public properties.

 

I pretty much agree though. His points are only valid because the devs want PHP to be backwards compatible - they don't want to piss people off by breaking things, or clutter the namespace with consistently-named core function aliases. I mean, it's not like they don't have amazing documentation (learning how to use the manual is step 1 in understanding the language), and well grouped function sets that are easy enough to search or skim through.

 

json_decode returns null for invalid input, even though null is also a perfectly valid object for JSON to decode to?this function is completely unreliable unless you also call json_last_error every time you use it.

He gets another point here, json_decode really should throw an exception. Though to be fair, if I ever get a json object which resolves to null, I'm going to handle it as an error regardless.

 

Half point at most. A JSON string parsing as null should always mean garbage-in/out. If you need more specific reporting, it's easy enough to code in and return. If it's an external JSON and there's a potential of it returning NULL as well as badly formed data, then I think you've got a bigger issue on your plate.

 

If there isn't a damn good reason to return NULL, it shouldn't be there. I suppose json_decode could throw an warning or something on invalid input. Seems like a pretty weak argument though.

 

The title of the article is pretty goofy too. Seems like he's grasping for a reason to use a fancy word.

 

Reported for exessive use of the word 'boilerplate' BTW. I hate this new goofy 'design pattern 2.0' lingo.

Half point at most. A JSON string parsing as null should always mean garbage-in/out. If you need more specific reporting, it's easy enough to code in and return. If it's an external JSON and there's a potential of it returning NULL as well as badly formed data, then I think you've got a bigger issue on your plate.

I still gave him a full point because you can't argue with the basic statement: The error condition is also valid output.  The fact that the programmer should know better doesn't change the validity of his statement. 

 

 

The title of the article is pretty goofy too. Seems like he's grasping for a reason to use a fancy word.

 

Reported for exessive use of the word 'boilerplate' BTW. I hate this new goofy 'design pattern 2.0' lingo.

Reported?  I hate it too, I was mimicking his style.  He's synergized to the cloud, and eschews boilerplate for more streamlined antipatterns and whatnot.

Note: the following is mostly tongue-in-cheek comments and should not be taken seriously, or quoted against me in the future. 

 

---

 

And E_ALL?  How is a constant name (which resolves to -1 anyway) a "surprise"?  The list of error-level constants is in the manual.  they all begin with E_ and then give what they describe.  E_ALL is all.

 

Only relatively recently did E_ALL actually encompass everything. For PHP 5 < 5.4.0 it wasn't all since E_STRICT was not included. Also, E_ALL has never been -1.

 

---

 

I'm writing this for the DevShed community

 

 

---

 

There?s no clear design philosophy.

Yes, we know.  He still has one point.

 

I guess the following counts as a design philosophy. 

 

< rasmus> PHP is ugly.  It was meant to be ugly.  If you don't like ugly' date=' don't use PHP.[/quote']

 

---

 

Line-level error suppression is a powerful feature, I'm glad to use a language which supports it.

 

Expression-level, which PHP uses, is even MOAR powerful.

 

---

 

He gets another point here, json_decode really should throw an exception. Though to be fair, if I ever get a json object which resolves to null, I'm going to handle it as an error regardless.

 

By convention, core functions don't throw exceptions. OOP constructs should throw exceptions, but json_decode() isn't one of those. The correct thing (currently available) to be doing for functions that may give the same return value for success and failed states is indeed to check the associated error function, that is what they're there for.

 

---

 

objects are always passed by reference

 

Say what? 

 

"One of the key-points of PHP 5 OOP that is often mentioned is that "objects are passed by references by default". This is not completely true." - read the whole article.

 

---

 

I?ve yet to find a global function that even has a capital letter in its name

Anyone else feel like scrolling up to where he complains about function names being case-insensitive?  No?

 

Coding standards; believe it or not, even PHP has them.

 

---

 

So you can foreach over an obect to get its public variables (or, if it implements arrayaccess, some other variable of the author's choosing).

 

The article had this right when saying accessible (or in PHP parlance, visible), rather than your public. The properties iterated over are the visible ones.  Also,ArrayAccess bears no relation on what happens with foreach().

 

---

 

As for function names, inconsistencies, and all that jazz; some food for thought.

 

<@Rasmus_> everything in PHP was and mostly still is like that

<@Rasmus_> a very thin layer on top of underlying library functions

<@Rasmus_> mysql, oci, pgsql, etc.

<@Rasmus_> what you see in PHP is what you see if you read the API docs for those

 

< ajf> You know, the reason PHP is so inconsistent is probably because (so far as I understand) Rasmus didn't really set out to create a language, it was a set of scripts which evolved rapidly into a somewhat-C-and-Perl-like language

<@Rasmus> it really isn't inconsistent. It is just lower-level than some people expect

<@Rasmus> most things in PHP mirror the underlying libs they talk to

<@Rasmus> the naming is from the underlying libs as well

 

(I'm sure he's fine with me quoting him completely out of context.  )

Only relatively recently did E_ALL actually encompass everything. For PHP 5 < 5.4.0 it wasn't all since E_STRICT was not included. Also, E_ALL has never been -1.

Yeah, I glossed over the first bit.  The last bit...was a brain fart.  No idea why I put -1.

 

 

I'm writing this for the DevShed community

Whoops, removed.  I thought I got the two devshed references, there were 3.

 

 

 

Expression-level, which PHP uses, is even MOAR powerful.

You're right, I misspoke.

 

 

 

"One of the key-points of PHP 5 OOP that is often mentioned is that "objects are passed by references by default". This is not completely true." - read the whole article.

Not completely true, but true enough to refute someone who doesn't even know what a reference is, like this author.  Good read though, I didn't know they went so deep into it.

 

 

Also,ArrayAccess bears no relation on what happens with foreach().

Been a very long time since I've written an object that extends arrayObject, I got the interface wrong.  Which is it?  ArrayIterator? 

 

<@Rasmus> it really isn't inconsistent. It is just lower-level than some people expect

<@Rasmus> most things in PHP mirror the underlying libs they talk to

<@Rasmus> the naming is from the underlying libs as well

Poor Rasmus, he gets so much flack for letter-by-letter reproducing someone else's work.

Half point at most. A JSON string parsing as null should always mean garbage-in/out. If you need more specific reporting, it's easy enough to code in and return. If it's an external JSON and there's a potential of it returning NULL as well as badly formed data, then I think you've got a bigger issue on your plate.

I still gave him a full point because you can't argue with the basic statement: The error condition is also valid output.  The fact that the programmer should know better doesn't change the validity of his statement. 

 

Well, json_decode can also return FALSE on a successful parse, so beyond throwing an error/exception, what can it do? The behaviour is documented, and since NULL is the least likely 'correct' return value, I think it makes sense on failure.

Just a little comment about the missing thread functionality of PHP. While it is true that you wouldn't (normally) need threading in a web langauge, PHP does indeed have process support. Granted, it's rather bare-boned, but it's there. Along with Shared Memory support.

We also have a PECL library for thread support, though experimental (and not something I'm familiar with).

 

Considering the overall (lack of) understanding the author displays in his article, I'm not sure whether he actually means "thread support" or is confusing threads and processes.

We also have a PECL library for thread support, though experimental (and not something I'm familiar with).

 

Wow a blast from the past there. It is super-duper ancient (a decade ago) and there was never a release made.

Hmmm... Guess I'd better check the date the next time, eh?

Oh, well. The point still stands, even though a bit reduced.

For those that are interested, the author himself personally replied to my devshed thread on the subject.  His arguments are more of the same, but I deconstructed them anyway.  His core argument still seems to be "loosely typed languages are confusing to me and that makes me sad."

Best. Thread. EVAR.

For those that are interested, the author himself personally replied to my devshed thread on the subject.  His arguments are more of the same, but I deconstructed them anyway.  His core argument still seems to be "loosely typed languages are confusing to me and that makes me sad."

 

Nice, Phil Sturgeon argued with him too.

Did the author seriously argue that there is something intrinsically wrong with PHP because of The Query String, and suggest that a URL which can be used by PHP thanks to mod_rewrite is ... Not usable by PHP?

 

Does he think all the sites he goes to with pretty URLs are powered by Ruby? When statistically they are most likely to be PHP powered?

 

Our perl app at work uses query string vars, so I'm making an assumption that leaves Ruby as the only option.

Did the author seriously argue that there is something intrinsically wrong with PHP because of The Query String, and suggest that a URL which can be used by PHP thanks to mod_rewrite is ... Not usable by PHP?

Yes.  I even asked him directly.  We'll see what he says today when the thread unlocks. 

"I rarely see big new interesting projects started in PHP."

 

I guess since the projects I've worked on for the past 5 years aren't really interesting, they don't count...weird.

I mean, the reporting tools for ensuring that medical instruments that detect cancer via a blood sample are working correctly and finding common problems with them, that wasn't INTERESTING. Sure was useful. Not really interesting though. Potentially life saving? The touching letter we got from a cancer survivor who was diagnosed early thanks to our equipment, which was fine tuned thanks to the reporting system...would say yes. Well maybe it is interesting in that regard. *shrug*

 

Interesting projects don't pay the bills. The software that powers every day businesses is what pays the bills. I care a lot more about that then if what I'm doing is new and exciting but maybe that's just me.

"I rarely see big new interesting projects started in PHP."

What he really means is "I hate PHP and anyone who uses PHP is a moron, how come nobody works with me on awesome PHP projects?"  It's like a racist saying he rarely sees successful black-owned businesses. 

 

 

Well, PHP being the most used makes it no longer trendy.

 

Who wants to develop a cool, trendy app on a non-trendy platform?

 

LOL, you aren't using NoSQL for that?

Well PHP is not a fully object-oriented programming language, which is a huge drawback. On the other hand, Ruby is quite difficult to learn, definitely not recommended for the vast number of beginner coders. I do believe there is a good reason why PHP is more popular than the other two though. I am not quite familiar with Python though, anyone mind explaining?

For the umpteenth time, you're not going to get anyone here to agree with you that PHP allowing procedural code is a "huge drawback". If anything it's the opposite. PHP is FLEXIBLE.

Well PHP is not a fully object-oriented programming language, which is a huge drawback.

Why?  Go ahead, tell us why the ability to program with or without objects is a drawback, instead of a feature.  My car isn't fully a forward-moving car, it has reverse.  major drawback?

Well PHP is not a fully object-oriented programming language, which is a huge drawback.

Why?  Go ahead, tell us why the ability to program with or without objects is a drawback, instead of a feature.  My car isn't fully a forward-moving car, it has reverse.  major drawback?

 

This analogy made my head explode