Wednesday, 2 March 2016

Picking an Approach

Fig 1. Several Languages
I should hope that the majority of people reading this consider themselves polyglots.

A polyglot is a person able to speak in many languages; It's almost a requirement of programming that we should know more than one language.

Using the right language for the job is a worthy aspiration to have.

When you, or I, as a programmer are setting out to write a new product, or application, we should definitely consider our options: It's a matter of fact that no language is best for everything.

The right tool for the job makes sense as part of our approach to writing applications ...

Choosing Wisely

Fig 2. PHP Internals

When we approach the design of a language, I submit that it doesn't make sense to use the right tool for the job argument against having a feature.

We need to aim for something in our approach, but what should it be ?

Before I try to define that, we should probably admit that whatever our aim, we might miss by quite wide margins.

It's difficult to organize groups of individuals spread out across the world, when there isn't so much as a single person you could identify as "manager". Your team at work might be spread out across the world, but your teams at work are carefully managed.

We can choose an idyllic aim, even knowing that we will probably miss: Being anywhere close to an ideal, is better than having no aim at all!

I think, our aim should be to provide the best tool for the job.

It's true that no language is best at everything, it's also true that no language is good at everything. However, it has to be part of everybody's ideal that such a language should exist; One that is good at everything.

We will probably miss our target, PHP will never be best at everything, but in aiming for that, we have good chance, over a long period, many versions, of really having a language that is genuinely good at everything (that we care about at the time).

It still won't be the right tool for every job, there will be better languages, forever.

I want to see people stop advancing the right tool for the job as an argument, I want to see people accept foreign ideas more willingly if it creates a better tool for programming.

In the not too distant future, when things like async/await are suggested, don't be tempted to rebel against that because there are better tools for the job.

Don't shout "use go", even though we all know it's probably the best tool for that kind of work today.

Let us make PHP a realistic option for tomorrow, let us at least try to provide the best tool for the job ...

Back to code ...