Slashdot Mirror

You asked, he answered!

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

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

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

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

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

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

Flying Cars
by WorBlux

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

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

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

How can we get PERL into the browser?
by Proudrooster

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

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

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

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

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

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

Why isn't PERL more windows friendly
by goombah99

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

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

Thoughts?

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

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

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

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

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

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

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

Perl in the embedded world
by mykepredko

HI Larry

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

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

Thanx!

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

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

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

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

Language Design
by columbus

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

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

LW: Everything.

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

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

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

Intellectual Property
by ytene

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

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

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

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

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

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

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

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

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

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

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

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

By the way, did you know Perligata and Babylscript?

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

Python . . . ?
by PolygamousRanchKid

What do you think about Python . . . ?

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

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

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

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

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

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

Perl and PHP
by hcs_$reboot

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

Reversely, which Perl features PHP should have taken?

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

P.T. Barnum would love it...

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

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

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

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

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

Esteemed Individuals
by JohnDeHope3

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

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

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

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

Patch and git
by waveclaw

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

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

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

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

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

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

Project governance
by njahnke

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

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

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

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

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

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

Why perl?
by Anonymous Coward

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

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

Achieving Escape Velocity From Perl 5's Gravity
by Baldrson

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

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

LW: The strategy is anti-gravity.

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

Double Question
by shaitand

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

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

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

Help me promote Perl 6
by Anonymous Coward

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

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

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

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

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

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

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

How to think in Perl 6
by mattr

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

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

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

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

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

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

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

So you try this snippet, and find it prints:

1405006117752879898543142606244511569936384000000000

which you immediately recognize as 42 factorial. :-)

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

Here's another example. Suppose you see:

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

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

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

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

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

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

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

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

Rational behind the major syntax changes in 6?
by colin_faber

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

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

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

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

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

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

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

to

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

In what scenario is Perl 6 most ideal?
by orlanz

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

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

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

Double Question
by shaitand

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

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

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

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

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

Hi Larry,

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

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

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

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

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

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

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

Question
by mlwmohawk

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

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

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

what do you think about the Perl guy?
by alloB

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

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

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

"Well then, don't do that."

Who's using Perl?
by quentindemetz

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

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

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

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

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

BANG!

brindafella (702231) writes Australian scientists have accidentally made one of the most significant discoveries in stem cell research, by studying the transparent embryos of Zebrafish (Danio rerio). The fish can be photographed and their development studied over time, and the movies can be played backwards, to track back from key developmental stages to find the stem cell basis for various traits of the fish. This fundamental research started by studying muscles, but the blood stem cell breakthrough was a bonus. They've found out how hematopoietic stem cells (HSC), among the most important stem cells found in blood and bone marrow, is formed. The scientists are based at the Australian Regenerative Medicine Institute at Monash University. The research has been published in the Nature medical journal. This discovery could lead to the production of self-renewing stem cells in the lab to treat multiple blood disorders and diseases.

JamesD_UK writes "Elissa Suhr of the School of Biological Sciences at Monash University has discovered a 100km long colony of Argentine Ants in Melbourne. With a reduced genetic pool compared to ants native to south America, the Melbourne ants have put aside their differences and formed a super colony. The Argentine Ant poses a threat to native ants who are unable to compete, affecting animals further up the food chain (such as the coast horned lizard in South California). With the average size of an Argentine Ant at 3mm, you could fit 30 million insect overlords along the length of this colony!"

Rogue-Lion.com writes "Take a time out to remember the accomplishments of two bicycle shop owners who changed the world immeasurably, 100 years ago today. The Telegraph is running a story about a recreation of the Wright's (and world's) first heavier-than-air powered flight. President Bush will be in attendance at the event." Setting aside even more exotic theories, rod writes with an alternative point of view: namely, that man's first flight took place in New Zealand, on March 31, 1902. "I admire the U.S.A and the Wright brothers,but there are facts to consider today, 17/12/03, on the centenary of Kitty Hawk." Update: 12/17 13:44 GMT by T : Or was it a Brazillian invention? (Thanks, Anderson Silva.)

