What’s the difference between:

<form action="/foo" method="post">
    <!-- other form fields -->
    <input type="submit" value="Send data" />
</form>

…and…

<form action="/foo" method="post">
    <!-- other form fields -->
    <button type="submit">
        Send data
    </button>
</form>

Apparently none. Both snippets look and act exactly the same way. And yet, there is a more subtle difference. The difference lies in the semantics and in the meaning of the two types of buttons. A <button> tag displays a button, that you can click with your mouse and can be placed almost anywhere on a page. That’s all. It doesn’t have a purpose.

An <input type=”submit” > on the other hand does a lot more. It’s a form element – can only appear in a form – and it has meaning attached to it. When you submit a form by clicking on such an button, the value of the button is being sent along with the values of all the other form elements to the server.

<form action="/foo" method="post">
    <input type="checkbox" name="item[]" value="1" id="item_1" /> <label for="item_1">First item</label>
    <input type="checkbox" name="item[]" value="2" id="item_2" /> <label for="item_2">Second item</label>
    <input type="checkbox" name="item[]" value="3" id="item_3" /> <label for="item_3">Third item</label>
    With selected: <input type="submit" name="delete" value="Delete" /> <input type="submit" name="archive" value="Move to archive" />
</form>

In this case it matters on which button the user clicks, so an input type=”submit” tag is the best choice. But when you have something like:

<form action="/foo" method="post">
    <input type="text" name="email" />
    <button type="submit">
        Subscribe to newsletter
    </button>
</form>

…it doesn’t! So here the button tag is best suited.

I’ve read this article that debates the differences between perl and PHP in a childish way – sort of like the kindergarten debates on whether Batman can kick Spiderman’s ass. Since I haven’t ever coded a single line in perl, I can prove to the world that I’m a mature person that doesn’t plunge into “my operator in better than yours” debates, because if I would have any perl experience, I would be right there in the middle of it .

They may be right on some of the statements they make, but when they claim that a career in perl in better than one in PHP they’re wrong. Dead wrong. PHP has a bright future ahead it whereas PERL does not. Because, in the end, arguments such as “perl has better naming conventions” don’t matter. Decisions on what technologies should be used, especially on large projects where loads of money are involved, aren’t taken by geeks in dark rooms over a game of AD&D, but by CEOs over a game of golf or in really expensive restaurants. This is where perl loses the battle: PHP has Zend for its PR.

If you go on Zend’s website, you find things like improve productivity, maximize IT investments. This is music to a manager’s ears. CEOs like pie charts more than they like pie. If you go on perl’s website, what do you see? Well, perl 5, perl 6, CPAN ratings, Annotated CPAN, mailing lists. Why do you think that there are so many products being developed on Microsoft technologies? Do you think C# in better than perl or PHP? Or that ASP (not ASP.NET, the original ASP) was better? No, this is just Microsoft’s image at work.

PHP is quite big on its own, but compared to perl, it’s huge. PHP in on Oracle’s site. PHP is on Adobe’s site. Wikipedia is built on PHP, Wordpress is built in PHP and the examples go on and on. Perl is not even in the debate, it’s seen as an esoteric language used by CLI geeks. I doubt (I haven’t checked so feel free to prove me wrong) that there is a single project with a budget over 200.000 euros being developed on perl.

These factors aren’t exactly “programming related”, so why are they so important in the day by day life of the average programmer? Well, they create jobs, pay money, give you the ability to pay the rent, buy a car, go on vacation and so on. If you come across a career decision between perl and PHP, don’t waste time wandering if perl’s naming standard is better than php’s or which language has less string comparison functions. But instead ask yourself, which technology will allow you to find a better job? Look on a local jobbing site and see how many PHP are available and compare that number to the number of perl jobs available – if any.

…just my 2 cents.

Today I had to choose between Google’s and Yahoo’s Maps APIs. As I’m quite a Google fan, I first checked out its maps API. Very disappointing. It seems that the API was designed by some marketing guy or a janitor. I know, tough accusation. And I haven’t even code one page with Google’s API. What makes me say that? Well, it all ended when I started reading their Terms and Conditions. It seems that all Google Maps API key are domain dependent (only work for a specified domain). And this sucks.

There are 4 traditional stages in software development: development, integration, staging and production. Usually, all these stages take place of different machines that have different domains and/or subdomains. This means that you need a Google API key for each stage. It means that you’ll need at least 3 different API keys just to get to the part where you’re testing the application. But if the developers use different virtual hosts for the project, the number of required APIs increase exponentially. I know that API keys are free, but time isn’t and it’s quite annoying to have to register for a new API key everytime you set up a demo version of the project on a new subdomain.

With Yahoo on the other hand, you only need one API key. And it works. A word of advice: if you need a map API, go with Yahoo! I did…