
Perl Startups: Lacuna Expanse - szabgab
http://blogs.perl.org/users/ovid/2013/07/perl-startups-lacuna-expanse.html
======
kriro
I think "I just like it" or "it feels right to use it" should be enough
explanation.

There's a tendency for people to demand a rational list of reasons for any
choice (very academic thinking) but more often than not that results in tacked
on reasoning anyways...oh sure I use it because of X,Y,Z while in reality we
just picked it because it "seemed cool"

I think people are too scared to regret their choices. Just picking something
and "muddling through" tends to be pretty awesome. Sometimes you'll just find
out it won't click and then you can pick something else (you should find out
pretty quickly because it just won't feel right)

Instead there's often a tendency to read "haha IF ONLY YOU HAD THOUGHT ABOUT
THIS BEFORE...FOOL" responses instead of "cool that you jumped into the pool,
I hope you learned a lot"

/rambling and ranting

~~~
smoyer
And he can then be countered by those who just hate Perl ... I'm getting tired
of language rants (either pro or con) but my overall impression is that he's
pretty close-minded.

~~~
lazyloop
All language zealots are close-minded by definition.

------
pachydermic
I really don't like the hate for perl. Sure, it's got some stuff which can be
a bit difficult to understand at first, but that flexibility is nice when you
just want to whip something up quickly. It reminds me of how people love to
hate Java because of it's verbose code (myself included). At the end of the
day, if you know what you're doing it really doesn't get in your way.

I do a lot of metaprogramming and text processing at my job. Using regex as
much as I need to in most other languages just feels clumsy compared to perl.
It's a great language for sysadmin type stuff. It has a good niche. I wouldn't
use it for what this guy did, but I have no doubt that tons of stuff in CPAN
probably made his job significantly easier.

I don't think perl is hard to learn - I spent a few days with the camel book
and was able to pick it up fairly quickly - and as others have said any
language can be unreadable or abused. Also, I don't use Moose or objects in
perl and I think that OOP can be cool but can also be abused just as much as
perl's nonstandard syntax.

When it comes to other types of projects, I don't think your language of
choice makes a huge difference in theory. I think javascript, perl, python are
all pretty good and not too hard to pick up if you already have programming
experience (don't know about ruby, although I assume that the same holds
true). What really makes a difference in practice is the network effects,
though. I really love perl, but I'm going to go out of my way to learn other
languages because no one respects it and the job market isn't as good for it.
Oh well. I don't really mind having to choose based on fads because I honestly
think that my choice of programming languages won't make much of a difference
on my performance.

~~~
smoyer
Sounds like you have the right tool for the job. I'd be curious to know if you
use Perl for large projects with long lifetimes (and if so, strategies for
doing so effectively).

~~~
tene
PerlCritic for coding standards tests was very helpful for the projects I've
adopted it on.

------
asperous
>Ruby - Now that Perl has Dancer/Plack/Moose, Ruby has nothing that Perl
doesn't have (at least that I've seen). Therefore no reason to switch.

>Python - Basically the same argument as Ruby, except that in my opinion
Python isn't half as good of a language as Ruby.

IMO he kinda missed the main ideological differences, benefits, pros, cons of
both ruby and python.

~~~
areski
I don't have the feeling he did a serious analysis of any of languages, he
sounds that he wants to work with what he knows.

I was very excited to see a startup using PERL but it's a pity the article
fall into a languages war.

~~~
e3pi
Totally agree. HN comments rarely stay on page.

The online front-end is awesome. I've never seen anything like it in CPAN,
though I've never really looked for intense GUI. This is the first online game
I'm motivated to pick at, hoping to see where the perl CGI spins.

Looking up `lacuna', the single example of usage quote:

"self-centered in opinion, with curious lacunae of astounding ignorance"

seems keenly apt for most of us, I myself have over-focused for so long now on
emacs, perl, that it would be foolish for me to voice an opinion on other
contemporary languages, or my `problem with vi'.

