Live data from Hacker News

Why Did I Choose Perl When Building Crowdtilt?

dsog.info

71–80 of 143 posts

Re: Why Did I Choose Perl When Building Crowdtilt?

#71

Earlier quoted context omitted.

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/} 1;

Verbosity.

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

Re: Why Did I Choose Perl When Building Crowdtilt?

#72
post #52
post #38

I 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…

>> EVERY OTHER LANGUAGE DOES THAT Do you really know about this? I've done a bit of Python lately. The infrastructure isn't close (see e.g. Perl Testers, chromatic had a blog post about it quite recently). Also, CPAN is much richer than pypi.

Which modules are missing on Pypi?

Re: Why Did I Choose Perl When Building Crowdtilt?

#73
Perl is a really great language at getting things done today. Its failing (and the thing that makes a "mem" perl developer and a star developer) is what happens six months to a year after you complete a feature.

If you are willing to have some discipline up front (and the expense of some amount of velocity), it can save your bacon later.

Re: Why Did I Choose Perl When Building Crowdtilt?

#74
post #72
post #52

Earlier quoted context omitted.

>> EVERY OTHER LANGUAGE DOES THAT Do you really know about this? I've done a bit of Python lately. The infrastructure isn't close (see e.g. Perl Testers, chromatic had a blog post about it quite recently). Also, CPAN is much richer than pypi.

Which modules are missing on Pypi?

Off the top of my head -- a serious sql parser and the whole TAP test ecosystem. After a while I stopped checking cpan for what I needed, since I just got angry.

Another difference: In the Perl world, you can find and have dependency trees with dozens to hundreds of modules installed from cpan -- and you expect it to work, particularly since the module tests by default are run at install. (It is a bit painful with too many dependencies, but it works if you need it.)

Re: Why Did I Choose Perl When Building Crowdtilt?

#77
post #31

Earlier quoted context omitted.

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 cla…

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 w…

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.

Re: Why Did I Choose Perl When Building Crowdtilt?

#78
post #74
post #72

Earlier quoted context omitted.

Which modules are missing on Pypi?

Off the top of my head -- a serious sql parser and the whole TAP test ecosystem. After a while I stopped checking cpan for what I needed, since I just got angry. Another difference: In the Perl world, you can find and have dependency trees with dozens to hundreds of modules installed from cpan -- and you expect it to work, particularly since the module tests by default are run at install. (It is a bit painful with to…

I think there are many cases where packages may not be in one language repo, but in another. However, Python does have a lot of testing packages available that do a swell job. Also, the JUnit test-report format these days tends to be what I see a lot of.

http://wiki.python.org/moin/PythonTestingToolsTaxonomy

Also, as far as SQL, and even Object Relational Mappers goes, there's SQL Alchemy.

You can verify they are present here, in PyPi: http://pypi.python.org/pypi

Re: Why Did I Choose Perl When Building Crowdtilt?

#79
post #72
post #52

Earlier quoted context omitted.

>> EVERY OTHER LANGUAGE DOES THAT Do you really know about this? I've done a bit of Python lately. The infrastructure isn't close (see e.g. Perl Testers, chromatic had a blog post about it quite recently). Also, CPAN is much richer than pypi.

Which modules are missing on Pypi?

It's not the modules - it's the infrastructure of the CPAN environment.

See this comment on an old Perl thread for some pointers

http://news.ycombinator.com/item?id=4042344

Re: Why Did I Choose Perl When Building Crowdtilt?

#80
post #40

Earlier quoted context omitted.

Those are both excellent examples. One modifies the core language syntax to allow for writing tests in a cleaner and easier way. The other one modifies the language to make writing OO code in a new way, one that will be familiar to Java developers. I don't know of very many languages that allow developers to modify the core language via 3rd party modules. That's why Perl will never die - it will simply evolve as the…

As has been alluded to in another comment: Which other languages that compare to perl have you actually looked at? Python has rich meta-programming. Ruby has (almost) single-handedly super-hyped and re-invented the idea of domain specific languages (DSLs). Lisp is of course all about this (as is Forth). Javascript builds on the ideas from Smalltalk and (especially) Self to allow you to crazy stuff with how objects wo…

"As has been alluded to in another comment: Which other languages that compare to perl have you actually looked at?"

I am very familiar with all of the languages that you mention. They are all great languages in their own right. My comment however was about Perl's ability to easily evolve the core language via contributions from its community, as opposed to other languages that require a lenghty process performed by the core maintainers of the language. This allows Perl to evolve at a much faster pace than other languages. A lot of your points do not seem relevant in that context.

"Python has rich meta-programming."

Who cares? So do most modern languages.

"Ruby has (almost) single-handedly super-hyped and re-invented the idea of domain specific languages (DSLs)."

The Perl community has been writing DSL's since before most people had heard of Ruby. Real DSL's. Not just invoking functions without parens and labeling it a DSL, as is often done in the Ruby community. Ruby in no way invented or re-invented anything having to do with DSL's.

"Lisp is of course all about this (as is Forth)."

Agreed. Lisp macros are very powerful. Lisp is a great example of a language that can do this.

"I'm very much on the burnt-by-crazy-old-nasty-perl-legacy-crap side of the fence -- but I can't deny that I see some of the reasons why people would like to use perl -- it's just not for me."

This is a common complaint. People have had to deal with Perl code that they do not understand. It may have been poorly written, or it may have been perfectly written Perl code. If you do not take the time to learn Perl, you would not know the difference. The most common reaction is to blame the language.

"Still -- it's a bit strange to see the claim that perl is somehow much more flexible than other comparable languages."

It may be strange to you because you are not very familiar with Perl.

Post reply on HN