Live data from Hacker News

Why I Use Perl: Reliability

modernperlbooks.com

171–180 of 196 posts

Re: Why I Use Perl: Reliability

#171
post #162

Earlier quoted context omitted.

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.

I don't follow?

(and I'm saying this as somebody who love's Perl - I'm not seeing the connection)

Re: Why I Use Perl: Reliability

#172

Earlier quoted context omitted.

The 'ghoti can be pronounced as fish' thing is a bit unfair to English orthography, where you must take the surroundings of the letter cluster into account.

You also have to take the rest of the sentence into account too. English has a lot of words which mean different things depending on how they're pronounced (or, from the other side, that you can't know which way to pronounce until you already know the meaning), e.g. bass, close, desert, does, dove, familiar, have, intimate, invalid, lead, lives, number, object, present, produce, read, refuse, sewer, sow, subject, tea…

familiar? have? number? Don't think so...

Re: Why I Use Perl: Reliability

#173
post #127

Earlier quoted context omitted.

Unless you're completely impatient, you can pretty much take anybody with a "scripting" language background and throw them in and it's fine. Works the other way around, too. Python, Ruby, and Perl are all nearly the same language under the hood, with Javascript and Lua somewhat more distant but still not all that different. (Also, I mean someone who knows Javascript , not merely someone who can copy and paste some sn…

My old CTO would have argued with you that Perl was not a mere scripting language* and that our shop's style of coding was indeed object oriented. The other problem we ran into was that the programmers who loved other languages were very religious about it. In fact I use to visualize that each programmer worshipped the specific animal that shown on the O'Reilly book cover: And I'm still haunted in my dreams by that c…

"that our shop's style of coding was indeed object oriented"

All of the other languages I mentioned are roughly as OO as Perl. (You sometimes have to go looking for it, and Perl's probably ultimately the weakest at the core, but it's still there and mostly strong enough it doesn't matter.)

Re: Why I Use Perl: Reliability

#174
post #166

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.

You don't need to download the whole of CPAN to install Moose: http://deps.cpantesters.org/?module=Moose&perl=5.16.0&#3...

MongoDB (if that's what you are using?) has a few more dependancies however it actually uses Any::Moose and so could you Mouse instead of Moose: http://deps.cpantesters.org/?module=MongoDB&perl=5.16.0&...

Were you using cpanminus to install your modules? Because its much faster than default cpan command.

I just tested using cpanminus (cpanm) on a vanilla perl install and installing Moose & MongoDB modules took 4 minutes here.

Here's a summary:

  Install perl-5.16.0 via perlbrew - under 15 mins
  Install cpanminus - 5 secs 
  cpanm Moose       - 2 mins 5 secs (installed 22 distros)
  cpanm MongoDB     - 1 min 52 secs (installed another 20 distros)
Here's the log: https://gist.github.com/2836306

Re: Why I Use Perl: Reliability

#175
post #160
post #85

Earlier quoted context omitted.

> What is your emotional response to that request? Heh the worst upgrade experience I've had with any language was with perl. The issue wasn't with changes to language features, it was chaos resulting from CPAN XS module compatibility and compilation failures. I remember one trivial module (array::compare) went from a having few core dependencies to dozens of CPAN dependencies (including all the moose OO modules). An…

I think it has improved much after 5.10, of course most companies are not yet there - so what chromatic describes is far from being a standard experience.

Interesting, the upgrade I mentioned was 5.8 to 5.10.

Re: Why I Use Perl: Reliability

#176
post #138

Earlier quoted context omitted.

Others have noted that your reply is a non-sequitur. However, I'd like to address it anyway, specifically the "luck" part. I have written all of what you describe: large-scale multithreaded high-performance distributed applications using Perl. When necessary I have written perlXS bindings to C routines, but this is surprisingly infrequent. Most high performance system interfaces are exposed to Perl in an efficient ma…

Just curious: what did you use for IPC at this scale?

I'm describing about a dozen separate projects above. For same-system fast IPC I often used an in-house library (with Perl bindings) which implemented a memory mapped, sharable hash table. Unfortunately it hasn't been released as open source. The closest similar project might be http://fallabs.com/kyotocabinet/ however it's inferior in a few important ways.

Re: Why I Use Perl: Reliability

#177
post #21
post #19

Earlier quoted context omitted.

You can write readable Perl, just like you can write secure PHP. The fact that a large number of people don't is not necessarily a failing of the language.

Disagree. Readability and reasonable shoot-self-in-foot protection are not optional. See the article from earlier today about not catering to power users. Same concept. You can't really design a language for the top 5% of programmers and expect it to gain any sort of acceptance. (See: Haskell, Ocaml)

I completely agree with your first statement, but I have no idea how you get to your final statement from that. Ocaml and haskell are both on the "shoot self anywhere protection" end of the language spectrum. I used ocaml for a couple years and program in haskell for a living, and I assure you I am not in the top 5% of programmers.

Re: Why I Use Perl: Reliability

#178

Language keywords: Ruby ~40 Python ~40 Java ~50 Perl ~1800 Perl can have all the community support, packages, and testing that it wants, but I dislike programming in it and find it difficult to code in. This is not because I have only ever done Ruby or Javascript, I would consider my strongest languages to be Objective-C and Java, I have used C quite a lot, I know what I am doing with programming languages. I just di…

This sounds wrong...so I thought I'd see what Notepad++ has built into its syntax highlighting lexer (langs.model.xml): * ~ 35, Python * ~ 53, Java * ~ 59, Ruby * ~189, Bash * ~253, Perl Perl has a higher keyword count than Ruby or Python, but remember Perl's keyword list includes its core socket/network library (which Ruby/Python/Java don't contain in theirs...according to Notepad++).

Core network as well as many POSIX functions which other languages place in sub-modules (but still use the same names for). eg select() vs IO.select or mkdir() vs FileUtils.mkdir.

OP is clearly thinking of PHP.

Re: Why I Use Perl: Reliability

#179

Earlier quoted context omitted.

You also have to take the rest of the sentence into account too. English has a lot of words which mean different things depending on how they're pronounced (or, from the other side, that you can't know which way to pronounce until you already know the meaning), e.g. bass, close, desert, does, dove, familiar, have, intimate, invalid, lead, lives, number, object, present, produce, read, refuse, sewer, sow, subject, tea…

familiar? have? number? Don't think so...

Putting "would" in front of "have" turns it into "would've (wood of)" when spoken.

And the number 3 is different from your fingers being number now than they were before.

Not sure about 'familiar' though.

Re: Why I Use Perl: Reliability

#180
post #21

Earlier quoted context omitted.

Disagree. Readability and reasonable shoot-self-in-foot protection are not optional. See the article from earlier today about not catering to power users. Same concept. You can't really design a language for the top 5% of programmers and expect it to gain any sort of acceptance. (See: Haskell, Ocaml)

I completely agree with your first statement, but I have no idea how you get to your final statement from that. Ocaml and haskell are both on the "shoot self anywhere protection" end of the language spectrum. I used ocaml for a couple years and program in haskell for a living, and I assure you I am not in the top 5% of programmers.

Well, they are, but they fall into the "Designed for Top 5% of Programmers" trap.

Basically - it's a balance - don't be too dumb, but don't be too clever either. I'd submit Python as being solidly in the middle ground here.

Post reply on HN