Beefy Boxes and Bandwidth Generously Provided by pair Networks
P is for Practical

Re^4: Perl archeology: Need help in refactoring of old Perl code that does not use strict (hurry up and wait)

by likbez (Acolyte)
on Nov 15, 2017 at 04:38 UTC ( #1203446=note: print w/replies, xml ) Need Help??

in reply to Re^3: Perl archeology: Need help in refactoring of old Perl code that does not use strict (hurry up and wait)
in thread Perl archeology: Need help in refactoring of old Perl code that does not use strict

Python? Really? Do you mean Ruby?
IMHO in large enterprise environment Ruby is almost not visible. At the same time Python is gaining ground as universities both in the USA and Europe now teach Python in intoductory classes and people come "knowing some Python". That's alone is a huge factor. Python is also now installed on all Linux distributions by default (like Perl) and there are some system programs written in Python (yum, Anaconda, etc) which implicitly suggest that Python has Red Hat mark of adoption too.

To say nothing about the list of IDE available. Perl does not even ship with the "Standard IDE" although Padre, which is somewhat competitive with Komodo is available for free, but the latest binary distribution suitable for beginners is from 2012. This IMHO is highly detrimental to the language adoption. My feeling is that for Perl to remain competitive IDE should be maintained and shipped along with Perl interpreter. May be at the expense of some esoteric modules included.

Also compare number of books per year devoted to Python and available via Amazon for 2017 with the number of books devoted to Perl for the same period(quality issues aside). All this creates a real pressure to use Python everywhere, the pressure that I as a person who uses Perl (and will continue to use it, as I prefer Perl to Python) feel.

In other words "It's like deja-vu, all over again": looks to me like "Java story" on new level (and with a better language then Java).

Even in such "Perlish" domain as bioinformatics/genome decoding, Python gradually gains ground at the expense of Perl. The same is true in some "numeric computations" domains (via Numpy). There might be other factors at play as well. That's sad, because IMHO Perl is a great scripting language which can be used on many different levels, starting from AWK/SED replacement tool.

The list of references to related Perl Monk posts is really helpful. Thanks a lot !

Especially the first one Strategies for maintenance of horrible code? by converter (Jul 12, 2006). It contains several additional useful references posted by eyepopslikeamosquito

I would also add Analyzing large Perl code base. by Dmitry (Apr 14, 2005). Among others it contains the following post:

Re: Analyzing large Perl code base. 
by dave0 on Apr 15, 2005 at 15:32 UTC  
Having recently done this on a fairly large codebase that grew organically (no design, no refactoring) over the course of four years, I feel your pain.

Writing a testsuite, on any level, is nearly essential for this. If you're rewriting an existing module, you'll need to ensure it's compatible with the old one, and the only sane way to do that is to test. If the old code is monolithic, it might be difficult to test individual units, but don't let that stop you from testing at a higher level.

B::Xref helped me make sense of the interactions in the old codebase. I didn't bother with any visualization tools or graph-creation, though. I just took the output of perl -MO=Xref filename for each file, removed some of the cruft with a text editor, ran it through mpage -4 to print, and spent a day with coffee and pencil, figuring out how things worked. <p. Pretty much the same tactic was used on the actual code. Print it out, annotate it away from the computer, and then sit down with the notes to implement the refactoring. If your codebase is huge (mine was about 4-5k lines in several .pl and .pm files, and was still manageable) you might not want to do this, though.

In any case, attempts to create a relevant to this topic list of Permonks threads is a more constructive approach then yet another semi-religious discussion about proper use of OO in Perl. Your mileage may vary.
  • Comment on Re^4: Perl archeology: Need help in refactoring of old Perl code that does not use strict (hurry up and wait)

Replies are listed 'Best First'.
Re^5: Perl archeology: Need help in refactoring of old Perl code that does not use strict (hurry up and wait)
by eyepopslikeamosquito (Chancellor) on Nov 15, 2017 at 06:07 UTC

    To clarify my original surprise that you mentioned Python, I was not disputing that Python is gaining ground, I was challenging you on your reason, namely "OO (inspired by the desire to compete with Python)" because I found it hard to believe that Perl's OO enhancements were in any way inspired by Python's (rather pedestrian and uninspirational) OO features! Far more plausible to me, was for Perl to seek OO inspiration from a stronger OO language, such as Ruby or Smalltalk or CLOS, rather than pragmatic Python. Do you have any citations to support your claim?

    From the Moose manual in the "Justification" section:

    For Moose, we have "borrowed" features from Perl 6, CLOS (LISP), Smalltalk, Java, BETA, OCaml, Ruby and more, and the bits we didn't like (cause they sucked) we tossed aside. So for this reason (and a few others) Stevan has re-dubbed Moose a postmodern object system.
    An academic paper Super and Inner - Together at Last is also cited. No mention of Python. Similarly, in Class::MOP (SEE ALSO section), The Art of the Meta Object Protocol (CLOS), Smalltalk, and many other influences are given. Again, no mention of Python.

    Finally, in the original Apocalypse 12, Larry explicitly gave only one reference, namely "Traits: Composable Units of Behavior. European Conference on Object-Oriented Programming (ECOOP), July 2003. Springer LNCS 2743, Ed. Luca Cardelli. by Nathanael Schärli, Stéphane Ducasse, Oscar Nierstrasz and Andrew Black". The only mention of Python is this Larry quote: "Python's attributes suffer from the same misdesign as Perl 5's attributes. (My fault for copying Python's object model. :-)"

    In summary then, I'm not aware of any significant Python influence on Perl OO or Moose design. If anyone knows different, please let us know.

        Yes, you're right, Python was a significant influence on the early Perl 5 object system in the 1990s. And passing 'self' as the first parameter to access object state still endures today.

        My original gut reaction to the claim that Moose is "Perl trying to keep up with Python in the OO domain" still stands; that is, Python's OO system hasn't been the inspiration for enhancing Perl's OO capabilities since around the year 2000 or so.

        Thanks for the link. Though (for some definition of object) everything is an object in Python, it's not a pure OO language, rather it's a pragmatic multi-paradigm language. Like Perl.

        IMHO, Perl and Python remain similar pragmatic, multi-paradigm languages, the main point of (philosophical) difference being Perl's TMTOWTDI ("There's more than one way to do it"), or the more recent TimToadyBicarbonate ("There's more than one way to do it, but sometimes consistency is not a bad thing either"), versus Python's TOOWTDI ("There should be one -- and preferably only one -- obvious way to do it").

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1203446]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others chilling in the Monastery: (6)
As of 2019-11-14 11:23 GMT
Find Nodes?
    Voting Booth?
    Strict and warnings: which comes first?

    Results (77 votes). Check out past polls.