Perl Startups: Lacuna Expanse
blogs.perl.org
blogs.perl.org
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
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.
>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.
I was very excited to see a startup using PERL but it's a pity the article fall into a languages war.
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'.
No. He wasn't arguing ideology. He was saying that for his needs, this is how he compares things.
Of course his needs implicitly assume his own ideological biases. Yours may vary. But he's not trying to convince anyone else - merely say what went into his decision.
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...
It just goes to show: Don't worry about using the "best language", just use the best language for you.
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.
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.
Here's why I think learning Perl is worth it: a lot of programmers write stuff in it. It won't make you know other languages any less.
(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... instead)
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.)
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.
"C# isn't quite as good as Java"
Can anyone who truly believes these things be taken seriously, really?
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/), 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.
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.
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.
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...
Read https://coosoft.wordpress.com/2013/02/24/the-perl-vs-python-...
To be honest the parent comment to yours first link reminds me of a rather lot of shell/perl created by people that treat things with the procedural mindset and just keep bashing their heads against a problem until it succeeds. There isn't anything wrong with that but that python really is no different stylistically than any of the "horrible perl" stories I've seen. I've seen perl that made most ruby look unreadable at first glance too. I think it really goes to show encrypting human thought into programming languages is not trivial. Also I'm getting sick of these $foo_language is better/worse/a threat(really threat? weird word choice imo) to anything. Every language I learn I learn something new in. Even if its the ones I don't like much like Java/PHP, doesn't mean they're bad languages or they're devoid of being able to teach you new ways to approach problems.
Meh, ranted longer about this than I'd thought I would.
To my mind, that's a success for Perl: it allows people who wouldn't otherwise be able to write programs to do so. Sure, they make messes--who doesn't at first?--but they get things done.
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
This has nothing to do with either language and everything to do with the projects themselves. Stop dissing languages based on the distant past, especially not when using Perl.
There's really no way to use MySQL without DBI. But at that level, one is still writing db-specific SQL -- perhaps you mean an ORM?
Although Perl is now a general-purpose programming language, it originated as a scripting language for UNIX systems administration and for parsing text files. Perl's traditional use case is one where you're working on a UNIX server through an SSH terminal, so you only have vi/vim or maybe emacs. In that situation, GUI IDEs are not really an option, and trying to use them kind of goes against the whole purpose and culture of Perl. If you're using Perl, you're probably already comfortable working in a command line terminal and have no need for an IDE.
Also, Perl is complicated and looks "like a cartoon character swearing" (-pg) but a nice thing about Perl is that to learn it, you really only need a computer with an OS (which will come with Perl installed on it as long as it isn't Windows) and the camel book.
I wouldn't consider doing any serious Perl dev without 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).
I don't use it, too slow compared to just "vi" and a command line. I can type quickly, cannot click a mouse 1000 times quickly to do the same thing. Given that I find it uninteresting so I'm not a sympathetic reviewer, I have played with padre enough to see it works and has quite a few features and is free. I've seen it improve over the years. I'm not sure what specific barriers are reduced by an IDE like padre, as most of the features seem only of benefit to truly immense non-modularized projects which culturally don't "fit" well in Perl. If it can't all fit in your head at once, abstract something out into a separate package complete with unit tests and shrink it until it does fit. And a large full screen editor with no IDE in the way makes it easier to fit in your mind rather than a small postage stamp view of the code. That all said, I liked seeing the integration in padre with perlcritic and perltidy, just not enough to switch away from vi. I need my screen real estate and keyboard more than I need automated perltidy/perlcritic and mouse shortcuts which have an impedance bump with vi anyway.
Perhaps the best "ide" for a newcomer would be multiple machines/monitors with one very large editor for code, one web browser to google for questions/examples/ideas/docs and one large window for interaction either in the debugger or testing your code. So three monitors minimum connected to 1 to 3 computers? I feel cramped when doing "stuff" with less than three. I can't imagine doing anything other than emergency support with a small laptop screen although I've had to do it in the past.
...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.
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.
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.
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
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.
I would also think hiring professional, experienced, Perl coders for a decent salary is easier than finding Rails, node,etc. (I've used Perl and Ruby for quite some time in the past. My last startup is still looking for more Rails engineers. I chose Rails because it was a good fit, but finding talent can be hard).
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.
I don't think the most rabid PERL fanboy would ever make a similar claim.
I don't understand this. If this hurts you, wouldn't you have the same problem with domain knowledge, except an order of magnitude worse? Why are your developers not talking to each other?
I agree this is also a problem with domain knowledge. The second you commit something to your code base the clock starts ticking. The further away from your own code, the harder it is to have context and the more difficult it is to fix problems. If you feel like you can jump back in to your Perl code easily after a prolonged absence, by all means, do it. My point was only that in Perl, it's easy to use many different idioms which not all coders are familiar with. This can make debugging more difficult.
And the good programmer could do anything in a less eccentric language anyway, so...
Did the rest of the article need to be written?