Login/Register
Real advantages of using Moo(se) over Perl OO
Asked Answered
Solved perlmoosemoo
S

2

6

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?

Sentimentalize answered 5/3, 2015 at 12:1 Comment(3)
Coupling is hardly a good software design principle (did you actually mean decoupling?). Inheritance may be as far as you don't abuse it. – Fescue
Well obviously high coupling is bad, but they don't know the concept of coupling, they don't realize them and they are abusing global state and passing around references to subroutines, scalars, hashes all over the place. Ofc the way to go with coupling is down :) – Sentimentalize
That's really your first port of call - don't talk about the "sexy new module" you like. Talk about how these principles are well established as ways of making better code. And by 'better code' you mean 'less annoying for your fellow developers to debug'. (Go for the selfish reasons first). And then off possible approaches to doing this. Include Moose, but offer others. Suggest a couple of pilot schemes and an evaluation period. You may find the answer is Moose, you may find it's something else. But either way - progress is made. – Carolanncarole
C
4

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 :)

Carolanncarole answered 5/3, 2015 at 12:52 Comment(0)
P
9

For Moose specifically, there are some interesting discussions of performance on PerlMonks and Stackoverflow. The gist of it seems to be that Moose has a significant startup penalty, but not much after that.

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

There are two different thresholds to consider when choosing a new tool/method:

  1. Tool/method XYZ is beneficial , so we should use it when writing new code.
  2. Tool/method XYZ is so beneficial that we must rewrite existing code to use it.

Many, many people have made the mistake of rewriting a whole bunch of perfectly good code using their preferred paradigm, when the existing paradigm was just fine. Not only is this wasted work, it has the danger of introducing new bugs and making the final product worse than it was before.

Changing the object system that an existing code base uses is close to a fundamental rewrite of the code. This is a major cost and risk, and you need a very good reason to do that. More than just "Moose is nicer to write code in".

When it comes time to write a new piece of code that is fairly separate from legacy code, that might be a good time to try Moose. But I suspect that changing all the existing code is not really justifiable. (Also, from the perspective of actually getting people to listen to your ideas, small incremental changes will work much better, anyway).

Passkey answered 5/3, 2015 at 12:43 Comment(2)
I agree with the part about rewriting. However I am writing a new piece of functionality (new code) right now, and I would like to use those modules there. – Sentimentalize
@Davs, sorry if the answer was a bit misdirected, then. I suppose I misunderstood the part about "cleaning up" the code to apply to switching to Moose. – Passkey
C
4

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 :)

Carolanncarole answered 5/3, 2015 at 12:52 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.