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

Why I Use Perl: Reliability

modernperlbooks.com

Post reply on HN
Print view View original

161–170 of 196 posts

Re: Why I Use Perl: Reliability

#161

Post by zby »

fennecfoxen wrote: post #28
tlianza wrote: post #23

The article makes a good point. But, the title (and comments here) infer that there are a mountain of reasons why people don't use it. Is there a compelling argument against that mountain, or is this just a reminder that Ruby/Python/Closure/Scala communities would be well-served to try and improve in this area?

The worst problem with Perl as a language is hiring for a good Perl programmer. It's easy to hire a mediocre Perl programmer, mind you, sometimes even a mediocre programmer who's really good at Perl specifically and knows all the packaging tricks and whatnot so he can get through the interview before falling apart on the job, but really hard to find the good ones. It just doesn't have much mindshare at the moment (ug…

Did you announce the jobs at http://jobs.perl.org? I tend to use that site primarily when looking for a job. It's the only one to maintain a high signal to noise ratio, posting there also shows that the company knows about the Perl community and probably accepts its values.

Re: Why I Use Perl: Reliability

#162

Post by kokey »

waffle_ss wrote: post #65
fennecfoxen wrote: post #28

Earlier quoted context omitted.

The worst problem with Perl as a language is hiring for a good Perl programmer. It's easy to hire a mediocre Perl programmer, mind you, sometimes even a mediocre programmer who's really good at Perl specifically and knows all the packaging tricks and whatnot so he can get through the interview before falling apart on the job, but really hard to find the good ones. It just doesn't have much mindshare at the moment (ug…

Are there really any compelling reasons to use Perl over Ruby for greenfield projects (i.e. not legacy maintenance)? I've written maybe a dozen medium-length Perl scripts (but nothing very large) before I got into Ruby, and I can't seem to think of anything that Perl does that can't be done at least as well in Ruby. Honestly not trying to start a religious war here - just curious - and I think it's fair to compare th…

Here's another reason: If you are doing work you know you are likely to port to C at some point.

Re: Why I Use Perl: Reliability

#163

Post by pwaring »

adrianhoward wrote: post #111
zentrus wrote: post #104

Earlier quoted context omitted.

Check this site out for a comparison of the various module counts per language. It is really incredible that rubygems surpassed CPAN last year and continues to grow at a very rapid rate. Quality may be another matter, but still, impressive. http://www.modulecounts.com/

Nice site. Well found. I find it interesting that PHP doesn't have anything in the same league as Perl/Ruby/Python even after all these years. Any PHP folk out there?

The closest PHP has to CPAN is PEAR (http://pear.php.net). It stalled for a long time, although development seems to have picked up a bit now that everything is on GitHub (https://github.com/pear/)

Re: Why I Use Perl: Reliability

#164

Post by gouranga »

adrianhoward wrote: post #46
gouranga wrote: post #42

Earlier quoted context omitted.

We killed that as well!

Considering the number of folk dealing with COBOL systems I bumped into at GOTO Copenhagen last week, and the number of COBOL jobs that pop up after a quick google I would beg to differ. I can, of course, understand why you would really want it to be dead ;-)

I'm quite surprised actually! I've not seen COBOL in the finance sector (at least in the UK) for about 5-6 years.

Perhaps there still are a few corners where there are some rotting corpses hacking away on AS/400s which are actually gluing everything together!

I remember getting to sledgehammer the crap out of our AS/400 platforms and incinerate two entire pallets of IBM manuals - was "a great day for freedom" to paraphrase Pink Floyd.

Re: Why I Use Perl: Reliability

#166

Post by nyddle »

Speaking of Moose, dependencies and reliability: I love Perl but today having to download the whole CPAN to use a MongoDB driver (based on Moose) forced me to switch to pure javascript with mongo js interpreter.

Re: Why I Use Perl: Reliability

#167

Post by kamaal »

hkolek wrote: post #146
kamaal wrote: post #131

Earlier quoted context omitted.

The difference between computer science and software engineering is Software engineering is real work for the real world. Often the constraints are money, time, resources. So demands of a software project in the real world are very different than the academia. Although you can argue that Lisp is far more a better language than Perl, based on some parameters you wish to evaluate. Others might have totally different pa…

You said it yourself, comfort is a subjective term. So why do you talk as if Lisp were objectively more complicated. If I'm familiar with Lisp but have no clue about Perl I don't need to be a university professor with endless time to choose Lisp over Perl every time. To me, Perl looks vastly more complicated than Lisp. I believe you'd find that if you'd know Lisp like you do Perl you'd be at least as productive as yo…

>>I believe you'd find that if you'd know Lisp like you do Perl you'd be at least as productive as you're in Perl.

No,

And this is probably the reason why Lisp never took off post the appearance of C based languages. This is also why there are so many languages, because there are that many use cases for them. Denying the existence of a problem doesn't offer a solution. I can build anything quickly merely by using CPAN modules, I can manipulate strings and do all the text magic real quickly in Perl. That's not the same case with Lisp.

What you are saying is something like this. One guy wants reach from point A to B. He can either run or go in a car. You can argue that if he practices enough he can run as fast as the car, sure he can. But there is 0 logic in subjecting your legs to that kind of a torture, while all you need to learn is how to drive a car.

Now don't tell me that going from point A to B itself is wrong and he should be going to C instead.

Re: Why I Use Perl: Reliability

#168

Post by kamaal »

