For now, Perl 6 is quite a moving ground for any implementation. And, indeed, that's why nobody is using any implementation of it on production systems (AFAIK), despite the reference implementation of it being quite stable by now.

For now, Perl 6 is quite a moving ground for any implementation. And, indeed, that's why nobody is using any implementation of it on production systems (AFAIK), despite the reference implementation of it being quite stable by now.

That, and the fact that it comes too late. Perl 6 has been a work in progress for fifteen years, and in that time, the world has moved on somewhat.

Fifteen years ago, I'd have used Perl for almost everything - now, I'd use Python for most of the same tasks, or sometimes Node. Perl is a powerful language, but compared to newer rivals, it's a pain in the ass to work with... and from what I've seen, Perl 6 doesn't offer enough improvement to win people back.

Somewhat Perl 6 lost his reason to be since Perl 5 got his development resumed few years back.

So, Perl 5 himself evolved quite a bit these last fifteen years. Several features from Perl 6 ended being backported to Perl 5, and new ones was implemented, to the point that both languages now evolves in parallel. In many ways, Perl 6 got so long to be usable that Perl 5 got a life of his own.

Now we are in the odd situation of the old language supplanting the new one.

I can only speak from a personal point of view - I still code (professionally) in Perl from time to time.

I just love the language, mostly because there are 1000s of (perfectly good) ways to get the same thing done. That means that your own style and expression of coding are more important than in other languages.

When I started coding in Perl I was cursing it like anyone else, but I have come to appreciate the flexibility of the language and its versatility. For instance, it's quite an achievement that Perl supports Object Oriented Programming with a minimal change to the language.

I actually really like the language: hashes and arrays our of the box with all the manipulation functions, auto-vivification, interpolation of strings, file handling. Yes you can screw it up the readability royally and the language requires discipline but at least everything is possible.

I also like the gigantic library of useful code called CPAN and the extremely knowledgeable and friendly Perl community. See www.perlmonks.org

And I also really like the really good builtin documentation (perldoc), character and language support, package managers and mostly the builtin debugger.

I just love the language, mostly because there are 1000s of (perfectly good) ways to get the same thing done. That means that your own style and expression of coding are more important than in other languages.

It's funny because Perl and Python are languages that have very similar use cases but have a very distinct ideology and approach.

I personally prefer Python's way. The expression is in the structure of your data and the architecture built around it, not in the code that is derived from it. Get your data structures right and the code should write itself.

That's nice about having the choice. We're all different and what doesn't work for me, might just work all the better for you. So let Perl flourish!

That's funny as it's the complete opposite of the Zen of Python: "There should be one-- and preferably only one --obvious way to do it."

I still use perl because it's always there (alot like VI actually), but this 1000s of ways has got to be one of my biggest gripes with it, since there's absolutely no possibility of mastering it. Everyone just learns a small subset and goes with it, this is especially true with modules. Devs wanting something better keep building new modules and wrappers with enhancements, which would be fine except that thousands of developers have the same idea. Without more discipline in synchronizing their work, it results in severe duplication and "not invented here" syndrome.

Yep, that's one of the two main reasons I don't really like Perl. The other being that Perl's syntax is just too cryptic and ugly.

Personal styles usually suck anyway. I've always followed a very clean coding style, or so I thought, until I threw my (python) code through a PEP8 linter. I didn't believe it would make much difference, but the readability and consistency definitely improved. Some very smart people gave those things a lot of thought, why would my gut feeling be any better?

But then, I guess everyone's got different preferences and who am I to deny others having fun. Some people love puzzling. Let them enjoy it! As long as they stay away from my work.

As a side note, the above is also a bit why I'm not a huge fan of templating inside languages (such as Clojure). It again provides too many ways in which you can express the same thing. I'd rather have more explicit templating outside the language (i.e. strings or different files).

IMHO the fact that there are 15 different Date modules in CPAN isn't a big problem at all, it is a feature.

Just like the 10s of Desktop managers, init systems, file systems, distributions in Linux, this is what makes it strong. It means you aren't coerced into using some shitty API but can pick what suits you.

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

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.

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.

I strongly disagree with that sentiment. If that's the case why aren't we all programming in Fortran or Cobol? Both are perfectly functional and Cobol particularly is quite maintainable and easy to read.

Also - and this is hard to define, it is a subjective feeling - it seems to me that elegant, pleasant, concise, well formatted, 'beautiful' code is easy to maintain rather than the stuff that just fits the coding standards of the company.

