Live data from Hacker News

Why is Funding Perl Core Development So Difficult?

modernperlbooks.com

41–50 of 87 posts

Re: Why is Funding Perl Core Development So Difficult?

#41
post #30

Earlier quoted context omitted.

Signs of what exactly? That people like to argue about languages? Or are you saying that choice of language / stack should be dictated by popular trends?

He's saying "The lady doth protest too much, methinks". You don't have this problem with Python, Ruby, C++ or even C. I certainly don't see a "C isn't dead! Really!" post every other week.

To put it absolutely fucking bluntly:

Most Perl developers are grown-ups who are a) too busy solving problems and b) mature enough to not go and troll every post about a language they don't like.

On the other hand, Perl has attracted a handful of recurring names of amazingly dedicated detractors who seemingly have nothing better to do.

Re: Why is Funding Perl Core Development So Difficult?

#42
post #8

In part I think it's because Perl is done. It works. It's effective. Extending Perl beyond what Perl is makes Perl something else. Perl 6 is barely Perl in any classical sense. The "Swiss Army Chainsaw" was never intended to be Java or C#. Its weaknesses, a lack of formal typing, a small, simple set of core data structures, a terse and convoluted syntax, are actually its strengths. Just as C++ is not really C, and Ja…

Perl 6 sucked some air out of the room, too. The final, official decision to keep Perl 5 alive indefinitely and declaring them to be separate languages is still relatively young. But I tend to agree that to a large degree, it's done. Many new features that were mentioned would require major overhauls to the language. You can't just bolt "better parallelism" on to a language, for instance. And macros would make what i…

... macros would make what is already a fairly large language even larger, along with the fact that it wouldn't really buy you that much vs. what you can already do.

They would for me.

Re: Why is Funding Perl Core Development So Difficult?

#44
post #11

In part I think it's because Perl is done. It works. It's effective. Extending Perl beyond what Perl is makes Perl something else. Perl 6 is barely Perl in any classical sense. The "Swiss Army Chainsaw" was never intended to be Java or C#. Its weaknesses, a lack of formal typing, a small, simple set of core data structures, a terse and convoluted syntax, are actually its strengths. Just as C++ is not really C, and Ja…

The successor to Perl is Ruby. System administration used to mean Perl, now it means Ruby. Fast web development used to mean Perl, now it means Ruby or Python. The successor to Perl is Ruby.

When ever I drop in to write sysadmin scripts, I choose ruby, python or powershell depending on the platform. I never choose bash/dos batch/perl anymore. Granted I'm a developer who does sysadmin on the side.

Edit: (Python on ubuntu, Powershell on windows, ruby on everything else. Python on ubuntu since it's there out of the box)

Re: Why is Funding Perl Core Development So Difficult?

#45
post #44
post #11

Earlier quoted context omitted.

The successor to Perl is Ruby. System administration used to mean Perl, now it means Ruby. Fast web development used to mean Perl, now it means Ruby or Python. The successor to Perl is Ruby.

When ever I drop in to write sysadmin scripts, I choose ruby, python or powershell depending on the platform. I never choose bash/dos batch/perl anymore. Granted I'm a developer who does sysadmin on the side. Edit: (Python on ubuntu, Powershell on windows, ruby on everything else. Python on ubuntu since it's there out of the box)

I'm also a developer who still does sysadmin on the side (and probably far too much for my liking!) and I always write my scripts in Perl or bash.

And from what i've seen and anecdotally this still seems to be the common case (Java & Perl are the main languages used by companies in the City of London).

Re: Why is Funding Perl Core Development So Difficult?

#46
post #8

Earlier quoted context omitted.

Perl 6 sucked some air out of the room, too. The final, official decision to keep Perl 5 alive indefinitely and declaring them to be separate languages is still relatively young. But I tend to agree that to a large degree, it's done. Many new features that were mentioned would require major overhauls to the language. You can't just bolt "better parallelism" on to a language, for instance. And macros would make what i…

... macros would make what is already a fairly large language even larger, along with the fact that it wouldn't really buy you that much vs. what you can already do. They would for me.

You sound like you have a specific use case in mind. I'm curious what that may be, and what kind of advantage you're expecting over already-existing constructs that could be used to do the same thing. (Unless you've really got a use case that simply can not be done with existing constructs, which I'd also be interested in.)

Re: Why is Funding Perl Core Development So Difficult?

#47
post #46

Earlier quoted context omitted.

... macros would make what is already a fairly large language even larger, along with the fact that it wouldn't really buy you that much vs. what you can already do. They would for me.

You sound like you have a specific use case in mind. I'm curious what that may be, and what kind of advantage you're expecting over already-existing constructs that could be used to do the same thing. (Unless you've really got a use case that simply can not be done with existing constructs, which I'd also be interested in.)

I have a couple of deployed applications where I've found similar patterns of advanced control flow. In one case, a mixture of early exits and exception handling is boilerplate repeated dozens of times. I prefer not to copy and paste all of that code, but the only other abstraction technique Perl 5 gives me right now is to extract this behavior to some sort of Command Pattern object system, and that seems like a lot of complexity both in design and in surface syntax for what's just standard control flow.

Another pattern I use quite a bit is to write an parent application class which has the scheduling and task management behaviors of several subclasses (these subclasses each have separate and idempotent behaviors, such as "fetch newest data from remote server" or "republish static data from templates"). Most of the core behavior of each application is "loop over a task queue and process each individual element", the specific details of each task are so different that it's difficult to abstract further to push more behavior into the superclass. I could go further and use more higher-order functions, but there's a point at which you're building up a long chain of closures closing over closures just to avoid writing a loop, and I'm not sure that's practical.

Basically I want parametric custom control flow.

Re: Why is Funding Perl Core Development So Difficult?

#48

Earlier quoted context omitted.

Let's be honest, Python and Ruby have eaten Perl's lunch. All it's got left to argue for it is CPAN. The first startup I worked for, in 1999, was built entirely on Perl. At the time it was a good choice. It isn't now.

Outside of the start-up world Perl is still heavily used and Ruby is probably not quite as popular as you believe.

So why are none of the heavy users of Perl willing to stump up some cash to fund its development?

Re: Why is Funding Perl Core Development So Difficult?

#49

Earlier quoted context omitted.

Outside of the start-up world Perl is still heavily used and Ruby is probably not quite as popular as you believe.

So why are none of the heavy users of Perl willing to stump up some cash to fund its development?

They actually do. Check the Perl Foundation website. :)

Re: Why is Funding Perl Core Development So Difficult?

#50
post #46

Earlier quoted context omitted.

You sound like you have a specific use case in mind. I'm curious what that may be, and what kind of advantage you're expecting over already-existing constructs that could be used to do the same thing. (Unless you've really got a use case that simply can not be done with existing constructs, which I'd also be interested in.)

I have a couple of deployed applications where I've found similar patterns of advanced control flow. In one case, a mixture of early exits and exception handling is boilerplate repeated dozens of times. I prefer not to copy and paste all of that code, but the only other abstraction technique Perl 5 gives me right now is to extract this behavior to some sort of Command Pattern object system, and that seems like a lot…

Interesting, Can you please illustrate with an example how this could possibly end up looking like?

Will be nice to have something like this.

Post reply on HN