adrianhoward wrote: post #156
kamaal wrote: post #132

Earlier quoted context omitted.

I find the opposite to be true. You are likely to find better Perl programmers than Java programmers. Because its easy to spot bad programmers in Perl. Most Java programmers can't write simple apps without the help of an IDE. Or refactor a small part of a large project with an Text editor. In many other languages forcing people to write programers in a particular style often leads to code written by bad and good prog…

Most Java programmers can't write simple apps without the help of an IDE. Or refactor a small part of a large project with an Text editor. I'm curious why you think editor choice is the sign of a good developer? Pretty much nobody I know can code with a line editor (anybody else out there remember ed?) - that doesn't make them worse developers. Hell - I'd jump at an IDE that let me do automated refactoring in Perl. I…

>>I'm curious why you think editor choice is the sign of a good developer?

I have nothing against IDEs. But anybody who claims to know a language must at least able to work with the source code and semantics.

If a person absolutely can't code at all. I mean slowly is still acceptable. But if he absolutely just can't write code without an IDE, I would doubt his claims of knowing the language.

Knowledge of tools != Knowledge of a programming language.

Re: Why I Use Perl: Reliability

#169

Post by adrianhoward »

kahawe wrote: post #153
rcthompson wrote: post #79

For any value of $LANGUAGE, imagine this situation: your boss comes to you and say "Hey, they just released a new major version of $LANGUAGE today. Can you go upgrade it on all our production servers?" What is your emotional response to that request? For many values of $LANGUAGE, there would probably at least some element of terror (for many languages, probably much more than just "some"). But Perl is one where, depe…

> But Perl is one where, depending on the circumstances, the response could plausibly be as article says: boredom. "Yeah, sure, whatever. I'll go upgrade them." (Certainly there are others, but Perl is definitely one of the best in this regard.) Remaining backwards-compatibility and having good, reliable tests for your OWN software are two separate things and I am sure a special hell awaits those who are unfortunate…

To be completely honest, I would expect no less from Java or python within the same major release, namely for the language and the interpreter to "just work"

I'd expect it too. Sadly my expectations are often not met :-)

Can you help me understand why Perl is so special or outstanding in that regard? Maybe just the very test-aware community?

I think it's a combination of the test-aware community - and the infrastructure that community has built up.

Little things like having the default behaviour of all the build/install tools be "run all the tests and only install if they all pass", rather than having running tests be optional.

Or take cpantesters.org for example.

For those who don't know cpantesters is basically a distributed continual-integration environment for all of CPAN. Any time anybody releases something to CPAN it gets downloaded and compiled on dozens of OS/perl combinations, and the automated tests run.

If I release a module on CPAN and it doesn't work on some obscure OS/perl combination I'll likely get an automated e-mail in a matter of hours. The results of those tests are public - so anybody can easily see what versions of what modules work on what platforms. You'll see them up right next to the module in all the CPAN search tools. So folk can easily understand where they'll be problems, and people with access to that platform can more easily find and patch problematic code.

So anybody who releases anything to CPAN gets a fantastic multi-platform CI tool for free.

And a discussion forum (http://cpanforum.com/). And a bug/issue tracker (https://rt.cpan.org). And a review platform (http://cpanratings.perl.org/). And automated "quality" metrics (http://cpants.charsbar.org/) and .... well... I could go on. All of them have public data or API routes so they very quickly get integrated into tools like https://metacpan.org and http://search.cpan.org/.

The perl community has done a stirling job taking the whole small-pieces-loosely-joined philosophy onto their community module distribution / testing infrastructure.

Because of the transparency and integration "bad" modules are obvious, and tend to get quickly fixed or deprecated. At the very least it's very easy to identify problematic areas and work around them.

Re: Why I Use Perl: Reliability

#170

Post by adrianhoward »

kamaal wrote: post #168
adrianhoward wrote: post #156

Earlier quoted context omitted.

Most Java programmers can't write simple apps without the help of an IDE. Or refactor a small part of a large project with an Text editor. I'm curious why you think editor choice is the sign of a good developer? Pretty much nobody I know can code with a line editor (anybody else out there remember ed?) - that doesn't make them worse developers. Hell - I'd jump at an IDE that let me do automated refactoring in Perl. I…

>>I'm curious why you think editor choice is the sign of a good developer? I have nothing against IDEs. But anybody who claims to know a language must at least able to work with the source code and semantics. If a person absolutely can't code at all. I mean slowly is still acceptable. But if he absolutely just can't write code without an IDE, I would doubt his claims of knowing the language. Knowledge of tools != Kno…

But if he absolutely just can't write code without an IDE, I would doubt his claims of knowing the language.

Would you be productive in QED http://en.wikipedia.org/wiki/QED_(text_editor) ? Should I doubt your coding skills because of that?

Knowledge of tools != Knowledge of a programming language.

Agreed. But you seem to be saying that people who code well with an IDE, and can't code well with a more vanilla text editor, means that they don't know the language. This is a tool knowledge issue - not a language knowledge issue.

Some people are good at coding, and others are bad at coding. IDE/editor choice has little to do with it. Lines like "Most Java programmers can't write simple apps without the help of an IDE" are just false - and have nothing to do with whether the developer is any good or not.

Twenty years ago people were saying the same thing about lazy developers who use screen based editors instead of line based ones. I'm sure that twenty years before that folk were complaining about folk who use terminals instead of punched cards as god intended :-)

Post reply on HN