Slashdot Mirror

You asked, he answered!

Perl creator Larry Wall has responded to questions submitted by Slashdot readers. Read on for his answers... What's your computer set-up look like
by LichtSpektren

Can you give us a glimpse into what your main work computer looks like? What's the hardware and OS, your preferred editor and browser, and any crucial software you want to give a shout-out to?

LW: For the last year or two, I've been using a four-core Lenovo X1 Carbon2 (provided by my employer, craigslist, who hired me to be their "Artist in Residence" (and are still hiring, though not for that position)). Apart from a wonky keyboard layout and a capacitive strip that's close to useless, it's been pretty much ideal for my development, communication, and presentation needs. I'm running Linux Mint on it (Cinnamon, if you care, or even if you don't care, like me).

As for editor, I've used lots of them, so I have no strong religious feelings. I hacked on Goslings emacs when I was younger (and in fact the regex package in very early Perl was "borrowed" from there, before we switched to Henry Spencer's regex engine). But I started getting an arthritic pinky finger from emacs, so I switched to vi, and by the time vim came out my neurons were pretty much wired up to that way of thinking.

I run firefox on Linux, and chrome on my ancient Google phone, but I'm not a browser wonk. Maybe I'll have more opinions on that after our JS backend is done for Perl 6...

We've used lots of tools, of course, but certainly we couldn't have got Perl 6 done as fast^Wsoon as we did without irc or git.

Flying Cars
by WorBlux

Given that every other famous Larry in tech seems to be starting their own secret flying car factory, when are you going to start yours?

LW: If I told you, it wouldn't be a secret anymore, now would it?

Actually, I have a little cash flow problem, insofar as I was too efficient: I gave away all my billions in advance directly, rather than via my bank account. Most philanthropists get that way by screwing you over when they're younger, then becoming more generous as they get older. I guess I'll just have to do it the other way around.

How can we get PERL into the browser?
by Proudrooster

Larry, PERL is a great language, the swiss-army chain saw.

My question is, how can we strategically pull the PERL language into the browser? Javascript and PHP are getting all the browser action. We know that Embperl and Mod_perl exist for server side scripting, but how can we can PERL into the browser? Do you have friends at Google/Apple/Firefox?

LW: Our rakudo compiler for Perl 6 was designed to have multiple backends. Currently we support both MoarVM and JVM, but others are planned. In particular, a Javascript backend is already underway, and has progressed to the stage of being bootstrapped in NQP (that is, "Not Quite Perl", the restricted subset of Perl 6 that rakudo itself is written in), so the JS backend is most of the way to being able to compile and run the full rakudo compiler, and once it can do that, most of the rest of Perl 6 is already written in Perl 6, so someday in the not-so-distant future you'll be able to compile and run Perl 6 anywhere you can run Javascript.

At some point, the Nativecall library will also be ported, which gives full access to pretty much any C shared library, as well as embedded Perl 5, Python, or what have you, as well as their associated libraries. (Of course, sandboxing might get in the way of that in a browser, not to mention you can't rely on what the user has or hasn't installed on the client anyway.)

By the way, the MoarVM backend uses libuv, so our semantics should not be very far from what Node.js supports.

All that being said, getting mindshare is a slow process unless you're willing to overpromise, which we try not to do. We do get excited about the fundamental strengths of our design in FP, OO, concurrency, Unicode, and so on, but over the short term that translates mostly to acceleration, which only later leads to velocity. For a computer language that is meant to last decades, we're more interested in steady growth without artificial barriers. Of course, we won't mind at all if this generation of hipsters decides to use Perl 6, but we're not really interested in joining the Flavor of the Month club. If you look at our butterfly mascot, you'll see we're thinking generationally. Camelia is designed to impress 7-year-old girls more than 47-year-old alpha geeks, and generally succeeds at that. :-)

Why isn't PERL more windows friendly
by goombah99

My pet theory of why Perl has lost favor to Python is that it's really a Unix language. You can run it on a Windows box but only with a lot of effort to install and to maintain it. It seems to me that Perl could be more successful if one could get it adopted intrinsically into the Windows environment. A common, mistaken, lament about Perl is all the sigils that make it look like swearing. But those actually add meaning (I can tell what's an array, a reference, a glob, or a scalar) and they are familiar to bash users. But one can see how windows users aren't steeped in this so Perl gets a bad rap.

If Microsoft were to distribute an app that ran a Perl shell with all the first class privileges their own shells have Perl would be widely adopted as a superior do-it-all administration language.

Thoughts?

LW: Well, my spies inside Microsoft tell me that Perl is actually used quite heavily internally, so maybe I haven't been beating my wife quite so much as the question would indicate. :-)

It's true that Perl came from a Unix heritage, so there's a bit of impedance mismatch with some of the more Unix-flavored builtins, at least up through Perl 5. Perl 6 is much more OS-agnostic, both in design and in community support, insofar as a number of our developers work on Windows or OS X in addition to Linux. Indeed, our chief architect, Jonathan Worthington, develops primarily on Windows.

We already had an independent, proof-of-concept implementation of Perl 6 on the CLR (niecza) which worked pretty well, so as soon as someone gets the gumption to implement a CLR backend for rakudo, I suspect we'll fit back into the Microsoft toolbox about as well as C# does.

That being said, Perl has never been designed to be primarily an interactive shell. We do have a much better REPL in Perl 6 than Perl 5 has, though.

As for the success of Python relative to Perl, it's not so much either Windows or sigils. Some people do seem to develop an allergic reaction to the sigils, it's true. And that will continue, since we've regularized and powered up the sigils in Perl 6, so they're pulling even more weight than in Perl 5.

