Hacker News Reader

Comment by astrodust | Hacker News Reader

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 Java is certainly not C++, Perl would be better suited by some kind of successor language that embodies the Perl spirit without having to carry forward on the same code-base or concern itself with legacy. I don't think Perl 6 is this thing.

View on HN

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 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.

... 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.

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

Will be nice to have something like this.

Quite a bit of work is still being done on Perl 5.

http://news.perlfoundation.org/2011/05/perl-514.html

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.

I think that you are vastly overestimating Ruby's popularity outside of the HN crowd.

I'm not into the whole sys-admin thing or the Ruby hotness or the Node.JS hype but I noticed that there are more utilities or tools that are written in Ruby lately.

CloudFoundry seems to be written in Ruby and it looks like a bunch of sys-admin tools.

Chef, Puppet are both written in Ruby and utilized Ruby (or Ruby DSL?).

There's a strong push for Ruby lately and it might be because Ruby is kind of similar to Perl so some sys-admins are okay with that?

Agreed. Ruby is very popular in a few smallish circles. It's still essentially unknown pretty much everywhere that isn't a small web-based startup.

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).

Actually nothing ever truly replaces those classic tools bash/awk/sed/perl.

But every now and then you will see <insert some new tool> being compared with a <insert classic tool>. And then told since the <insert some new tool> is a little famous now, its likely to replace the <insert classic tool> and that <quote some irrelevant search engine statistic> actually proves <insert classic tool> is dead and <insert some new tool> is actually going to replace the <insert classic tool> in the future.

Then suddenly expect a stream of tweets, blog posts and forum discussions on how useless <insert classic tool is>.

Please replace <insert classic tool> by "Perl","SQL","Php".

Please replace <insert some new tool> by "Python","Ruby","Tcl","NoSQL","Django"..

Please replace <quote some irrelevant search engine statistic> by Google search stats or Tiobe(Which is the same ,but presented differently metric).

Totally agree.

While it's good to always review your tools & skills... spending lots of time looking at sparkling new things could be better focused on i) getting work done or ii) improving your proficiency with current tools :)

Well said.

Sometimes a new tool will come along that truly is a huge improvement on previous tools. But, when those previous tools are "classics", it's pretty rare that the "new" tool is truly that much of an improvement.

There's a reason that these things (bash, sed, awk, perl, SQL, Unix/Linux, etc) are still popular and still going. It's because they're time tested, they're well known, and they work.

I'm a sysadmin who does development on the side.

When I start writing something, I think about how big I expect it to be. If it's expected to be 50 lines or less, then it's bash for general scripts, and awk for text filtering. If it's expected to be more than 50 lines, I go with Perl. That goes regardless of platform (as it's already available on every *nix platform I use, and Strawberry or ActiveState makes Perl easy to add on Windows).

Yeah, I'm gonna have to completely disagree with you here.

I'm a sysadmin that does a decent amount of automation and scripting work. Almost all of that is done in Perl. Among the other guys on my team, everyone uses Perl, except for one person who uses Python.

We had one person who came into the team as a Ruby fan. Within 6 months of working with us, she'd become a Perl fan. She told me she'd passed on Perl and gone to Ruby because she'd heard bad things about Perl. After seeing it in use and checking it out a little closer, she realized that almost everything she'd heard "bad" was outdated, incorrect, or overstated.

Outside of my team, I know lots of people who use Perl, a decent number of people who use Python, and a very small number of people who actually use Ruby. Yeah, there's a few high-profile apps in it, and yeah, Ruby on Rails got it a lot of attention for quick and dirty web apps, but it has a long way to go before it'll reach anywhere near Perl (or even Python) is.

Reply on news.ycombinator.com