4 ms·

It is a very good question and I had to think really hard about it in the early days. My take on it is that I appreciate good developers regardless of the lang

It is a very good question and I had to think really hard about it in the early days. My take on it is that I appreciate good developers regardless of the language of choice and those are the stars that we want to have at Crowdtilt. Good developers will usually learn any "needed" tools in a matter of hours. 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.

lawnchair_larry 14y ago
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.
- knighthacker 14y ago
  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.
  - mamcx 14y ago
    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.
    - chromatic 14y ago
      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.
      - j-kidd 14y ago
        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.
        chromatic 14y ago
        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.
- debacle 14y ago
  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.
- juan_juarez 14y ago
  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.
  - knighthacker 14y ago
    +1 I definitely recommend reading "Modern Perl". It is a game changer. http://www.onyxneon.com/books/modern_perl/index.html http://www.onyxneon.com/books/modern_perl/index.html
  - lazyjones 14y ago
    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).
    - singingfish 14y ago
      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/} 1;
      - colomon 14y ago
        Verbosity. class Point { has Int $.x is rw; has Int $.y is rw; method clear() { $.x = 0; $.y = 0; } } :)
        dkoch 14y ago

lawnchair_larry 14y ago

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.

knighthacker 14y ago
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.
- mamcx 14y ago
  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.
  - chromatic 14y ago
    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.
    - j-kidd 14y ago
      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.
      - chromatic 14y ago
        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.
debacle 14y ago
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.
juan_juarez 14y ago
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.
- knighthacker 14y ago
  +1 I definitely recommend reading "Modern Perl". It is a game changer. http://www.onyxneon.com/books/modern_perl/index.html http://www.onyxneon.com/books/modern_perl/index.html
- lazyjones 14y ago
  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).
  - singingfish 14y ago
    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/} 1;
    - colomon 14y ago
      Verbosity. class Point { has Int $.x is rw; has Int $.y is rw; method clear() { $.x = 0; $.y = 0; } } :)
      - dkoch 14y ago