------
Mikeb85
We need posts like this for every language. Nowadays, thanks to the open-
source culture, the ease of sharing and installing libraries, you can do just
about anything with any language.

You can run a start-up on Python, Ruby, Java, Scala, C#, Haskell, OCaml,
Clojure, Common Lisp, C++, etc... Programmer familiarity with language
semantics and tools is likely going to make a bigger difference than the
language itself.

Google runs on Python/Java/C++, Facebook runs on PHP/C++, Twitter on
Scala/Ruby, and a number of large sites run on all sorts of other crazy
languages.

Hearing about the pros of Perl from a Perl programmer is nice, even though I'm
not particularly fond of Perl. I'm personally building apps in Clojure,
because I like Lisps, Clojure has great features and a great environment, and
it just suits the way I like to think about problems. I think it's the best
language ever, but I also understand why people would think the same about
Ruby, Python, Scala, JS, etc...

I think some people make too much out of posts like this, yes he thinks Perl
is the best language, and it probably is for him. At the very least, he gives
compelling reasons for Perl programmers to continue in Perl, and not feel like
they 'need' to switch to Python or Ruby...

------
noonespecial
I love his system of regularly evaluating other languages to see what
advantages they might offer him.

It just goes to show: Don't worry about using the "best language", just use
the best language _for you_.

~~~
ownagefool
Based on what he posted, either he's doing an extremely superficial comparison
or he's done a proper one and realised there is actually not a lot in it when
talking about modern languages.

Fair enough, he wants to continue to use Perl because it's familiar and there
aren't really massive advantages to using the other languages, that's a fair
point, but state that as opposed to having a tone that suggests Perl is a
better language than the others, or at least back that up with something
quantifiable.

On the other hand, Perl (when comparing php, python, ruby) would be last on my
list because it requires the most effort to learn and get familiar with the
syntax and I don't think the extra work required to learn Perl is worth the
effort, because again, I think you'll actually be alright with the modern
versions of all the languages.

~~~
chipotle_coyote
There _does_ seem to be a certain amount of truth to the "oh, you kids, we
were doing that in Perl ten years ago" attitude I occasionally run into. (Sort
of like Lispers, except they invented whatever cool feature you think is new
back in 1958.) But it's hard to justify switching from something else _to_
Perl, and indeed I think your rephrasing -- "it's familiar and there aren't
really massive advantages to using the other languages" \-- about sums this
up. (Largely why I've been using PHP for a current project, despite agreeing
with a lot of the criticisms people make of it.)

I'm not sure I can see explicitly choosing to _learn_ "modern" Perl to start a
new project in, though. Personally I prefer Python over Ruby, unlike the
author here, but I prefer both of them to Perl and its extremely... eclectic
syntax. I once failed a job interview because I joked that Perl was a read-
only language, but it really frequently is.

~~~
RussianCow
You mean write-only?

------
thomasjames
I feel like that, among Perl startups, DuckDuckGo is the elephant in the room
these days.

~~~
robotmay
Their introduction to Perl and documentation for it is really quite handy for
someone coming from another language. I wrote a plugin in Perl without any
previous knowledge of it and it only took an evening. And as it turns out I
quite like Perl now.

~~~
dmoney
I can't seem to find DuckDuckGo's intro to Perl.