But I think the success of Python has mostly to do with being light enough in its OO model that it could move into some ecological niches more quickly than the Perl 5 design could. Perl has always considered itself primarily a programmer-centric language, while Python has always considered itself to be more institution-centric. So in a sense it's a bit dumbed down, much like Java. You'll note both of those languages make their greatest appeal to managers. :-)

Also, Python has done pretty well as a first programming language, even if the design runs out of steam at certain points. In contrast, we tend to think of Perl (especially Perl 6) more as a last programming language, the language of choice for people who need a language that won't give up when the going gets tough.

Perl in the embedded world
by mykepredko

HI Larry

What has been done to port Perl to very small devices as a tool to create test applications? I'm doing some control work right now and testing/characterizing devices and peripherals with the results generating a set of csv data on the console that is copy and pasted into Excel.

I am really asking about small 32bit devices (with floating point units) - Cortex M4 specifically. I don't think a port could be created for an 8bit processor like the AVR.

Thanx!

LW: Several things to say about that. We're already 32-bit capable, if "already" is the correct term for being so retro. (For a given architecture, you might have to make sure you can emulate 64-bit integers with a pair of 32s, since we guarantee 64-bit denominators for our rationals.)

Second, we can already compile and run Perl 6 on a Raspberry Pi, though of course it takes hours for Perl 6 to compile itself, since we don't have a jit for that CPU, so everything is interpreted.

Third, since the normal way of bootstrapping a new backend is via cross-compilation, we already have mechanisms in place for that, so if a given device is not big enough to support the whole compiler compiling itself (which needs a gig or so of memory), but it can support the runtime, we could do cross-compilation to the device and then download a program with runtime support into it.

Not saying we support this out of the box right now for any random architecture, but as with our philosophy on a lot of requested features, we try to make sure we just get close enough to it that someone sufficiently motivated could take it the final step pretty easily.

Language Design
by columbus

Hi Larry, Thank you for your contributions to the field of Computer Science.

My question is: in your opinion, what are the most important things to consider when designing a new computer language?

LW: Everything.

Seriously, if you're not designing a DSL (Domain Specific Language), then you're designing a general purpose language, and your only choices are to force the world to fit into your chosen paradigm, or try to support multiple paradigms. We much prefer the multi-paradigm approach. It turns out if you accept the 90% of each paradigm that is practical, and reject the 10% that puritanically rejects other paradigms, you can get a pretty decent general-purpose language out of it (see Perl 6).

But no matter how much of "everything" you take into account, you're still going to get blindsided, and you're still going to discover lots of ways you could have made better tradeoffs. There's no such thing as a perfect language, really. We used maybe 50 or 60 competing design principles in the design of Perl 6, but the most important one is: "There is no single most important design principle, including this one."

Or to put it the other way around, if you focus on only a few important things, your language will be good only for those few important things you focus on. Which is okay, if that's the goal you want to have. But there's a long history of people confusing "general-purpose" with "Turing-complete".

Intellectual Property
by ytene

As the recently re-trial of the case brought by Oracle against Google (over use of Java structures in Android) shows, intellectual property is and will remain hot property. One of the interesting things about intellectual property and languages, however, is how much of the syntax of supposedly different languages is remarkably similar (with a lot of inheritance from C).

May I ask for your views with respect to firstly protecting the intellectual property that you have invested in Perl as a language, but then perhaps also the wider challenge of IP with respect to programming languages and actual software packages?

LW: Well, the most fundamental protection of most open-source code is that it flies under the radar. Or to mix in a different metaphor, we tend to come up from the grassroots, and while it's possible to kill a given lawn if you try hard enough, you can never kill all the grass in the world. So as much as possible we merely try to flow around the problem. Software interprets lawyers as damage, and routes around them.

That being said, there are various ways to get more protection than mere anonymity; you may have noticed there are more strongly-held opinions about that than there are software licenses. But for myself, I'm under no illusion that I have anything like equal protection under the law. I can't afford to patent any of the many patentable ideas in Perl. That's not how software development should work, anyway. It would be a waste of my time. Along with many others, I hope copyright law, well-written licenses, and mutual-aid societies are sufficient to keep the patent trolls from starting to play whack-a-mole with us.

So I think the best thing open-source authors can do right now is to absolutely ignore existing patents, because if you happen to know you're violating a particular patent, they can whack your mole much harder. And maybe, just maybe, the courts will someday decide that we don't really want to end up with a society where multi-national corporations own everything worth owning. One can hope, and occasionally vote.

How do you perceive English predominance in the IT
by Anonymous Coward

As a linguist, you surely have some thoughts to share on the English language predominance in the IT field (as well as many others). Do you think that it may somewhat shape the way programming languages are designed, as well as IT infrastructures and ultimately our societies, in comparison of what it would be if we would use a no-nation-native language such as Esperanto?

LW: Well, sure. I suppose if Japanese had turned out to be the lingua franca of the computing world, we'd all probably have ended up using some "reverse-Polish" language like Forth or Postscript, since Japanese nearly always puts the head of any phrase at the end. I didn't know there were people who thought in reverse-Polish till I started learning Japanese.

On the other hand, we did end up with English as the lingua franca, lucky me. There's really no way to change that. My impression of Esperanto (without having learned it) is that it's still rather Euro-centric, so it would likely not appeal much to Asians. And while Lojban tries to be less, um, imperialistic, it doesn't really succeed in being a good human language. I mean, come on, mandatory positional parameters to verbs, with little rhyme or reason across different verbs? Gimme a break. A case grammar (more like named arguments) would have made much more sense.

