kekoa vincent

PHP has been good to me.  I started using it over 7 years ago as a Perl refugee, and it really allowed me to get a strong understanding of programming in general because it was so easy to use.  I started playing with PHP when PHP 4 came on the scene.

I will admit that I probably didn't learn great design patterns, but things were simple, and there were basic objects.  As I learned more about good programming through other languages, that was able to influence my PHP work.  Java was probably the most influential in teaching good style.

Unfortunately PHP was not originally designed for objects, but was strapped on there in PHP 4 in a sort of hodgepodge way.  But with PHP 5 I really gained confidence that PHP was getting serious, as it's support for objects was much improved.

Is PHP a child's language?  It is if it is in a child's hands.  I think that the great thing about PHP is that it doesn't limit you that much.  If you want to make a terribly unorganized mess of code, that's your perogative, and PHP doesn't get in your way.  However, if you want to be disciplined, and do things elegantly, it provides the language support for that as well.

Anyone who criticizes PHP for being ugly, messy or anything else need only to say to the programmer that they are ugly and messy, because I have seen some very elegant PHP code, and have seen some utterly terrible code.

Anyhow I don't think the usefulness of PHP can be discredited, as it is used in many major websites, such as facebook, digg, and others that escape me.  It has proven to be a real performer when it comes to scalability.

PHP was my "gateway drug", it allowed me to get immersed in web programming technology without being overwhelmed by anything; I just got things done.  It also helped to provide experience that later could be built upon while maturing into a professional computer scientist.

I've noticed that many people still want to do things the hard way.  People don't want to use libraries to help them out.  They construct Json code by hand crafting curly braces, and quoting their values.

In PHP it is so simple to do Json, that really you have no excuse not to.  You have a couple of options, the PHP extension, which comes with most PHP installations nowadays, or another library, most importantly, my preferred one, Zend_Json, which is part of the Zend Framework.

Both libraries have two functions, encode and decode.  Encode takes in an object and spits out the string that represents the Json.  Decode is the opposite, feed in Json, and the function spits out a generic PHP object of type stdClass, that represents exactly the Json, (including translating Json arrays to PHP arrays).

Luckily, PHP and Javascript are dynamic languages, so you can add properties to any object, including changing the types and whatnot, you don't need to specify a 'Class' in order to construct a message.

To construct some Json in PHP(using the PHP extension), here's an example:

$obj = new StdClass();
$obj->mythings = array(1, 2, "3", false);
$obj->person = new stdClass();
$obj->person->name = "Kekoa";
$obj->person->age = 88;

echo json_encode($obj);

Which prints out:

{"mythings":[1,2,"3",false],"person":{"name":"Kekoa","age":88}} 

Wow. Exciting, it even takes care of quoting strings, and not quoting numbers, and booleans. Also takes care of any internal arrays or objects.

Decoding Json is easier:

$jsonText = '{"mythings":[1,2,"3",false],"person":{"name":"Kekoa","age":88}}';  

$obj = json_decode($jsonText);
print_r($obj);

When executed, the print_r reveals the PHP structure of $obj (the boolean false doesn't get printed nicely, but it's there, I promise):

stdClass Object
(
    [mythings] => Array
        (
            [0] => 1
            [1] => 2
            [2] => 3
            [3] => 
        )

    [person] => stdClass Object
        (
            [name] => Kekoa
            [age] => 88
        )

)

Since objects and associative arrays in PHP are essentially the same thing, you can request to have the decoder return your decoded Json into an associative array.  Simply set the 2nd parameter to json_decode() to true.  This is what you'll get:

Array
(
    [mythings] => Array
        (
            [0] => 1
            [1] => 2
            [2] => 3
            [3] =>         )

    [person] => Array
        (
            [name] => Kekoa
            [age] => 88
        )

) 

