I am currently working at a company, where we are doing Perl development. However the code is really messy, uses really old Perl idioms, so I've decided to slowly clean it up and teach my coworkers about Modern::Perl, good software design, OOP - abstraction, coupling, inheritance, SOLID principles etc. I have a disadvantage, that I am working here only for a month, so I'm quite new here.
My question is: can I (if so how) convince them of considering switching to Moo(se) from plain Perl OO? What are the advantages of it? I need really good reasons for them to consider.
Is there a big cost performance-wise with using those modules? I know from experience, that it is very comfortable to use those modules (also traits are really good), but I am afraid that they will deny switching because of performance reasons.
So. Is there an advantage and how would you describe it to Perl developers, who are stuck in the pre-2000 era?
I'd start by asking - do your colleagues appreciate what you mean by these terms and why they're good things? There's always a difficult challenge involved in adopting a new paradigm, because EVEN IF your 'new way' is in all ways better... you'll be creating a legacy codebase that still has to be maintained. Or reworked.
Convincing someone to 'go OO' if they've built their Perl understanding from bash scripting to perl hacking ... can be a challenge. They may well - quite correctly - point out that whilst there are advantages to switching, "lowest common denominator" is applicable. There's a lot of people who know 'non-Moose' perl compared to those that know 'Moose'. (This may count in your favour though - point out it's a useful technical specialism that improves their future employability)
There is, after all, a reason why shell scripts are still used today - it's because they're a simple, straightforward and accessible solution to an immediate problem.
So first off - introduce your computer science principles. Get your colleagues to 'buy in' to the things you outline. This will take time. Probably a lot of time. If the code style hasn't changed for 15 years, that means that the coders there are comfortable with the way things are.
Then, you need to prove to your colleagues why 'your way' is better enough for them to bother to learn it. New 'stuff' comes along all the time, and there's always someone who wants to try out a new and cool thing. You will look like this person to them. As far as they're concerned, the current 'house style' works fine.
You may find that implementing something new in your new style is convincing. Get them to 'buy in' to your doing it as a proof of concept. You may find several other coders like the idea too.
But regardless - you have to accept the very real possibility that no one wants to pay the technical debt of the 'legacy' you'll create by doing this. There is a lot of business advantage by having a limited set of coding paradigms in use in your organisation. You need to think about how having both in service is going to work out.
This isn't a new discussion though - OO programming has always had those that don't see a point to it - they see the overhead, not the benefit. The reason we use OO is not because it's more efficient. It's because it's a good way of building robust, reliable and testable code. This will be your 'pitch' for adopting Moose. I would suggest you look to the various forms of testing, and prepared a demo of a test suite, because these are the things that most coders hate :)