In any case, people want to learn English anyway so they can watch movies from Hollywood, so it's a losing cause. The best we can do as English speakers is to try to be sensitive to the needs of other language groups. One thing we do to fight cultural imperialism with Perl 6 is to treat any grapheme as if it were a precomposed character, whether or not the Unicode Consortium happens to have defined one under NFC yet. If there's no precomposed codepoint, we simply make one up temporarily. So we get O(1) string indexing based on what the user thinks is their language. (Even for characters outside the BMP. Lots of current languages force you to consider an emoji or a cuneiform character as a combination of two codepoints. Yuck! I mean, XP. Well, I really mean U+1F61D, FACE WITH STUCK-OUT TONGUE AND TIGHTLY-CLOSED EYES. But you'll have to imagine it for now, because Slashdot is not written in Perl 6. (Yet.)

As far as I know, Swift is the only other major language so far that attempts to present graphemes as a native speaker of a language would understand characters. However, my understanding is that the Swift algorithm is still O(n) or so, not O(1) like Perl 6.

Beyond that, we also make virtually no ASCII or Latin-1 based decisions in Perl 6. You want Chinese characters in your identifiers, no problem. Tamil in your module names, no problem, we'll map to whatever your filesystem supports. You wanna define a new operator with a happy cat emoji, no problem. It's Unicode all the way, baby! If your client turns your ASCII quotes into smartquotes, we don't care, we just handle it. And not just English quotes, but also other common quoting styles with lowered and/or reversed quotes smartquotes. You wanna write Inf as that funny sideways 8 character, or write pi with the Greek letter, go right ahead. You wanna write your powers with superscripts instead of **, you can do that too. Yes, we're insane, but you're gonna love it...as soon as you figure out how to type it.

By the way, did you know Perligata and Babylscript?

I'm aware of both of them, but I wouldn't exactly put them into the same category. :-)

Python . . . ?
by PolygamousRanchKid

What do you think about Python . . . ?

LW: Well, alright, since you asked...

Python is a pretty okay first language, with a tendency towards style enforcement, monoculture, and group-think. Python is more interested in giving you one adequate way to do something than it is in giving you a workshop that you, the programmer, get to choose the best tool from. So it works well for certain problems that can use an existing tool, but less well for other problems that require a machine shop to make a new tool. For instance, if you only want to think of your list processings as list comprehensions, Python 3 tends to enforce that culturally. If you want several ways to map over a list depending on which order makes more sense in context, Perl 6 will be more accommodating. If you want concurrency with a global interpreter lock, Python might suit. But if you want a concurrency model designed to scale to multicore/manycore, look to Perl 6, which avoids global bottlenecks and non-composable primitives, but instead borrows composable ideas from Haskell, Go, Erlang, and C# instead.

If Python's object model matches how you want to do things, it's fine for that. If it's not, Python doesn't really provide a coherent meta-object model underneath, just a lot of hooks, which might or might not give you the flexibility you need.

Some Pythonistas claim that Python is a good functional programming language, mostly on the strength of list comprehensions, but in my estimation Python has only half-hearted FP support; it really doesn't provide the benefits of lexical scoping, closures, laziness, or higher-order programming that I'd expect in a strong FP contender, nor does it encourage you to think that way.

Finally, many of us feel that Python 3 broke backward compatibility for very little benefit. When we broke backward compatibility with Perl 6, we decided to break everything that needed breaking. It took us a bit longer -- well, okay, quite a bit longer -- but I think we'll be much happier with the end result in the long run.

In any case, I hope Perl 6 will have more staying power than Duke Nukem Forever, even if they did beat us out the door. Same with Python 3.

Perl and PHP
by hcs_$reboot

PHP got a lot of inspiration from Perl, while missing key concepts (you know this one). However, thanks to web development PHP is currently one of the most popular languages. What is your honest opinion about PHP? Are there things in PHP, missing in Perl, you regret not having thought about?

Reversely, which Perl features PHP should have taken?

LW: PHP is both the motivational poster child for worse-is-better, as well as the demotivational poster child for worse-is-worse. Somehow PHP has managed to convince a horde of programmers that if their programs are flakey or hard to maintain, it must somehow be the programmer's fault. It couldn't possibly be because they've been frog-boiled.

P.T. Barnum would love it...

(I suppose in all fairness I should point out that I have friends who have managed to put PHP to good use, but then I have a lot of weird friends, so take that for what it's worth.)

To the best of my recollection, Perl has never borrowed a PHP feature. We didn't even skip version 6, as they did.

And you really can't ask me what other languages should borrow from Perl. Well, you can, but the answer is the same for all of them. If you borrowed enough features to make a difference and arrive at a consistent solution, you'd've just reimplemented pretty much all of Perl 6. :-P

And here you thought I was a humble guy...

Doubtless future years will find plenty of ways to humble me again, but this year I'm officially proud of everything the team accomplished.

Esteemed Individuals
by JohnDeHope3

It seems like a lot of industries have "esteemed individuals" who are given the benefit of the doubt. Priests, rabbis, imams, tenured professors, elite actors and directors, etc. Maybe in technology we have people like Larry Wall, David Heinemeier Hansson, Douglas Crockford, Paul Graham, etc. What are your thoughts on this?

I like having the feeling of esteem. It warms my heart when I think about what I've learned reading Fred Brooks, Seth Godin, Donald Knuth, etc. I hold you all in revence. I don't think this is such a bad thing. Would I blindly follow whatever any you say? No, of course not. But wisdom is wisdom, and experience is experience, and those of you who have it, and have had it, and have written to me about it, are very much appreciated and held in high esteem. I think this is all very good and healthy and perfetly natural. Thank you!

LW: You're very welcome, and thanks for the encouragement!

We have all been given great gifts, and each of us must pass them on as we are able. I am okay with receiving esteem, since it's probably more beneficial to the giver than the recipient anyway. I'll only point out that I get a lot of credit for stuff other people have done too, and that's probably bad for my immortal soul. :-)

Patch and git
by waveclaw

What are your views on version control systems like git and modern development practices around them?

Early F/OSS development practices started with tarballs and patches, moved to packages and VCSes then to (a)social coding with DVCS like Mercurial or git. You've been there for most if not all of that. git can be described as a distributed content management system for patches. Linux Torvals' git --am workflow can be likened to playing chess via email but with kernel development the end game and patches as moves.

LW: As I mentioned earlier, we rely heavily on git for Perl 6 development. Certainly git requires you to think more like a functional programmer, where all your data is immutable, so if you change something, it has a different identity. Most of the design falls out from that, so once you get that into your head, the design makes much more sense. Of course, the git command set is a bit wonky in spots, but you can always write your own shell aliases...

And thank you for patch, by the way. The diff command outputs the difference between two files. You wrote the patch command to take diff output and turn one file into another, including the ability to even go backwards and undo that change later. As someone who's had to package software for a Linux distribution this is critically important tool. Patch lets me preserve the original author's work. But patch (and quilt) lets me still apply needed changes and store those changes in obvious discrete packets of standard format that are diff files.

Well, I suspect git and its ilk have largely superseded the need for patch, partly because they cover the same functionality, but mostly just because networks are so much faster. The main benefit to patch when it came out was that it allowed any collaboration at all, since back in the day nobody had the bandwidth to just keep resending the whole project over and over. The patch program provided two killer features that helped with that. First, the fuzzy matching based on context diffs that would allow you to apply patches to a program you'd since modified yourself (if your mods weren't too violent). Second, the mechanism to enforce the application of previous patchlevels, which I put in in self-defense because my attempts at supporting the first version of rn resulted in tragicomic, er, results. So the second version of rn enforced patchlevels, which kept everyone in sync sufficiently well that they could apply later patches without worrying about whether they skipped some earlier patch accidentally (or more likely, on purpose, since people were understandably lazy about hand-applying patches).

