And to respond to some commenters, yes, some features (like the shrug operator) were presented in a humorous fashion. No one's advocating you actually make your code look like an orgy of emoticons. I didn't use PPT for the slides, because I like the freedom of needing only a browser to display the slides. They weren't really meant for public consumption, thus the UI is not entirely obvious.
I'm unsure why the person who posted this on HN posted only the slides and not the recording or the blog post. But I have no control over that.
And if anyone has any more questions, you can join us on IRC at irc://irc.freenode.net/#perl6
I understand that the video was not meant for public consumption, but I'll still say this, as a general note: It's way more easier to follow when the questions are at the end, and the presentation is not interrupted. I see many speakers saying "Hey, I'd like this to be an interactive thing, interrupt me if you have a question", and although this is nice for offline events, for a talk that'll be published, a more old-school interaction makes the things easier for the guy who watches the video.
Yes, I guess that makes sense. But I think in a 1.5hour talk, many of those questions will be forgotten by the end, so I rather they get asked right away. Especially in a small gathering of 20 or so hackers, most of which know each other.
No, I just took it from another presenter and changed the content of the slides. I believe it's actually a themeable slideshow thingie someone else developed.
My boss came up with a good analogy to describe why some people like Perl and why some don't. There are some people who appreciate games that are very abstract and with simple rules from which complex behavior emerges, such as a game like Go. These people tend to be drawn towards programming languages that are built out of small pieces with a consistent philosophy from the ground up, such as lisp or Haskell. There are others who enjoy games with complex rulesets and lots of detail. These people probably like Perl with all its nooks and crannies.
Perl code has many things to discover, and the way you assemble larger things relies on unique features of these smaller things. While in the end both approaches have you building a larger thing out of smaller things, the former approach is more likely to be built out of all of the same small thing, while the latter is more likely to be built out of a bunch of different small things. I think that's why some people can find Perl code to be "dense" and others find it "expressive".
I think Perl 6 was built with a much more consistent philosophy behind it than Perl 5, so this analogy breaks down a bit. But the user experience, the "Perlishness" of it, still remains. To the extent that people pick sides in language wars, I hope this analogy can help people appreciate the other side.
I think this theory is too simple. For example, I find both well-written Perl and Haskell to be beautiful.
It's a bit like saying some people only like minimalist writers and some people only like maximalist writers. But a discerning reader is interested in quality over the style. That is, they recognize that there is good maximalism and good minimalism, and appreciate both.
And that's true of reading, but notice that you refered to "minimalist writers" and "maximalist writers" rather than minimal and maximal works. Because most people do choose one over the other when creating rather than consuming.
I disagree with the suggestion that Perl is not built with a consistent philosophy. That philosophy isn't "build from a minimal set of orthogonal features", but it's a coherent design philosophy:
Many (but not all) of the questionable decisions in Perl come from its origins in Unix philosophy and the desire to provide a comfortable migration path for system administrators away from command-line tools such as awk and shell. Where Perl's struggled in recent years to borrow features from Rakudo, it's because those features assume a different underlying philosophy.
I'd also suggest the purpose matters. What languages I like to use for my own personal work vs. what I want for professional work are quite different.
Perl 6 may have a theoretically more consistent philosophy behind it than Perl 5, but as that philosophy would likely lead to even more complicated code than Perl 5 already does, I would live in fear of anyone at work adopting it for code I then have to maintain. Except that there doesn't seem to be any chance of that, precisely because everyone else around me feels the same way.
I hope it's permissible to contribute to an explicitly "opinion" subthread. Given that premise, here's my 2c:
I'm not a lover of Scala, in fact I tried it and gave up on it because I didn't like its ratio of cleverness to simplicity (again, a personal opinion). But that said, and also being reasonably familiar with Perl, I would say that Scala is still much cleaner, more consistent, less idiosyncratic than Perl. I've seen some beautiful, expressive, masterful Perl code but I find that Perl really doesn't encourage me to write that way, while Scala works a bit harder to nudge you to write elegant code.
Absolutely! I hadn't looked at Perl 6 before the OP's presentation.
But isn't Perl 6 a full superset of Perl 5? That would mean the full clutter is still underneath, and some people will continue to code Perl 5 in Perl 6.
Perl 6 is carefully designed to be able to smoothly use other programming languages and their compilers and/or libraries. The most advanced implementation of this concept is (re)use of Perl 5:
use Inline::Perl5;
use DBI:from<Perl5>;
my $dbh = DBI.connect('dbi:Pg:database=test');
# etc.
The first line happens to be valid Perl 5 syntax as well as valid Perl 6. But the next two are Perl 6 code that calls Perl 5 code behind the scenes. In principle those who write such Perl 6 code don't need to know any Perl 5 whatsoever. (In practice current API docs assume use of Perl 5 so there's that.)
The same is true for Python code etc. (though the sugar isn't yet as sweet):
use Inline::Python;
my $py = Inline::Python.new();
$py.run('print "hello world"');
So Perl 6 is either a superset of Perl 5, Pythons, Java, Lua, etc. or it's not a superset of any of them, just good at working with them, depending on how you look at things.
Scala has additional considerations going for it with its integration into the JVM ecosystem.
That said, may I observe that the hype seems to have died down for Scala. Everyone I personally know who was into it has dropped it. None of them would have shipped anything into production. Anecdotal, sure, but that's all we ever really have. My guess is that its own complexity is indeed strangling it. Only time will tell, but I'm not sure Scala is really that great an argument.
And, also, for consistency, yes, absolutely, I wouldn't want to suddenly be handed a Scala system to professionally maintain either.
The simple theory I use for explaining Perl preference is that it correlates to your preference and tolerance of postmodernism in general. http://www.wall.org/~larry/pm.html is a good elaboration on the postmodernism of Perl, I think.
I started with Perl in the 1990s and well it was the only game in town for the things I needed to get done. Now as a semi-professional programmer (Temporary work and side jobs at work) I have learned to love Racket (Lisp Family), awk/sed and R.
Since I only do this less then full time my brain can't hold everything in it for Perl or similar languages. I can sit down with a Lisp and just work it out with the parts I know and have to look up things far less.
Interesting you mention awk. Do you use that professionally? For string manipulation I use almost exclusively pipe output to bash then format/grok with awk/sed, and wish that more (any?) languages implemented them fully!
> There are some people who appreciate games that are very abstract and with
> simple rules from which complex behavior emerges, such as a game like Go.
I love Go, but I despise perl. Perl is not built on "very abstract and simple rules. For instance, this code is quite hard to reason about:
1: my @to-infinity-and-beyond = 0, 2 … ∞;
2: say @to-infinity-and-beyond[1008];
# OUTPUT:
# 2016
This is self-indulgent mucking around. An inference procedure which goes from "0, 2 … ∞" to "the even-nonnegative integers" is bound to lead to unpleasant and hard-to-debug surprises.
I'm confused. What's so hard to reason about that? It's very obvious that it prints 2016. Maybe "infinite lazy lists" isn't something that most mainstream languages consider, but honestly, they're very handy and hardly "self-indulgent mucking about."
(Though I'd probably use an asterisk instead of the infinity symbol)
Indeed, if we're going to hold up Haskell as an exemplar of simplicity—which, in its philosophy if not always in its implementation, I think it is—then we can hardly ding Perl for including lazy lists!
What you consider "self-indulgent mucking around" others may call "declarative programming". I can appreciate that you don't like it, but I think you've missed my point.
> These people tend to be drawn towards programming languages that are built out of small pieces with a consistent philosophy from the ground up, such as lisp or Haskell.
If you like go and dislike perl its to his point.
A TLDR (because apparently); People who like games that are complex because of complex rules like perl. People who like complex games with simple rules dislike it.
GP was emphatically not saying that Perl 6 is the abstract and simple one. GP was saying those qualities apply to Go and are what make some personalities like Go more than P6. You like the Go qualities and not the P6 ones; QED.
Some of this looks great. I'm suffering through making some internal tools an old version of php after deprecating some older perl 5 cgi scripts on an even older CentOS box, and reaaally not enjoying it.
I understand the value of coding in other texts, but I still get a little squicked out seeing the characters for pi, and union, etc in code. I know they have ascii equivalents, but its not saving a keystroke, exactly. Though, it does remind me of some joker Swift posts where the identifiers were all emoji's. I'd keep interns away from it for now.
The built-in grammar parser looks great! C-lib integration looks promising. Multi-methods look nice. Operator overloads look ... safe-ish-er than C++. Simpler profiling.
Perl5 module + other language in-lining looks great and terrible. "Whatever" wildcards don't quite seem like full pattern-matching, but better than $_ or endless shift loops.
Overall, seems pretty good!
If I can just drop it in for my "perl -lne 'm|($regex)|g&&print$1'" command-line use I might swap it out sooner than later.
You read a piece of code many more times than you write it, so even if an extra keystroke is needed to make the code more readable, it's worth it, IMO.
But, I find it very easy to type all that fancy stuff with XCompose sequences. My keyboard also has a bunch of media keys I never use, so it's probably possible to map those into the unicode ops.
I for one am extremely excited for Perl6's ecosystem to grow, documentation to increase, and for the performance optimizations to reach maturity.
Perl5 has raw text processing power, but Perl6 kicks that into overdrive with a much cleaner language (clean and powerful OO with a MOP), with cool goodies from a dozen other languages. I think this may be the first decent contender for the 100 year language if it becomes production worthy.
God I sure hope not. (Only if it's a lot easier to maintain than Perl 5 maybe...)
I have bad feelings about Perl after having to parse and cleanup a bunch of abominably written multi-thousand line pages full of regular expressions and all manner of cleverness. I mean, I actually hated Perl so badly I believed it was the worst invention ever. Then I saw a well written project and was easily able to understand and felt slightly less negative. So it's not entirely the language, but to this day seeing 'Perl' brings negative emotions to the surface. Something like PTSD I guess. It will probably take 100 years for that to go away and me to willingly look at anything called 'Perl'.
Believe me, I've seen bad Perl[1]. Luckily I was already very familiar with Perl, so I was able to discern that the developer was just batty.
1: Global variables everywhere. Every function call did not pass arguments, but instead they assigned data to global variables in the immediately preceding lines, called the function, and then used those global variables. Copious use of SQL where every query was saved in a variable called $stmtA, $stmtB or $stmtC, depending on how many levels of sub-querying needed to be done in a loop. Obscure variable names in general. Zero comments. No use of modules, everything in one flat text file (for 5-10 or more flat text files), no code reuse. PHP used in the same project, to the same standard (one large sprawling multi-thousand line PHP file). This was an open source project, and to this day I wonder if possibly it was all a purposeful design decision, so they could charge for development requests.
Personally, I think a lot of the bad Perl code people have had to deal with relate back to three things.
a) Many of people writing the code were sysadmins that just needed to get a job done, and didn't have much real development experience.
b) Perl was also easy to get access to in cheap shared hosting environments, so it attracted other people without some development discipline.
c) Perl4 did not have objects, and scoping was limited to local(). Thus, lots of spaghetti code and global vars.
However, none of that would have gotten exposed to developers if their teams had decent interviewing techniques, or code review, etc.
All that to say that Perl 6 shouldn't have the same propensity for bad code to end up in a real project. Any more than any other language that is. I can certainly misuse regexps, lambas and other features and write some hard to maintain Python.
100 year language might be meant seriously by some people, but I meant it as something that has enough powerful concepts to stay relevant for a long time.
It harks back to Paul Graham's essay where he started off on Arclisp as a 100 year language and better designed lisp. Other priorities came up and it didn't really go anywhere besides maybe being used for this website. Hopefully Perl6 doesn't suffer a similar fate.
Perl gets proper OOP, as now that OOP seems to be out of fashion!
(I wish the fashion part of our industry would disappear and people would use the correct tools appropriately. OOP still has plenty of valid cases in my opinion).
OOP isn't out of fashion, per se, I don't think. Inheritance is what really went out of fashion. Part of the problem, I think, is that people use OOP and Inheritance interchangeably too much.
objects are just syntax sugar for a closure or a set of curried functions. As such they are useful. It's inheritance that gave OOP a bad name.
I still recall reading ECOOP papers in the 80s that made it very clear that composition is a much better approach for most things than inheritance (and that a single inheritance mechanism is generally much simpler than a multiple inheritance one).
But, while Larry Wall agreed in the sense he put emphasis on features such as roles (cf Haskell type classes) he has also said that there are some important scenarios in which inheritance (and very occasionally multiple inheritance) make coding a solution to a problem more straightforward where use of composition makes it less so, so standard Perl 6 supports both composition (eg roles) and (multiple) inheritance and the compiler (which is written in Perl 6) uses one or the other based on whichever is deemed to work best.
Curious what about Perl 5 OOP makes it not proper. Is is just the required constructor boilerplate, like bless()? Or is it the lack of enforced private methods?
Neither seems like a showstopper to me...honestly curious.
Perls OOP was an afterthought and it does feel a bit of an add on rather than a core part of the language.
Having said that I got my first job using Perl after learning Java at university. It actually helped me understand OOP and inheritance a lot better because it was so transparent compared to Java's OOP which seemed more of a black box - it worked but I never really knew how.
I thought it was strange to be able to use greek characters and the like in the code, and then I arrived at the slide about Custom Terms and Operators[0] and... now I think it's an April fool.
Julia lets you use Unicode in your code as well, and it's great. I use Julia for math a lot and it's really nice to go straight from your equations to code with variables named α and ϵ instead of alpha and epsilon. The vim and emacs modes also make it make it easy to enter characters like this.
Yes, Unicode variables are a thing, but I am afraid it makes the language less approachable if it requires a special keyboard or at least some tweaks in the IDE to input those characters - and I say that as someone who added some macros in emacs to enter French accentuated characters with an American keyboard. I think it's one of the reason APL isn't much used these days...
So just curious can anyone share their uses of Perl 6 and if they have anything going on in production? I already know that CraigsList at one point (if not still) is powered by Perl, but I'm not sure which Perl that is really.
On another note: I find it quite fascinating that Perl 6 is implemented in Perl 6, that would in theory allow you to implement Perl for .NET or the JVM and retain plenty of Perl as a result if I'm not mistaken.
I haven't heard of anything in PROD yet (there is a QUORA question on this), but I know there are several Perl shops that would jump on this when it's fully ready. You can use it today for most things (assuming hard performance isn't needed). When the optimizations and JIT are complete, you'll have a very fast OO language with optional types. My intended use cases are for pretty much anything that doesn't need a GUI like a .NET desktop app. I have a LOT of data at work and look forward to using the Grammar functionality to build useful and beautiful parsing code.
I believe Perl6 is bootstrapped by a subsection of Perl6 called NQP (not quite perl)which is written in C.
NQP is actually bootstrapped, so it's written in NQP. NQP in turn has different backends targetting different virtual machines. The backend used by almost everyone is the MoarVM backend (a VM made specifically for the Perl 6 object model, which is written in C), and there's also a JVM backend. The Parrot backend is pretty much legacy at this point, and there's an experimental JavaScript backend.
I remember an earlier Perl6/Rakudo post here (I think), where chromatic showed up and mentioned a few things that had been running reliably for a couple years in his stack. That it was at least "good enough" for his purposes.
Chromatic used to be a proponent of Perl6, defending it against criticism and claims of being vaporware. I don't quite remember when he became a critic, 2010-ish or so.
Around the time when Rakudo further detached itself from Parrot, and declared an effort to support alternative VMs (eventually writing one of its own).
No, I think it was well before that, and he was just more vocal at that point. IIRC became rather disillusioned with the project quite a while back, and he wasn't even involved with it (maybe nominally) at that point.
He put lots of hard work into the project, he wouldn't have done that if he had nothing positive to say. (But sure, lots of stuff have been backported to Perl 5, so the step up to Perl 6 is smaller today.)
He seemed a bit unhappy with some of the internal mess of the development, but that is not exactly uncommon for big projects.
...the primary deliverable ... is the language specification, known as “roast” (Repository Of All Spec Tests) ...
In other words it's roast, the digital acceptance test for any candidate Perl 6 compiler, that is arguably the only thing that was officially declared, and hence the only thing that could be construed to have been officially declared any particular thing such as "stable".
Continuing:
... This Rakudo release targets those tests (over 120 thousand of them), and passes them all on at least some architectures when the moon is in the right phase.
Rakudo is a Perl 6 compiler (so that one can try out the announced language).
Note the moon phase comment. While obviously not literal and arguably misleading it is a brilliantly concise and precise explanation of the degree to which Rakudo, the leading Perl 6 compiler, should or could be characterized as officially "stable".
> On another note: I find it quite fascinating that Perl 6 is implemented in Perl 6, that would in theory allow you to implement Perl for .NET or the JVM
Rakudo already has a JVM backend! It's not used as much as the MoarVM backend, mostly because the startup time of the JVM is horrible, but it's there. A Javascript backend is being worked on.
Yea I think the JVM backend was broken recently by a patch (if I remember correctly), but should be fixed soon if not already. I'm surprised it actually works so well when MoarVM isn't 100% done.
I assume the JVM would allow you to use Java libraries as well?
> I think the JVM backend was broken recently by a patch
That's a wrong way to describe it.
There were some important performance related changes to the spec prior to the Christmas release. The focus was on keeping MoarVM backend up-to-date, that's my understanding.
Just use a Rakudo Star release on MoarVM and it will be stable. Since Christmas it will be stable and conform to the official 'Perl 6.C' language specification. A lot of people in Perl6 land keep up with HEAD development building the Rakudo compiler from source daily/weekly with a tool called rakudobrew. HEAD by definition can sometimes be funky, a lot of the reports floating around are use cases against development builds and not official releases. Rakudo improves daily the development is that rapid. With the spec frozen the improvements are mostly performance, relatively obscure bugs and nice things like a better REPL.
Confusing UI? It's text separated into a sequence of pages: you read a page and when you're done you advance to the next one and so on. I like that sort of UI, books use it too.
The title sums it up. Good ol' Perl text processing, plus awesome new list processing (will be useful for n-grams, etc.). My favorite is slide #85, though. Communication with other processes in Perl 5 is always a huge pain, and I can never get it to not hang; you have to unbuffer STDOUT via $|++, then you have to read from STDIN and maybe STDERR to keep it from blocking. The Java solution is similarly painful, requiring spinning up threads for reading each stream (see http://stackoverflow.com/questions/14165517/processbuilder-f...).
There's a new Perl 6 book being written as we speak. I have high hopes that it can follow the excellent example of the Camel book. If it does, it can be the starting shot that Perl 6 perhaps still needs.
Learning Perl6. It will be the continuation of Learning Perl, but for Perl6 instead of Perl5 I think. My bet is they'll (last edition had 3 authors)continue to publish both as both languages will survive for a long time until Perl6 wins out. There's also the possibility Perl6 just never really takes off, but I hope not.
Brian D. Foy has a WordPress site up for it.
There is a perl6 intro website as well that is awesome.
Hm. What is the origin of 'Texas symbols'? A reference to being old-fashioned or something? It's amusing, though I'm not sure it's the clearest euphemism
That depends on your audience. There's a far more people that know mathematical summation than know how to program. Allowing a language to easily make good use of preexisting knowledge seems like a good selling point to me. Making it optional, as in provided through a module seems a sane way to gate it as well.
I was just implying that Perl was jokingly called a "write once" language. It certiainly was for me. Remember starting a bionformatics project with it, and after a few months, I could not read my own code. This just reminded me of that.
There are definitely those times when that happens, but I find it's mostly when the code has grown without a plan, and that it's mostly a problem for every language. That said, Perl (5 or 6) can easily get you in trouble if you aren't disciplined and decide to take your one liner and make a program out of it without taking a bit of time to convert it into a more readable form.
I'm still undecided on whether Perl 6 takes the TIMTOWTDI motto too far. There seem to be multiple purely cosmetic ways to do something (sigil-less variables), and that's less of a "more tha none way to do it" thing and more of a "more than one way to make it look" thing (colon method call syntax), and I'm not sure how that will work in practice.
Then again, there are lots of things that I think are unequivocally much better, such as method signatures (which you can approximate in Perl 5 with Kavorka[1]) and OOP (which Moops[2] in Perl 5 seems to do a good job of bundling the various Moose family modules together for, with Kavorka).
"Perl gives you enough rope to you .." cit. Larry Wall. It is cause Perl is very expressive. I usually write code even my boss can read, and looks trivial remember Perl is inspired on natural languuages. On the other hand you can write very cryptic code, in every language, but Perl can be very tricky: use comments for the future you.
Learning Perl was a great excercise, after that I could learn JavaScript really easy not only cause they are so similar but cause Perl and its culture teaches you about programming. It is a milestone.
I will say that I started using Perl5 recently (big python fan). I expected everything to be crusty and bad. CPAN worked great, and the doc...my GOSH the doc is sooo good. It is everywhere. In my command-line, gazzillions of websites. I forgot what it was like to not be dependent on StackOverflow.
Perl Monks is far better than Stack Overflow for Perl questions, as they actively encourage the discussion that Stack Overflow avoids, leading to a greater understanding afterwards as opposed to just something that works.
I can't count the # of times a super helpful question was closed on StackOverflow for being "off topic" or being likely to cause a flame war. I do like Perl Monks, but wish the format was a little different UI wise. Def still usable though.
> There's a far more people that know mathematical summation than know how to program
Source?
My experience is about 100 to 1 the opposite. I know tons of programmers that don't know math notation. I know few people at all, even non programmers, that know math notation.
I know 8yrs old that code. They don't know any math.
Yes, but I think they're the kind of knowledge you hold on to for the test and then, unless you become a mathematician, you avoid for the rest of your life.
I understand "sigma notation" and related mathematical symbolism, and can work my way through understanding a formula if I really need to. But given a choice, I let my eyes glaze over and pretend I didn't see the formula. I'm one of those programmers, and I think typically so, who consider math a distant relative whom I give a friendly wave from a distance but not one I like to corner for an intense heart-to-heart.
But you've seen it before, and if you saw it again and you didn't remember exactly what the symbol stood for, you would probably still remember it was math related, and be able to look it up fairly quickly. There's a whole class of domain symbols that fall into this category, and even for the people that don't know them immediately, if they look them up, they might find useful info that conveys some of the original developer's intent. For example, Δ, an searching for it will probably bring you to Wikipedia[1], where some common usages are easy to see (and "change" is the top one, which is what I would assume when seeing it).
Increased symbolism front-loads learning to increase expressiveness later. If we've already front-loaded that learning to a small or large part on a large chunk of the population, that can greatly change the equation for how much it slows initial understanding of the code, and thus it's usefulness. As I mentioned elsewhere, we generally use '+' and '-' in programming languages because everyone already knows what they mean. We could just as easily use add(a,b) and subtract(a,b), and in some languages we do so, but in general there's so little friction in using the most basic math notation it's accepted without qualification as a better way to do it.
I've never written any Perl 6, so this comment could be badly foolish.
As you point out, the suggested `∑` is just sugar (for some value of 'sugar') for `[+]`. In Perl 5, one could easily alias subroutines using, for example, `* a = \&b` (space inserted to fool Markdown). Is there any analogue in Perl 6, so that, say, `* ∑ = \&[+]` or its modern variant would automatically inherit the parsing semantics without having to go through the cumbersome process of declaring a new sub just to pass its arguments unchanged to an old one?
I'm still upset with the perl6 devs for sending me down the Haskell rathole so many years ago, but perl brought a lot of pretty great things forward and it was by far the best text parsing language for entirely too long. I like what I'm seeing today and I'm willing to give it another shot. I am a bit concerned about whether perl is going to be able to gain momentum again.
It won't take too long before people start checking it out and there are some good real-world use case benchmarks.
I am trying really hard to approach Perl 6 with an open mind, but my gut reaction to most of the code I see is negative.
It seems like the guiding principle was to create a language that gives you incredible freedom in terms of how you do things. While that is great in theory, in practice mentally modelling that expressiveness reduces the amount of attention I can devote to the specific problems being addressed by the code. Maybe if I put a lot of time in that would change; I don't see a big potential payout though, so I'm not going to bother.
With that being said, grammars look well designed. If all I was doing was parsing/transforming text, I would definitely consider using Perl 6.
I used to really like Perl, but endless operator-obfuscation nonsense a la C++, Perl 6, Scala REALLY makes me appreciate Lisp (should I ever get to use it again outside of 80s college work). Every function has a plain old name, no magic symbol operators, inner parens evaluate first. No bullshit.
I go back and forth on that. I like both Perl 5 and Common Lisp, and am investigating Perl 6 now. Perl has more operator magic, but it also makes many things a lot less tedious to write, and for common tasks I quickly figure out a nice way of doing things. Common Lisp is more uniform but somewhat clunky and verbose for a lot of common things. And when it's not, it's because you created a nice little DSL using macros (maybe even read macros), which then starts looking more like Perl-style magic (except done with metaprogramming, not built in).
As far as heritage, I think Perl's love of magic and concise operators is influenced more by the awk/sed/sh trio that it originally borrowed a lot of its syntax from, rather than by C++.
Damian Conway (Perl5 frequent contributor) is a professor who knows and has taught Lisp classes. He made a good point that although Lisp is powerful in it's own way, you don't get a lot of information by simply glancing at some code. With sigils and other known operators, Perl gives the reader a lot of information as long as it isn't abused.
This is a great point that often get's ignored or glossed over. Perl code is information dense which makes it look messy to someone who doesn't know what each of the sigils and syntax elements mean. What this means is that perl has a longer learning curve but once you get over the hump you know a lot more about what the code is doing in a glance than you do for other languages. So it's not more readable to the new guy but it can be more readably to the ones who put in the effort to get up to speed.
It's kind of amazing to me, after learning all kinds of abstractions and syntaxes, how much I just come back to the function to organize my code. And over and over, that seems like the most flexible and powerful way to do that.
That does work really well for me in my Javascript code.
Java is getting increasingly painful to look at (even without operator overloading), and most of our work is still Java (due to the need to write so much of it???)
I don't know why you got downvoted but Haskell also gives excessive freedom for infix operators with adjustable precedence, ability to make up new operators etc. and a lot of libraries use such operators excessively so I think you are right. Come to think of whenever I need to write a PEG or use a not-so-common typeclass I need to open documentation to see what juxtaposition of ascii characters to use where. On the other hand, I think the expressibility outweighs the cognitive overhead in case of infix operators, especially when using relatively common operators (Scala kind-of has a similar feature and I (ab)use it frequently and it is nicer and closer to math when combined with Unicode. Closeness to math is an important feat. when translating academic papers into code or vice versa).
The funny thing is I have seen many more damaging errors caused by operator precedence / grouping, which continue running and doing the wrong thing, than by type mismatch errors, which blow up and stop.
The problem with the code you talk about is that they use libraries that are intended to create a new DSL, instead of fuse into the language itself.
Apart from that, there isn't really much problem with Haskell's operators. There are only few in standard library addressing applicative and monad, and the de facto standard Lens library.
The biggest problem with lisp as I see it is that the code is typically not read in the order that it is evaluated. This results in significant cognitive overhead when reading code.
Additionally, while there is a definite elegance to its simplicity, most people have built up fairly good understanding of a number of glyphs. Using some of the additional glyphs to make the code more visually distinctive would definitely improve code reading speed.
Ultimately it seems like operator overloading is something that should be possible, but made intentionally difficult to discourage abuse.
Related: While flipping through the slides I was annoyed how many of Perl's plain old names aren't really exact name but more casual description. .say, .hyper, .race, start for Promises in this slides. Even the keywords my, our, has annoy me a little bit. Not to forget strange jargon like bless.
Yes, at the end they all are token and one has to learn them. But I miss more exact words for some value of exact. Going a little bit into the ObjC school of naming would do Perl some good.
This function is loosely similar to `print` in the sense it sends a version of its arguments to an output handle (STDOUT by default).
But `say` is emphatically casual and human oriented in stark contrast to the formal and computer oriented `print`. For example, `say` uses human friendly gists of its arguments and truncates arguments that are absurdly long. I think `say` fits perfectly.
hyper
Er, yeah. Reasons. Onward:
race
A race delivers the first of several competing concurrent computations to successfully complete (or the last to fail if none succeed). What would be clearer?
start
`start` starts something that will complete later. Again, what word would you pick?
I agree with kbenson about `my` and `our` and note that those were stolen from Perl 5 because they're considered to be spot on.
See my reply to kbenson for my uneasyness with casualness and human orientation of names. :)
But following my gut feeling for completeness in bikeshedding:
say → Two things irk me, also in other languages. First is the where of writing out. Which is missing here. So I'd always use it as a method of the corresponding handle, here STDOUT. What to name the method? .write would be used for generalized writing (print in Perl6, I think). .writeLine for writing with Newline. And yes, say seem to write a custom representation of the written objects. STDOUT.writeRepresentation would be to long even for me. ;) So .. Stdout.writeRepr(), maybe.
.hyper, .race → If I understand .race correctly after some googling (the Perl6 docs seem to be very sparse), it doesn't returns the result of a race, e.g. a winner or an ordering from winner to loser. Instead it transforms an Iterable into a parallel processing pipeline with custom map/filter/... methods which do their work on parallel workers.
Iterable::inParallel / Iterable::inOrderedParallel would be my compromise.
start → I don't have a Problem with Promise.start but with the corresponding global routine. Start seems so be a too often used concept for different things, most of them custom defined by the user of the language. But I don't know how pervasive usage of promises is in Perl 6, so maybe it is warranted.
`start`ing Promises, `race`ing pipelines, and `say`ing are all frequently used Perl 6 features. So we want nice simple short words for them. I think the ones we've got are well chosen but it's clearly a taste thing. You could always define aliases... :)
So, what exactly are the "exact words for some value of exact" that you would prefer? Extern? local? Keep in mind that there's a duality between my and our which is obvious and part of the words themselves, so they don't need as much memorization. "my" is private, and local, "our" is shared, and not local.
I'm not super happy about some of the other words chosen (start, race, etc), but I think my/our has a nice symmetry to it.
> "my" is private, and local, "our" is shared, and not local.
Which begs my question: If you already have more exact words (”private“, ”shared“) for these concept, why not use them? Yes, ”my“ and “our” have these connotation too, but it works only for humans and their relations.
I guess that's my disquiet with some of these names: Perl mixes the realms of machines and humans. See also `bless` and `say`. And the anthropomorphization of abstract concepts only creates a slightly uncanny valley in my mind.
Maybe because english isn't my mother tongue. Perhaps native speaker is more ok with this mixture of concepts?
> Which begs my question: If you already have more exact words (”private“, ”shared“) for these concept, why not use them? Yes, ”my“ and “our” have these connotation too, but it works only for humans and their relations.
It works on items to denote their relationship to people. That Perl expects the code to be written by a person and uses terms people are used to for dealing with ownership doesn't seem weird to me. That you see it as weird and other words as more appropriate I think is more likely related to what words you learned first for those concepts. I don't see them as inherently superior in any way.
> I guess that's my disquiet with some of these names: Perl mixes the realms of machines and humans.
Given that it's creator is a linguist, and there's some very specific things that were attempted, your feeling that it's taking terms you associate with relation and using them somewhere else is probably purposeful. Perl was designed with some very specific ideas, and one of them was to make it usable in a way more like a natural language.
> And the anthropomorphization of abstract concepts only creates a slightly uncanny valley in my mind.
I think you're stretching your analogy too far to make a point. My and our denote ownership of an item. It's used in Perl to denote something very similar, as the core concepts are the same, responsibility and access.
> Maybe because english isn't my mother tongue. Perhaps native speaker is more ok with this mixture of concepts?
Possibly. I'm a native speaker and the concepts aren't mixed in my mind.
"private" is used in several major programming languages to mark private instance variables. But all instance variables are private in Perl 6 so the keyword is unnecessary. Using it instead for what "my" is used for in Perl 6 would be very confusing.
I do wish Scala libraries would stop using symbolic operators, but I do think they're less bad there than the other places: symbolic names are just ordinary method names (no magic desugaring), and make no difference except for a short precedence list.
Interesting observation. In practice, I found coding in Perl 6 is much faster than in Perl 5, for example. One of the programs I converted was half as short. On the contrary, it's expressiveness let's me focus on the problem instead of trying to figure out whether my large loop of code is in order.
English is an expressive language as well, but I don't become paralyzed writing this comment.
I do agree that abstractions that reduce the amount of code you have to write can allow you to devote more brainpower to the code at hand. I would argue that global abstractions are generally inferior to local abstractions for this purpose though. If you make the language locally more complex (via defining terms i.e. functions) you can leave that complexity behind when you don't need it. If your language grammar is naturally complex you have to deal with that all the time.
As for English... Writer's block and futile rewriting cycles are real issues that basically every writer grapples with. On the other hand, coder's block isn't really a thing, and refactoring occurs infrequently compared to writing.
It turns out lots of things make sense to parse using grammar like constructs: various binary formats, JSON, CSV, etc. I have a feeling that community writing decent parsers for once will make perl's parsing ability across the board pretty amazing and less fussy than just about anywhere else.
Perl has always been really good at parsing, it's one if its strengths. In fact, you can usually distinguish people who like perl from those who don't based on whether they understand regular expressions or not.
Another thing I like about perl is a lot of the standard library functions take an array of inputs, or a single value; and return an array or a single value.
Perl has always been really good at enabling cargo-cult parsing -- the vast majority of "parsers" I've seen in Perl 5 have been ad-hoc, buggy, slow, and informally-specified. The nice thing about grammars as a language construct is that you get formal specification for free; this aids in understanding the parser. When it comes to parsing, grammars really are the right way to go, either as a built-in or as a library (Elisp, for example, has a few parsing libraries available in MELPA, and there's always good ol' LPeg for Lua).
When all you have are regeces, there's a tendency to model a parser as a finite automaton where transitions are labeled with regex matches, but given how frequently programmers deal with extracting information from text, I think there's a solid argument for grammars or parser combinators being readily available in a language. Really, any text processing task more sophisticated than grep calls for tools more sophisticated than regular expressions.
Regular expressions are improved in perl 6, using a syntax that allows better readability through whitespace and comments (previously the x modifier) and new features that make the regular expressions more like PEG grammars.
> It seems like the guiding principle was to create a language that gives you incredible freedom in terms of how you do things. While that is great in theory, in practice mentally modelling that expressiveness reduces the amount of attention I can devote to the specific problems being addressed by the code.
In defense of Perl 6, you could say more or less the same thing about Perl 5 and every Perl that came before it. Perl has always been optimized for cleverness, in the sense that it's much more interested in making it easier for people to write code than it is in making it easier for anyone (even the person who wrote it) to read it.
Well, it would not really be Perl if it allowed reason to take precedence over the inclusion of yet another confusing feature, right? And I don't mean that in a negative sense, unbounded expressivity already is the central reason to use Perl and any changes to the language should respect that.
I always appreciated the expressiveness of perl, and ruby for that matter... however, reading perl you've written a while ago, of even after not writing any for some while is a lot of mental hurdle...
I hear this a lot, but I have gone back to plenty of my old scripts and have no trouble parsing them. This is something I worried about several years ago when writing some fairly hairy code, but it really has not panned out.
I do have trouble reading other people's code sometimes, but that's true in any language. It's easy to get thrown for a loop when someone uses a language feature that you've never seen before.
Haskell had a big influence on Perl6. Lazy evaluation is built in to the language just like Haskell. If you look at the bottom of the Perl6 website you'll see the Fibonacci sequence using a lazy infinite list.
Fun fact, one of the original Perl6 implementations was done in Haskell (the parrot VM I think).
Parrot VM is a separate project from Perl 6. It originally started as a VM that could handle Perl 6, but then decided it wanted to focus on being a general VM for dynamic languages. This led to a rift between the two communities.
Before all that happened, though, there was Pugs, which is the Perl-6-on-Haskell thingy that you are thinking of. A fair portion of the current Perl 6 test suite comes from the Pugs project, at least originally. And, IIUC, it was the success of Pugs that revived the Perl 6 efforts and led to the Rakudo project (Perl 6 implemented in Perl 6) which is what we still use today.
So yeah, it is definitely the case that Haskell had a big influence on Perl 6 both from a language design and a more raw "inspiration" in the sense that it literally might not have happened without it -- the original wave of Perl 6 development had largely failed and there was some serious burnout happening. Pugs, Haskell, and Audrey Tang managed to put the ship back on course.
A lot of history happens in 16 years, and I make no claim to know the truth of any of it. There are more than a few rants floating around out there that will give you a picture of what happened when, albeit from a ranty perspective. Hopefully one day it will all be collected in a more comprehensive historical document.
> it was the success of Pugs that revived the Perl 6 efforts and led to the Rakudo project
Note that depending on your point of view, Rakudo actually predates Pugs: It's just that Parrot and Perl6-on-Parrot used to be developed in a single repository, and it wasn't yet called 'Rakudo'.
edit: However, NQP (the basis for the current Rakudo architecture) does indeed postdate Pugs (according to the ChangeLog, it first appeared in Parrot release 0.4.15 in 2007).
Ah, yes you are correct. Thanks for pointing out some of the finer historical notes! I bet there are plenty of people here that would be impressed to know how much P6 has to do with Haskell. I think the general impression isn't one of lots of advanced ideas but Hey Perl finally got a decent object system which is kinda sad lol.
Fair critique. I meant that in the sense that the original vision of Parrot was quite closely tied to delivering a VM which could handle P6. By logical extension, this would mean it could handle any given dynamic language.
However, I am talking about the focus shift that made Perl 6 just one among many of "client languages" (for lack of a better word). This was a distinct moment, at least as far as I remember it.
By logical extension, this would mean it could handle any given dynamic language.
Not only by logical extension! One of Larry's primary goals was to "let any language use the CPAN", through Parrot. Running Perl and P6 on the same VM, in process, without embedding libperl.so was the plan as far back as I can remember.
I am talking about the focus shift that made Perl 6 just one among many of "client languages"
That's been a common, though unrealistic, criticism of Parrot for the past several years. Various contributors never had (or lost) interest in P6 but wanted to work on an multi-language VM. Expecting that all volunteers to a project have the same primary goal in mind is ridiculous and ignores decades of F/OSS contributions; it's easy to look at the Linux kernel and recognize that multiple competing business and personal interests can be shepherded into a technically useful result that meets a lot of those needs despite their competing interests.
People implementing `invokedynamic` didn't somehow make Java a second-class citizen on the JVM, for example.
You can certainly argue that we handled some of those competing interests poorly (I've argued this), but the "focus shift" argument rests on some questionable assumptions and ignores other, more important, concerns.
Hey chromatic, maybe you missed the parts where I explicitly said that my historical knowledge is only as good as the sources I have read (+/- my sideline experience)? Please stop framing my clarifications as intentionally disingenuous. If you have additional historical perspectives to share, then by all means. I even explicitly asked for that in my original response.
Now, I think you are also being a bit disingenuous. The Parrot team shifted focus. You can say all you want that the original vision was always all dynamic languages (which I already said, by the way). But to frame the original Parrot efforts as anything less than building a foundation for Perl 6 clashes with my own memory of the timeline.
If the JVM and the Java teams essentially stopped talking to each other, I would definitely consider that to be some form of collective decision making representing an overall shift in focus for the projects. That's more akin to what I remember of the Parrot/P6 split. Even your post hints at it when you say "Various contributors never had (or lost) interest in P6". But again, I was only "involved" from the sidelines and am limited to the available materials, including yours, and synthesizing them from individual rants into some semblance of a balanced picture.
If the JVM and the Java teams essentially stopped talking to each other, I would definitely consider that to be some form of collective decision making representing an overall shift in focus for the projects. That's more akin to what I remember of the Parrot/P6 split.
That's the story certain people have been telling for quite a while, but it never happened while I was involved in either project. If you look at the use.perl.org archives, you can see that both Allison and I (as the architect of Parrot and a lead developer, respectively) were collaborating closely with Rakudo developers on the weekly P6 design calls.
I understand that, from the outside, there's a natural tendency to take all of the perspectives and comments and assume that the truth lies somewhere in the middle, but the historical record is out there and available. I've certainly referred to it directly when posting my opinions about what happened and when.
> Hacker News takes that excitement and beats it into a nasty pulp on the floor.
You're as much a part of HN as anyone else is, and tons of people here like Perl 6. That's presumably why stories about it such as this one get upvoted so highly.
Instead of dissing the community and adding to the negativity, it would be better to ignore it (which is hard, I know) and share some things about what you like so much.
Thanks for your moderation! I'll just add that I generally love Hacker News, and I wish I knew a more constructive way to express my feeling here. (By the way, I think it's an interesting approach of MetaFilter to have a "meta" forum for meta-discussions like this one...)
Larry Wall gave a state of the onion speech about Perl as a "postmodern" language... which means something like, its guiding principles aren't only classical or modernist... it doesn't just aim for simplicity, purity, elegance, unity, etc... instead, it includes some very different values, like plurality, camp, fun, "just weird enough"-ness, "ha ha only serious"... some quotes:
> I combined these cool features [from all kinds of other languages] in a way that makes sense to me as a postmodern linguist, not in a way that makes sense to the typical Modernistic computer scientist. Recall that the essence of Modernism is to take one cool idea and drive it into the ground.
> Well...Perl does one thing, and does it well. What it does well is to integrate all its features into one language. More importantly, it does this without making them all look like each other. Ducts shouldn't look like girders, and girders shouldn't look like ducts. Neither of those should look like water pipes, and it's really important that water pipes not look like sewer pipes. Or smell like sewer pipes. Modernism says that we should make all these things look the same (and preferably invisible). Postmodernism says it's okay for them to stick out, and to look different, because a duct ought to look like a duct, and a sewer pipe ought to look like a sewer pipe, and hammer ought to look like a hammer, and a telephone ought to look like either a telephone, or a Star Trek communicator.
> How does Perl put the focus onto the creativity of the programmer? Very simple. Perl is humble. It doesn't try to tell the programmer how to program. It lets the programmer decide what rules today, and what sucks. It doesn't have any theoretical axes to grind. And where it has theoretical axes, it doesn't grind them. Perl doesn't have any agenda at all, other than to be maximally useful to the maximal number of people. To be the duct tape of the Internet, and of everything else. You've heard the joke, I'm sure. How is duct tape like the Force? It has a light side, and a dark side, and it holds the universe together.
> Let me state my beliefs about this in the strongest possible way. The very fact that it's possible to write messy programs in Perl is also what makes it possible to write programs that are cleaner in Perl than they could ever be in a language that attempts to enforce cleanliness. The potential for greater good goes right along with the potential for greater evil.
I love this attitude, and I think it's very hackeresque, so yeah, it's nice to see it upvoted and discussed on Hacker News.
This talk literally changed my life. I was very much of an "or" person before, with various pureist views on all kinds of things. Ever since, I have embraced the "and" perspective in most every area.
Yeah, that talk is pretty awesome. It's indirectly responsible for my current job and my taste in anime. I honestly can't thank Larry enough, but I do what I can by helping Perl 6 succeed.
Perl 5 was my first language after a failed attempt at C as well. I no longer use it, in fact my favorite dynamic language is now Lua which I consider a polar opposite of Perl in some ways.
I now consider Perl, and in particular Perl 6, as a language to learn ideas and concepts from. This slide deck shows me TIMTOWDI is not dead :) Perl does not shy in taking concepts made popular by other languages (Lazy lists from Haskell, "Hyper operators" from F#, channels from Go...) or inventing its own. It makes it a complicated mess, but also a fantastic source to learn about different paradigms and ideas.
I am eagerly waiting for a Perl 6 version of Programming Perl now, given how influential the third edition has been on me 15 years ago.
Brian D Foy has a WordPress site up for Learning Perl6 with some pretty random blog articles. I'd say he's 1-2 years from publishing which is both frustrating and good. The language should be solid by then.
In a few weeks we are having the DC-Baltimore Perl Workshop (in Baltimore on April 16) where there are a few talks on Perl 6. Join us! http://dcbpw.org/
That's what I like about Lisp's s-expressions: Every operator is syntactically equivalent, so there tend not to be as many "forgotten tricks". You just write the code that does the thing.
If you want a real reason to be astonished, the bit with "INIT now" is run at a completely different time than the rest of the interpolation, apparently.
Is this is a joke or does perl 6 actually use that hyper arrows thing? Reminds me of an old language that used math symbols and had a custom keyboard with those keys on it.
It's no joke. You're free to use the asciified versions of those though, like << instead of the proper «. It's really not that much work to put them in your keyboard layout though, and I found myself using them a lot more often than when writing Perl 6 :)
As the second slide pointed out, you can use ASCII variants for everything. That said, I've found the Unicode operators nice to use in some cases, and I've been working on learning more about my compose key combinations.
It sure makes for pretty code. And, it's gotten easy to use Unicode under Linux, Windows, and Mac OS X over the past few years.
I posted an example of hyper operators a little while back, and used the Texas variants because I thought it might be intimidating to show them with Unicode...and, they were just so darned clunky looking, I had to change them back, and included a little note that there was a non-Unicode way to use the feature, as well
The typing isn't the bad part...you're going to spend more time reading the code than writing it, and it definitely helps readability. But, I do find I have a hard time keeping enough of Perl 6 in my head to make sense of what I'm reading. I believe this is because it's so new to me, even though I've written and read Perl 5 or many years. But, it also seems intimidatingly large as languages go.
Anyway, I think I'm sympathetic to where you're coming from; Perl 6 is challenging looking. We may disagree about why. But, I think I like the Unicode enough to consider it a net positive for readability, even though I also think it makes for a very broad and deep language that will need ages to properly wrap ones head around. But, then again, if a language isn't big and broad, a big and broad ecosystem develops anyway (see JavaScript and so-called "JavaScript fatigue" for a prime example of that), so there's still a tremendous amount to grok before being really productive and literate in the language.
Julia has a few Unicode operators and will allow you to tabcomplete the LaTeX
symbol in the REPL [1]. For example, \div followed by TAB
becomes ÷.
This can be implemented in popular editors [2].
I personally use XCompose and I'm eyeing the media keys on my keyboard as potential single-key operators. But you don't have to use fancy Unicode and can just use Texas variants.
I was 100% sure there would be a comment such as this.
How are HNers still confused? The same exact instructions have been given time and again, for almost each and every presentation posted on HN -- and there are always 1-2 comments asking about them for any new presentation posted.
New users? Not technical enough to try the keyboard arrows and/or space?
Sites like this would make sense to me if I downloaded them as .ppt files.
I don't understand the need to 1) be so clever and 2) get mad when people call you for being annoyingly clever.
I mean, first you take away the scroll bar, because it's ugly. Fine. Whatever. Next, you expect me cause the page to transition by moving RIGHT and LEFT. Not UP and DOWN, you know, like web pages have always worked. Finally, you don't bother to mention this fact anywhere on the website?!
>I don't understand the need to 1) be so clever and 2) get mad when people call you for being annoyingly clever.
What's clever? It's just a link to an online presentation. They don't use links etc because it's not a web page, just a html document -- it's primary use is for seeing it as slides through a projector.
This fact is evident both from the text and from the site's looks, and from that everything else follows (how you navigate, etc).
But confusion would still be OK, if we haven't had the exact same discussion 100s of times before on HN -- and if we weren't 99% devs, supposed to be able to solve much worse "mysteries" on our own...
There's nothing on the page to indicate that it responds to hotkeys, and there's a big (dead) link front and center that's labelled as leading to the presentation.
This. If I was to randomly stumble across this, without having had someone say "use arrow keys"... there is NOTHING on the page to indicate what to do.
I'm sitting at my desk... one hand holding a soda, one hand on mouse... and... nothing.
What would I do normally? Mouse 3 (back page) and never return.
Why? As far as it looks like, it's just a simple page with an "presentation coming (soon)" front page.
Fair enough! But I for one managed to guess from context (a solitary cover page just wouldn't make much sense) that I was looking at one of them there fancy "presentation HTMLs" and then I just had to guess how to work it. I tried the scroll wheel first (a reasonable expectation), then up-down keys (as many people would), and finally left-right turned out to do the trick.
Some species of HTML presentation-creating software have the good sense and courtesy to put a navigation hint on the cover page. I think it would be a good thing for that to happen more universally.
Navigational hints would be one step ("Use arrow keys to navigate" would be soooooo simply to add).
Alternative methods would be another (floating/transparent arrows on the sides... prev/next page area's to click... sliding bar on the bottom to indicate something that can be moved)
My two main gripes are lack of indicators/training... and forced use of keyboard. This is the web. Smart phones, tablets, mice, etc...
But... that's just my not-so-humble non-ux-guy opinion :)
==> Is this a feature that Perl authors are promoting about the language? If so, I can understand why it's not gaining traction. Coding like this benefits absolutely NO ONE--including the one who wrote the code. The hipster coder who's just excited to learn perl for the first time may try it out, just to come back the next day and wonder "what the hell did I write"
This kind of response is as reflexive as it is common; every innovation in programming language notation meets with it immediately. I think it has to be regarded as a middlebrow dismissal, indeed the middlebrow dismissal in its class. It's Tall Poppy Syndrome applied to programming languages: no unfamiliar expressions allowed.
No language makes sense before you learn it. Therefore unfamiliarity should cause us to suspend judgment, not rush to it. Otherwise we end up with what Alan Kay calls pop culture programming, which tragically junks things like the breathtakingly beautiful and powerful APL, and limits us to surface tweaks around the edges.
I studied natural language processing so have used perl a lot in the past. I kind of drifted away since then, but remember that it made me feel cool when I was writing a perl code, but made me feel stupid when reading one--even the ones I wrote--kind of like how regular expression is easy to write but hard to interpret. I think a language needs to be both easy to express and easy to comprehend in order to gain adoption and that's what I was trying to say.
If reading regexes you wrote is a pain point for you, then you're not making as much use of the readability tools Perl provides as you could, i.e. the /x modifier to make unescaped whitespace insignificant, and in-regex comments. ( http://www.perl.com/pub/2004/01/16/regexps.html )
And well, honestly, more often than not i found that "hard to read" perl code would be just as hard to read if it was written in lisp, python, c, or any other language you care to name; since more often than not that code is hard to read due to variables and functions having names that don't help the reader understand what they're holding or doing, and long blocks of code not having been encapsulated into functions well enough.
And lastly, to tie in to dang's point: Having "used Perl a lot" does not mean much if you have not also "learned Perl a lot". I've known, in the extreme, a Perl dev of 10 years experience, who had started out as a C dev, and yet did not use or trust Perl hashes, instead opting to write his own data structure encoding format. Have you ever read chromatic's Modern Perl?
If you watch the presentation, you can see those few slides were just used to add humour to a dry technical presenation. There's a huge number of mathematical symbols and physics notations (not to mention other fields) that could use their native symbols in programs.
You know, it's possible that some programmers are not native English speakers and might want Unicode availability in their entity names... you know... since they might not be using the Western American alphabet, and all that.
Never would've thought my slides I used for a presentation to 20-something people would make it to front page of HN...
You can watch the actual presentation here: https://www.youtube.com/watch?v=paa3niF72Nw I also wrote down the answers for questions that came up during the presentation here: http://blogs.perl.org/users/zoffix_znet/2016/03/wow-perl-6-t... (I now updated to include these in the slides too)
And to respond to some commenters, yes, some features (like the shrug operator) were presented in a humorous fashion. No one's advocating you actually make your code look like an orgy of emoticons. I didn't use PPT for the slides, because I like the freedom of needing only a browser to display the slides. They weren't really meant for public consumption, thus the UI is not entirely obvious.
I'm unsure why the person who posted this on HN posted only the slides and not the recording or the blog post. But I have no control over that.
And if anyone has any more questions, you can join us on IRC at irc://irc.freenode.net/#perl6
Cheers.