All the Perl that's Practical to Extract and Report

Navigation

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Without JavaScript enabled, you might want to
use the classic discussion system instead. If you login, you can remember this preference.

Please Log In to Continue

Great conversation here. Glad that people are willing to engage in it thoughtfully. (Many thanks to Alias for the conversation starter.)

@educated_foo [perl.org]: The reality is that people are using Ruby, and Rails, for more than just scripting up "shiny-looking web page with minimal effort." (I'll concede the point about DHH's hair.) They're using it for all kinds of crazy stuff, like writing desktop applications and large-scale messaging services like Twitter. (All things that Perl can do equally well.)

Desktop applications? I haven't seen any yet (I don't count web apps), so can you point me in the right direction?

AFAIK, Twitter is just a shiny web app that throws a lot of servers at a problem. Other than the web interface, it seems like the whole thing could be done with text files and a UDP server. Rails actually seems like a terrible fit for what Twitter is doing; it seems better suited for the simple, low-traffic web interfaces that most small businesses want than for a high-traffic buffered message queue.

Admittedly, I think that's what you're saying with "package up your code in a way that others can use it."

Exactly. UNIX, C, Perl 5, and Rails worked because they were first written to solve actual problems, then cleaned up so they could be used by others. I expect Perl 6 will fail because it's not directed at an actual problem ("keep Perl moving" and "make Perl clean" are too vague).

most of the people using frameworks like RoR and Django have made the choice to learn them recently.

Fads count for a lot in programming. Perl, Python, and Ruby are all roughly similar at a technical level (though Perl gets variable scoping right), so if I don't know any of them, then all else being equal, I'll choose the one most likely to make me look cool and/or get me a job. But immediate usefulness also counts: if one of them has a ready-made solution for my specific problem, then I'll probably choose that one. Perl seems to have done well 10 years ago for its text munging and CGI handling. I (thankfully) don't have to write web apps, but Ruby became popular because other programmers were forced to write them, and Rails made that less painful. I hope people don't lose sight of the fact that the most important goal of any programming tool is to be useful. You don't need to shine a diamond, and you can't shine a turd.

Just to take one example, "the AUTOLOAD subroutine should be able to decline a request" may be a shortcoming of the Perl language, and may annoy some Perl programmers, but it's not a "problem" in the sense I intended. "I need to offer my company's widgets for sale on the web" is a problem. "I need to convert this UniProt file to FASTA" is a problem. If you design a programming language while thinking about programming languages, you get Scheme.

If you design a programming language while thinking about programming languages, you get Scheme.

That's a lovely slogan, but in the real world I suspect it's meaningless.

If you don't think about programming languages while you design a programming language, I wonder how you add features that are specific enough to address real design problems while general enough to allow people to use them to address problems that didn't exist while you were designing the language. I wonder how you balance elegance and t

I missed a "solely" there: "If you design a programming language while thinking *solely* about programming languages, you get Scheme." If you look at the languages that endure, most were designed by smart people with specific problems to solve: John Backus wanted to TRANslate FORmulas to machine code, and created FORTRAN; Dennis Ritchie wanted to program his PDP-11 in something higher-level than assembly, and created C; etc.

Perl fit(s) into this tradition. Perl 6 hasn't quite figured it out yet.

"AFAIK, Twitter is just a shiny web app that throws a lot of servers at a problem. Other than the web interface, it seems like the whole thing could be done with text files and a UDP server. Rails actually seems like a terrible fit for what Twitter is doing; it seems better suited for the simple, low-traffic web interfaces that most small businesses want than for a hi