I strongly disagree with that sentiment. If that's the case why aren't we all programming in Fortran or Cobol? Both are perfectly functional and Cobol particularly is quite maintainable and easy to read.

Because they're not all equally functional for a job. There are problems for which Fortran is traditionally very well suited, hence it's ongoing popularity for those problems - for those problems, it does the job required better than anything else.

But you wouldn't use it for everything, because for other problems, other languages do a superior job of expressing the solution to that problem. And it's nothing to do with beauty, any more than the decision to use a hammer versus a screwdriver for nails and screws - it's simply that a hammer works better for one case, and the screwdriver works better for another.

And my problem with Perl is that while it used to be indispensable to me as a tool, these days I can't think of any problem that another tool won't be at least as well suited.

Also - and this is hard to define, it is a subjective feeling - it seems to me that elegant, pleasant, concise, well formatted, 'beautiful' code is easy to maintain rather than the stuff that just fits the coding standards of the company.

I think you have that around the wrong way. The purpose of writing concise, well-formatted code is to ensure that the next person to maintain it (possibly yourself) can read it. Maintainability is the driver - any aesthetic quality is a side-effect of something well suited to purpose...

I just love the language, mostly because there are 1000s of (perfectly good) ways to get the same thing done. That means that your own style and expression of coding are more important than in other languages.

This is why I never want to use it for anything that anyone else will ever contribute to. Everyone has their own style and in perl they are greatly exaggerated and its difficult to get people to switch

Yes you can screw it up the readability royally and the language requires discipline but at least everything is possible.

Yes, I agree. And yes its difficutl to get more than a few people to share the required discipline.

This is why I never want to use it for anything that anyone else will ever contribute to. Everyone has their own style and in perl they are greatly exaggerated and its difficult to get people to switch

Yeah. I've (unfortunately) had to maintain some perl code and quickly realized that out of the 9,000 different ways there are to do one thing in perl, perl coders usually gravitate to the most cryptic and hard to read way, because they seem more interested in showing off than actually writing readable code. And you know what I'm talking about too... the kind of code that looks like modem line noise, without a comment in sight.

And I think they do it on purpose too. If you ask me, they've gotta be compensating for something. Penis size, perhaps

The modem static noise style is great, but it takes too long to load up all that parsing logic in your head unless you do it on a daily basis. I deal with output that's as crazy as that regularly. But it just becomes second nature. But yeah, I've turned down perl jobs because its just too much to maintain.

I just love the language, mostly because there are 1000s of (perfectly good) ways to get the same thing done. That means that your own style and expression of coding are more important than in other languages.

Which is funny, because I (and most of my colleagues) regard that as one of it's biggest weaknesses. Too many ways to do the same thing, so that unless you're an expert in all of them, it's all but impossible to maintain code written by someone else according to their own personal style and expression.

I actually really like the language: hashes and arrays our of the box with all the manipulation functions, auto-vivification, interpolation of strings, file handling. Yes you can screw it up the readability royally and the language requires discipline but at least everything is possible.

It's been a long time since most of those features were considered to be anything more than *absolute minimum* functionality for any popular scripting language.

It's been a long time since most of those features were considered to be anything more than *absolute minimum* functionality for any popular scripting language.

You would think so, I tried to learn Ruby lately but it isn't easy. I couldn't understand why it wouldn't accept constructs like my_array[][] and it turns out that you have to create your own overloading to do auto-vivification. I just couldn't believe it.

You would think so, I tried to learn Ruby lately but it isn't easy. I couldn't understand why it wouldn't accept constructs like my_array[][] and it turns out that you have to create your own overloading to do auto-vivification. I just couldn't believe it.

"Most" of those features, I said. Auto-vivification isn't supported by many other languages, but you're also citing such basic things as arrays, maps, and file handling. These aren't exactly unusual features in a scripting language...

As to auto-vivification, it *is* a nice feature, particularly for nested map structures, but not so nice as to outweigh all the other issues with the language...

Autovivication causes headache and bugs. I'd rather initialise an object explicitly. It's just too error prone and it takes too long to figure out what's going on: "are we accessing something that is already initialised or did the author intend to initialise it here? Or did the author make a mistake by accessing something that he forgot to initialise somewhere?"

There is also no coherence, some functions do it, others do not. It consumes more brainpower than necessary, energy that could be used for more important things.