Live data from Hacker News

Why Did I Choose Perl When Building Crowdtilt?

dsog.info

31–40 of 143 posts

Re: Why Did I Choose Perl When Building Crowdtilt?

#31

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.

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.

Re: Why Did I Choose Perl When Building Crowdtilt?

#32
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.

That's a chicken and egg problem though, especially in a place as driven by fashion as the technology startup scene in Silicon Valley. Training a decent developer to be effective with Perl is fairly easy (use my free book on the subject!).

Getting attention because you didn't use Node or Clojure or Erlang or Ruby or Python or Java is trickier.

(I've been at this long enough to remember hearing from VCs "Your product has a Perl backend and a Python frontend? Oh... would you consider rewriting it all in Java? Java has more buzz.")

Re: Why Did I Choose Perl When Building Crowdtilt?

#33

Earlier quoted context omitted.

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.

That's a chicken and egg problem though, especially in a place as driven by fashion as the technology startup scene in Silicon Valley. Training a decent developer to be effective with Perl is fairly easy (use my free book on the subject!). Getting attention because you didn't use Node or Clojure or Erlang or Ruby or Python or Java is trickier. (I've been at this long enough to remember hearing from VCs "Your product…

I second the reference to the book. It is a must read for all new devs at Crowdtilt. Excellent book @chromatic.

Re: Why Did I Choose Perl When Building Crowdtilt?

#35
post #31

Earlier quoted context omitted.

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

Re: Why Did I Choose Perl When Building Crowdtilt?

#36
post #28

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.

Workhorses are never fashionable.

Re: Why Did I Choose Perl When Building Crowdtilt?

#37
post #28

Earlier quoted context omitted.

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.

Workhorses are never fashionable.

"There are only two kinds of languages: the ones people complain about and the ones nobody uses"

- Bjarne Stroustrup

Re: Why Did I Choose Perl When Building Crowdtilt?

#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 fortran"

Re: Why Did I Choose Perl When Building Crowdtilt?

#39

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

Not the same thing. DSLs are not the same as extending the functionality of the interpreter. And it's basically the flexibility of perl as a procedural/functional/declarative/OO language (i.e. lack of assumptions of how you want to work) with its roots in practical natural linguistics (as opposed to theoretical as with lisp) that makes this possible. Yes, that does mean coding with some discipline (Perl::Critic and Moose & friends helps here), and some things are more of a pain in the arse than with a more opinionated language, but it seems a reasonable trade off to me.

Re: Why Did I Choose Perl When Building Crowdtilt?

#40

Earlier quoted context omitted.

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…

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

Java can't do much of this, but the JVM has been bent in surprising ways by efforts like Clojure and Scala...

While it is great that you know and like perl -- That particular point in the post (and this comment) seems rather poorly researched.

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. The statement "Perl evolves in a ... manner that makes the language always fresh" makes me want to hide under the bed -- if I have to deal with someone else's code in production ;-)

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

Post reply on HN