Anyway, patch did help launch the whole open source movement, and I'm content with that, even if patch itself is wandering vaguely in the direction of the sunset.

Project governance
by njahnke

Do you know of any project governance models that are 'known good' other than benevolent dictator for life? It seems to me like 'caring' is the key to project success - and the BDFL him/herself, presumably, cares a great deal and inspires others to care a great deal.

I've always wondered whether this known good level of success could be achieved with some modicum of democracy or in a project that is part of a larger project (and the project manager is appointed from above rather than self-selected). I've heard some good things about Apple's DRI or directly responsible individual, but it doesn't seem like other groups have had as much success implementing it, which makes me wonder about the method.

By the way, thank you for all your work on Perl - it has brought me great fortune.

LW: Thanks. I know some projects have been successfully democratized out to the level of a committee, but I suspect it's very difficult to democratize much beyond that, simply because most people wouldn't have time to learn enough to cast meaningful votes. Certainly the founders of the U.S. felt that way in establishing a representative republic rather than a direct democracy. It's hard enough to get people to vote as it is.

In Perl culture, I'm known as a BDFL, but I tend to emphasize the B over the D, unlike certain other BDFLs we could name. Really, though, I function much more like a supreme court than a chief executive. The irc channel functions as our congress, proposing and hashing out new ideas. But I actually delegate most of the executive and architectural decisions to other designers, and get involved mostly only when I see issues that other people don't see, or when a decision on overall direction or balance is necessary and there doesn't seem to be a reasonable consensus. I do pretty much retain dictatorial veto power, but I try to use that power as seldom as possible.

As Queen Elizabeth would say, I try to reign, not rule.

Why perl?
by Anonymous Coward

Why would you encourage someone to learn perl? (Compared to other programming languages, feel free to just give a general "reason" for perl, or an actual comparison)

LW: The main reason to learn Perl is that, since we don't enforce any particular style or approach, you don't have to switch languages when you start wanting to learn some other programming style or paradigm. We hope that Perl 6 will be especially useful to professors who want to cover industrial strength OO, FP, and concurrent programming in a single course or curriculum.

Achieving Escape Velocity From Perl 5's Gravity
by Baldrson

Perl 6 seems to offer a lot in the base language, obviating many CPAN modules, but the network-effect of CPAN modules creates a gravitational field which, in combination with the differences in the base language, makes reaching escape velocity to Perl 6 challenging.

What is the strategy for achieving escape velocity from Perl 5's orbit to Perl 6's?

LW: The strategy is anti-gravity.

You can build a platform in mid-air that is all Perl 6 on top, but can reach down to call into any existing Perl 5 infrastructure as needed. It isn't quite free of overhead, but it works pretty well, even emulating Perl 5 classes in Perl 6 and vice versa. Perl 5 XS-based modules even work (though Perl 6's Nativecall is much simpler to use). So there's no need to panic and translate everything to Perl 6 all at once. It can be an organic process over time. In general, though, we've found that many people enjoy translating their Perl 5 to Perl 6, since it gives them a chance to rethink and refactor with a new set of tools. We allow people to stop part way up our space elevator, but the view is arguably a little more spectacular at the top.

Double Question
by shaitand

As a Perl 5 programmer, why should I care about Perl 6? Perl is most used by sysadmins and Perl 5 of some sort can be found on all major *nix distributions out of the box. Without this support Perl 6 might as well not even exist for this group who already have to code for Perl versions a decade out of date in many cases. How, if at all, do you see Perl 6 resolving this problem or do you see Perl 6 hitting a different base altogether?

LW: Perl 6 is not meant to replace Perl 5, at least not in the sense that Python 3 is meant to replace Python 2. There are no plans to murder Perl 5. There is certainly some overlap in the applicability of Perl 5 and Perl 6, and Perl 6 arguably has a lot more potential long-term, so at some point in the distant future, we expect that Perl 5 will eventually run out of cultural steam. But we're decades from that point now, and if anything, the Perl 6 effort has injected a lot of new energy into Perl 5 support.

