The real benefits of using Moo (se) over Perl OO

Question

I currently work for a company where we are developing Perl. However, the code is really messy, it uses really old Perl idioms, so I decided to gradually clear it and teach my employees about Modern :: Perl, good software design, OOP abstraction, binding, inheritance, SOLID principles, etc. I have the disadvantage that I have been working here for only a month, so I am completely new here.

My question is: can I (if so) convince them that you decided to switch to Moo (se) from a simple Perl OO? What are its advantages? I need really good reasons to consider them.

Is there a high cost using these modules? I know from experience that it is very convenient to use these modules (also the features are really good), but I'm afraid that they will refuse to switch due to performance reasons.

So. Is there an advantage and how would you describe it to the Perl developers who were stuck in until 2000?

Answer 1

I would start with a request - your colleagues appreciate what you mean by these conditions, and why are they good things? There is always a difficult task associated with adopting a new paradigm, because EVEN IF your “new way” is better in every way ... you will create an outdated code base that still needs to be supported. Or recycled.

Convincing someone to “go OO” if they built their understanding of Perl from bash scripts to crack perl ... may be a problem. They may, quite rightly, indicate that although there are advantages to switching, the “lowest common denominator” is applicable. There are many people who know non-moose perl compared to those who know moose. (This may be deemed to be in your favor, though - point him to a helpful technical specialist who improves their future employment opportunities).

After all, there is a reason that shell scripts are still in use today because they are a simple, simple, and affordable solution to an immediate problem.

So, first familiarize yourself with the principles of computer science. Ask your colleagues to “buy” what you draw. It will take time. Probably a lot of time. If the style of the code has not changed for 15 years, this means that the coders there are comfortable in how this happens.

Then you need to prove to your colleagues why “your path” is better for them to work hard to learn it. New “stuff” comes all the time, and there is always someone who wants to try a new and cool thing. You will be like this person. As for them, the current style of the house works great.

You may find that the realization of something new in your new style is compelling. Ask them to “buy” to do so as proof of concept. You can find several other coders, such as an idea.

But regardless - you must accept the very real possibility that no one wants to pay the technical debt of the "legacy" that you will create by doing this. There are many business benefits because a limited set of coding paradigms is used in your organization. You need to think about how to work as a maintenance.

This is not a new discussion, although in OO programming there have always been those who do not see the point - they see overhead, not benefit. The reason we use OO is not because it is more efficient. This is because it is a good way to build reliable, reliable, and verifiable code. This will be your "step" to accept Musa. I would suggest you look at the various forms of testing and prepare a demo version of the test suite, because this is what most programmers hate :)

Answer 2

For Moose specifically, there are interesting discussions of PerlMonks and fooobar.com/questions/466211 / ... performance . Its essence is that Much has a significant launch penalty, but not so much after that.

However, I think there is a bigger question here: When should you rewrite existing code?

When choosing a new tool / method, two different thresholds must be considered:

• The XYZ tool / method is useful, so we should use it when writing new code.
• The XYZ tool / method is so useful that we need to rewrite existing code to use it.

Many, many people made the mistake of rewriting a whole bunch of very good code, using their preferred paradigm when the existing paradigm was fine. This is not only this lost work, but also the danger of new errors, and the final product is worse than before.

Changing the system of objects used by the existing code base is close to fundamental rewriting of the code. This is a great cost and risk, and for this you need a very good reason. More than just "Moose is better at writing code."

When it comes time to write a new piece of code that is pretty separate from the old code, this may be the right time to try Moose. But I suspect that modifying all existing code is not really justified. (Also, in terms of actually attracting people to your ideas, small incremental changes will work much better).