For the record. I wasn't talking about the performance of Perl OOP, but that of autobox. Perl's OOP can be perfectly efficient, provided it is coded to attain its benefits, and not enforce its associated dogmas.
With respect of Working Code First and Tune Later. You do not achieve effective, maintainable, scalable efficiencies by optimising after the fact. That inevitably leads to obscure idioms and unmaintainable hacks that come back to bite you. You acheive it by designing efficiently from the ground up.
Adding layers on top of badly designed code, may bring short-term relief, but they don't last. The earlier in the design cycle that efficiency is considered seriously, the less often it will need to be re-visited. Ignoring the problem from the outset and relying upon Mooore's Law to compensate has been the downfall of so many (large, well-funded and infamous) projects, it really is a surprise to me that the message hasn't got through yet.
As for the rest of it. I realise that you'll say: "This was just an example". But that's the problem with unrealistic examples, they do not stand up to even the simplest analysis.
Any programmer or analyst who cannot foresee that an array is an inadequate data structure for a collection of entities called 'Employees'... Well frankly, perhaps they should consider another careeer.
An array is a numerically indexed collection. The only attribute of an 'Employee' entity that makes even the vagest sense as a numerical primary key is 'EmployeeNo'. But even the smallest of new companies is going to start numbering its employees from something like 100000 or 10000000. To cater for hoped for future growth. And to allow for the inevitable turnover of staff. And other than using the long deprecated and obscure $[, it doesn't make much sense to start using an array from such a high base.
There is simply no correspondance between those operations available on an array, and those that are obviously going to be required--from the very outset--for an 'Employee' collection. shift might superficially seem like an operation made for discarding an ex-employee, but a) employees don't leave in the order they joined; b) it would cause all the existing employee numbers to change; c)...; d)...; e).... There is just no utility in starting with an array of 'Employee's; never mind trying to extend its operations to the foreseable and inevitable conclusion.
Other than for transient uses--say, sorting a small subset of the collection--using an array for Employee entities is an obvious non-starter.
As for the twigils suggestion. I think you have about as much chance of getting the Perl 5 language redesigned from the ground up, in order to ease the refactoring of broken-from-the-day-it-was-conceived code, as I have of enjoying the first 1/6th gravity orgy on the Moon.
Perl has it all! =)
Not all. But most of what is truely useful. You just have to learn what it has; learn why it has it; and learn how to use it effectively. And part&parcel of that, is learning why it doesn't have certain things that other languages do have. Whilst there are some that I'd put into the 'it'd be nice if' pile, for the most part, the reason it doesn't have them, is because it doesn't need them.
The only answer to the exponential growth in software costs, is for programmers to learn to concentrate their efforts on what is needed. And forget the rest, until it is needed.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.