An anonymous reader writes "Joseph J Monaghan and David May, of Australia's Monash University, have proposed a novel theory for Bermuda-Triangle-like disappearance of ships at sea: They were swallowed in giant methane bubbles released by undersea vents. Monaghan & May point to sonar of a ship wreck that's sitting in the center of a known methane eruption site, and they've developed a mathematical model that predicts how an eruption could take down a ship. Hey, we ain't talkin' bovine flatulence here..."

An anonymous reader writes "Joseph J Monaghan and David May, of Australia's Monash University, have proposed a novel theory for Bermuda-Triangle-like disappearance of ships at sea: They were swallowed in giant methane bubbles released by undersea vents. Monaghan & May point to sonar of a ship wreck that's sitting in the center of a known methane eruption site, and they've developed a mathematical model that predicts how an eruption could take down a ship. Hey, we ain't talkin' bovine flatulence here..."

paul_harrison asks: "I am trying to introduce a new P2P protocol. It's technically superior in several respects to existing protocols, but there's one big problem: too few people using it. Now this is not a new problem, there's even a name for it, "Network Effect". It crops up all over the place: which websites become popular, which formats and protocols people use, which operating systems people use, even which side of the road people drive on... So my question is this: how do things like these overcome network effects and become popular?"

paul_harrison asks: "I am trying to introduce a new P2P protocol. It's technically superior in several respects to existing protocols, but there's one big problem: too few people using it. Now this is not a new problem, there's even a name for it, "Network Effect". It crops up all over the place: which websites become popular, which formats and protocols people use, which operating systems people use, even which side of the road people drive on... So my question is this: how do things like these overcome network effects and become popular?"

BorrisYeltsin writes "perl.com has Exegesis 4 from the Damian, in repsonse to Larry's latest Apocalypse. This installment covers news of the new flow and block control changes, fully integrated exceptions and some other cool stuff!"

Slashback tonight with more updates, responses and corrections on scalability in P2P networks, TV shows which may not actually be cancelled, tentative wireless service in the Mile High City, and what exactly OS X is. Read on below for these and more.

The difference between theory and practice ... Paul Harrison writes: "I see your theoretical discussion of a scalable gnutella, and raise you a working, open source implementaion! Details in this linux.conf.au talk."

I was in Berkeley at a party, and then things got hazy. In response to the recent story on fixing the UNIX configuration mess, jbloggs writes: "OS X is not on top of NetBSD, but rather is a BSD compatibility layer on top of a Mach kernel. Its closest BSD-lite would be FreeBSD, which is used as a reference platform."

The problem with unstated motivations. Reader app writes "Tim O'Reilly responds to the BountyQuest piece on Salon and featued here. Tim makes some interesting points and clarifications -- especially where he refers to theodp as a crank."

You can't watch, and neither can they. UberOogie writes: "Who didn't see this coming? The MPA shut down Movie 88 today. What should be noted by everyone is that they took no legal action: they just went to the ISP, HiNet, and got them to shut off the pipe. (Movie88 was legal through a loophole in Tiawan copyright law.) So much for process, even in Tiawan. Movie 88 vows to find another provider."

I hope they use the time to reconsider. Cynical_Dude writes: "David Cohen, one of the producers of Futurama, was interviewed on Cinescape. He says that Futurama is not really cancelled, but will run for another year or so ... at least that's how many episodes they've got more or less ready now. FOX hasn't ordered any additional episodes, but Cohen asks fans to "write those letters [...] in physical form, not email" to the FOX executives."

And in other TV News, Glitch Tybalt writes: "Working for Hot Topic has its benefits. We recieved an e-mail saying that Invader Zim will not be cancelled after all. It seems that it was getting no ratings whatsoever, because they kept changing the time slot for it. Once they had decided to cancell it, they left it in one slot to finish playing the remaining episodes out. Then, since everyone could figure out when it was on, it got great reviews. (plus, the Schweet Schwag has started selling like crazy)the Invader Zim petition must have been pretty convincing as well. I guess one of them stopped to read it before wiping his ass. Maybe there's hope for a megaconglomo like Nikelodeon after all..."

