Hacker News Reader

Comment by lawnchair_larry | Hacker News Reader

In fact, I think if anything Perl would speed up the time it'll take to train a dev and get him/her to have an impact on the product from day one due to how easy is it to learn.

Which will be negated by how hard real-world perl code is to read and maintain.

View on HN

There's a school of writing "modern" Perl, using source filters and object systems. Bare Perl is a mess but, in somewhat of a Lispy way, you can use Perl to rewrite your Perl. If none of your functions have signatures and you're manually blessing objects, your codebase will quickly turn to shit. Using a standard bits (such as Moose) to give you a consistent object system and method call syntax changes things dramatically.

This is a new fad and it undoubtedly leads to more maintainable code, but it still feels like a bad tradeoff to me: you get the verbosity of stricter languages without the benefit (compile-time errors) at worse performance than plain Perl. I'd rather write something new in Scala or Go nowdays than in strict "modern Perl" style / Moose (and I've used Perl almost exclusively for the past 13 years).

umm, verbosity?

  package Point;
  use Moose; # automatically turns on strict and warnings
  has 'x' => (is => 'rw', isa => 'Int');
  has 'y' => (is => 'rw', isa => 'Int');
  sub clear { my $self = shift; $self->$_(0) for qw/x y/}

Verbosity.

    class Point {
        has Int $.x is rw;
        has Int $.y is rw;
        method clear() { $.x = 0; $.y = 0; }
    }

Perl 5.18 may have the following:

  use mop;
  class Point {
    has $x = 0;
    has $y = 0;
    method clear { ($x, $y) = (0, 0) }
  }

ref: https://github.com/stevan/p5-mop/blob/master/t/000-examples/...

Looks like a noble attempt to remove perl5 and ruby pain in the arse points simultaneously. Wonder if it will ever come to anything ...?

Perl 6 is / will be sweet :)

Perl 6 is sweet, and will be sweeter when it has better performance. :)

Source filters? Hahahahaha. The only acceptable source filter to use is Smart::Comments - https://metacpan.org/module/Smart::Comments - and even then, if you fire up code using Smart::Comments in the interactive debugger it's going to be a pain in the arse.

Moo/Moose (and Mo and Mouse if you must) are on the other hand game changers.

I definitely recommend reading "Modern Perl". It is a game changer.

http://www.onyxneon.com/books/modern_perl/index.html

Developers that write unmaintainable and unreadable code exist. This has nothing to do with the language. That's where "Good Developers" come in.

You don't even need to know how to write code to understand the code written at Crowdtilt or any other company that really uses Modern Perl and have good practices.

Yeah, but the language helps a lot on that. And so, it is related to the language.

Comparing the readability of python vs perl/c-like languages show it clearly. In python the readability come as a natural idiom, it is part of their zen!.

I found that when I develop in python/delphi/pascal the code is readable by default, but in ANY c-derived language could become messy fast. Something as simply as how align a IF clause. In C-like language I could go wild (and I see a LOT of code that look different, from person to person) and in contrast I read almost any python code as if I was write by myself.

In python the readability come as a natural idiom, it is part of their zen!

Superficial readability, perhaps.

Neither PEP 8 nor PEP 20 get into interesting questions about maintainability like:

    * How long should individual compilation units be?
    * How do I factor my code?
    * What metaphors do I use to name components?
    * How do I know when to break apart components?
    * How do I know when to merge components?
    * How do I write effective documentation?
    * Is this API easy to use?
    * Have I sufficiently encapsulated this component?
    * How easy is this code to test?
    * Does this code match local style?
    * Does this code follow the idioms and express the necessary elements of the problem domain effectively?
    * Is it easy to misuse this API?
    * Have I made too much information public?
    * Have I made too little information public?
    * Does this code make potential bugs screechingly obvious?
    * Do I handle potential error conditions sensibly and completely?
    * How much work do I face enhancing this code in the future?

PEP 8 concerns itself with far less interesting things, like why vertical alignment is annoying. In my experience, that's one of the least substantial elements contributing to maintainability.

As for readability, it doesn't really matter if someone who doesn't know the language can't read it.

You need good developers to tackle those interesting questions. There is no answer, because you can only rely on rule of thumb and you must know when to break the rule of thumb.

PEP 8, on the other hand, is to get these good developers to agree on the less interesting things, such that they can use it as a stepping stone to the more interesting ones. PEP 8 requires strict compliance, because if different developer ignore different portion of PEP 8, you end up with nothing.

In short, if you have long lines of code crammed together with no spacing, get them to look pretty based on PEP 8 first before we talk about how easy is this code to test.

I agree, but nothing in Python the language addresses any of my questions. Those concerns are so far beyond the language level that the language is irrelevant.

It's incredibly easy to write good Perl.

It's just easier to write bad Perl, and most Perl is set it and forget it in scope.

Reply on news.ycombinator.com