Tag Archives: Php

I hate config files.  There, I said it.  Made a change to your configuration?  Database?  Temp location?  Gotta redeploy your application.  Even if you have an awesome deployment mechanism it just seems somehow wrong to have to redeploy your app to make a configuration change.  From a security standpoint, I don't particularly like having passwords and such being stored in a source repository.  Or making it part of your build process.  Or manually editing files in production.

I want my configuration to be discoverable.  In other words, the only part of the deployment process that has configuration information is the information needed to discover your configuration.

I'm doing some work again (finally!) on a really cool cloud example.  But one of the things I had noticed was that every time I redeployed the app I needed to script out changing some discoverable endpoints.  For example, if a queue has a load balancer in front of it, that load balancer name/IP may have changed.  Having that extra level of deployment in there really bugged me.  Some may say "with continuous deployment you don't have to worry about that!"  Oh yeah?  What are you doing making your production environment available to your testing environment?  Production settings, by definition, should not be testable in any other environment other than production and you generally shouldn't be testing in a production environment.

One of the big tenets of building a scalable application is being able to discover resources.  Who knows where information lies in a large scale system?  Now, PHP developers may say "it's never been a problem before!".  To which I would reply, "that's the only way you've ever done it."  In other words, having an easy way to manage configuration options and application resources are things that most PHP developers have not really done.  I take that back, I have seen it done, but it's done by figuring out what the local configuration file says about those app resources and configs.

That's it.  Just ranting.  Kinduv.  But seriously, I do think we need to handle configuration and resources in a better way.

I am about to head out to Magento Imagine to speak on queuing and scalability.  So what is today’s blog post about?  Dynamic typing; which has absolutely nothing to do with scalability.

Every once in a while I inject my opinions into places where they are not welcome.  I have heard from people in the staticly-typed realm of how amateur dynamic typing is.  Some people are interested in understanding how to use dynamic typing, others, not so much. So what I would like to do is talk about some of the arguements made against dynamic typing.  Clearly PHP will be my reference point, but many of my points will be salient across many dynamically typed languages.

The biggest misconception about PHP is that it is a strictly dynamicly typed language.  In other words that cannot have typed variables.  Where you are using the OOP mechanisms in PHP, you have the opportunity to strictly type your variables.

1
2
3
4
5
6
7
8
9
10
11
12

class Test {}
class Test2 {}
 
class ExecuteTest {
 public function exec(Test $test)
 {
 doSomethingWithTest($test);
 }
}
 
$et = new ExecuteTest();
$et->exec(new Test2());

What happens when this code gets compiled?

Catchable fatal error: Argument 1 passed to ExecuteTest::exec() must be an instance of Test, instance of Test2 given, called in test.php on line 17 and defined in test.php on line 9

Fatal error.  This is because the type of object passed in was incorrect.  So data types do exist in PHP and many other languages.  The only downside is that you need to actually run the code on your web server or in a unit test to compile it.  Some would (and have argued extensively) that this is a significant drawback.  There’s truth to that, but on a very limited scope.  Is it a drawback?  Yes.  Is it signficant?  Not by a long shot.  Whether it’s PHP, Java, C, Perl, Ruby, VB, C#, JavaScript, etc. etc, if you deploy code that you haven’t tested then you deserve every error and every sleepless night you get.  It’s called being responsible for your code.  And don’t think that having your code pre-compiled is much better.  I have a lot of compiled applications running on my computer.  Cakewalk SONAR, Firefox, Apache, PHP (the binaries), MySQL, Tweetdeck, Java, etc., etc.  And you know what?  Shit still happens with compiled code! Sometimes even type-related errors!  Compiling your code ahead of time as you do with C, Java, and the like does not protect you from type-based errors.  Can you catch some fat-fingered errors?  Sure.  Are you safe?  No.

For example, take this Java code

1
2
3

System.out.print(
     Integer.MAX_VALUE
);

Running it provides an output of

2147483647

What about this code?

1
2
3

System.out.print(
     Integer.MAX_VALUE + 1
);

The output is 2147483648, correct?  No.  It is

-2147483648

Did the compiler flag that?  No.  Is that a weakness in Java?  No.

That was a bit of a side-track, but it highlights what I think is a misconception about PHP applications and structure, usually made by those who don’t do significant work in PHP.  Do you HAVE to build a well-structured application?  No.  Should you?  Of course.  PHP does not force you to write bad code.

