Tag Archives: Opinion

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.

I have a thing for charts.  Charts have the ability to convey very complex scenarios in a single line, or a few lines, if there are multiple considerations to be made.  But the reason I have an interest in charts is not because of the information they convey, but the information that they don't convey.  I find that the information that is left out of a chart is often the most important piece.  This is because statistics can be made to say pretty much anything.  You've probably heard the line "Lines, Damn Lies and Statistics".  When I start hearing things like "60% of people think X" or "20% of people think Y" I tend to switch off.  Interestingly enough, I do the same thing, though.  Probably because that's the easiest way to make a point.  It sounds scientific.  It sounds like you've done your research, even if you really haven't.

Three years ago I saw this at a conference I was speaking at.  It was a conference that was supposedly about working in mixed environments where you would have .NET applications talking to C applications and Java applications talking to Ruby applications and PHP talking to, well, nobody, aparently.  During one of the keynotes the presenter had a chart of different programming languages placed based upon their feature set.  They had C, Java, Ruby, Python, etc.  But where was PHP?  PHP powers 30 million websites and is number 3 on the TIOBE index, so why was it not there?  They had the languages at position 1, 2, 4, 5, 6, 7, 8 and 11 (which the speaker clearly thought should be at number 1) but not the programming language at number 3.

After the keynote I was introduced the person who created the chart by a customer of ours.  I was introduced as "This is Kevin Schroeder, PHP Consultant for Zend Technologies." and the keynote speaker, presumably thinking he was funny, stated "Oh, I'm so sorry."

That exchange has often gone through my mind as I run into people, articles, blog postings and such that demonstrate this kind of attitude.  In fact, do an image search on Google on programming language charts and on the ones that are not scientific ("scientific" meaning that they are based on actual numbers), and you will often find that PHP is simply omitted.  It is an elephant in the room.  Given our mascot, appropriate, do you not think? 

From a programming languages perspective (not talking hardware, networking, web server or operating system) I think I can argue that PHP is responsible for the web we have today.  Is there ugly PHP code out there?  Yes.  A lot of it.  But what PHP basically did was made web programming available to the masses.

That's it!  I think I've figured it out.  Just now.  I think I now know why PHP is either scorned or completely omitted when people talk on comparative programming languages.  PHP is the programming language of the unwashed masses.  PHP is not the language of the "elite".  PHP is like spaghetti.  You throw it at the wall and it sticks.  It was not born out of a computer science department.  It was not born out of a design pattern.  It is impure.  It is unwashed.  It is unsophisticated.

This explains why many people try ignoring it.  They, having either been "properly" educated or having "seen the light", cannot force themselves to look upon what they see as the putrid stinking mass of PHP.  It is like the politician who thinks they need to tame the masses.  It is like the business leader who thinks they deserve ridiculous pay.  It is like the actor who thinks they have anything resembling a logical thought in resounding cavern they call a brain.

PHP is like the market place.  You go there and it is noisy and rambunctious.  But it is also where the people meet.  If you need something for dinner, as much as the politician would like to think they know best (like how much salt should be added to a restaurant dish), you go to the market place, not the politician.  Because they have what you need.  It might not be the highest quality.  It might not have the nicest shine.  But you know what?  It does what it is supposed to do.

To be fair; I do think that the PHP community initially missed how important developing for a framework was.  But you know what?  Microsoft missed the Internet.  And you know what?  Microsoft turned around and embraced it (for good, bad or in between, I will let you decide) virtually overnight.  PHP developers looked at some of the new technology coming out and said "you know, there are some good ideas there."  We now have half a dozen strong frameworks available for PHP each with their own strengths and weaknesses.

More could be written about the subject, and I'm sure that more will be.  But after thinking about it, Elitism is a strong candidate for the explanation the disparagement of PHP.  PHP is the language of the unwashed, uneducated masses.  And any type of Elite has difficulty comprehending how the masses survive without their help.  But yet we do.  Are things perfect?  No.  But we have no illusions of Utopia or programming Nirvana.  Appropriately, the word utopia, interpretted, means, that no place is perfect.

I think that quoting Sylvester Stallone, or rather Sylvester Stallone portraying John Spartan in Demolition man, is apt when talking about programming languages.  "You (elitists), get a little dirty.  You (PHP), a lot cleaner.  And somewhere in the middle, I don't know, you'll figure it out."  PHP has gotten cleaner.  MUCH cleaner.  Can the others stand to get a little dirty?