Won't someone start making money with unmetered wireless? tabbser writes: "According to Aerie networks, the folks that bought bankrupt Ricochet (www.richochet.com) tests are being conducted in Denver, CO with the support of the City and county of Denver's Office of information technology. Ricochet will test and evaluate the network as part of an initial step to reactivating the service. The full story can be found on Ricochet's web site news room at http://www.ricochet.com. Go Aerie!" Aerie announced this a while ago, but in these uncertain times it's nice to see it actually happening.

Ashes to ashes, little blinking lights likewise. spike666 writes: "Blinkenlights.de is coming to an end! The Blinkenlights project by the Chaos Computer Club will be ending its run February 23, 2002. It was exposed to /. back here They are having a big party, and we're all invited. One last chance for Taco to embarrass Kathleen ..."

Slashback tonight with more updates, responses and corrections on scalability in P2P networks, TV shows which may not actually be cancelled, tentative wireless service in the Mile High City, and what exactly OS X is. Read on below for these and more.

The difference between theory and practice ... Paul Harrison writes: "I see your theoretical discussion of a scalable gnutella, and raise you a working, open source implementaion! Details in this linux.conf.au talk."

I was in Berkeley at a party, and then things got hazy. In response to the recent story on fixing the UNIX configuration mess, jbloggs writes: "OS X is not on top of NetBSD, but rather is a BSD compatibility layer on top of a Mach kernel. Its closest BSD-lite would be FreeBSD, which is used as a reference platform."

The problem with unstated motivations. Reader app writes "Tim O'Reilly responds to the BountyQuest piece on Salon and featued here. Tim makes some interesting points and clarifications -- especially where he refers to theodp as a crank."

You can't watch, and neither can they. UberOogie writes: "Who didn't see this coming? The MPA shut down Movie 88 today. What should be noted by everyone is that they took no legal action: they just went to the ISP, HiNet, and got them to shut off the pipe. (Movie88 was legal through a loophole in Tiawan copyright law.) So much for process, even in Tiawan. Movie 88 vows to find another provider."

I hope they use the time to reconsider. Cynical_Dude writes: "David Cohen, one of the producers of Futurama, was interviewed on Cinescape. He says that Futurama is not really cancelled, but will run for another year or so ... at least that's how many episodes they've got more or less ready now. FOX hasn't ordered any additional episodes, but Cohen asks fans to "write those letters [...] in physical form, not email" to the FOX executives."

And in other TV News, Glitch Tybalt writes: "Working for Hot Topic has its benefits. We recieved an e-mail saying that Invader Zim will not be cancelled after all. It seems that it was getting no ratings whatsoever, because they kept changing the time slot for it. Once they had decided to cancell it, they left it in one slot to finish playing the remaining episodes out. Then, since everyone could figure out when it was on, it got great reviews. (plus, the Schweet Schwag has started selling like crazy)the Invader Zim petition must have been pretty convincing as well. I guess one of them stopped to read it before wiping his ass. Maybe there's hope for a megaconglomo like Nikelodeon after all..."

Won't someone start making money with unmetered wireless? tabbser writes: "According to Aerie networks, the folks that bought bankrupt Ricochet (www.richochet.com) tests are being conducted in Denver, CO with the support of the City and county of Denver's Office of information technology. Ricochet will test and evaluate the network as part of an initial step to reactivating the service. The full story can be found on Ricochet's web site news room at http://www.ricochet.com. Go Aerie!" Aerie announced this a while ago, but in these uncertain times it's nice to see it actually happening.

Ashes to ashes, little blinking lights likewise. spike666 writes: "Blinkenlights.de is coming to an end! The Blinkenlights project by the Chaos Computer Club will be ending its run February 23, 2002. It was exposed to /. back here They are having a big party, and we're all invited. One last chance for Taco to embarrass Kathleen ..."

