The Slashdot Interview With Larry Wall 167
Perl creator Larry Wall has responded to questions submitted by Slashdot readers. Read on for his answers...
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!
Comctl (Score:3, Interesting)
When are we going to see a common controls library for perl that lets applications run natively on iOS, Android, Web, Windows, Mac OS X, and Linux so that we can have the same type of portability as Java without the suck and can write Perl apps in something like Visual Studio.
Thanks for the great answers (Score:5, Insightful)
Was reluctant to do so, but now it seems I'll have to give Perl 6 a try!
Re: (Score:3)
Eh it's a LW interview, of course he's going to talk up Perl 6 and should get props based on that assumption; no use bashing--wait, what?
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.
Followed by "Perl is objectively a broken language"...
"Doctor, it hurts when I do this!"
"Well then, don't do that."
PHP sucks because PHP is broken, and PHP has conned programmers into thinking it's their fault and not the fault of their shitty language. If you found certain language features lead to really shitty perl, it must be your fault and not the language's fault.
Re: (Score:2)
Re: (Score:2)
Followed by "Perl is objectively a broken language"...
There is a saying in the C++ community, that many language features are intended to protect against Murphy, not Machiavelli.
Unlike Java, Perl does not even try to protect you from malicious programmers. Being a scripting language, Perl also doesn't try hard to protect you from careless programmers. Nonetheless, these particular examples of brokenness would be hard to encounter by accident. You can't say that of PHP.
Re: (Score:2)
>There is a saying in the C++ community, that many language features are intended to protect against Murphy, not Machiavelli.
And yet as C++ progresses, it becomes easier and easier to write simple and performant code that can't be exploited. We're a long way from the strcpy() days. I can, for example, uppercaseify strings without ever using a pointer, iterator, square bracket, or at(). And the strict typing of C++ stops every one of the exploits detailed in those Perl Jam videos, with -Wall being there t
Re: (Score:2)
And yet as C++ progresses, it becomes easier and easier to write simple and performant code that can't be exploited.
True, but that's not what is meant by the phrase. "Machiavelli", in this case, refers to the programmer.
In Java, "private" means "private". It is an abstraction which cannot be broken by the programmer. In C++, you can get at a private member of a class if you are sufficiently determined thanks to pointer shenanigans. But you can't do it by accident.
Re: (Score:2)
So hard to encounter by accident that a five-line perl script allowed remote execution because someone used while(<file>) on a variable that they checked was a file, which turned out to also be a string, which turned out to contain the value "ARGV".
That perl script was directly sourced from the perl documentation.
Re: (Score:2)
Programs which accidentally allow remote execution in any non-managed language are easy to find. It's much harder to encounter a Perl script which breaks the security of the Perl language/VM itself.
Re: (Score:2)
You mean like Bugzilla? Or did you mean DBI?
Something tells me you have no idea what kinds of things perl is vulnerable to. Things like the user feeding a list as input, which causes all variables in a function call to shift down, thus giving the user control over variables which aren't user-input variables. The remote execution bug from CGI was from Perl::CGI validating an HTTP post with a foo=ARGV and a file upload named foo as foo being a file (because foo is ALSO a file), then passing foo (which s
Re: (Score:2)
Something tells me you have no idea what kinds of things perl is vulnerable to.
I think you might be missing the context of Larry Wall's remarks, and the attack vector that is being described. We are not talking about ways that a programming language can help protect the system that the program is running on from a malicious program, or from a carelessly written program. We are talking about ways that a programming language can protect its own virtual machine from having its own invariants broken.
Java bytecode cannot crash a Java virtual machine no matter how hard the programmer tries.
Re: (Score:2)
No, I'm not talking about the VM crashing because of badly-written code; I'm talking about the VM allowing you to make it do things.
It's possible to write Perl code that opens a program and runs it, or opens a file and writes it. It's *also* possible to write a perl program which does nothing of the sort, except--oops--it does, because of the way perl's language features work, and all the unexpected shit that can happen when using perl. The VM doesn't crash; it operates *exactly* as designed, and that
Re: (Score:2)
No, I'm not talking about the VM crashing because of badly-written code; I'm talking about the VM allowing you to make it do things.
And that's correct. However, you are not talking about what Larry Wall was talking about when he said "don't do that".
Re: (Score:2)
Then Larry Wall avoided the question by giving an answer to something else. The original poster was talking about EXACTLY WHAT I AM DESCRIBING. He linked to videos of presentations by Netanel Rubin, who demonstrated this code is vulnerable:
use strict; use warnings; use CGI;
my $cgi = CGI->new;
if ( $cgi->upload( 'file' ) ) {
my $file = cgi->param( 'file' );
while ( <$file> ) { print $_; }
}
This allows remote code execution. He also showed how to break REST APIs that create hashes from user input, as well as the myriad of options opened up if the Perl script uses Catalyst or Mojolicious instead of CGI.PM, which allows you to fill variables with things
Re: (Score:2)
OK, we have been talking cross-purposes it appears. I went back to the question and I did indeed miss one crucial detail in it.
My fault. Sorry about that.
Wow (Score:5, Interesting)
Re: (Score:2)
Except it's annoying (to me anyway) that the "editors" didn't correct basic spelling and grammar mistakes in the questions before posting...
Larry on PHP (Score:2, Insightful)
What Perl could have learned from PHP is the value of providing an easy learning curve. PHP creator Rasmus Lerdorf is, lets face it, a much worse designer and coder than Larry. Interviews with him are scary because of that. He is the kid whole was at the bottom of your coding class, yet churned out a product adored by hundreds of thousands people.
PHP didn't achieve that sort of success because of Lerdorf's flaws. It succeeded despite them. Becaus
Re: (Score:2, Insightful)
We all have different values. I see no value in striving to be the king of idiots. PHP continues to suck and it continues to be used for stuff that sucks, no matter how popular. Donald fucking Trump, a laughable embarrassment to most of the rest of the world, is more than a fringe outsider in US politics. That doesn't mean more people should aspire to behave like Trump.
Re: (Score:1)
> Perl will always be around, but if it doesn't make a serious attempt to fix the learning curve problem, it'll end up the wrong kind of 1%er.
You're not the first to say such a thing. A while back many Perl folk decided to try improve Perl in various ways and addressing the learning curve was very much a part of what they wanted to do. They shipped the first official fruit of that effort a few months back. It looks like it'll be another year or three before 7 year olds start having fun with the new Perl
My theory, which is mine (Score:2)
I've thought about this.
How did a catastrophe like PHP come to be so widely used?
I've come up with two answers.
1. Historical accident
There was a need for a PHP-like language to write web back-ends. It could have been Perl, or Python, or PHP, or Ruby, or probably any of a hundred others. At some point, some language gains critical mass. Then everyone uses it because everyone uses it, and we're off to the races. Which language is first to critical mass is--at least somewhat--a matter of chance. As it happens,
Re: (Score:2)
There was a need for a PHP-like language to write web back-ends. It could have been Perl, or Python, or PHP, or Ruby, or probably any of a hundred others.
Clearly you weren't there.
Ruby didn't exist. Python may as well not have existed. Unless you had a lot of money to spend, your choices in the web app space were, at the start, SSI or CGI (the back end for which was often Perl). CGI was notoriously slow, and Perl was quite slow to start a script (it was quite speedy once it was running). Yes, mod_perl existed, but it was at its core a mechanism for extending Apache's functionality, not really a system for building web apps/sites in. JSF existed, if you had t
Stupid python comment (Score:1, Troll)
" 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. :-) "
What a pile of steaming ****. I'm a C++ programmer (so I'm used to obtuse syntax), not a manager but I'd always choose Python over Perl since I want a scripting language to have a lot of useful libraries (yes, perl has those t
Re: (Score:2)
Thanks for your comment, it expresses my view pretty well. I want to add a note about this:
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.
I started coding with BASIC and Z80 Assembly in the late 80's, then coded mostly C until 97 when I switched to C++, then finally in 2006 I switched to Python as main programming language. In these ~30 years I obviously had to program in several other languages, and Perl is by far the one I most hated. After my bad experience with Perl I even translated some Perl scripts coded by a biologist friend (Perl seems to be st
Re:Stupid python comment (Score:4, Insightful)
After my bad experience with Perl I even translated some Perl scripts coded by a biologist friend (Perl seems to be strong in the field) to show her how much more clear and concise they can be made in Python, and the difference is undeniable.
a) Scientists are terrible at Perl. "You can write FORTRAN in any language" applies to them; they often write Perl as if it were C. Or that's my experience based on Stack Overflow and Perlmonks questions. They aren't programmers, they're scientists, and it shows.
b) A rewrite is always clearer, no matter the language.
Re: (Score:2)
a) Scientists are terrible at Perl. "You can write FORTRAN in any language" applies to them; they often write Perl as if it were C. Or that's my experience based on Stack Overflow and Perlmonks questions. They aren't programmers, they're scientists, and it shows.
Yep, that's usually the case.
b) A rewrite is always clearer, no matter the language.
You are right, of course, and as I used the word "translated", that could imply a rewrite. I should have used "transliterated", as I kept the original structure.
I tried to find these scripts so I could give a concrete example, but I could only find my Python versions. But it was stuff in Perl like
open($file, "file.txt");
my $data = do { local $/; <$file> };
that in Python becomes
data = open("file.txt").read()
that makes you think, wtf Perl??? Really, why do you need all that
Re: (Score:3, Informative)
that makes you think, wtf Perl??? Really, why do you need all that crap just to read the whole file?
It's mostly because Perl is line-by-line by default. Most of the time you don't want to read a whole file into memory, do you?
local $/; switches to slurp mode (temporarily).
You could also do my @data = <$file>; which slurps the whole file, line-by-line, into an array, if that's what you need.
Re: (Score:2)
It's mostly because Perl is line-by-line by default. Most of the time you don't want to read a whole file into memory, do you?
[...]
You could also do my @data = <$file>; which slurps the whole file, line-by-line, into an array, if that's what you need.
I can't say "most of the time", my guess is I use equally reading the whole file, reading chunks of binary files, and reading lines.
local $/; switches to slurp mode (temporarily).
Ahhh, of course!!! That's obvious! </sarcasm>
Not only the syntax is cryptic, the terminology is terrible! "Slurp" is a funny way to describe the process, but introduces one more step (two more for non-native speakers) to understanding it. Compare that to Python's `file.read()` and `file.readlines()` and you'll understand why Python is better for beginners and for people t
Re: (Score:1)
I can't say "most of the time", my guess is I use equally reading the whole file, reading chunks of binary files, and reading lines.
Well, binary files aren't read with the line-by-line <> operator but with the read() function. So it fails in only 1/3 of your use cases.
local $/; switches to slurp mode (temporarily).
Ahhh, of course!!! That's obvious! </sarcasm>
Not only the syntax is cryptic, the terminology is terrible! "Slurp" is a funny way to describe the process, but introduces one more step (two more for non-native speakers) to understanding it.
Frankly, there are other ways that make sense for beginners. A while loop that appends to a string is common, for example.
Compare that to Python's `file.read()` and `file.readlines()` and you'll understand why Python is better for beginners and for people that want maintainable code.
Yes, I know, you can have easy-to-read functions like that with an OO design. Use the module IO::File if that's what you want. It's included in the base Perl distribution. It provides the methods getline, getlines
Re: (Score:2)
You can always cleanup that Perl 5 code using a module such as Path::Tiny [metacpan.org]:
use Path::Tiny;
my $data = path('file.txt')->slurp;
Re: (Score:2)
I dunno but I do
open($file, "file.txt");
my @data = <$file>;
To slurp in a whole file
Re: (Score:2)
Well, in some ways this isn't a bad thing to bust perl on, because most of us would agree that doing something like a "local $/;" is a bit of cruft we're stuck with for legacy reasons. But on the other hand, neither form is something that a beginner would know without being told, really you're going to need to be handed an example to learn it, so the actual practical difference between the two isn't that huge.
Interestingly, there have been multiple attempts at cleaning up this particular cruft but none ha
Re: (Score:2)
By the way, the Perl 6 way of doing this is:
See: https://docs.perl6.org/routine/slurp.html [perl6.org]:
And the same thing can be done in perl 5 with the CPAN module Perl6::Slurp: https://metacpan.org/pod/Perl6::Slurp [metacpan.org]
I look forward to hearing why Python's chained method call syntax is so much more newbie-friendly than a single, colorfully-named built-in command.
Re: (Score:2)
But on the other hand, neither form is something that a beginner would know without being told, really you're going to need to be handed an example to learn it, so the actual practical difference between the two isn't that huge.
A beginner wouldn't know that a "read" method exists in a "file" object. But when confronted with a "file.read()" invocation, the meaning seems pretty straightforward to intuit.
Now, "local $/;" gives you absolutely nothing to reason over it. Only after your explanation I have a grasp on what's happening (which in Python could be represented with "".join(file)) , though I still don't understand how the $/ syntax means $INPUT_RECORD_SEPARATOR = undef.
Re: (Score:2)
Ah, well, "local" assigns a temporary, dynamically scoped value to "$/", defaulting to an "undef", i.e. undefined.
"English" is a module that provides alternate, more readable names for the old-style globals like "$/". It hasn't really caught on, so my point is that using it would be a source of confusion for different reasons.
It is however, pretty funny that on a typical unix box a "man English" will take you to the docs for an odd perl module.
Re: (Score:2, Flamebait)
You have that backwards. Perl is terrible at scientists. Perl is terrible at everyone except Larry Wall and a handful of other hacks that can't see why it is a truly abhorrent language.
Ah. Now I see the problem. You have never actually written anything in Perl! ;-)
Re: (Score:3, Insightful)
It someone might think its clever to write a 10 line script in perl that can process an entire DB and make the coffee at the same time, but I'd sooner have to work on the 50 line python script that I can actually understand in 10 mins, not 3 hours.
I don't see why the Perl script must be written in ten lines. Surely it can take 40-50 lines and be understandable in ten minutes?
Re: (Score:2, Informative)
... I'd always choose Python over Perl since I want a scripting language to have a lot of useful libraries (yes, perl has those too) but crucially I want any code I write in it to be obvious what its doing not only to other coders in the future but to me too!
I get what you're saying (and agree with the general thought process), but I cease to see how this makes Python a "better" choice over Perl (or more importantly, any other language). I'll share my view, and I apologise in advance for my lack of brevity.
There is a common misconception that any Perl written is obfuscated or difficult to read. I've been doing Perl since the mid-90s. I'm 39. I'm a UNIX systems administrator by profession. Every piece of Perl code I've written has been intentionally readab
Re: (Score:2)
"For code that's not immediately obvious, or complex: that's what comments are for."
Agreed. But sadly a lot of coders think comments are for sissies, so given that I'd sooner have to read their uncomment mess in python than perl.
"Have you ever used the MySQL-python extension (a.k.a. MySQLdb)"
No, but I've used Cx_Oracle and that seemed fine to me. Anyway, you can't blame the language for someones bad library design. That happens in every language.
Re:Stupid python comment (Score:5, Insightful)
Every language debate on Slashdot eventually winds up here.
Some programmers hate their peers. These programmers choose languages that are good for hating your peers (Java, Python).
Some programmers admire their peers. These people write "in my shop we've been using C++ for a decade now, and while it's far from a perfect language, we've never really had a problem with it".
Thesis: Many of the people who hate their peers suck as teachers.
True? False? Hard to say.
Personally, I know that I like my peers a lot more when I unselfishly contribute to their growth as programmers. But, hey, suit yourself. Sit in the corner all alone reading 50 lines of pablum, where 10 lines of well judged code would have done the job instead, without even lapsing into arcane idiom.
My personal hell is paved with pablum.
Re: (Score:1)
Whatever it is you're smoking I suggest you refrain. Once your brain fog has cleared you might be able to write a coherent post.
Re: (Score:2)
In python, % is an operator, taking the items on the right-hand side and inserting them into the string on the left-hand side. This operator is not SQL aware, so the items are simply inserted into the string without even trivial escaping.
The comma separates arguments, making the list of items a second argument for execute() to properly handle, hopefully using the database's prepared statement execu
Re: (Score:3)
" 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. :-) "
What a pile of steaming ****. I'm a C++ programmer (so I'm used to obtuse syntax), not a manager but I'd always choose Python over Perl since I want a scripting language to have a lot of useful libraries (yes, perl has those too) but crucially I want any code I write in it to be obvious what its doing not only to other coders in the future but to me too! Now I don't much care for the whitespace-is-indentation aspect of Python, but aside from that its syntax kicks Perls backside I'm afraid. It someone might think its clever to write a 10 line script in perl that can process an entire DB and make the coffee at the same time, but I'd sooner have to work on the 50 line python script that I can actually understand in 10 mins, not 3 hours. Too many sigils in a language does NOT aid clarity - it has exactly the opposite effect. Line noise is not a good look for code.
Just because your programmers golf stuff because they can doesn't mean that ALL programmers golf stuff. Bad code exists in EVERY language, because there's no limit to bad programmers, speaking as one who considers themselves mediocre at best.
Saying that "perl sucks because clever programmers try super hard to be clever because they can" isn't a verdict against perl. I would say that any language that's flexible enough to allow for such things will allow clever programmers to pull stunts like that.
Re: (Score:2)
They don't, they simply add to the already unreadable brevity due to a lot of implicit functionality.
Re: (Score:2)
I notice you used a comma in your sentence because it has a meaning and add information to the sentence in addition to just letters. You could have used bold and italics. Sigils in Perl have the same purpose.
Re: Stupid python comment (Score:1)
Whereas a function called "poo()" would be perfectly clear? It's the programmer's job to use sensible names, in any language, no matter what set of characters is available to choose from.
If your employer is Craigslist (Score:1)
Please start writing some 1337 scripts to sort the spam issue out. kthx
This interview can't have been with Larry Wall (Score:1)
it was readable
something worth reading in full at /. for a change (Score:5, Informative)
read title.
Perl 6 is a thing? (Score:2)
Re: (Score:3)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Christmas already happened?? 2016 is wild.
Derp. Even preview won't save me from myself.
Re: (Score:3)
A "release" was made, by which it is meant that there is a contract between the
developers and the users: the developers will not break things that are tested
for and currently pass in the test suite until the next version, and for the most part
any changes to the test suite (and thus, behavior) in that next version have to
be well justified, documented in release notes, etc.
Also, a lot of features work and as a whole the language is very usable.
If you'd been playing with Perl 6 before this, there was a *lot* o
This is the best thing that's been on /. in years. (Score:1)
Thanks Larry.
whiplash et al: More of this!
Re: (Score:2)
Re: (Score:2)
Don't you [whipslash] need a celebrity email system?
Don't I need a way to spot such interesting articles? PERL is one of my favorite perversions, and I still use Strawberry PERL several times a week. Surprised I never noticed this article.
Kind of confused, however. On the one hand, you seem to be laying low (which only makes good sense in the absence of that celebrity email system), but on the other hand, you (if you are the source of the newest poll) seem determined to harvest the whirlwind. On the third h
Re: (Score:2)
Re: (Score:2)
Actually I think of it as a kind of dual of the spam problem. What sort of email system would help people who get too much non-spam? Or perhaps I'm just trying to reduce my own tension because I want to react to something that a celebrity had done (usually what an author has written in my case), but I don't actually want to waste their extremely valuable creative time?
What I would like to receive when I write to such a person would be a robotic reply from their celebrity email system. It would actually retu
Re: (Score:2)
Re: (Score:2)
More importantly, why don't you let the members help pay you to look into things?
Based on my experiences in pitching these ideas over the last few years, it seems to me that the main reason "decision makers" hate the ideas is that they fear loss of control. There are plenty of ways to keep a leash on the mob, most obviously be retaining careful control over the projects that actually get offered for funding.
Thanks Larry (Score:2, Insightful)
Thanks Larry for the answers!
And thank the heavens that Slashdot actually managed to get somebody who answers the damn questions instead of giving tiny meaningless answers.
Great answers Larry! (Score:4)
As always, we appreciate the time taken to respond to the questions and you're insight into the life, the universe and everything.
I tried watching the videos mentioned (Score:4, Interesting)
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.
I didn't know about the videos and tried watching them, but I couldn't finish they since they seemed to me very idiotic. He seems to "misunderstand" a lot of very useful features of perl on purpose, and poses as a big WTF the fact that it doesn't die on every weird thing he tries. And people in the audience actually find it funny... Enabling warnings (as you always should) would generate a helpful and explanatory warning on each of these occasions. Also, Perl has references for many things that don't work as he "expects". The only truth is that there are some sloppy programmers that leave vulnerabilities, but that happens regardless of the language. The guy should also work a bit of his articulation if he wants to be a public speaker, sure I am ESL too, but that doesn't mean I don't try to sound clear...
As for the coding style, apart from regexes which are hard to read for almost everyone (and not just in Perl), I have found that if you don't try to be a smartass (e.g. super-concise or obfuscate on purpose) when writing Perl code, it can be quite readable. For example, when I finished my Master's project which involved a lot of spidering and text processing in Perl, I had to pass it on to the next generation of students. I gave the code and a document with a quick description of the role of each script and after a week I asked the students if they had questions. They told me they had no questions, they found my code surprisingly readable and could follow it. Well, see, I tried to make it readable and it was, perfectly readable in all its Perl 5 glory ;)
Re: (Score:2)
I just watched them both, and while I think he overdoes it for effect, and some people may dismiss it because it's full of camel memes, he's got some basic points that can't be ignored.
The language and some of its libraries have implicit unexpected behavior (as opposed to the "nasal demons" explicitly undefined behaviors in C), that just isn't something even a well-experienced programmer would expect from a typical programming language, and even with workarounds, there is still unexpected behavior. Arrays
Perfect Sig (Score:3)
The Hunting of the Snark (Score:1)
Re: (Score:1)
You hit the nail on the head, and the funny thing is that it used to be true that he openly admitted that Perl was exactly that. This new spin, where he says Perl is a great language for the masses, is in my mind a sell-out of his honesty and ideals. He is brilliant, but his languages are niche languages and no software professional should ever use them unless they can guarantee the only people who will have to work on the software are niche programmers.
Re: (Score:3)
wheelbarrio wrote:
Oh yeah? Well if you're so smart you'd tell us how you managed to avert world war and achieve world peace in our time before you take pot-shots
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
You see, this don't sound like a technical dispute to me.
Re: (Score:2)
You see, this don't sound like a technical dispute to me.
Spoken like someone who's never managed a software development project bigger than themselves.
Of course it's a technical problem. Why buy into a tool and ecosystem with warts that piss more people off than the next tool's?
Re: (Score:2)
Point the first: this is a non-sequitor. Once again, y
Re: (Score:2)
Point the first: this is a non-sequitor. Once again, you're trying to claim it's primarily technical issues with the software, and I'm making the point that you just don't like Larry Wall. He's just not *one of us*. Why no gentleman would take swipes at Python's one-true-way.
Ascribing particular states of mind to me might well make your points easier for you to make, but it doesn't make them any good. I don't dislike Larry Wall — I've never met him — although I certainly think he says some silly things, and I don't care at all for the language that he wrote. And although I like Python I haven't used it in my day job for several years now; my workplace is a Groovy/Java/Scala shop.
If you were actually someone in management, would you listen to someone like yourself? Why?
Because I understand that despite what you seem to think, the technical challenges invol
Re: (Score:2)
What I'm hearing here is you're arguing that the smear campaign worked, you convinced enough of the kids that perl is not bright and shiney, and obviously management should move o
Ternary Fail: "??", "!!" (Score:2)
or:
or:
or:
Would of made far more sense than to use NOT NOT "!!" as a ternary operator. Even more so since ! (NOT) is valid.
Re: (Score:2)
Re: (Score:2)
Considering the Regex code that I see in Perl 6 is easier for me to read than the Perl 5 equivalent. I have more than a decade's worth of experience with the latter, but only a couple years worth in the former. I would definitely say it is worth it.
I would like to see a conventional regex for JSON that is easier to read and understand than JSON::Tiny::Grammar [github.com].
Everything that was broken deserved to be broken, and was replaced by a much more generally useful feature.
( That said there is an adverb that
Fixing simple errors (Score:2)
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."
This answer is a cop-out to a clear flaw found in the language. That is, list flattening. There are two basic common errors when implementing your first interpreter. They happen because the natural efficient, elegant, but incorrect solution lead you that way. The errors are, namely, dynamic scoping and list flattening.
Heck even LISP created by giants of computer science had the dynamic scope error which shows you how easy is to fall in that trap. Dynamic scoping comes from searching in the dynamic environm
Re: (Score:2)
Lisp fixed that error early on. Perl creator Larry Wall solution to "break pedal doesn't work" is "stop using the break pedal" (yay car analogy!). Seriously, that is what you have to say about that noob error?
What I take away from Larry's flippant comment: "Don't do that" -> Don't use Perl.
BS (Score:2)
Re: (Score:1)
And perl has anonymous functions with proper closures, so there's very little I need a 'yield' for. But if I do need some variant of a coroutine, there's the Coro library.
Re: (Score:2)
Re: (Score:1)
( with Python's yield being roughly the same as take )
The reason for for the gather is that it requires you to be explicit about where the generator is, unlike Python which is implicit.
my @even = gather loop { take $ += 2 };
say @even[^10]; # (2 4 6 8 10 12 14 16 18 20)
Which in this case would be better written as
my @even = 2,4,6
Here is another example.
# note that this isn't a generator on it's own like it would be in Python
sub roll-die ()
Re: (Score:2)
wow (Score:2)
Re: (Score:2)
Re: (Score:2)
Also most of the things he wrote about Python are very similar to things I've seen stated by Python programmers.
That doesn't make them true. I started using Python around version 1.2 (ONE point 2). So I am going to claim that I am fairly familiar with the language. Despite the fact that Python 3 broke some C code which uses Python and despite the fact that Python 3 features are still backported to Python 2.7 branch, the push to Python 3 to replace Python 2 is there. It just happens to be more of a gentle nudge than a push. But this fact, in itself, signifies that Python 3 is meant to replace Python 2 and that's
Re: (Score:1)
He said "here" in Europe. Wherever "here" is it has only one timezone.
Europe timezones (Score:2)
Just one counter example: Lisbon, Portugal is not on the same timezone as Paris, France. WET/WEST vs EET/EST.
Re: (Score:1)
And if you are in Lisbon you're not in Paris. So "here" could be either Lisbon or Paris, but not both.
Anyway, the most important point is that any discussion of Perl must result in linguistic nit-picking.
(I'm a crazy Perl fan. Might like to pick up Perl6 one day).
Re: (Score:2)
Russia has eleven time zones. Russia begins in Europe.
11? That's ridiculous [youtube.com].
Re: (Score:2)
I'd echo that, but the cat's out of the bag.
Re: (Score:3)
Re: (Score:3)
Perl 6 aims to be a compiled language and in large part already is -- just, the compiler needs a lot of work to catch up to more established languages. There is still the ability to compile Perl 6 code from a Perl 6 program which could be interpreted as interpretation, but most people won't be doing that.
The compiler already does a fair amount of compile-time bug detection. Best way to know more is to play with it.
Re: (Score:1)
Perl 6 is (mostly) ideologically non-ideological.
Thus, for example, to the degree compilation is clearly the sensible thing to do, a Perl 6 compiler is enabled and encouraged to compile things. Thus many typos, type errors, etc. are caught at compile-time. In contrast, by default, public method calls are late-bound. And so on.
Re: (Score:2)
And they didn't fire you and hire a firm with competent programmers? I guess there's one born every minute...