People tend to think of new versions of a language as parent and child (where the child is expected to kill its parent?!?), but nowadays we like to think of them more as older and younger sisters, with different strengths and weaknesses. There is occasionally a bit of sibling rivalry, but by and large they blend well when they sing together. And for sure, many of the Perl 6 developers still love Perl 5 for what it is, and don't want to break that.

Help me promote Perl 6
by Anonymous Coward

I'm a big fan of Perl and still use it when I can for various personal projects and have been known to introduce it in official work-related tasks (where engineers were using batch files or shell scripts, etc.). I love Perl's terseness and flexibility. I learned regex from Perl in my first development job and it has stuck with me through a dozen different languages.

However, as many others have mentioned, it is falling out of favor, and in fact there are very few development shops that even have a need or desire for it. I've looked for Perl jobs and they rarely come up. It seems that most back-ends are now being written in any number of next-gen scripting languages like Python, JavaScript (NodeJS), and Swift. I don't see the advantages of these, but it's often hard to explain to colleagues, CTOs, managers, etc. the value of Perl over the newest trends. And Perl "6" is meaningless because to everyone else it's still Perl. Why should we choose Perl 6 over the new establishment?

LW: Because it's the next generation after all those languages you mentioned.

Perl's place in the world...
by drakaa

Perl used to be central to so many things (the 'glue' language for the internet), but seems to be slowly falling out of use in deference to JavaScript, Java, Python, VBScript/PowerShell, etc. It's the language I used in my first job as a system administrator (back around the time you gave your first interview), and I loved it.

With so many years between the announcement of Perl 6 and it's completion, many people moved on to other solutions or technologies. Perl 6 is here now, but why should I use it?

LW: Because it's the next generation after all those languages you mentioned. Or maybe it's several generations beyond that, but showed up early. :-)

How to think in Perl 6
by mattr

I'd like to express my deep, unending thanks for building something that is really wonderful, Perl, and a wonderful community. I made a living with Perl, the first postmodern language of which I am aware, and derived a lot of enjoyment from TMTOWTDI, and contributed back to the community on Perl Monks at the time. It was a lot of fun to meet some of the famous, talented Perl visionaries then. I enjoy thinking in Perl and it has made me stronger.

I'd like to get into Perl 6 which having stolen all the cool stuff from the other languages appears likely to be the most advanced and artistic of all them. At the very least I look forward to being able one day to think in Perl 6.

Can you provide some examples to /. readers about why you like Perl 6, and what dimensions of awesomeness are waiting beyond Python and Javascript? I think you would be a good person to rouse a wakeup call.

LW: Well, I like Perl 6 mostly because it fits my brain. I like the way it scales up and down on abstraction levels, so you're not forced to use fancy abstractions if you don't want to, but when you do want to, they're there for you. I like that the Perl 6 parser is really a bunch of braided sublanguages that can be derived from and overridden to turn Perl 6 into whatever language I'll want 20 years from now. Probably software to automate my old-folks home...

But lessee, you want some examples, we can do examples. In fact, rather than just me inlining a bunch of them here, I'll recommend you look at sites like Rosetta Code, where you can not only see hundreds of examples of Perl 6, but also compare them to similar solutions in other languages. The Perl 6 solution will usually be one of the most concise and elegant, yet pretty darn readable, even if you don't grok all the constructs. Just as a for-example, you might run into any of various metaoperators in the examples. Say, for a factorial:

sub postfix:<!> ($n) { [*] 1..$n }
say 42!;

Even if you don't know the language, you can see that it's defining some sort of postfix operator called "!", which if you're at all familiar with math, will look like a factorial. The parameter in parens looks a lot like a parameter in many other languages. But instead of an explicit loop or recursive definition, we're doing something to what is obviously a range from 1 to $n. The prefix [*] is apparently related to the * of multiplication somehow, and maybe the [] are indicating some kind of list processing, since other parts of the program might be composing lists using []. Together with the ! hint, it's probably sufficient for you to deduce that [*] is some kind of reduce-with-multiplication operator (sometimes called a "fold" if you're coming at it from the functional programming end of things).

So you try this snippet, and find it prints:

1405006117752879898543142606244511569936384000000000

which you immediately recognize as 42 factorial. :-)

You might also be delighted that, without any extra work on your part, it didn't overflow your native integer type.

Here's another example. Suppose you see:

my @values = some-random-call();
say @values[0,2,4 ... *];

It doesn't take much brain to see that @values is some kind of plural value, probably an array, and that you're probably indexing into it, because you've already figured out that [] seems to have something to do with lists. But what the heck is that subscript? It looks exactly like, gee, the sequence of all the even numbers, up to some kind of wildcard value.

Well, that's exactly what it is, and it gives you a slice of every other value.

So go ahead, and read some of those Rosetta Code examples, even if you don't know Perl 6 yet. Only a few of them are scary, and most of those have explanations. Go ahead, I'll wait here.

That, and if you have a moment, how about a good reason or three (efficiency? creativity? extensibility? ability to suggest further growth? having lots of PhDs?) why Google should promote Perl 6 in-house and support the growth of the Perl 6 language and implementations. Perhaps sponsor completion of the Perl 6 kernel for Jupyter project? How about sponsor some people to document and make accessible free books? What are some Perl 6 initiatives that could use some eyes if not $$?

Well, if Google wants to do something like that, it's really up to them. I do know that some people inside Google are playing with Perl 6, and probably have a better idea than I do when it would be appropriate to promote Perl 6 internally. But I've seen languages rise and fall based on attempting to get corporate sponsorship, so we don't tend to emphasize the institutional end of language promotion much. (One of Perl's slogans is: "We suck at marketing.")