Often those who complain about PHP will complain not about what PHP developers DO, but about what they COULD do.

But let me address what I think is probably the biggest complaint from the static-typed crowd.  The biggest problem is not the programming language, but the user sitting at the interface.  The problem is that if you have data entered for a field called “width” and the person on the other end enters “wiener” the problem isn’t that “wiener” evaluates to zero, it’s that you didn’t validate your data.  This problem exists for C, Java, or whatever your compiled language is.  Why?  Because if you are building a web site you do not have the ability to force typed input.  Why? HTTP is ALL strings.  There are no integers, there are no floats, there are no booleans.  They are all strings, regardless of the language you are working in.  And there are plenty of validators in the core PHP language to use (ctype_*) and plenty of frameworks that offer more advanced validators.  If you aren’t validating input in ANY language you will have problems.

The next issue is with API code.  I have no problem conceding that if I am writing an extremely math based application that PHP is likely not a good choice.  So, 3d applications, music/audio applications, games, etc.  Going back to the previous paragraph, PHP was written for HTTP.  HTTP uses strings.  But if you’re building an API or structuring an application, how do you make sure that other programmers don’t provide data that royally messes up your code.  Conceptually, I will concede that this could be a problem.

But go back a few paragraphs.  I made the claim that people complain not about what PHP developers do, but what they could do.  The example I saw was

1

$square->setSize("hello");

setSize(int), in a static-typed language, will fail.  Could you put “hello” into a method call named setSize() in PHP?  Yes.  Next question; would you?  If you are worried that someone will put the word “hello” into a method called setSize() then you should be wondering about the basic cognitive abilities of the programmer, not the abilities of the language.  We’re not even talking about using something like Hungarian notation or anything like that.  We’re talking about simple logic.  Does “hello” make sense in that context?

OK, so that example was on the simplistic side.  What about when you are dealing with complex third party applications?  In all honesty, I don’t know how to quantify that.  If there’s a method called setPrice() do I put a description in there?  I suppose that if you are using a log of magic in your application that there could be a benefit, but the whole complaint is that static typing is safer than dynamic typing.  In that case

1
2
3

System.out.print(
    Integer.parseInt("Dubious data")
);

should be a nonexistant issue.  But it’s not, because invalid data was passed.  These kinds of games can go on and on but they miss the point becuase these are things that the language cannot check against.  If you intend to leave your application open with no validation either at the front of your application or in your API then you will have problems.  It doesn’t matter if it’s typed or dynamic.  What matters more than the type is the value, as we saw in the Integer.MAX_VALUE + 1 example.  So even when writing or writing to a third party API you still need to validate data.  As such, the gain of typing is not as significant as is sometimes claimed.

I’ve talked so far about objections to dynamic typing.  What about the pros?  This is a short argument because there is one big reason why dynamic typing is good, and it is quick to explain.

I think the biggest pro of working with a dynamically typed language as that you go from working with data/types to working simply with data.  In other words, do you really care about whether or not 1 is a string “1″ or an integer 1?  No.  You care that it’s a 1 up until you are doing math.  Then at that point the interpreter works on that data as if it were a number.  When you print that number in a browser do you care if it’s a numerical 1 or a string “1″.  No.  You care that the user sees the number 1 on their screen.  In that case it’s a string.  Data; that is what applications are about.  Data.  Applications are not about data types.  Data typing for scalar data can help to mitigate some issues but it is by no means fool-proof.  In fact, a lot of security issues are due to some very smart “foolish” people messing with input.  Data types do not protect you against anything.  In Java, you get bad data, in C you get a buffer overflow.

Data.  That is what we are working with.  My purpose in writing this is not to say that dynamic typing is better than static typing, or anything like that.  Types are ways of describing data, but they do not protect you against anything.  Statically typed languages will protect you in some cases, but leave you wide open in others.

So why is dynamic typing sometimes listed as an objection.  I believe that’s exactly what it is; an objection.  Objections are simply reasons that people find to not use your stuff and are usually done to put you on the defensive.  It’s standard fare for if you’re selling kitty litter or a programming language. A lot of people hate PHP, for reasons I have described before.  My interpretation is that dynamic typing is raised as an issue mostly because people see attacks on their preferred language as an attack on themselves.  Honestly, I can think of no other reason why people get so engaged in tech-wars the way they do.