~~~
sciurus
For a decent intro try Learn Perl in about 2 hours 30 minutes by Sam Hughes
[http://qntm.org/files/perl/perl.html](http://qntm.org/files/perl/perl.html)

(although unless you;re working with an established codebase, skip the section
on objects and read
[http://modernperlbooks.com/books/modern_perl/chapter_07.html...](http://modernperlbooks.com/books/modern_perl/chapter_07.html#toc_T2JqZWN0cw)
instead)

------
simula67
Perl is not going away any time soon. 1,20,000 packages[1] ( compared to Pypi
: 32621 [2] and Rubygems : 59,519 [3] )is nothing to scoff at.

[1] [http://www.cpan.org/](http://www.cpan.org/)

[2] [https://pypi.python.org/pypi](https://pypi.python.org/pypi)

[3] [http://rubygems.org/](http://rubygems.org/)

~~~
btilly
This is true, BUT there is a law of diminishing returns. The value of a large
library scales nonlinearly. The added packages are more likely to be unrelated
to whatever you are doing, and so become progressively less likely to be
useful.

That said a culture of testing all of the time makes the Perl packages less
likely to have serious conflicts. Which is a huge value proposition. (For the
Ruby fans who jump up to object, do you run unit tests by default every time
you go to install gems? Do you have people volunteering lots of machines with
different things installed for the purpose of running unit tests on everything
in Rubygems? No? Then you don't know what a "culture of testing all the time"
is.)

~~~
VLM
"The added packages are more likely to be unrelated to whatever you are doing,
and so become progressively less likely to be useful."

I've not found that to be a problem in actual development. It just gives the
search engine extra work with no impact on my productivity. For example, the
existence of "CNC::Cog" has no impact on me, although it gives the search
engine extra work when I search for "Astro::FITS".

The value of Perl to me, is if its computationally possible, there's probably
a module on CPAN to make it easier for me. Therefore its the easiest to use,
most powerful language, because I can do the most with the least effort, and
time is money. Shrinking CPAN would merely make me move to the currently
second most powerful language/library team. Donno, java or ruby or python or
something like that.

I do agree that in an academic setting, a homework assignment like "here's a
list of 10 random Perl modules, now make something interesting out of them"
would be painful. However, the programming equivalent of the "Chopped" TV
cooking show might be highly amusing for a youtube video series or some kind
of competitive multi-player startup game company.

------
seunosewa
"Python isn't half as good of a language as Ruby."

"C# isn't quite as good as Java"

Can anyone who truly believes these things be taken seriously, really?

~~~
Mikeb85
These sorts of things are subjective. I personally like Ruby at least twice as
much as Python. Since Ruby is far more Perl-like than Python, it's hardly a
surprise that a Perl programmer thinks it's better.

------
StephenFalken
Just a side note: somehow the official Perl website is one of the fastest
websites I've come across on the web. Is there a reason for this ?

~~~
mjn
It looks like it's using this CMS:
[http://git.develooper.com/combust.git/](http://git.develooper.com/combust.git/)

------
mikepk
I have some experience in this area. My first startup: Grazr
([http://tcrn.ch/aUqiIb](http://tcrn.ch/aUqiIb)), the back end was mostly Perl
with some custom C modules. Grazr was started in 2005 when Perl was already
out of fashion.

So why did we choose Perl, practical reasons mostly. My co-founder had
previously been the CTO of the company that owned Slashdot and he had a team
of top-notch Perl people that he thought would want to join us. I had worked a
lot with Perl in a previous life so it seemed like a natural fit.

Perl has many strengths. You can "just get stuff done" with Perl. The module
library is obviously a huge strength. The first version (effectively a public
prototype) of Grazr went live very quickly (days). If you’re careful with it,
you can also build some fairly complex projects using Perl. The machinery for
Grazr processed a huge amount of data (for the time) multiple terabytes of
feed data and had a lot of advanced features like: processing of normalized
feeds, an embedded scripting language, cross link analysis, a search engine,
and most of the heavy lifting was Perl. Think of the system as an advanced
form of the feed API that Google Reader eventually released, nearly real-time
(unlike the Reader API we updated feeds upon request) with the addition of a
scripting layer on top. I'm very proud of what we built, technology-wise. We
failed in other ways (UX, marketing and sales mainly) but the underlying
system was quite impressive.

When the feed application language and processing engine stopped being the
focus of the company, the Grazr system ran on only a few virtual servers,
responsively and smoothly for over a year with steadily growing traffic. That
was with the whole company ignoring it and focusing on other 'pivots' (before
pivot was the term-du-jour for that). Why the company ignored a service that
was steadily growing traffic with absolutely no input from the team/company is
a rant for another day. :)

When I co-founded my next company, Smarterer
([http://smarterer.com/](http://smarterer.com/)), I vowed gone-with-the-wind-
style that as God as my witness, I would never write a big startup-project in
Perl again. Smarterer is written mainly in Python.

Why the Perl hate? First, I still think Perl is a fine language. You can get a
lot done with it. But as other's have pointed out, one of the primary design
philosophies of the language make it painful in some cases. Large, evolving
projects with multiple contributors seems to be the axis of evil for Perl.
Startups exacerbate this problem because they exhibit most of these factors
and compound it with unrealistic functional time pressure.

What I observed as problems were:

First, with Perl there is always a temptation to be clever. It's a lot of fun,
but one of the underlying philosophies of Perl, the "Tim Toady" thing, opens
up a lot of temptation to show just how clever you are, usually _too clever by
half_. That always leads to the WTF moments as you’re reading any code you
haven’t written in the last week. I started to feel each WTF moment as a tax
on our tech team.

When you have a big Perl project with several contributors, coming up with
coding standards is a _must_ but usually in a startup environment getting
something working is almost always the first priority. Also, coding standards
only get you so far with Perl because it's so flexible. If you spend any
reasonable amount of time, the _unwritten_ standards of how people write Perl
code subtly shifts over time. Usually the code get better as contributors
influence each others coding styles, but this makes going back to read working
code that’s 6 months to a year old a massive pain in the ass.

Lastly, having coding standards doesn’t protect you against _other peoples
modules_. If you have a large and complex enough system, you’re going to start
tripping over the bugs and corner cases in other people’s modules. Perl has
the strength of CPAN, but because you can’t enforce a coding standard across
all of Perl, debugging into other people’s modules can be an exercise in
frustration. When some bug is tracked down to a third-party module, treating
it as a black box is no longer an option.

When faced with these problems you can usually work through each case. In the
best case it just takes a few minutes of working through the cognitive
dissonance, but in other cases you end up breaking out the print statements
and/or debugger to instrument code just to figure out _what the heck was the
intent here_.

As a startup guy, the energy required to “re parse” code that’s already been
written in subtly different ways starts to drive you crazy because that’s time
and energy that could be being applied to solving the bug and tackling the new
problem at hand. That re-read and re-parse tax gets worse and worse the large
the project becomes and the more people that are involved.

That’s, generally, why I wouldn’t recommend Perl as a language for a startup
project, but every case is different. If you're not in the axis-of-evil for
Perl, you have _incredible discipline_ and you only rely on a limited number
of third-party modules you may be OK.

------
reidrac
I've been a Perl fan for years and I really enjoyed using the language in my
personal projects (and in a couple of professional projects, it was "the
secret ingredient"), but I couldn't fight all the prejudices surrounding Perl;
so I finally gave up and learnt Python hoping to find a quality job as
software developer.

It worked out pretty well and I found a great job. I love doing Python, the
community and the culture behind the language, so I've never looked back.

I get contacted from time to time by recruiters looking for Perl developers
but the truth is that it is still less frequent than Python; and now I don't
have to explain that you can use a powerful language in different ways and
that it's up to you if your code is readable, maintainable and easy to deploy.

~~~
gautamsomani
But he used perl to build some thing huge. Just wondering if that huge thing
would have run as smooth in python as in perl?

~~~
scardine
I used to love Perl as well, it is amazing for text processing and at the time
was the silver tape of Internet.

It is pleasant to write, but I can't say the same for reading: sometimes it is
hard to understand my own Perl code after untouched for a few months. In this
regard, my experience is the same: Python is more readable and easy to
maintain.

There's more than one way to do it (TMTOWTDI or TIMTOWTDI, pronounced “Tim
Toady”) is a Perl programming motto. This is diametrically opposed to the zen
of Python: "There should be one-- and preferably only one --obvious way to do
it"

Once you get used to Python, it is very hard to get back to “Tim Toady”, and
your Python experience is likely to heavily influence how you write in other
languages.

~~~
berntb
I did a year of Python. There are good and bad things with everything. Python
was OK, the learning curve the first few weeks/months is really well planned.

I prefer Perl given a competent team. Mostly because of the CPAN Testers and
because it is fun.

Bad with Python are details like e.g. no real one-liners. I also think there
is something rotten with the language culture that e.g. results in lots and
lots of language war trolls from 19-karma accounts on HN...

------
systems
a bit off topic, but i really wish if jetbrains creates an ide for perl,
similar to their pycharm or phpstorm

i believe compared to other younger languages perl can be overwhelming, and i
think a great ide will go a long way reducing the barrier of entry to new
comers

~~~
tskrainar
Ever heard of Komodo? I've been using it for years for Perl development, plus
it supports Python, Ruby, and a host of other languages.

I wouldn't consider doing any serious Perl dev without it.

~~~
systems
is Komodo bound in any way to ActiveState perl distribution? or can it be
configured to use any perl you have installed, including perlbrew stuff

~~~
tskrainar
No. If it were, I wouldn't even consider using it.

Switching between multiple interpreter installations is pretty easy (a drop
down in a preference pane) -- it will find every interpreter on your path, and
can index anything defined in $PERL5LIB for auto-complete goodness.

The debugger is great -- I love being able to set conditional breakpoints
using a possibly complex expression in the native language (not just simple
var=val type things).

------
Ixiaus
As an aside: Blekko is a PERL company (not sure if they qualify as a startup
anymore).

~~~
greglindahl
We qualify, we're still losing money! :-)

~~~
perigrin
So is Amazon! You're startup buddies!

~~~
greglindahl
This isn't really the place to argue about the definition of a startup, but
"has lost money continuously since inception" and "hasn't IPOed" are on the
list of many people when they define what a startup is. Amazon has both IPOed
and has had many quarters of profit.

------
danbmil99
TL; DR: the founder likes Perl

------
nnq
> Ruby has nothing that Perl doesn't have (at least that I've seen). Therefore
> no reason to switch

...such a _" wrong"_ way to think! You can say that you'll stick to Perl
because you know it better and it has the same feature set. But you can't say
that you won't use some other language just because "it has no extra
features".

The advantages of a programming a language over another are not its
"features". All it matters is:

\- "learnability" \- how fast can you learn it (not "hello world", but how
fast can you get to the level of writing "big" and maintainable projects in
it)

\- productivity - how productive are you coding in it once you know it well

\- maintainability - how well can you maintain code written in that language

\- security - how easy it is to write secure code in it

...because when it comes to features even assembler has _all_ the features you
need. And no, for a language to have a "productivity" feature (like features
that make OOP possible), is not the same as actually benefiting from the
possible productivity increases of that feature - for example, having an
object system that is "too" complex and not in-tune with the language (eg.
CLOS) or having multiple object systems (Perl), doesn't give you anything
close to the benefits of a good and clean Smalltak-flavored object system like
Ruby's. Or, having all the features required for functional programming (like
Python, Perl, and even Ruby have), is nowhere near as useful as having them
well thought and in a language that emphasizes this paradigm, like Clojure.

~~~
chromatic
_But you can 't say that you won't use some other language just because "it
has no extra features"._

Sure you can! The cost of switching languages may outweigh the expected value
of the extra features, especially if they're only marginally more useful or
not useful at all.

* ... the benefits of a good and clean Smalltak-flavored object system like Ruby's.*

I'm unconvinced. Ruby's hacky metaprogramming is hacky because you just don't
get the Smalltalk browser without an image-based environment. You _can_ make
huge messes in Smalltalk if you monkeypatch hither and yon, but you also get
better tools to help avoid the situation and to extricate yourself from it.

------
dragonwriter
Its mildly interesting but the conclusions stated on alternative languages
seem somewhat odd, and what is presented isn't enough to tell the real reasons
for them. It also seems to conflate platforms with languages (e.g., the "Mono
is no real substitute" in regard to C#; there are some ways -- which might be
important -- where Mono doesn't substitute for .NET, particularly in terms of
library support, but C# on Mono and C# on .NET, from a language perspective,
aren't that far apart.)

And even to the extent I can pull apart some idea of the preferences
underlying the conclusions, I simply can't fathom the idea that C# is in any
way an inferior language to Java in a way which the tie to Microsoft would be
_on top of_ the some language inferiority as presented here.

So, in the end, I don't get much from this than that Perl was chosen because
they like Perl better based on underlying preferences that aren't really clear
at all.

------
netvarun
We (Semantics3) are a perl shop too! Other YC companies, AFAIK that use Perl
are: Crowdtilt and Terascore

~~~
Ovid
As the author of the original blog post, this is good to know. When I have
some more time, I'll get around to contacting you if you're willing to do a
similar interview.

------
e3pi
lacuna:

1\. An empty space or a missing part; a gap: "self-centered in opinion, with
curious lacunae of astounding ignorance" (Frank Norris).

2\. Anatomy A cavity, space, or depression, especially in a bone, containing
cartilage or bone cells.

___________________________________________

Is Lacuna Expanse(LE) modeled on EVE Online? I do not know about games as my
boxes always appear limited, connection slow, and there is a learning curve to
these sprawling fantastic worlds. Popular EVE Online has beautiful Youtube
vids, so the tease is there. LE looks more accessible, and from the OP, a perl
API to grow the LE expanse. There must be many isolated(frustrated?) perl
programmers that will be drawn into this Lucana universe.

I've a suspicion while never having personally faced this argument other than
adapting snippets of CPAN perl module source, like lisp's power to
individually coin, perl's 'more than one way to do it' may become a handicap
when projects scale big and it depends on walking through other's code beyond
the standard gluing of perl modules.

...space jump on over to LE right now...

Login `empire name'? What's this? Not user name? ... here we go, tutorial =
vids w/ emails

------
Patrick_Devine
The largest reason why I would hesitate to use Perl in my startup would be the
core philosophy of TIMTOWTDI (there is more than one way to do it). Being able
to write something multiple different ways leads to Perl being a lot easier to
write than it is to read. As a result code maintenance can become a huge
headache due to someone not understanding the idioms used by the person who
originally wrote the code.

I've seen this happen on a number of projects that I've worked with using
Perl. Typically a person wouldn't be familiar with "silver ball" (Effective
Perl Programming), would go off an write a large body of code which would be
difficult to wade through. This gets exacerbated by new coders not
understanding how perl expects you to understand some of its idioms (like $_,
@_, etc.) implicitly. Because reading other people's code is a great way to
learn a language, this makes Perl a lot less approachable.

I think Ruby suffers from some of these problems to a certain degree as well.
I haven't worked with Ruby professionally, but in the few times I've played
around with it I've found myself spending a lot of time trying to figure out
which looping construct I should use over another.

Python does have a leg up in this department. The language tends to be fairly
succinct and things like Pep8 and flake8 really help in making most code
fairly digestible.

~~~
gabriel
What language prevents TIMTOWTDI? And don't say Python. I'm not talking about
the language motto. Because that's the nature of using these things called
programming languages:
[http://www.paulgraham.com/langdes.html](http://www.paulgraham.com/langdes.html)

Python has Pep8. Perl has Perl::Critic. C# has FxCop. Etc.

I've not yet seen any language possess the qualities that prevent it from
being unreadable. It's an amazing open question though, isn't it?

I think you hit the point with "code maintenance can become a huge headache
due to someone not understanding the idioms used by the person who originally
wrote the code". But this isn't a language thing. This is a people thing.

~~~
danbmil99
In my X, for whatever reasons (lang design, culture, etc) Python is most
definitely the easiest language to read and understand what another programmer
is trying to do.

I don't think the most rabid PERL fanboy would ever make a similar claim.

------
snambi
Nice to see some action on Perl. IMHO its better than most of the existing
dynamic languages.

------
jf22
>I've been using Perl since 1996, but it became my language of choice in 2001.

Did the rest of the article need to be written?

