First let me start with “Pizza” the author of “Parseerror.com” is a friend of mine and I think we have always disagreed on how harsh to be in reference to “php” as a programming language. I will jump at the chance to comment on an entry I found on his site though, which I have quoted below:

I’d realized years ago how horrible of a language php is. But amazingly, php just gets worse. For example, they manage to easily temper the good news of the addition of long-overdue namespaces with the ludicrous use of the ‘\’ character to separate them, when every other language in the Universe uses ‘.’ (This.Makes.Perfect.Sense vs. What\Were\They\Thinking). Today a member of #php ran across another horrific misfeature; a reasonable attempt at string concatenation from a newbie programmer:

"a" + "b"
This code works well in java, javascript, C# and other languages, resulting in a string “ab”. but in php it does the worst possible thing:
var_dump("a" + "b"); int(0)
It happily converts the two strings into integer 0 and adds them, destroying all data in the non-numeric strings with no warnings whatsoever. This is particularly painful because the + operator is a common string concatenator in other languages.

Let me say, to a degree… I agree. It seems silly at best that “a” + “b” does not convert as expected; BUT… for a php developer the result is expected, as this is a known action of php. In most cases when developing code for php developers I assume are not concerned if the developed code would work directly in java, javascript, C# and or other languages, save those that are developing for a multi-platform, multi-language architecture, in which case …. why are you using php to begin with.

From a pure code aspect I would tend to agree that the functionality mentioned above should produce universal results as one would expect. I do not think that we are striving to build a universal language for development in any of these languages that we have mentioned though. I do agree with common practice to keep singularity between languages, but would not go so far as to say that it’s a reason to label php as a “horrible language” because it deviates in this manner, when there are so many better examples to label it with this tag.

On a side note….. “Hi Ryan”

My most recent email to my boss while he was on vacation to update him on a simple little project.

Without flying to India and holding their hand while spoon feeding them,
I cannot explain how email works any clearer than I already have. The
level of programming inexperience emanating from {india team name} has exceeded
the threshold that I allow myself to be exposed to during the course of
one day.

Email conversion is not complete because they fail to read, comprehend
and/or pay attention to anything other than the Corky from “Life Goes
On” ( http://www.imdb.com/title/tt0096635/ ) retarded code that they
insist upon creating.

I’m not sure if this is the norm, I stumbled across the answer while banging my head against a wall trying to integrate a Lucene search through the ZF framework (zend). So, as an example I wanted to run the following code block. It simply adds a document and some fields to the the document and some unstored content.. pretty basic.

Notice the last line though…. “index->commit();”

You will have to look hard to find the use or reason for using this, but if you do not and your script ends pre-maturely, there is a chance you will not get the results you expect. The examples I have seen do not mention that if you do not do this and you run and exit or throw an exception prior to the front controller dispatching, it goes to shit.

Just as an fyi many people after the commit will toss in the index->optimize,.. it’s a good practice, I just did not do it for this example.

Example code:

$index = Zend_Search_Lucene::create(SEARCH_DIR.'articles/'.$data['article_index']);
$doc = new Zend_Search_Lucene_Document();
$doc->addField(Zend_Search_Lucene_Field::Text(’title’, $data['article_title']));
$doc->addField(Zend_Search_Lucene_Field::Text(’description’, $data['article_short']));
$doc->addField(Zend_Search_Lucene_Field::Text(’link’, $data['article_url']));
$doc->addField(Zend_Search_Lucene_Field::UnStored(’contents’, $data['index_content']));
$index->addDocument($doc);
$index->commit();


I currently work with a team overseas in a location that will remain nameless (India). Now I am not overly thrilled with having to work with this team, aside from the time difference, language barrier combined with my inability to spell, as you can probably see in my blog. I have tried to keep an open mind with them, to the best of my abilities, but my experiences with them are far from…. good.. hell they are just down right annoying at times.

I have a list of things I could post that would probably make most open source developers curl up under their desk and cry a little, but I’ll keep it short for now. I will post the following in a questions / answer format, my question… their response. (I refuse to call them answers.)

Q: This query we have on page “a” take 12 seconds to return 100 records…. I noticed it makes 3 joins to tables that have no relevant data in them to the response needed, why do we join those tables?

Response: We join those tables in-case our application corrupts data in the database. If we join those tables and the data is corrupted, then the query will not fail. It should still work.

Q:I have taken our repository and made a branch specifically for your team. This branch should be used for the new project you are working on as it will take a large amount of time to complete and modify large amounts of files. I have attached the check-out procedure for this branch.

Response: (paraphrased) Making another branch for a new project is very time consuming for us to maintain. Branching is really not a good practice in development and we should try and find another solution.

Honestly I think developers should all have to be licensed, if you fail your test and do not receive your license, you are banned from development and branded with “RETARD” on your forehead.