We mostly just need champions who have the vision to drive projects like Jupyter. And to envision them in the first place, since I'm just one guy, and a pretty senile one at that. Even without my age, I'm coming back to that peculiar place I was at with Perl 5 in the mid-90's, when I started getting the pleasant feeling that I was no longer in control, no longer able to keep up with the ferment of activity, that it was no longer possible for me to know everything about every part of the project, and that it was time for the community to be self-energizing. Perl 6 is just now starting to feel that way to me. So I could try to make up some things that need doing, but I'd probably just repeat what you already know. We already have people working hard on various forms of documentation, as well as the release and module tools, for instance.

Much as I'd like to think of Perl culture as a star topology with me at the center, it's only a little bit that way, and I'm mostly just one node in the community graph that has many interconnections I'm not aware of. And that is exactly how it should be.

Rational behind the major syntax changes in 6?
by colin_faber

Hi Larry, As a long time Perl hacker, and contributor of various modules to CPAN I'm wondering what the rational was behind the major syntax changes in Perl 6? I've read various items trying to explain it, but none so far have done a very good job. Admittedly I haven't fully grasp Perl 6 yet (mostly because it involves learning a new language I thought I knew well).

There isn't room here to explain the 15 years of reasoning and discussion that went into all the changes, but I assure you the syntax changes were all well motivated, often for multiple reasons simultaneously. But I can at least give you some examples of the principles we used in the refactor.

First, let's clear one thing out of the way. The heart of Perl is not some particular syntax, but a way of thinking about how a language works together with itself holistically. Mechanisms we use in natural languages come into play, such as metaphor and simile ("A class is just a kind of package, a method is just a kind of function."), as does the idea that your program should talk about the problem you're trying to solve, not just describe its own structure (given/when/next instead of switch/case/break). If you like the way Perl 5 works inside, I think you'll come to like the way Perl 6 works inside even better.

Now, some of those principles I promised. As I write this, I'm riding in a 767 at an altitude of 35,000 feet or so. The outside of this jet is very smooth, compared to the airplanes of 100 years ago, or even 50 years ago. There's a certain amount of drag as the plane goes through the air, but streamlining and vortex control is all about reducing the unnecessary drag on the airplane. So too, computer languages have a certain amount of complexity necessary to solve the problem, but also introduce a certain amount of unnecessary turbulence in the stream of tokens. So some of our syntax changes are just for simplification and cleanup of unnecessary complexity. Case in point: Perl 5, like many C-derived languages, requires parentheses around conditional loop arguments. Those turn out to be largely redundant in a language that requires braces around the block. So they're gone in Perl 6. As a side benefit, this makes it easier to refactor a front conditional into a back conditional, and vice versa.

The change from -> to . can also be seen as such a simplification, especially since Perl 6 is more object-oriented than Perl 5, so you tend to use more method calls. Also it simplifies the learning process for all those programmers coming from little-known languages like Java. Beyond that, when you have a simpler form like a dot, it becomes much easier to define variants of it. Perl 6 can now do things like have an assignment operator form of method call using $obj .= method or a conditional form of method call using $object.?method. Those would be much uglier if we stuck with -> for method calls.

We also changed syntax to make things more regular and consistent. You might ask why we flipped the for loop syntax around from:

for my $i (1..100) { say $i }

to

for 1..100 -> $i { say $i }

Well, the main reason is that curlies now consistently indicate closures, even in special syntax like this. (It's really a kind of lambda, if you're into Lisp and such.) So the loop body is really a closure that is called with $i as a parameter. This automatically scopes the variable to the block, where Perl 5 has to do special magic to make that work. It also automatically allows more complicated argument passing to your loop, so you can loop over multiple values at once, or unpack compound values right there in the signature if you like. The special case of "loop variable" simply doesn't exist in Perl 6. We got rid of oodles of special cases by a few simple syntactic tweaks. In fact, notice how you could use the same closure to write the loop other ways:

(1..100).map: -> $i { say $i }# method style
map -> $i { say $i }, 1..100; # function style

Likewise, a simple block using $_ as its single argument is merely a handy way to write a single-argument closure with a self-declaring argument.

As another example, there's no longer a list of special functions that magically take the topic as an argument. Instead, you just call a method without specifying the object, and it defaults to the topic. So you see things like a bare .say in Perl 6 where you'd see a bare say in Perl 5. But don't have to remember that "say" takes an implicit topic anymore. Another special case gone.

Another driver of syntax change is disambiguation of confusingly overloaded terms. In Perl 5, "package" might indicate a package, or a module, or a class. In Perl 6, those are now separate keywords. They are still packages, but we put the metaphor in at a semantic level rather than the syntactic level. Likewise for subroutines vs methods.

Perl 5 also has a lot of things that are defined operationally through setting magic variables like @ISA. In Perl 6, we tend to use actual declarations instead. They still run code underneath to take care of the operational aspects of the declaration, but the ducts and wires are hidden now unless you take down the ceiling tiles. So modifications to declarations are generally done by applying traits, not by tweaking magic variables.

Of course, Perl has always tried to make easy things easy, and hard things possible. In the syntactic realm we often call this "Huffman coding", in metaphorical honor of Huffman's compression code that assigns smaller numbers of bits to more common bytes. In terms of syntax, it simply means that commonly used things should be shorter, but you shouldn't waste short sequences on less common constructs. One example of this is the ternary operator:

$maybe ? "yes" : "no"# Perl 5 (and C etc.)
$maybe ?? "yes" !! "no" # Perl 6

Here we decided that the ternary operator was just not common enough to waste two very useful characters on. So we demoted it to using doubled question and exclamation marks. This has the added benefit of being more consistent with all the other short circuiting (thunk-based) operators such as && and ||. We picked !! instead of :: because the latter can be confused with package separators, and because consistently throughout Perl 6, ? is associated with testing for truth, while ! is associated with testing for falsehood. (Indeed, instead of writing !!$x to test for truth, you can now just write ?$x.)

