SoylentNews is people
SoylentNews
from the There’s-more-than-one-way-to-do-it,-but-sometimes-consistency-is-not-a-bad-thing-either dept.
Ruth Holloway at Red Hat's marketing site, OpenSource.com, has a retrospective on three decades of perl covering some history and a few of the top user groups. The powerful and flexible scripting language perl turns 30 at the end of this year. It is a practical extraction and reporting language widely used even today and has a dedicated community. It's ease of use and power made it the go-to tool through the boom of the 90's and 00's when the WWW was growing exponentially. However, its flexible syntax, while often an advantage, also functions as a sort of Rorschach test. One that some programmers fail. Perhaps two of its main strengths are pattern matching and CPAN. The many, mature perl modules available from CPAN make it a first choice for many when needed to draft something quickly or deal with a quick task.
(Score: 2) by http on Thursday October 12 2017, @02:57AM (8 children)
The complaint about perl looking like line noise has always looked like a bluff to me. Take these two (awful) sentences:
There's entire families of natural human languages which have definite and indefinite articles, and consider number agreement serious fucking business. English is one of them and you're using it.
Nobody complains about this "line noise" in human languages. Yeah, maybe you could drop them in some situations, but telling a listener "this is one of those situations where articles are not needed" requires more effort than just using the articles, and not only are you at risk of being misunderstood, you have to say when you're switching back. Count me out.
I browse at -1 when I have mod points. It's unsettling.
(Score: 5, Insightful) by Thexalon on Thursday October 12 2017, @04:22AM (7 children)
That's not the complaint. The complaint is Perl that looks like this:
That makes it nearly indistinguishable from line noise. Yes, you can write incomprehensible gibberish in any language, but Perl makes it easier than many others, especially with all its regex-related features.
The only thing that stops a bad guy with a compiler is a good guy with a compiler.
(Score: 3, Informative) by Anonymous Coward on Thursday October 12 2017, @04:42AM (2 children)
Perl makes it easy, as does C, Javascript, PHP and others. Note: this program is *deliberately* hard to read, not just golfed, so the comparison should be made against IOCCC, obfuscated Javascript and similar code.
If you used maintained production code to make your point, we would have something to talk about. I'd probably show you a gargantuan unification error spat out by a C++ compiler to rejoin, but at least we'd be talking about real code.
I'm sorry but your argument is either ill-considered or disingenuous.
(Score: 3, Insightful) by forkazoo on Thursday October 12 2017, @07:09AM
Perl's enthusiasm for things like regex as a first-class language feature tend to mean that a lot of ugly perl gets written. Compare that to a language like Python where readable use of whitespace is considered a first class language feature, and it's not shocking that Python tends to be more readable than Perl in practice. Sure, it's possible to write ugly code in any language. But Perl is a language where it tends to be easy to make things ugly.
(Score: 2) by canopic jug on Thursday October 12 2017, @07:53AM
Indeed. Obfuscated code contests exist for many languages. So the comparison is not apt.
Perl also makes it very easy to write simple to read code as well. Programmers should naturally, but often don't, gravitate to writing clear, easy to read code because code is read many more times than it is written. So the best cost reductions can come from reducing the burden of reading, especially when other people or the passage of time is involved and therefore programmers need to aim to write clearly. It takes both practice and will. One thing prevents that are the rush to just throw work over the fence and call it finished, same as in any other language. If the coding team, especially the boss, accepts or rewards hard to decipher work then that's what will be produced, regardless of language.
Messy code can be overcome by a group decisions to do so. An example is what the OpenBSD developers do with their C code by enforcing style(9) [openbsd.org]. It is certainly in any team's self interest and even in programmer's own self-interest to strive to write clearly. Yet some don't. Thus the comment about the Rorschach test.
Money is not free speech. Elections should not be auctions.
(Score: 3, Insightful) by The Mighty Buzzard on Thursday October 12 2017, @09:17AM
Reading a highly optimized perl script is no more difficult than reading highly optimized C. You need mastery of the language rather than casual familiarity to do either. If you have that mastery, neither are difficult to read unless intentionally made so.
My rights don't end where your fear begins.
(Score: 2) by Phoenix666 on Thursday October 12 2017, @10:39AM (2 children)
Most code will look baffling if you run all the lines together like that. Vim has a great plug-in, perltidy, you should run.
Beyond that it seems intelligible to me, once you understand regex's.
Washington DC delenda est.
(Score: 1, Funny) by Anonymous Coward on Thursday October 12 2017, @12:08PM (1 child)
FTFY
(Score: 0) by Anonymous Coward on Thursday October 12 2017, @04:01PM
No, Emacs doesn't have plugins. It has packages.