Slashdot Mirror
The Slashdot Interview With Larry Wall
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!
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.
Most of them deserve a 5 Insightful + 5 Funny :-)
Was reluctant to do so, but now it seems I'll have to give Perl 6 a try!
Slashdot, fix the reply notifications... You won't get away with it...
This is the best interview I've ever seen on Slashdot. Thanks!
Yeah, all of Europe is on the same timezone.
Get a grep of yourself!
Great interview. I first learned perl back when I was in high school, learning how to create web sites with interactive components. My first impression was that perl was specifically for web sites. Only later did I learn that perl is a "swiss-army knife" that can be found on just about all UNIX systems.
Larry doesn't say much about PHP other than a veiled insult.
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. Because of that easy learning curve. Perl's failure to fix its steep learning curve problem is why PHP has survived while Perl has struggled. http://www.fastcompany.com/302... It's also why newer languages like Python and Ruby which fixed PHP's flaws *and* have an easy learning curve did so well.
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.
" 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.
Please start writing some 1337 scripts to sort the spam issue out. kthx
Donte Alistair Anderson Roberts - hi son!
Karma: Chameleon
it was readable
read title.
"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. :-) "
Creepy smile there Larry...
So.. Perl6 is actually finished? Or is that the wrong sort of question to ask?
Thanks Larry.
whiplash et al: More of this!
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.
He said "here" in Europe. Wherever "here" is it has only one timezone.
Watch this Heartland Institute video
Since Mr. Wall answered a question about language design, I wonder how he managed to invent an assignment operator that modifies the right hand side.
Eu quero mais que essa merda da Helena se mate enfiando a Samanta no cú dela e que meu caralhou cresça.
Russia has eleven time zones. Russia begins in Europe.
Yes, and if he's in Russia, then "here" refers to whichever part of Russia he's in, not the entire country.
As always, we appreciate the time taken to respond to the questions and you're insight into the life, the universe and everything.
Mimetics Inc. Twitter
First, great questions and answers, thanks! Really awakened my interest in Perl.
How do you see Perl in relation to compiled languages (to give a spectrum: C, Java, Rust)? I know performance will be the first thing that many people will think about, but there are many other interesting issues: when optimisation happens, how concrete library APIs are, API documentation (including how unexpected input is handled), when bugs are detected in your code (compiler/validator or run-time), how many bugs can detected just by compiler/lint tools.
Two, actually. Normal time and summer time.
EET and EEST.
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 ;)
Damn - I wanted to ask, what's it like living with all warnings treated like errors?
"Software interprets lawyers as damage, and routes around them" - Larry Wall
I'm a minority race. Save your vitriol for white people.
I understand you're proud of Perl 6: that's great, but I'd be more convinced as a developer or manager of developers to take a deeper look if you could demonstrate with examples how teams of mixed experience and aptitude have built complex, performant, maintainable software with it, rather than throwing ill-judged stones at the competition (the Python and Java comments in particular). There are just so many panes of glass around... and I find myself strangely uncompelled by a cute factorial one-liner. And as roll-my-own guy, I'd be more convinced if you could demonstrate elegance surpassing Haskell or LISP.
"A last programming language" is a neat turn of phrase that a) is hard to reconcile with the claim that you're "thinking generationally" and b) much like the original TIMTOWTDI motto, though doubtless sprung from your own formidable brain, ironically reads to me like the exasperated marketing department's spin after realizing that "shit, Larry's written another language for Larry".
The discussion was about a specific point in time, so only one of those is applicable.
^--- What he sed.
Freindly? Really?
It's apparent that someone asked Larry how it feels to be beat to market by DNF. I'm so glad they did, as I didn't figure I'd ever come across him to do the same. :)
Can this really be the same Larry Wall who's famous for promoting hubris as a virtue?
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.
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 environment \pi recursively for the declaration of the given value, instead of searching upwards in the lexical symbol table for the current value. A similar naive representation leads to flattened lists. Trust me, been there, done that myself, both errors. If you design your interpreter cleanly, the code pulls you in that direction.
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?
Just one counter example: Lisbon, Portugal is not on the same timezone as Paris, France. WET/WEST vs EET/EST.
I stopped reading at Python gives you one way of doing things well. Python's 'yield' allows you to maintain state entirely within re-entrant functions. Which removes a lot of need for classes (as keepers of state of methods). The data-operation duality is much more fluid in Python than it is in Perl. The only reason Perl was ever successful is because it did wild card operations really, really well. Everything else about it is unreadable. Python allows you to have both RAII(with 'with' keyword) and gc-style resource collection. Perl (and I admit that just like everyone else I didn't bother with Perl 6) never had RAII despite living in the networking world, where msg parsing makes it of paramount importance.
Any guest worker system is indistinguishable from indentured servitude.
Is he just bitter? He didn't give away his billions to "the people". He essentially gave it to O'Reilly Press. He keeps making statements about Python which are just aren't true. Oh, and as much as I regret it, Python 3 *is* meant to replace Python 2. I like the Python 2 print statement, but such is life.
Any guest worker system is indistinguishable from indentured servitude.
Larry's still at it? The last time I saw a Perl script in production, we had to get the business to sign waivers to absolve us. Sorry man, your Aspergian vision is dead.
AWKward cannot compute.
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, it was PHP.
2. The default behavior of the language processor is to emit the entire program text on STDOUT.
What this means is that you can take an entire existing static web site--a whole tree of static HTML pages--declare them to be PHP scripts, et voila, there is your web site, just like it was before, except that now you can start adding $variables to your pages and creating dynamic content. It gives managers and salesmen and marketing people and non-programmers a way to get into the game without actually having to do any of that--you know--programming stuff.
Calling this an easy learning curve misapprehends the situation. It is more in the "this one weird trick" category.
The actual PHP learning curve is vertical, which is to say, no one can learn PHP. The language is such a tangled mass of inconsistencies, exceptions, breakage and lossage that acquiring the knowledge necessary to use it competently is virtually impossible.
Russia has eleven time zones. Russia begins in Europe.
11? That's ridiculous.
And is there a chargeback method?
Tracy Johnson
Old fashioned text games hosted below:
http://empire.openmpe.com/
BT
I'd echo that, but the cat's out of the bag.
working on it!
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 hand, you didn't ask for any suggestions this time, though I have thought of several improvements to my troll-deterrence suggestion, mostly in terms of making it easier to implement (and more symmetrical) in the slashdot context. On the fourth hand, I still can't help pay for the implementation or ongoing costs of anything in particular (but could only donate in unacceptably general terms), and on the fifth hand I already forgot what hand this was...
Had to hit the head, which apparently reminded me to suggest Stallman (rms) as an interview candidate. See if you can get him to confess to his cancerous anti-design ideology of anarchism. After all, slashdot suffers from emacs disease, an extreme form of feeping creaturitis. (I've had several email exchanges with rms over the years, and they even contributed to the development of the financial model I've suggested slashdot should consider adding, but mostly I've concluded that he's from a different universe than the rest of us.)
Now to look at the secret Larry Wall interview...
Freedom = (Meaningful - Coerced) Choice != (Speech | Beer^2), and sad sock puppets' bad mods avail them naught.
What do you mean by celebrity email system?
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 return a webform based on the analysis of my email. As I work through the reply I would be able to confirm the analysis (or provide feedback to improve the analysis) while hopefully getting answers to any questions or recording my sentiments for the convenience of the author in question. After getting through the analysis (which would also prove I'm not a robot), then I would be able to submit the form and the answers would be tallied up and I could see how other people feel on the same issues.
There should also be some meta-options, too. For example, there could be an option to publish my letter on the author's website, preferably 'close to' the letters of people who feel similarly to me. Then we would be able to see the comments and react to them, still without bothering the celebrity. If some part of the website becomes highly active, then maybe that should also be brought to the celebrity's attention. Another obvious meta-option would be to argue for escalation, if the author of the email insists that the email needs more personal attention, but I think this should be deliberately made quite difficult.
In cases where the celebrity wants to communicate more personally with fans, certain email could be selected for a personal reply. Perhaps a lottery or a vote of other fans for the best email, and the celebrity's reply could be shared widely.
Anyway, I've written to a lot of authors over the years, and many of them have been kind enough to respond, but I wish I had been directed to a celebrity email system. Not sure about your situation, but slashdot used to be a hotbed of activity--and I noticed that you stayed out of the way after the wasps' nest poll was posted recently...
P.S. And once again I wish that slashdot were using a financial model such that I could help contribute to the development costs or the ongoing costs (in the case of some authors I admired).
Freedom = (Meaningful - Coerced) Choice != (Speech | Beer^2), and sad sock puppets' bad mods avail them naught.
Good ideas. I'll look into it
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.
Freedom = (Meaningful - Coerced) Choice != (Speech | Beer^2), and sad sock puppets' bad mods avail them naught.