FYI, Zend_Json works almost exactly, but uses the static functions Zend_Json::encode() and Zend_Json::decode() instead.  The built in command is definitely faster(written in C) but the Zend_Json decoder is much more flexible(forgiving) if you're reading Json from someone who say, handcrafted their own Json instead of using a library.

Check this outdated, but still interesting comparison of Json libraries: http://gggeek.altervista.org/sw/article_20070425.html

Do you need to use the whole Zend Framework to use Zend_Json-- no, it's a component framework, you can pull out the Json utilities without any external coupling.

In my Scheme class, we went over how tail recursion allows for nice compiler optimizations.

http://en.wikipedia.org/wiki/Tail_recursion - Great resource

I decided to code up a quick experiment of how this can work. I have a simple recursive add function that will add up all the sequential integers up to and including num. This is also a proof of Pythagoras' tetrad. So if I do add(4) the return will be 1 + 2 + 3 + 4 = 10:

add-recursive.c :

int add(int num) {
   if(num == 0) return 0;
   return (num + add(num - 1));
}

int main(int argc, char** argv) {
   int count;
   if(argc > 1) {
      sscanf(argv[1], "%i", &count);
      printf("Result: %i\n", add(count));
   }
} 

Ok, let's try it out

$ ./add-recursive 4
Result: 10
$ ./add-recursive 100
Result: 5050
$ ./add-recursive 100000
Result: 705082704
$ ./add-recursive 10000000
Segmentation fault

Uh oh. Looks like we overflowed the stack at 10000000. The solution to such a silly problem would be to use tail recursion, which is a special form of recursion where your final operation is a recursive call. Normally, each recursive call will add a stack frame for each call to add(), but since you're only returning the result of the next recursive call, the compiler can re-use the same stack frame, and reload the recursive call onto the same stack frame, thus averting any stack overflow problems.

Here's a modified function that will do the same thing, but allow for the tail recursion optimization.

add-tail-recursive.c :

int add(int num, int count) {
   if(num == 0) return count;
   count += num;
   return add(num - 1, count);
}

int main(int argc, char** argv) {
   int count;
   if(argc > 1) {
      sscanf(argv[1], "%i", &count);
      printf("Result: %i\n", add(count, 0));
   }
}

Here's the new results:

$ ./add-tail-recursive 4
Result: 10
$ ./add-tail-recursive 100
Result: 5050
$ ./add-tail-recursive 100000
Result: 705082704
$ ./add-tail-recursive 10000000
Result: -2004260032 

Hey, we got a result, our integer overflowed, but that's beside the point, we got an answer, which means the recursion ran to completion without a stack overflow.

So, the obvious response is, that's a dumb idea to use recursion for adding like that, you should use a for loop. Yes, I know, I was just trying to test out this tail recursion in hopes that I will one day find a great use for it.

Note that when you compile your C, you'll want to turn on optimizations, I used -O2 for gcc, without that option, it has the same effect of blowing the stack up.

I just have to say the past few weeks have been so great as far as experimenting with different technologies.  Over the Christmas break I have been playing with Android, and as school is starting I have found myself neck deep in Flash/Actionscript, Python, using Amazon Web Services, Scheme, and it is mildly crazy, but has been very fun.

Lately, I have been able to detach from a single one-way thought process and have been forced to explore many different areas.  I would say it has helped me to find my strengths and weaknesses more than when I was concentrating on only a couple avenues in computer science.

Anyhow, I'm excited for the semester, I think it will be great to finish things up soon.  So far I'm definately on top of things, and really enjoying it, but I'll let you know in a couple of months if I still feel that way.

I have to say with no exposure to Actionscript until lately, that I like it as a language, it is what I felt Javascript should have been(mostly), but the integration with flash can be clunky I've found.

I'm starting to become more open to python, perhaps I will get to know it even more this time around, I've tried to avoid it up to now, but I am considering jumping in head first.

As for Scheme, it makes me feel like a retard, but I guess that's part of the process.  I will sum up my experience so far as, "If you can do it in scheme, you can do it in anything else easier."