Similarly, many things that were easy or hard to write in conventional regex notations now trade around in difficulty. We got tired of writing (?:a|b|c) for simple grouping and "huffmanized" that down to [a|b|c]. But that forces us to "dehuffmanize" [a-z] to something longer, which is fine, because [a-z] is not even correct for Latin-1, let alone all of Unicode. So you have to choose now: either you righteously write <:lower> or <:Ll> to get any lowercase Unicode letter, or if you really, really want an enumerated character class of only ASCII letters, you add angle brackets (which we also stole for metasyntax), to get <[a..z]> instead. Notice all ranges now are indicated with .. consistently. But because we dehuffmanized the notation, we can also fix the negation of a character class to be out-of-band; instead of poking ^ in with the characters, we put a minus outside: <-[a..z]>. (In fact, this notation now extends to set operations on character classes, so we come out ahead. Amazing things happen when you abandon insane syntax.)

These kinds of decisions are repeated over and over in Perl 6, both inside and outside of regex, particularly in places where early Perl slavishly followed inconsistent Unix or C traditions without question, merely to gain initial acceptance. It was time to reinvent all those traditions and replace them with a more consistent and readable notation. The concepts are largely the same though, once you get the hang of it.

Finally, some syntax policy changes are driven by the need for future extensibility. We're a bit stricter in our whitespace rules now, primarily to distinguish postfix from infix operators. Earlier, we could add a postfix bang operator only because the Perl 6 parser knows exactly where it is expecting a postfix, namely after a term with no intervening space. You couldn't write 42 ! there and still have it be interpreted as a postfix. Instead it would see the ! in infix position and treat it as a negating metaoperator for some subsequent boolean test, which might not even be a built-in operator, but one you defined yourself. There's never ambiguity in how it's parsed, though.

Another surprising regularization is that Perl 6 doesn't care whether your blocks are built-in or not. Any closing curly that ends a line is taken to be statement ending, so regardless of whether a construct is built-in or user-defined, you never have to worry about whether to put that pesky trailing semicolon afterwards, because it will always be assumed for you.

Well, that's just a start at answering your question. I hope this helps you understand some of the reasons for the syntactic refactor.

In what scenario is Perl 6 most ideal?
by orlanz

Use the best tool for the job they say. There are many areas that Perl excels at. But in your personal opinion, what kinds of scenarios, situations, tasks, and jobs are most ideal for Perl? What is it the best tool for?

LW: Perl 5 is really good at scanning and mangling text, and hooking up to external APIs via a trillion or so CPAN modules. It's a language that is good at getting out of your face when you just want to solve your problem. It's a good language for people who are learning to program, since it doesn't force you to learn everything up front. Historically, it's been a good workbench for experimenting with various OO and FP ideas (though sometimes at the expense of recommending one good idea).

Perl 6 expands on those strengths by upping its regex game to parsing with full grammars, and by making it almost trivially easy to interface to external libraries. It's still a language that rewards a learn-as-you-go style. It has even less boilerplate compared to Perl 5, and while you can still fiddle with your OO and FP metamodels if you try hard enough, the flexibility is now hidden under some very solid default implementations that will help cultural interchange between different shops. Yet the flexibility is there underneath so you can mold Perl 6 into whatever language you need next, so we think and hope that it will eventually be close to ideal for almost any situation, task, or job. (At least, once we get it running fast enough for whatever you need it for. We're still working on that...)

Double Question
by shaitand

According to most metrics Perl 5 usage hasn't decreased but there is a perception problem indicating it has. Perl usage outstrips python by a lot but many think the opposite is true. Why do you think this perception exists? Is it related to calling the new language Perl 6 giving people the false impression that Perl 5 hasn't progressed as dramatically as it has in the past few years?

LW: Not really. To my mind, Perl 5 is not much in competition with Perl 6 (except inside certain echo chambers). Perl 5's real competition for the last 16 years has been Python, Ruby, Lua, PHP, Javascript, Java, C#, Go, Racket, and Swift, to name a few. And it still stands up pretty well to all those competitors, for a very large problem space. Perl 5 is still way ahead of most other languages when it comes to Unicode support, and is still quite performant for the problems it's best at.

But arguably, each of those languages also offers at least one thing that Perl 5 doesn't do quite so well, or everyone would be using Perl 5.

So finally, we have an actual Perl 6 that can compete with all those languages too, at least in terms of features. One of the ways it does not yet compete with Perl 5 is in the area of performance, but the first half of this year we've already got it running nearly twice as fast as it was at Christmas. We've still got a lot of headroom for optimization. But Perl 6 has its eye on surpassing all those other languages eventually. Perl has always been about raising the bar, then raising it again, and again.

If you got a 'Do Over' for Perl 6..
by jjn1056

Hi Larry,

I'm a profession Perl 5 programmer who is very worried about the future of my language. I remember when you kicked off Perl 6 in the very late 1990s the talk was that it would replace Perl 5. Clearly that never happened. If you could redo the project what might you do differently?

LW: Well, the "talk" you mention was not particularly my talk. At the time, I mostly said that we were trying to do something impossible, and it would take a while, and the only reason we could aim so high is because Perl 5 was so stable and well-maintained, and would continue to be so for the foreseeable future. But people always get a bit more excited than strictly necessary, and when they do, they tend to fall into either/or thinking, when there's no reason not to have both/and. So it was natural that some people posed Perl 6's gain as Perl 5's loss.

Given that we were fighting this zero-sum thinking the whole time, I don't know what we could have done differently, in terms of culture, anyway.

