"As far as I know, Perl is one of the only languages that can evolve via 3rd party modules." Ummm... What?! There's a long tradition creating DSLs in the Ruby community. Lisp/Scheme/Clojure have macros. OCaml has campl4. I'm sure there are many others.
Why Did I Choose Perl When Building Crowdtilt?
41–50 of 143 posts
Re: Why Did I Choose Perl When Building Crowdtilt?
#42The one thing I've learned as a consultant working outside the startup world, in the boring world of everyday business is just how much of the computerized world still runs on perl. I've seen some fantastically made systems and some real stinkers. In the HN echo chamber, it seems like everyone who's anyone has moved on to ruby, rails, python, django, etc. Look into the every-web. My god, it's full of perl.
I agree. It is a misconception that Perl is "dying". It powers a lot of the web. It had a bad rep a few years ago due to cryptic-looking codes that were written as a throw away code and somehow spread all over the web :). I was one of the skeptical developers at some point, but then I got hooked :). Modern Perl changes the old rep alltogether. I encourage people to write well architected, maintainable, extensible cod…
Re: Why Did I Choose Perl When Building Crowdtilt?
#43Re: Why Did I Choose Perl When Building Crowdtilt?
#44Earlier quoted context omitted.
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 dramatic…
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).
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;Re: Why Did I Choose Perl When Building Crowdtilt?
#45Earlier quoted context omitted.
I agree. It is a misconception that Perl is "dying". It powers a lot of the web. It had a bad rep a few years ago due to cryptic-looking codes that were written as a throw away code and somehow spread all over the web :). I was one of the skeptical developers at some point, but then I got hooked :). Modern Perl changes the old rep alltogether. I encourage people to write well architected, maintainable, extensible cod…
Regardless of the structure of modern usage its syntax is still very noisy for the reader. It seems the majority prefer the cleaner syntax that doesn't use punctuation to define the type of access a la BASIC.
Re: Why Did I Choose Perl When Building Crowdtilt?
#46That said: The do what I mean paragraph kind of reminded me of the Stripe CTF. One of the levels (5?) was vulnerable to pass parameters to a POST handler via query string. In other words: In level 5 in that CTF, if you followed one possible solution, you abused this flexibility.
So .. maybe it's not always a good thing? Including this particular reference in the article?
Re: Why Did I Choose Perl When Building Crowdtilt?
#47Earlier quoted context omitted.
I agree. It is a misconception that Perl is "dying". It powers a lot of the web. It had a bad rep a few years ago due to cryptic-looking codes that were written as a throw away code and somehow spread all over the web :). I was one of the skeptical developers at some point, but then I got hooked :). Modern Perl changes the old rep alltogether. I encourage people to write well architected, maintainable, extensible cod…
Regardless of the structure of modern usage its syntax is still very noisy for the reader. It seems the majority prefer the cleaner syntax that doesn't use punctuation to define the type of access a la BASIC.
Re: Why Did I Choose Perl When Building Crowdtilt?
#48I see these justifications for perl almost every time it comes up - The community, cpan, writing lots of code fast. These are good things, but it's worth pointing out that EVERY OTHER LANGUAGE DOES THAT. Ruby has gem, python has pip - modern languages have these things built in by design. Not to hate on perl, because there's things I like about it, but this article could be retitled "what I like about not using fortr…
Edit to add: I know why this sounded familiar! I had forgotten I wrote about it recently:
http://www.modernperlbooks.com/mt/2012/08/why-i-use-perl-tes...
Re: Why Did I Choose Perl When Building Crowdtilt?
#49I see these justifications for perl almost every time it comes up - The community, cpan, writing lots of code fast. These are good things, but it's worth pointing out that EVERY OTHER LANGUAGE DOES THAT. Ruby has gem, python has pip - modern languages have these things built in by design. Not to hate on perl, because there's things I like about it, but this article could be retitled "what I like about not using fortr…
Re: Why Did I Choose Perl When Building Crowdtilt?
#50I learned perl in the past (I'd rate myself as ~somewhat proficient~, ignoring 'new style perl'), and I like the language. That puts me in a strange place when I talk to friends: I don't know ruby nor python, but do think that perl's a nice language. A strange position to be in, by now. That said: The do what I mean paragraph kind of reminded me of the Stripe CTF. One of the levels (5?) was vulnerable to pass paramet…
Thanks for the feedback :).