Why PHP must be abandoned (in my opinion)‎

Foreword

Every now and then, I find myself using PHP as a programming language.
I started using it since the early of 2000, and never really liked it.
Most people like it not because it is good, but because it is easy to "get inside" and start developing stuff with it.

But that's exactly one of it's biggest problems in the world.
I do not want that a programming language will be "easy" to start with, I want it to be good with what it suppose to provide.

First of all, easy is a relative word. That is, you must compare it to something. Back in the days, it was easier to start with PHP then with Perl for example. But when you actually start to "enter" inside the language, well, it's not really a programming language per-se, but a group of a lot of tools that allow you to have some sort of glue to use them.
It does not really act as a language (like with Perl), but a borrow stuff from other languages, such as Perl, C and few others.

Recently I found yet another problem with PHP. I got a 3rd party source code that explains to me how to implement a protocol that reinvent the wheel of HTTP REST using "JSON" like code, but with it's own TCP header, rather then to use plain old HTTP.

Problem

The way that they implement it, is really weird, because instead of using the "pack" function, they are using their own bit manipulation code (poorly), and use the "chr" function to convert each byte into an ASCII value representative.

They code it like so:

 chr(1000 >> 0) . chr(1000 >> 8) ....

The problem is that chr(1000)  (shift right by 0, keeps 1000 as 1000) must report an error, because 1000 is bigger then the last ASCII code (127), or extended ASCII code (255).
I'll explain it again: 1000 is bigger then the range of 255 . ASCII is only at the range of 0..127 chars, but extended ASCII provides extra chars up to 255 (full byte length).
Note: Even a numeric value of 256 is bigger then one byte !

With Ruby for example, I get "RangeError" exception for such action, so does with Python, Pascal, Perl (with strict bytes) and few other programming languages.

While with PHP, well it returns the value of 232.
You must shout out loud, "wait, WHAT ?" if you haven't done it by now.

I'll say it again: "chr(1000)" with PHP returns the value of 232.

It is doing so due to bit manipulation ($value & 255), but it's actually type of an integer overflow IMHO.Why you ask ? Well, the aim of "chr" is to provide one character of ASCII value. The spec of ASCII chars is very very very simple:

Range of a char is 0 to 127 (they write ASCII and not extended ASCII).If you are converting an integer value to it's ASCII value, and the last value is 255 (going extended ASCII here), then what is the representation of the 1000 value in extended ASCII ?

Answer: You do not have one.

That's why normal languages (give or take) return an error that you are out of range.When you give an answer that is not an error, then it means that there is a representation for the value. but 1000 is not 232, it's 1000, and 1000 is out of range.So you might call it a bug right ?
Well according to a person that works at Zend, it is a feature, and the bug is that it is undocumented feature.

Here it is (typos are from the original email):

First of all, this is not integer overflow. integer overflow is hwen the aritmethic result can not be held in integer. here, the function translate what it can and should, which is the last significant byte. I don't see a problem with that except of that is should be documented. if you test 1000 & 255 (the last byte of 1000) you will see that the result is indeed 232.

Oh, and this is the bug I opened for it, so you can follow it yourself.
And It's not the first or last of such "features" within the so called "language".

End

I for one, do not welcome our PHP overlords.
And I think that it's time to abandon this patched "ship" you call a language. The benefits of going in fast, are payed in the long run. with many problems that you actually require an IDE for not loosing your leg by hitting a mine.