Slashback tonight with more updates, responses and corrections on scalability in P2P networks, TV shows which may not actually be cancelled, tentative wireless service in the Mile High City, and what exactly OS X is. Read on below for these and more.

The difference between theory and practice ... Paul Harrison writes: "I see your theoretical discussion of a scalable gnutella, and raise you a working, open source implementaion! Details in this linux.conf.au talk."

I was in Berkeley at a party, and then things got hazy. In response to the recent story on fixing the UNIX configuration mess, jbloggs writes: "OS X is not on top of NetBSD, but rather is a BSD compatibility layer on top of a Mach kernel. Its closest BSD-lite would be FreeBSD, which is used as a reference platform."

The problem with unstated motivations. Reader app writes "Tim O'Reilly responds to the BountyQuest piece on Salon and featued here. Tim makes some interesting points and clarifications -- especially where he refers to theodp as a crank."

You can't watch, and neither can they. UberOogie writes: "Who didn't see this coming? The MPA shut down Movie 88 today. What should be noted by everyone is that they took no legal action: they just went to the ISP, HiNet, and got them to shut off the pipe. (Movie88 was legal through a loophole in Tiawan copyright law.) So much for process, even in Tiawan. Movie 88 vows to find another provider."

I hope they use the time to reconsider. Cynical_Dude writes: "David Cohen, one of the producers of Futurama, was interviewed on Cinescape. He says that Futurama is not really cancelled, but will run for another year or so ... at least that's how many episodes they've got more or less ready now. FOX hasn't ordered any additional episodes, but Cohen asks fans to "write those letters [...] in physical form, not email" to the FOX executives."

And in other TV News, Glitch Tybalt writes: "Working for Hot Topic has its benefits. We recieved an e-mail saying that Invader Zim will not be cancelled after all. It seems that it was getting no ratings whatsoever, because they kept changing the time slot for it. Once they had decided to cancell it, they left it in one slot to finish playing the remaining episodes out. Then, since everyone could figure out when it was on, it got great reviews. (plus, the Schweet Schwag has started selling like crazy)the Invader Zim petition must have been pretty convincing as well. I guess one of them stopped to read it before wiping his ass. Maybe there's hope for a megaconglomo like Nikelodeon after all..."

Won't someone start making money with unmetered wireless? tabbser writes: "According to Aerie networks, the folks that bought bankrupt Ricochet (www.richochet.com) tests are being conducted in Denver, CO with the support of the City and county of Denver's Office of information technology. Ricochet will test and evaluate the network as part of an initial step to reactivating the service. The full story can be found on Ricochet's web site news room at http://www.ricochet.com. Go Aerie!" Aerie announced this a while ago, but in these uncertain times it's nice to see it actually happening.

Ashes to ashes, little blinking lights likewise. spike666 writes: "Blinkenlights.de is coming to an end! The Blinkenlights project by the Chaos Computer Club will be ending its run February 23, 2002. It was exposed to /. back here They are having a big party, and we're all invited. One last chance for Taco to embarrass Kathleen ..."

Matthew Priestley has taken a break from slaving for the man to write us a piece where he takes on the convential wisdom that Security through Obscurity isn't secure at all, and tries to argue that sometimes it is. Click the link below to read it. Lots of interesting stuff and some good examples. Its worth a read. The following was written by Slashdot Reader Matthew Priestley Obscurity as Security Disclaimer: The author of this paper works for Microsoft, but his opinions may not be those of Microsoft. In fact, they aren't. The author hereby declares that nobody important is even aware of his existence and that the closest he has ever come to plotting with Bill Gates on the Master Plan was when they used adjacent urinals this one time. The author did not peek.

0 Introduction With the popularity of the open-source mindset, a general contempt has drizzled upon all forms of obscurity. The concept of security through obscurity (STO) in particu lar has been decimated. Security through obscurity, which relies on the ignorance of attackers rather than the strength of defenders, is dead in all but practic e. The victory of the opposing full disclosure approach is so complete that proposed ta ctics die at the mere hint they are a form of STO.

