Linked by David Adams on Tue 14th Jul 2015 23:21 UTC
Original OSNews Interviews From Linux Voice: "Perl 6 has been 15 years in the making, and is now due to be released at the end of this year. We speak to its creator to find out what’s going on."
Thread beginning with comment 614107
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[5]: Why perl?
by acobar on Wed 15th Jul 2015 16:31 UTC in reply to "RE[4]: Why perl?"
acobar
Member since:
2005-11-15

Had you ever worked with maintenance of code of someone else besides you ? If you had, chances are that you wished the coder had stick with standardized libraries instead of picking some random he thought were great and that didn't receive maintenance for a long time (i.e. is close to an abandoned carcass by then).

Anyway, I am not sure if my sarcasm detector is waning. ;)

Edited 2015-07-15 16:34 UTC

Reply Parent Score: 4

RE[6]: Why perl?
by Wondercool on Wed 15th Jul 2015 16:43 in reply to "RE[5]: Why perl?"
Wondercool Member since:
2005-07-08

I do maintain code written by others but the problems we solve aren't in the league of extremely complicated algorithms or problems and as such most code is still readable, just not my taste.

But yeah in Perl this is a bigger problem than in other languages but if you program often in Perl I don't think it is a big issue at all. I am certainly not a proponent of using exotic language features unless it is required.

That said: I don't think libraries are a particular problem of Perl. Just compare with Java where you have Log4j, SL4J, Logback just to name a few logging frameworks. Nowadays knowing your library is half the work, but that applies to many languages.

Reply Parent Score: 2

RE[7]: Why perl?
by Alfman on Wed 15th Jul 2015 19:47 in reply to "RE[6]: Why perl?"
Alfman Member since:
2011-01-28

Wondercool,


That said: I don't think libraries are a particular problem of Perl. Just compare with Java where you have Log4j, SL4J, Logback just to name a few logging frameworks. Nowadays knowing your library is half the work, but that applies to many languages.



Certainly this is true to an extent, but at least the standard Java libraries are designed under collaboration with the developers of the rest of the framework.

Perl modules are strewn together with no evidence of coordination at all. This wasn't so bad in the early days of programming when projects were self contained and the end result was all that mattered. But today's software is complex, requiring mashups of independent projects with many different subsystems working together. The absence of standard framework foundations can lead to unnecessary complexity and frustration when different pieces of the project use different abstraction libraries to represent the exact same data.

As you say, this problem isn't always unique to perl, but it is magnitudes worse. As cfqr pointed out above, some language designers explicitly aim to build a strong standardized foundation. Perl never had this goal, which is why it never achieved it.

IMHO perl is fine for small utilities and scripting, which is how I use it; I even prefer perl to bash any day! But I think the general consensus would be to avoid it for general large scale application development.

Reply Parent Score: 4