Stories
Slash Boxes
Comments

SoylentNews is people

SoylentNews is powered by your submissions, so send in your scoop. Only 16 submissions in the queue.
posted by Fnord666 on Thursday October 12 2017, @01:07AM   Printer-friendly
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.


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 0) by Anonymous Coward on Thursday October 12 2017, @11:57AM (1 child)

    by Anonymous Coward on Thursday October 12 2017, @11:57AM (#581087)
    PHP is even worse from that perspective and yet it's still very popular. Even Facebook was using it and is still using it or a version of it.
  • (Score: 2) by tibman on Thursday October 12 2017, @05:39PM

    by tibman (134) Subscriber Badge on Thursday October 12 2017, @05:39PM (#581235)

    In my experience PHP has all the functionality you need baked into it*. Most libraries i've seen just force you to use a pattern that you could be using without the library. Though i still prefer parameterized sql over an abstraction library that builds objects from your db schema. Just keep your db calls in a separate layer and you'll be fine. It turns into a mess when people are doing sql calls from controllers/views/high-level places. Every language has issues like that.

    *UI libs are an exception

    PS: I don't write php for profit. Just for fun : )

    --
    SN won't survive on lurkers alone. Write comments.