Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Did I Choose Perl When Building Crowdtilt?

dsog.info

Post reply on HN
Print view View original

21–30 of 143 posts

Re: Why Did I Choose Perl When Building Crowdtilt?

#21

Post by Protostome »

I've had some experience with perl. While it has a lot of advantages (most of them are described in your post) it clumsily support OOP and is very hard to maintain. It's true that perl gets you going pretty fast, But once your code base reaches several hundred classes, you'll really regret ever considering it for production.

As a grad student I found myself using it quite a lot for writing quick and dirty scripts for data manipulation until I finally decided to move to python. Since then, I never look back :-)

Re: Why Did I Choose Perl When Building Crowdtilt?

#22

Post by ionforce »

Protostome wrote: post #21

I've had some experience with perl. While it has a lot of advantages (most of them are described in your post) it clumsily support OOP and is very hard to maintain. It's true that perl gets you going pretty fast, But once your code base reaches several hundred classes, you'll really regret ever considering it for production. As a grad student I found myself using it quite a lot for writing quick and dirty scripts for…

Isn't the maintainability of the code a function of who wrote it?

Re: Why Did I Choose Perl When Building Crowdtilt?

#23

Post by lazyjones »

ujeezy wrote: post #2

How do you find hiring? A Blekko founder said they chose Perl partly because as one of the few hot startups to be using Perl, it would make them a top choice for great Perl hackers.

That's funny, because most of the "hot" startups are choosing/using languages that they can actually find developers for. If great Perl hackers were easy to find, more startups would use Perl.

Re: Why Did I Choose Perl When Building Crowdtilt?

#24

Post by lazyjones »

juan_juarez wrote: post #19
lawnchair_larry wrote: post #7

Earlier quoted context omitted.

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.

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).

Re: Why Did I Choose Perl When Building Crowdtilt?

#25

Post by sbochins »

ionforce wrote: post #22
Protostome wrote: post #21

I've had some experience with perl. While it has a lot of advantages (most of them are described in your post) it clumsily support OOP and is very hard to maintain. It's true that perl gets you going pretty fast, But once your code base reaches several hundred classes, you'll really regret ever considering it for production. As a grad student I found myself using it quite a lot for writing quick and dirty scripts for…

Isn't the maintainability of the code a function of who wrote it?

That is one aspect, but not the only one. When you start to write complex software you realize that the language, frameworks, libraries, design patterns, etc impact the maintainability of your code.

Re: Why Did I Choose Perl When Building Crowdtilt?

#26

Post by MetaCosm »

Protostome wrote: post #21

I've had some experience with perl. While it has a lot of advantages (most of them are described in your post) it clumsily support OOP and is very hard to maintain. It's true that perl gets you going pretty fast, But once your code base reaches several hundred classes, you'll really regret ever considering it for production. As a grad student I found myself using it quite a lot for writing quick and dirty scripts for…

Checkout Moose -- it is one of the thing the author points to about Perl. Tools like Moose do an amazing job of fixing the warts but keeping the power.

Moose's support and flexibility as an OOP layer is second to very few.

http://moose.iinteractive.com/

Re: Why Did I Choose Perl When Building Crowdtilt?

#27

Post by singingfish »

juan_juarez wrote: post #19
lawnchair_larry wrote: post #7

Earlier quoted context omitted.

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.

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…

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.

Re: Why Did I Choose Perl When Building Crowdtilt?

#28

Post by 16s »

noonespecial wrote: post #3

The 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.

Very true! It seems fashionable to make fun of Perl and C++, but in the real world, they are everywhere, doing everything and they work extremely well.

Re: Why Did I Choose Perl When Building Crowdtilt?

#29

Post by ironcamel »

knighthacker wrote: post #17
eblume wrote: post #14

I personally don't like the 'flavor' of most Perl that I've seen or written - and it was my first programming language - but it's obvious that it remains one of the most relevant languages in terms of shipped code. That being said, I don't feel that any of the reasons given in this post are in any way leading to the conclusion 'Use Perl'. In fact I think all of those points apply to just about every major high-level…

Indeed :). Checkout these modules: Test::Class::Sugar MooseX::Declare Thank you for your feedback.

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 needs of programmers change. Hey, Smalltalk Roles are a nice idea ... ok we'll add those (Moose::Role). Hmmm, lets allow method signatures to declare types for their params ... sure no problem (MooseX::Method::Signatures). Wouldn't it be cool if we could treat arrays as objects and invoke methods on them? Sure, here you go (autobox::Core).

Re: Why Did I Choose Perl When Building Crowdtilt?

#30

Post by singingfish »

I've been playing around with perl over the last 10 years, and over the last 4 years or so doing perl professionally.

Because I'm in the job market at the moment I figured I'd take a closer look at Python and Ruby, so I'm concurrently reading two python/ruby books. To be honest, I don't see much in it. If I were to chose one I think I'd have to go with python, because Ruby looks to me, just like perl but with a different set of weird symbols to remember, and a slightly different set of downsides.

Python on the other hand looks like a sufficiently different take on the dynamic language problem, so as to be more interesting.

PHP I'm not bothering with right now. It's just like perl only with most, if not all of the design intelligence removed.

Post reply on HN