This paper suggests security through obscurity can and does work in certain strictly limited ways, and should not be eliminated unthinkingly from the admin's arsenal. It further implies that the boundaries between STO and 'real' security are blurry and deserve evaluation. However, this paper in no way proposes obscurity as a method for keeping secrets in the long term.

1 Full disclosure does not apply to instantiated data Instantiated data - the data used by specific instances of an algorithm - do not fall within the scope of full disclosure. Were this not so, then even the simplest password would violate the ban on security through obscurity. Passwords are secrets known only to their creators, and password entry is commonly obscured, as in the case of the 'shadow' login of UNIX. While the login protocol may be open, passwords themselves are a form of STO, with obscurity localized in the password string.

Instantiated data are exempt from full disclosure because the risk from their failure is limited. When a script cracks a password, the damage done to the secure system extends only as far as that password's scope. The cracker cannot use the compromised string to gain power directly in another system, even if that system runs the same password protocol. Nor can anything be inferred about the value of one password merely from the value of another with equal or lower permissions.

A similar example of instantiated data obscurity is the private key that forms the basis of asymmetric cryptography. So obscure is this information that it is rare for even the owner to be familiar with its precise value. But such obscurity is a necessary element of modern security schemes. Strong security does not eliminate obscurity - rather, it localizes obscurity to instantiated data. The phrase in cryptology, 'carry all security in the key' might be better phrased 'carry all obscurity in the key'.

2 Full disclosure does not apply to time-limited secrets Secrets that expire after a short lifetime can be protected by a wider array of techniques than long-standing secrets. The defense of information that will be irrelevant in a matter of hours or days may not warrant fully peer-reviewed security. Consider the famous Navajo code-talkers of World War II. Among the Americans coordinating the at tack against Japanese-held islands in the Pacific were a number of Navajo Indians, who spoke a slangy version of the complex Navajo tongue. Commands from HQ were issued through these code-talkers, who encrypted and decrypted with an alacrity that belittled the automated methods of the day. This is an excellent example of time-limited security through obscurity. Secret languages are excellent security in the short-term, but however cryptic Navajo may be, it is a code subject to human betrayal. Use of Navajo against the Japanese much beyond the 3-year window of the war would have been unwise. But because the secrets of American strategy in the Pacific were irrelevant after the conclusion of the fighting, the long-term weakness of obscure Navajo as a security measure was unimportant.

3 Obscurity serves as a tripwire Perhaps the classic example of wrongheaded STO is the administrator who modifies his web server to listen on a nonstandard port - thereby confusing attackers, as the theory goes. Considering the degree to which tasks such as port scanning can be automated, the naivete of this defense seems plain. The cracker might be forced to check all 64512 unreserved ports, but eventually the concealed web server will be found. This appears to be a weakness of STO, but if manipulated correctly, it is in fact a great strength. Imagine that our same admin had also invoked a tripwire script and set it to listen on one or more unused ports. When the tripwire is probed with a SYN packet from a cracker trying to locate the web server, instantly the system goes to full alert. The packet is logged and the admin's pager sounds like an alarm.

Such tripwire approaches work because they do not expect obscurity to keep information hidden. Rather, they obscure information as a ploy to force invaders into showing their hand. Because the obscured implementation differs on each system, crackers must resort to guess-check scanning before attacks can commence. But tripwires are deployed throughout the system, anticipating this very move. Running an automated kit suddenly becomes a risky proposition, and even talented crackers must gamble on, for example, whether 'root' is really the name of the primary account or merely a hotline to the authorities.

Lighthearted implementations of this approach are a staple in the popular "Indiana Jones" films. In one scene, Jones is confronted with a hallway of lettered tiles, all seemingly alike. To cross safely he must step only on those tiles with letters corresponding to the secret word 'Jehovah'. The penalty for a misstep is to crash through the floor and plummet into a gaping pit. Attackers not privy to the password would find an exhaustive search less than optimal in this case. When traps are mingled with genuine data, STO can be a powerful disincentive. Such measures do not make a given machine resistant to breach in the long term, any more than medieval moats could ultimately protect their castles. But like moats, tripwire obscurity provides a critical buffer against attackers, allowing defenders room to breathe.