But the fact is, the zero-sum fallacy aside, Perl 5's growth was already tapering off some (compared to other languages) even before we ever got started on Perl 6, because we were already running into some of the unfixable limits of the Perl 5 design. Fixing these structural issues by breaking backward compatibility was part of the motivation for Perl 6 in the first place. For instance, for historical reasons, the Perl 5 design relies too heavily on global state, both hidden and explicit, which in turn is the main reason it's so difficult to write multi-threaded code. Perl 6, in contrast, has no interpreter globals, and only a few natural process globals, such as your $*PID (which you can see is special because of the star, even if you don't know how it's special).

In reality, trying to figure out what we might've done differently is pretty meaningless. We did the best we could with what we knew at each moment. We made plenty of mistakes, but we tried to learn from them, and then make different mistakes.

So I don't wring my hands over the past much. Sure, we can study the past and learn from it. But I'm not really a historian at heart, because I care a lot more about the future, especially the bits I still have some influence over. As my father used to say to me all the time: "It's not what you do, it's what you do next."

And the next thing I see is both Perl 5 and Perl 6 doing their respective jobs pretty well for the foreseeable future, if we make sure the Perl community as a whole stays healthy.

Question
by mlwmohawk

Why is the syntax of Perl so bad? It lends itself to scripts that even the authors can't understand after a week or two.

LW: Obviously because I'm a bad person, and I hate you.:-)

Seriously, the most unreadable thing about Perl 5 is the regexes, and that's mostly not our fault. (Even if everyone else did steal (resteal?) Perl 5 regexes for their own language.) In any case, we fixed all that in Perl 6, unless you're one of the unfortunate few who breaks out in hives when they see sigils. Your grandma could read your Perl 6 code.

what do you think about the Perl guy?
by alloB

Perl is proven to be fundamentally broken. Here are two very entertaining videos about how to exploit weird array casting, hashes and so on. I really think every Perl programmer should have seen it.

What do you say about this criticism and the exploited flaws?

LW: "Doctor, it hurts when I do this!"

"Well then, don't do that."

Who's using Perl?
by quentindemetz

Which large companies are still using Perl in production? I can name Booking.com, but do you know any others?

LW: I daresay the majority of large companies are still using Perl, even if their managers don't know they're using it. ;-)

These days, as it was in the beginning, most of this usage is infrastructural, but certainly there are still some largely-Perl shops out there, such as CPanel, craigslist, and ZipRecruiter. Last I knew, Ticketmaster and Amazon were still heavy users of Perl, and many large financial institutions have made use of Perl as one of their "secret weapons" that helps them be agile in their financial analysis. But they tend not to advertise their trade secrets.

But in any case, I would like to believe that, even if we're at a local minimum for new project starts in Perl, in the future we'll see not only more projects in Perl 6, but maybe also more new projects in Perl 5, since some folks will be glad to start with something familiar if they know there's an upgrade path later if they want it. I could be wrong. I've been wrong before, but I've also been right before.;-)

Oops, I ran out of questions, and didn't finish with a bang. So...

BANG!

An anonymous reader writes: Rosetta Code is a popular resource for programming language enthusiasts to learn from each other, thanks to its vast collection of idiomatic solutions to clearly defined tasks in many different programming languages. The Rosetta Code wiki is now linking to a new study that compares programming language features based on the programs available in Rosetta Code. The study targets the languages C, C#, F#, Go, Haskell, Java, Python, and Ruby on features such as succinctness and performance. It reveals, among other things, that: "functional and scripting languages are more concise than procedural and object-oriented languages; C is hard to beat when it comes to raw speed on large inputs, but performance differences over inputs of moderate size are less pronounced; compiled strongly-typed languages, where more defects can be caught at compile time, are less prone to runtime failures than interpreted or weakly-typed languages."

setori88 writes "Programming for concurrency makes sense in developing for both large scales (cloud computing) and small (multicore CPUs). Some languages were designed for concurrency and distribution; One of those languages is Oz, which provides advanced primitives regarding concurrency and distribution. Oz is mostly declarative, a paradigm that encompasses functional and logic programming. Despite its innovative features and expressiveness, Oz never made it into the wide developer community; one reason is its unusual syntax." Read on to learn about an effort to bring Oz's concurrency features to more programmers. setori88 continues: "But first, some background: Martin Odersky, in designing the Scala programming language, recognized the need for community acceptance of the kind that Oz lacked. He designed Scala as being both close to Java (in terms of syntax and concepts) and interoperable with existing Java libraries. Today, Scala seems to be the best hope for making functional programming accessible to programmers.

Although Scala has no language feature related to concurrency, the advanced library Akka, inspired by Erlang, provides Scala programmers with concurrent and distributed concepts.

Now comes a project attempting to popularize the concurrency concepts of Oz, called Ozma. Ozma implements the full Scala specification and runs on the Mozart VM. It extends Scala with dataflow variables, declarative concurrency, lazy declarative concurrency, and message-passing concurrency based on ports. Ozma extends the duality of Scala, namely the combination of functional and object styles, to concurrent programming."

mikejuk writes "A proof [preprint PDF] has been proposed for the Collatz conjecture about hailstone sequences. A hailstone sequence starts from any positive integer n the next number in the sequence is n/2 if n is even and 3n+1 if n is odd. The conjecture is that this simple sequence always ends in one. Simple to state but very difficult to prove and it has taken more than 60 years to get close to a solution."

Did you ever run into the problem where you knew how to do something in one programming language, but really needed to do it in another? That's what Rosetta Code is all about. A variety of programming tasks are solved using as many languages as possible. You can examine existing tasks, or create your own.

Did you ever run into the problem where you knew how to do something in one programming language, but really needed to do it in another? That's what Rosetta Code is all about. A variety of programming tasks are solved using as many languages as possible. You can examine existing tasks, or create your own.

Did you ever run into the problem where you knew how to do something in one programming language, but really needed to do it in another? That's what Rosetta Code is all about. A variety of programming tasks are solved using as many languages as possible. You can examine existing tasks, or create your own.