Everyone knows it as Perl 6. Therefore, everyone who would write about it after this proposed name change would say "formerly known as Perl 6," so that people know what you're talking about. All the conceptual baggage remains.

(And the reason the Perl name is a boat anchor is because someone hooked a chain to it and sank it to the bottom of the ocean. Perl didn't die from natural causes, Perl was killed by neglect - neglect caused because Perl 6 was always right around the corner and why sink more effort into maintaining Perl 5 than was absolutely necessary? So now OG Perl is stuck on 5.x from now until the heat death of the universe, because this project poisoned the well.)

thanks for the deep words, Kosh

http://youtu.be/g1GF4Gnb-D0

What are you talking about? ( http://perldoc.perl.org/index-history.html ). A lot of the releases in the last decade were inspired by Perl 6 features. And Moose is clearly inspired by Perl 6.

I've spoken with people who believe the last Perl release was 5.8 (released in 2002). I believe this is caused by many Linux distributions still shipping old copies of Perl 5, but it's incredibly annoying.

I don't think the name is the problem, I think that there is just too much competition among languages. If you ask a younger person which language they want to learn, will they think of Perl at all? Where is it used? Everywhere isn't an answer, Web or application programming or Apps are answers. What can I use instead that recruiters think is cool/relevant is also a fair question, albeit a simultaneously stupid one.

Perl may even have some of that Lispy retro-mystery.

Not sure about the marketing value, but it's properly geeky.

Is that what P6 feels like?

that might be also because you are not familiar with perl6 though, a form of blub paradox.

I.e. are perl6 grammars better for parsing than anything available for python? Maybe or maybe not, but one needs to know them before being able to judge.

The strong features of Perl that I know (which might be completely wrong): Regex and huge library. Both features are not distinct to Perl anymore though. Perl's regex might be a little better than Python's or AWK's but probably not enough to make it worth learning it.

And yes learning a new language to level that you not just know the syntax but also a few of the important libraries, blogs and developers is a huge task that takes several months. If you are not a student any more you really need to think hard before you commit to something like that. Sure there are people who just learn new languages for fun as a hobby. But that's not your target audience if you want your favourite language to become more popular.

That might have been the idea behind the ariginal article ("hey, Perl 6 has built in rational types").

As an example look at this Perl 6 grammar for JSON: https://github.com/moritz/json/blob/master/lib/JSON/Tiny/Gra...

Perl 6's best feature is that it combines many features from many languages in a way that allows combining them cleanly, and without any of them feeling like they were glommed on. (unlike Perl 5's object system which was inspired by Python's object system)

If you can get past the syntax differences from other languages, and program in it for a while, you may never want to go back to any other language.

If you can't get past the syntax, please say that you "don't like the syntax" instead of "it's unreadable" or "it's a write-only language" or "it's difficult to learn". ( I for one found it quite easy to learn, and can read it quickly. )

---

Really can you make all of the following examples clearer in any other single language?

  constant powers-of-two = 2,4,8 ... *; # an infinite deductive list

  # perhaps that would be more clear as:
  constant powers-of-two = 2, 4, 8, 16, 32, 64 ... *;

  # list of pairs using the zip meta-operator (Z)
  # combined with the pair constructor operator (=>)
  my @a = 'a'..'z' Z=> 0..*; # ( a => 0, b => 1, etc )
  my $new-password = ('a'..'z','A'..'Z',0..9).roll(12).join; # 'ygHIHbi4XgUV'

  # the zero in the following is to prevent an off-by-one error
  # when accessing by index
  # * + * creates a code ref that takes two inputs and numerically adds them together
  constant fibonacci-list = 0, 1, 1, * + * ... *;

   # takes about a second the first time it's accessed currently
  say fibonacci-list[10000].chars == 2090;

  # if you wanted it to look more like haskell you could write it like this:
  constant fibonacci-list = 0, 1, 1, &[+] ... *;

  my @dice-rolls := ('⚀'..'⚅').roll(*); # infinite list of dice rolls

  # deck of cards using the cross meta-operator (X)
  # and the string concatenation operator (~)

  my @deck = 2..10,<J Q K A> X~ <♡ ♢ ♣ ♠>;

  my @shuffled = @deck.pick(*);

  # ( .say ) is short for ( $_.say )
  # prints the first 6 numbers (0..5) each on it's own line
  for ^6 { .say }

  # prints the numbers 0..5 each on it's own line,
  # possibly randomized,
  # possibly each in it's own thread ( texas version )

  (0..^6)>>.say;
  (^6)».say; # ditto ( french version )

  # ( those were purposefully misusing an auto-threading list operator >> )

  # says a random number (1..5), 5 times out of 6
  if (0..5).pick -> $number { say $number }
  if (0..5).pick { say $^number } # ditto

That was just a sampling of the bread-and-butter constructs (some of which were used in a way that most people wouldn't use them). There are also operators for dealing with Sets for example. ( ⋃ and (elem) being two of them )

see: http://doc.perl6.org/

You can even create new operators the same way you define a subroutine ( That's all they are in the Rakudo implementation, for most of them. )

  # common factorial example
  sub postfix:<!> ( Int \n where * >= 0 ) is tighter(&infix:<*>) { [*] 1..n }
  say 5!; # 120

There is a set of programmers with whom this won't go down well. Enterprise programmers and the hipsters.

(Note: I'm the guy who wrote the post OP linked to)

Because, obviously, if people don't like what you made, it's just a question of what you called it.

Some of the semantics seem really nice, but the syntax is utterly disastrous.

But I've also written some of the most maintainable code I've ever seen in my career in Perl. One project in particular was over 30k lines long (which in non-Perl languages must be worth millions of lines of code ;).

It was put aside for a few years (4 or 5 IIR), then I had to return to it to do some maintenance and inside of an hour was able to digest the code-base, make the needed changes, test and release.

Sloppy code and poor design infects every language. Perl does make it easy, but that's because Perl has a design emphasis on one-off scripts in the same way Java has an emphasis on large-team collaboration, and write-once run-once is what makes Perl so absurdly productive.

Just like with any language, you set some code standards and some overall design principles and you can write really maintainable code in Perl.

My wife has a similar story, after learning some basic Perl, she waded into a 100k line Perl codebase and in a couple days refactored some memory intensive code to use cheaper data-structures in a memory intensive part of the code. It was no-big-deal, but that's because the original team had left things well documented and wrote along sane standards.

The problem with Perl is most times people are exposed to it, it's either from code golfing sessions were code is deliberately obfuscated; or when it's basically been used as a shell scripting language and thus often written by aging Perl hackers who don't care much for code cleanliness. And sometimes people just run away screaming because they simply don't understand all the regular expressions (but to approach Perl without an understanding of Regex is a little like trying to code Java without understanding classes then moaning about the weird surplus boilerplate code)

I'm not trying to say that Perl doesn't have it's faults. It has a great many problems. But to state that Perls syntax makes it impossible to write clean code, is just a daft flamewar argument.

In python you have: dog.head.ears[0].hairs[123]

In perl5 you have: $dog->{head}{ears}[0]{hairs}[123]

I can see why some folks prefer the former.

In modern Perl the attibutes would be accessed through accessors so the original example needs tr/{}/()/

In my personal opinion, I prefer C-style braces over whitespace formatted blocks. Which means I find reading function and iteration blocks much easier to read in Perl than I do in Python. I'm not saying one is "better" than the other, but just offering a counter argument for how subjective language aesthetics really is.

Perls OOP does feel like a bit of a hack. But it does make it transparent how everything works. I learned Java at University, and everything OOP was a black box and I had no real understanding of how it worked. After learning the Perl way, its really obvious what is going on because it is so transparent. Your current object doesn't have a method? Just look along the @ISA array until you find an object that does have it.

Pythons whitespace is a pain at first, but having used it for a few years, one problem I do not miss is loosing a brace, when reorganizing blocks of code. You cut a few lines of code and paste it somewhere above or below, and your IDE shows you you are missing a brace somewhere. The indentation looks fine, so you can't see where it is.

The whitespace thing is worth it to get rid of that problem alone.

Arguing that one is better than the other is like arguing over which colour the best. Which is why I get so utterly sick of Perl being compared with Python - they are all going to have their strengths and weaknesses so at the end of the day, the "better" language / syntax boils down to personal preference.

I personally haven't wasted anywhere near as much time with Python indentation compared to missing braces. I hated the whitespace thing at first, and it was only after going back to doing some Perl I noticed that the problem wasn't present in Python.

Though the fact that most other languages use braces is a pain, as it makes swapping between Python and Java / Perl / JavaScript / etc tricky, as I tend to get into the habit of using or not using semicolons at the end of a line.

And in both cases, that is terrible code. Use a class or something...goodness.

How is what someone who DOESN'T know Python would think relevant?

That said, after even the smallest familiarity with the language, he sees that it's obviously not method calls unless it ends in ().

Someone who doesn't know Lisp also doesn't know what (foo 4 2) or (quote foo 4 2) is.

Saying that the snippet is obviously not using method calls is naive. Python is too flexible and allows programmers to do too many clever things for that, all hidden under "nice" syntax.

EDIT: Forgot a case for what that code could be doing: it could be accessing a module with globals.

Because most of the people that complain about Perl don't know it either.

I have no problem reading perl code of any kind (because I know it). Perl is a beautiful language IMHO.

Much of the uglyiness can come from trying to write code for another language in perl syntax. Perl lets you write code that looks live Java, or C, or many other languages, but it usually ends up looking ugly. I see a lot of this.

But when you write perlish perl, especially using modern features of the language, then... yeah. It can look as beautiful as any other language.

So, it's definitely possible to write non-trivial Perl programs without feeling ill.

I'm actually learning more of it right now, so I can clean up and modularize some of my scripts. Because my other options (ksh93, Progress 4GL, and maybe older versions of Java or C++) are even less suitable.

1: https://metacpan.org/favorite/leaderboard

2: https://metacpan.org/release/Path-Tiny

3: https://metacpan.org/release/Try-Tiny

4: https://metacpan.org/pod/Function::Parameters

5: https://metacpan.org/pod/Task::Kensho

The validation is unfortunately at runtime, but at least you get a clear error instead of unanticipated behavior. Moo (and it's bigger parent, Moose) can really help you structure your application better using roles.

https://metacpan.org/pod/Moo https://metacpan.org/pod/Type::Tiny

Edit: Don't use Params::Validate; kbenson's recommendation for Function::Parameters looks awesome!

[1] https://metacpan.org/pod/Kavorka

[2] https://metacpan.org/pod/Moops

https://duckduckgo.com/?q=CVE+2013-1667&ia=about

http://blog.booking.com/hardening-perls-hash-function.html

I would also recommend reading "Modern Perl" which is made available for free by the publisher/author at http://modernperlbooks.com/

( Also there are large codebases written in Perl ( I beleive booking.com is an example )

I also recommend installing the Perl you are using outside of the system directories. You may also find Pinto and https://Stratopan.com useful for managing your dependancies. Which is especially useful if you make your codebase modular.

For that matter, ditto for Java. Ideal Java code seems to be "not notable", rather than "beautiful". At its best, it is clean and clear but unexciting, like a Honda Civic.