4 Asymmetric cryptography exhibits traits of STO Despite the notion that asymmetric cryptography such as RSA is 'real' security, in some aspects these methods resemble STO. Indeed, this entire class of cryptography is founded on the hopeful guess that a certain mathematical problem is intractable. The back door into cryptographic methods that rely on multiplying primes is, quite simply, to develop a swift means of factoring those multiples. This NP-time problem must be solved before a private key can b e derived from its corresponding public key, and the notorious difficulty of NP problems leads some supporters to characterize asymmetric cryptography as 'prova bly secure'. This is far from the case - there is uncertainty among mathematicia ns as to whether this problem will even prove non-trivial once approached from t he right angle. Startling progress has been made in solving similar 'impossible' problems using innovative ploys - for example, DNA computers can now solve the Traveling Salesman problem in linear time. Given that asymmetric encryption is used widely in the world's e-commerce infrastructure, the repercussions when this piece of obscurity is cracked are disturbing to contemplate.

One telling argument against STO is that it promotes a false sense of security, leading admins into complacency. But the complexity of asymmetric cryptography, combined with reports of its infallibility, can produce much the same effect. Co nsider this social-engineering exploit of digital signing. Using a tool such as m akecert, the cracker generates a root certificate with the name 'Verisign Class 1 Primary CA' and uses it to sign an end-entity certificate with the subject 'CN=Rob Malda, E=malda@slashdot.org' (CT:Please don't. I'm used to posers pretending to be me in Quake, but not on email ;) The cracker then sends the email to an enemy, using a client that does not validate e-mail addresses and spoofing the return address friendly name. The inexpert recipient, thinking all is in order and knowing that digital signatures never lie, trusts the root certificate and hence forth carries on a conversation with a false CmdrTaco. Only scrutiny of the headers will reveal the mail is actually going to a different address. The widely made claim that public-key cryptography is 'real' security and completely unrelated to 'false' STO delivers a more powerful illusion of security than anything an XOR'd password file can provide.

Even brute-force cryptanalysis has parallels in STO. Suppose we wish to conceal the passwords for a number of Swedish bank accounts. We resolve to write them to a secret location on our hard drive, perhaps a few unused bytes in a file sector. Only we, who know the lucky offset, can read the data. This form of concealment is a typical case of secruity through obscurity. The integrity of our secret depends on the ignorance of the cracker, and a trial of all 2^n possible locatio ns compromises the system. But in what way is this fundamentally different from the 'genuine' security of n-bit encryption? To break this form of security, 2^n keys are generated and tried agains t the cipher text until the result is a plain body. Is the difference between this 'true' security and the 'false' STO merely than n is considerably larger in encryption than in the case of hard drives? But this implies that our real error lay, not in reliance upon obscurity, but in having a hard drive of insufficient size!

5 Conclusions Security in the absence of obscurity is not strictly possible, but good systems both localize and advertise their points of obscurity. When the admin is fully a ware of the obscurity in a system, tripwires and instantiated data can provide a useful complement to more rigorous security techniques. Obscurity cannot keep information safe or concealed for long, but it can make attacks risky and destroy the effectiveness of automatic kits. These benefits should not be dismissed as an article of faith.

biggles writes "Seagate have announced new 50 Gb Barracuda drives. Nuff said :) " Not quite... my math says a 50 gig drive can hold close to a month's worth of MP3s...

Daedalus writes "A link from this week's issue of Science: "...check out the Postmodern Generator, a computer program that writes essays by linking up quotes and jargon." Just reload the page to re-run the generator. " We've mentioned several of these before, but this one is really clean. Generates completely meaningless gibberish, but it sounds like it should make sense. Natural Language Processing is very cool.