Perl Startups: Lacuna Expanse(blogs.perl.org)
blogs.perl.org
Perl Startups: Lacuna Expanse
http://blogs.perl.org/users/ovid/2013/07/perl-startups-lacuna-expanse.html
23 comments
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.
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.
Learn as many languages as you can and specialize in the one you love.
>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.
>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.
IMO he kinda missed the main ideological differences, benefits, pros, cons of both ruby and python.
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.
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.
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.
I was very excited to see a startup using PERL but it's a pity the article fall into a languages war.
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'.
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'.
Ruby has two things over Perl: a reusable library built in the same object system you want to use (most of CPAN predates Moose and uses the brain-damaged vintage 1990 dispatch setup directly) and a culture of raising exceptions (rather than returning arbitrary bad values nobody remembers to check for). Sometimes I wish Ruby and Python could have merged, but it'd never work so long as Guido prefers expressing everything procedurally rather than in reusable block objects.
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...
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...
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.
It just goes to show: Don't worry about using the "best language", just use the best language for you.
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.
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.
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.
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.
You mean write-only?
It was an interview on a Perl blog, so the target audience is people already enthusiastic about Perl.
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.
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.
I feel like that, among Perl startups, DuckDuckGo is the elephant in the room these days.
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.
I can't seem to find DuckDuckGo's intro to Perl.
For a decent intro try Learn Perl in about 2 hours 30 minutes
by Sam Hughes 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... instead)
(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)
Unfortunately neither can I! I'm sure they had one when DuckDuckHack was first announced but the docs have changed a lot since then.
One could argue that once a startup becomes an elephant it might not actually be a startup anymore. There are many big and successful Perl companies less than 10 years old, just not much buzz around them, because they never needed it. Perl has simply become an industry standard for tasks that involve a lot of text processing, not unlike C for system programming.
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/
[2] https://pypi.python.org/pypi
[3] http://rubygems.org/
[1] http://www.cpan.org/
[2] https://pypi.python.org/pypi
[3] http://rubygems.org/
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.)
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.)
"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.
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.
Just curious, are those packages being re-written to make them better and faster (if they can be, that is)?
"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?
"C# isn't quite as good as Java"
Can anyone who truly believes these things be taken seriously, really?
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.
Yeah, it was way too dismissive...made me think be has never touched any of these languages. I hate microsoft, .Net, and Mono the bastard child, and I love the JVM...but there is no way in hell you could convince me that Java is better than C#.
This is the part he lost me at as well. You can tell very little research went into the article when you quantify the broad-scope merits of any language. You can't say Python is 50 good, while Ruby is 100 good.
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 ?
It looks like it's using this CMS: http://git.develooper.com/combust.git/
Hah I never noticed that. It is strangely incredibly fast...
I have some experience in this area. My first startup: Grazr (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/), 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.
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.
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.
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.
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?
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.
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 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...
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...
What a absurd python propaganda it is.
Read http://www.wikivs.com/wiki/Perl_vs_Python
Read http://www.wikivs.com/wiki/Perl_vs_Python
Is there any reason to expect that it wouldn't run as well in Python? They're both dynamic, interpreted languages, and it's not as though no-one's ever written a large codebase in Python.
HAHA Python is fucking readable.
https://github.com/hiddenillusion/AnalyzePE/blob/master/Adob...
http://blog.delroth.net/2013/03/escaping-a-python-sandbox-nd...
Any language can be made unreadable. I can write terrible Ruby/Perl/PHP/JavaScript, too. Doesn't make them bad languages.
Agreed, I"m a Ruby person personally and often end up writing things that later I only shake my head at and rip out and replace with a few lines or a better idiom/algorithm.
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 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 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.
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.
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.
True enough, just pointing out that you can write... ugly code in any language. Bash/perl tend to get abused more often from what I've seen. Hopefully they improve in the future.
Yes, Python is more unreadable than Perl to me. :)
Read https://coosoft.wordpress.com/2013/02/24/the-perl-vs-python-...
Read https://coosoft.wordpress.com/2013/02/24/the-perl-vs-python-...
That first link is terrible. They should have used a rules engine.
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
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
Padre?
http://padre.perlide.org/
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.
http://padre.perlide.org/
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.
I'd venture to guess that they aren't doing that because there's little to no market for it.
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.
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.
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.
I wouldn't consider doing any serious Perl dev without it.
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
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).
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).
a bit off topic, i really wish Perl CMSes would stop dropping Postgres support in favour of a MySQL only strategy (Movable Type and WebGUI [Plain Black], this means you). You'd think DBI did not exist or that this was really PHP.
PHP has a database abrstraction layer built into language that offers support for postgres in addition to a couple of fairly popular abstractions / ORMs / other alternatives.
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.
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.
Everything has a database abstraction layer available. The problem is that programmers often don't use them. The perl CMSes obviously aren't using DBI, or they'd still be supporting Postgres... no need to turn the thread into language-related complaining when it is a universal problem.
> ...obviously aren't using DBI
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?
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?
Agreed. I have told JetBeans that they won't get a sale from my company due to not having any kind if perl support (even syntax highlighting). EPIC plugin for eclipse ain't perfect, but its better than nothing.
As an aside: Blekko is a PERL company (not sure if they qualify as a startup anymore).
We qualify, we're still losing money! :-)
So is Amazon! You're startup buddies!
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.
TL; DR: the founder likes Perl
> 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.
...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.
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.
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.
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.
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.
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
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
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.
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.
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
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.
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.
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.
I don't think the most rabid PERL fanboy would ever make a similar claim.
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 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 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?
Teams are dynamic, not static. You can have new hires, you can lose people and you can get code written by others that you have to maintain (especially the case with CPAN).
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.
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.
I think your comment is spot-on. A good Perl programmer can do wonders, but if you add just one average programmer to the team (without a very extensive training), he can write stupid things faster than the good programmer could fix, LOL. Then the codebase would be a mess, with things that kinda work but are conceptually wrong or weird for those who really know the language.
And the good programmer could do anything in a less eccentric language anyway, so...
And the good programmer could do anything in a less eccentric language anyway, so...
You can get around readability with good comments. Perl can be a b*tch to deduce - but it is simple and powerful.
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).
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).
Nice to see some action on Perl. IMHO its better than most of the existing dynamic languages.
>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?
Did the rest of the article need to be written?
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