Slashdot Mirror

At an event this month (you can find the video of it here), Davide Cavalca, a production engineer at Facebook, spoke about the growing adoption of systemd at the data centers of the company. From a report: Facebook continues making use of systemd's many features inside their data centers. Some of their highlights for systemd use in 2018 includes: Facebook's servers have been relying on systemd for about the past two years. Facebook is using CentOS 7 everywhere from hosts to containers. While relying on CentOS 7, Facebook backports a lot of packages including new systemd releases, Meson, other dependencies, and of course new Linux kernel releases. Facebook is working on "pystemd" as a Python (Cython) wrapper on top of SD-BUS.

Hackers could have manipulated the results of the upcoming election in Germany by using "trivial" attacks against a program used to count and transmit voting results, researchers warned on Thursday. From a report: White hat hackers from the Chaos Computer Club (CCC), a well-known hacking organization in Germany, claim to have found a series of serious vulnerabilities in PC-Wahl 10, software used by German authorities to count and transmit voting results. The researchers said their attacks show the software is in a "sad state" and that malicious hackers could have compromised it with "one click." "The amount of vulnerabilities and their severity exceeded our worst expectations," Linus Neumann, one of the researchers who conducted the study, said in a press release. The good news, however, is that the researchers believe it would have been hard for malicious hackers to get away with such attacks during the upcoming German election on September 24 without anyone noticing. "Technically, manipulation would be possible in several ways, but it is unlikely that manipulation would remain undetected," Thorsten Schroder, another researcher involved in the study, wrote in an op-ed for the magazine Der Spiegel.

"The security of online travel booking systems are stuck in the 1990s, according to security researchers," reports Computerworld. An anonymous reader quotes their article, which argues that the ancient systems are also "woefully insecure": This allows attackers to easily modify other people's reservations, cancel their flights and even use the refunds to book tickets for themselves, according a team of researchers who analyzed this online ecosystem... They presented their findings Tuesday at the 33rd Chaos Communications Congress in Hamburg. The three major Global Distribution Systems operators...store Passenger Name Records for hundreds of millions of travelers at any given time.

Any data added or modification made to a booking is stored in their systems and all that's required to access that information is typically a last name and a six-character booking code. There are multiple access points into these systems and this includes the websites operated by airlines and travel agencies, but also third-party websites like CheckMyTrip... The booking code itself is far from secret. It's printed on luggage tags that most people throw away after each flight -- even if their entire trip has not concluded yet -- and is also embedded in the QR codes printed on tickets that an alarmingly large number of travellers photograph and post on social media websites, the researchers said.

Long-time Slashdot reader JRiddell writes: A unique coming together of open source communities is happening in Berlin over the next week. QtCon brings together KDE, Qt, VLC and FSF-E to discuss free software, open development, community management and proprietary coding. Live streams of many of the talks are available now. The opening keynote spoke of open data and collaborative coding freeing accessibility information. 13 tracks of talks cover Community, Web, Best practices, Automotive, Mobile and Embedded, Let's talk business, Tooling, QtQuick, Multithreading, OpenGL and 3D.

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!

You asked, he answered!

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

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

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

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

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

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

Flying Cars
by WorBlux

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

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

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

How can we get PERL into the browser?
by Proudrooster

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

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

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

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

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

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

Why isn't PERL more windows friendly
by goombah99

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

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

Thoughts?

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

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

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

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

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

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

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

Perl in the embedded world
by mykepredko

HI Larry

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

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

Thanx!

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

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

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

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

Language Design
by columbus

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

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

LW: Everything.

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

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

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

Intellectual Property
by ytene

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

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

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

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

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

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

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

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

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

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

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

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

By the way, did you know Perligata and Babylscript?

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

Python . . . ?
by PolygamousRanchKid

What do you think about Python . . . ?

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

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

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

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

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

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

Perl and PHP
by hcs_$reboot

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

Reversely, which Perl features PHP should have taken?

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

P.T. Barnum would love it...

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

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

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

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

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

Esteemed Individuals
by JohnDeHope3

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

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

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

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

Patch and git
by waveclaw

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

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

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

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

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

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

Project governance
by njahnke

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

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

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

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

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

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

Why perl?
by Anonymous Coward

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

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

Achieving Escape Velocity From Perl 5's Gravity
by Baldrson

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

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

LW: The strategy is anti-gravity.

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

Double Question
by shaitand

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

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

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

Help me promote Perl 6
by Anonymous Coward

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

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

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

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

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

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

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

How to think in Perl 6
by mattr

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

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

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

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

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

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

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

So you try this snippet, and find it prints:

1405006117752879898543142606244511569936384000000000

which you immediately recognize as 42 factorial. :-)

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

Here's another example. Suppose you see:

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

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

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

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

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

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

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

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

Rational behind the major syntax changes in 6?
by colin_faber

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

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

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

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

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

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

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

to

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

In what scenario is Perl 6 most ideal?
by orlanz

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

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

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

Double Question
by shaitand

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

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

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

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

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

Hi Larry,

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

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

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

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

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

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

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

Question
by mlwmohawk

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

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

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

what do you think about the Perl guy?
by alloB

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

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

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

"Well then, don't do that."

Who's using Perl?
by quentindemetz

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

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

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

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

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

BANG!

An anonymous reader tips news that the Chaos Computer Club's website was inaccessible for many internet users in the UK after being blocked by the filter set up to block porn sites. Additionally, Vodafone users are unable to access the ticket site to this year's Chaos Commuication Conference. In a post on its website, the CCC said, "Internet filters simply do not work, but leaving technical limitation aside, the CCC's example shows that unsolicited overblocking, meaning wrongly classified websites, is a common phenomenon in large censorship infrastructures. However, it may very well be that the CCC is considered 'extremist' judged by British standards of freedom of speech." CCC spokesperson Dirk Engling added, "We see this as proof that censorship infrastructure – no matter for which reasons it was set up, and no matter which country you are in – will always be abused for political reasons."

An anonymous reader writes "A presentation at the Chaos Communication Congress explains how X11 Server security with being 'worse than it looks.' The presenter found more than 120 bugs in a few months of security research and is not close to being done in his work. Upstream X.Org developers have begun to call most of his claims valid. The presentation by Ilja van Sprunde is available for streaming."

An anonymous reader writes "A presentation at the Chaos Communication Congress explains how X11 Server security with being 'worse than it looks.' The presenter found more than 120 bugs in a few months of security research and is not close to being done in his work. Upstream X.Org developers have begun to call most of his claims valid. The presentation by Ilja van Sprunde is available for streaming."

hypnosec writes with word that the Chaos Computer Club claims to have "managed to break Apple's TouchID using everyday material and methods available on the web. Explaining their method on their website, the CCC hackers have claimed that all they did was photograph a fingerprint from a glass surface, ramped up the resolution of the photographed fingerprint, inverted and printed it using thick toner settings, smeared pink latex milk or white woodglue onto the pattern, lifted the latex sheet, moistened it a little and then placed it on the iPhone 5S's fingerprint sensor to unlock the phone." Update: 09/22 21:32 GMT by T :Reader mask.of.sanity adds a link to a video of the hack.

Weezul writes "The Ada Initiative's Valerie Aurora got Violet Blue's Hackers As A High-Risk Population (29c3 abstract) talk on harm reduction methodology pulled from the Security BSides meeting in San Francisco by claiming it contained rape triggers [ed note: you might not want to visit the main page of the weblog as it contains a few pictures that might be considered NSFW in more conservative places]. It's frankly asinine to object to work around hacker ethics as 'off topic' at such broad hacker conference. Is Appelbaum's 29c3 keynote 'off topic' for asking hackers to work for the 'good guys' rather than military, police, their contractors, Facebook, etc.? Yes, obviously harm reduction is a psychological hack that need not involve a computer, but this holds for 'social engineering' as well. It's simply that hacking isn't nearly as specialized or inaccessible as say theoretical physics. Worse, there is no shortage of terrible technology laws like the CFAA, DMCA, etc. that exist partially because early hackers failed to communicate an ethics that seemed coherent and reasoned to outsiders." The Ada Initiative responds that such talks do more harm than good. It could also be argued that "not working for the bad guys" type talks aren't off-topic, since the hacker community has traditionally cared about things like information freedom.

First time accepted submitter jehan60188 writes with this excerpt from an article from Hack a Day: "The 28th Annual Chaos Communication Congress just wrapped things up on December 31st and they've already published recordings of all the talks at the event. These talks were live-streamed, but if you didn't find time in your schedule to see all that you wanted, you'll be happy to find your way to the YouTube collection of the event. The topics span a surprising range. We were surprised to see a panel discussion on depression and suicide among geeks ... which joins another panel called Queer Geeks, to address some social issues rather than just hardcore security tech. But there's plenty of that as well with topics on cryptography, security within web applications, and also a segment on electronic currencies like Bitcoins.'" The CCC wiki has a list of mirrors with downloads in multiple formats (including WebM).

First time accepted submitter aeturnus writes "A new attack on the GSM mobile communications protocol has been demonstrated by Karsten Nohl and Luca Melette of Security Research Labs, based off their previously published attacks around vulnerabilities in the GSM A5/1 encryption protocol. This new attack, which Nohl indicates already in use by criminals, allows an attacker to simulate a GSM mobile and use it to make calls and send text messages. Nohl also discussed protective measures users should take against these attacks, and others in use by intelligence communities around the world." This was just one of many presentations at the 28th Chaos Communications Congress.

First time accepted submitter lennier1 writes "The German hacker group CCC (Chaos Computer Club) has analyzed a piece of malware the German government uses in criminal investigations to spy on a suspect's computer. I'm sure we're all surprised that it's opening security holes for third parties, and violates a related court verdict (and several laws in general)."

hypnosec writes "A German technology researcher on Wednesday showed global mobile makers and technology firms how General Packet Radio Service can easily be tapped, intercepted, and decrypted with an average mobile phone and a few applications. According to the New York Times, Karsten Nohl, a computer engineer and mobile security researcher, demonstrated to fellow researchers gathered to attend Chaos Communication Camp, a Berlin-based hackers event, how to intercept the voice or data messages sent between mobile devices over GPRS easily, owing to weak protection provided by mobile network carriers for data information. Nohl, in collaboration with his colleague Luca Melette, tapped the information within a radius of five kilometers using a seven-year-old inexpensive mobile phone from Motorola." Computerworld also has an informative, link-laden account. If you are attending this year's CCC (only every four years, sadly), feel free to drop a line (with the submissions form) about cool projects you encounter there.

ChrisPaget writes "I'm somewhat of an authority on GSM security, having given presentations on it at Shmoocon (M4V) and CCC (I'm also scheduled to talk about GSM at this year's Defcon). This is my take on the iPad ICCID disclosure — the short version is that (thanks to a bad decision by the US cell companies, not just AT&T) ICCIDs can be trivially converted to IMSIs, and the disclosure of IMSIs leads to some very severe consequences, such as name and phone number disclosure, global tower-level tracking, and making live interception a whole lot easier. My recommendation? AT&T has 114,000 SIM cards to replace and some nasty architectural problems to fix." Reader tsamsoniw adds that AT&T has criticized the security group responsible for pointing out the flaw, while the group claims they did it 'as a service to our nation.'

I Don't Believe in Imaginary Property writes "Professor Johannes Skaar's Quantum Hacking group at NTNU have found a new way to break quantum encryption. Even though quantum encryption is theoretically perfect, real hardware isn't, and they exploit these flaws. Their technique relies on a particular way of blinding the single photon detectors so that they're able to perform an intercept-resend attack and get a copy of the secret key without giving away the fact that someone is listening. This attack is not merely theoretical, either. They have built an eavesdropping device and successfully attacked their own quantum encryption hardware. More details can be found in their conference presentation."

t3rmin4t0r writes "Just when you were breathing easy about Kaminsky, DNS and the word hijacking, by repeating the word SSL in your head, the hackers at CCC were busy at work making a hash of SSL certificate security. Here's the scoop on how they set up their own rogue CA, by (from what I can figure) reversing the hash and engineering a collision up in MD5 space. Until now, MD5 collisions have been ignored because nobody would put in that much effort to create a useful dummy file, but a CA certificate for phishing seems juicy enough to be fodder for the botnets now."

Sub Zero 992 writes "Heise Security (article in German) is reporting that at this year's Chaos Communications Congress (25C3) researchers in Europe's dedected.org group have published an article (PDF) showing, using a PC-Card costing only EUR 23, how to eavesdrop on DECT transmissions. There are hundreds of millions of terminals, ranging from telephones, to electronic payment terminals, to door openers, using the DECT standard." So far, the Heise article's German only, but I suspect will show up soon in English translation. Update: 12/30 21:27 GMT by T : Reader Juha-Matti Laurio writes with the story in English. Thanks!

mister_woods writes "It's not just governments that lose private data. Germany's Chaos Computer Club (CCC) reports that market research firm TNS Infratest/Emnid has lost 41,000 private data records of their survey participants. By simply changing the customer ID number in the browser's address bar access could be gained to comprehensive survey results, including names, addresses, dates of birth, email addresses, phone numbers and much more sensitive data. A CCC spokesman described this as 'unprofessional, grossly negligent and above all deeply worrying' and sees this loss as a vindication for its calls for strict regulations for public and private sector data collectors."

A number of readers let us know about the Chaos Computer Club's latest caper: they published the fingerprint of German Secretary of the Interior Wolfgang Schäuble (link is to a Google translation of the German original). The club has been active in opposition to Germany's increasing push to use biometrics in, for example, e-passports. Someone friendly to the club's aims captured Schäuble's fingerprint from a glass he drank from at a panel discussion. The club published 4,000 copies of their magazine Die Datenschleuder including a plastic foil reproducing the minister's fingerprint — ready to glue to someone else's finger to provide a false biometric reading. The CCC has a page on their site detailing how to make such a fake fingerprint. The article says a ministry spokesman alluded to possible legal action against the club.

A number of readers let us know about the Chaos Computer Club's latest caper: they published the fingerprint of German Secretary of the Interior Wolfgang Schäuble (link is to a Google translation of the German original). The club has been active in opposition to Germany's increasing push to use biometrics in, for example, e-passports. Someone friendly to the club's aims captured Schäuble's fingerprint from a glass he drank from at a panel discussion. The club published 4,000 copies of their magazine Die Datenschleuder including a plastic foil reproducing the minister's fingerprint — ready to glue to someone else's finger to provide a false biometric reading. The CCC has a page on their site detailing how to make such a fake fingerprint. The article says a ministry spokesman alluded to possible legal action against the club.

jonkman sean writes "University researchers conducted research into how they can gain wireless access to pacemakers, hacking them. They will be presenting their findings at the "Attacks" session of the 2008 IEEE Symposium on Security and Privacy. Their previous work (PDF) noted that over 250,000 implantable cardiac defibrillators are installed in patients each year. This subject was first raised along with similar issues as a credible security risk in Gadi Evron's CCC Camp 2007 lecture "hacking the bionic man"."

SkiifGeek writes "With little fanfare, section 202c of the German computer crime laws came into effect over the weekend. Worryingly for Security professionals, the laws make the mere possession of (creates, obtains or provides access to, sells, yields, distributes or otherwise allows access to) many useful tools illegal. A similar law was proposed for the UK, however it was modified prior to passing through parliament due to the outcry from the industry. Phenoelit, KisMAC, the CCC, and the Month of PHP Bugs are just some of the relatively high profile projects and groups to have already taken measures to remove or modify content under this law."

87C751 writes "Security lists are abuzz about a presentation from the 23C3 conference, which details a fundamental design flaw in Javascript. The technique, called Prototype Hijacking, allows an attacker to redefine any feature of Javascript. The paper is called 'Subverting AJAX' (pdf), and outlines a possible Web Worm that lives in the very fabric of Web 2.0 and could kill the Web as we know it."

87C751 writes "Security lists are abuzz about a presentation from the 23C3 conference, which details a fundamental design flaw in Javascript. The technique, called Prototype Hijacking, allows an attacker to redefine any feature of Javascript. The paper is called 'Subverting AJAX' (pdf), and outlines a possible Web Worm that lives in the very fabric of Web 2.0 and could kill the Web as we know it."

87C751 writes "Security lists are abuzz about a presentation from the 23C3 conference, which details a fundamental design flaw in Javascript. The technique, called Prototype Hijacking, allows an attacker to redefine any feature of Javascript. The paper is called 'Subverting AJAX' (pdf), and outlines a possible Web Worm that lives in the very fabric of Web 2.0 and could kill the Web as we know it."

Autoversicherung writes "Germany has an activated by phone bike rental system across all major cities. At 6 cent a minute quite pricey, germanys famous Chaos Computer Club thought a free ride every now and then couldnt hurt. Optimizing the original system in the process, modifying the blink code to be easier found and changing the logo. About 10% of Berlins bikes are patched already. A detailed description of how they did it, and how the system works."

Autoversicherung writes "Germany has an activated by phone bike rental system across all major cities. At 6 cent a minute quite pricey, germanys famous Chaos Computer Club thought a free ride every now and then couldnt hurt. Optimizing the original system in the process, modifying the blink code to be easier found and changing the logo. About 10% of Berlins bikes are patched already. A detailed description of how they did it, and how the system works."

A8 writes "The biggest European Hacker Conference 21C3 from 27th to 29th Dec., organised by the Chaos Computer Club (CCC), just released version 0.9 of the Fahrplan (programme schedule)."

A8 writes "The biggest European Hacker Conference 21C3 from 27th to 29th Dec., organised by the Chaos Computer Club (CCC), just released version 0.9 of the Fahrplan (programme schedule)."

A8 writes "The biggest European Hacker Conference 21C3 from 27th to 29th Dec., organised by the Chaos Computer Club (CCC), just released version 0.9 of the Fahrplan (programme schedule)."

atoth writes "The German CCC issued a Call For Papers for its upcoming congress, which will take place from December 27th through 29th 2004 in Berlin, Germany. The motto for this year, 'The Usual Suspects', "integrates lectures, workshops and discussions about current scientific and technological developments, new aspects of engineering research and sociological insights gathered from deployment of modern technology.""

atoth writes "The German CCC issued a Call For Papers for its upcoming congress, which will take place from December 27th through 29th 2004 in Berlin, Germany. The motto for this year, 'The Usual Suspects', "integrates lectures, workshops and discussions about current scientific and technological developments, new aspects of engineering research and sociological insights gathered from deployment of modern technology.""

atoth writes "The German CCC issued a Call For Papers for its upcoming congress, which will take place from December 27th through 29th 2004 in Berlin, Germany. The motto for this year, 'The Usual Suspects', "integrates lectures, workshops and discussions about current scientific and technological developments, new aspects of engineering research and sociological insights gathered from deployment of modern technology.""

An anonymous reader writes "On the occasion of this year's Chaos Communication Congress some hackers of the German CCC have set up another Blinkenlights installation in Berlin (they use the glass facade of a house as a giant computer screen). It is on the same house as from September 2001 till February 2002 but with similar capabilities to the installation in Paris in September/October 2002. Heise has a story about this (German, here's the Google translation), but actually there's better information on the project website itself."

An anonymous reader writes "On the occasion of this year's Chaos Communication Congress some hackers of the German CCC have set up another Blinkenlights installation in Berlin (they use the glass facade of a house as a giant computer screen). It is on the same house as from September 2001 till February 2002 but with similar capabilities to the installation in Paris in September/October 2002. Heise has a story about this (German, here's the Google translation), but actually there's better information on the project website itself."

cavac writes "From 07.-10. August, we from the Chaos Computer Club have another Chaos Communication Camp. Please be sure to visit us at the BlinkenArea, a place where we show the newest projects and technology derived of Blinkenlights, the famous installation on Berlin's 'House of the Teacher'."

cavac writes "From 07.-10. August, we from the Chaos Computer Club have another Chaos Communication Camp. Please be sure to visit us at the BlinkenArea, a place where we show the newest projects and technology derived of Blinkenlights, the famous installation on Berlin's 'House of the Teacher'."

cavac writes "From 07.-10. August, we from the Chaos Computer Club have another Chaos Communication Camp. Please be sure to visit us at the BlinkenArea, a place where we show the newest projects and technology derived of Blinkenlights, the famous installation on Berlin's 'House of the Teacher'."

Aldert Hazenberg sent in this note about a Call for Papers: "Papers are being solicited for the second Camp of the Chaos Computer Club e.V., Germany, to be held near Berlin, Germany, on 7/8/9/10th August 2003. The Camp is intended to promote the interchange of technical, social and political ideas and concepts to find ways to make this world a little bit more friendly to intelligent beings."

cavac writes "At the 19th Chaos Communications Congress in Berlin/Germany developers showed their newest developments for the closed-down Blinkenlights-Project. One of the projects was the Blinkenlights Fileserver Project. Members of this team developed a protocol and some tools similar to ftp, which you can use to share Blinkenlights-Movies. Today, a first Beta-Version was released. You might want to check it out. (It also includes the famous Telnet-Blinkenlights-Player). We are still searching people willing to help us developing this software even more or to work with us on "Phase II": Implementing Soft- and Hardware for a Hardware-Based Blinkenlights Player. This will most likely based on one of Zilog's new Development Kits - the "Z8 Encore!"."

JCallery writes "CNN is reporting on the plan drawn up by ICANN's restructuring committee after ICANN decided to abandon direct elections." We had a earlier story about the restructuring plan with some notes from one of the board members who attended. ICANN's plan is online and a must-read for anyone interested in internet governance issues. Below, I have some notes about why this restructuring would be terrible idea for regular internet users.

If you've followed the history of ICANN at all, you know that it was originally set up to have substantial representation from the general public (known as At-Large representatives) - 9 of 18 board members. The original unelected board immediately set about undermining that, only electing 5 members and keeping on four "board-squatters" from the original unelected bunch.

The elections of the five At-Large members had two flaws from the point of view of ICANN's unelected board:

1. There were assorted technical issues with the voting process, due apparently to incompetence from the contractor who handled it.
2. Two of the five new board members who were elected did not represent the same corporate interests as the rest of the board.

Of these two flaws, the second was by far the more severe. The board risked losing control of ICANN to people who might run it for the public good rather than for the good of the corporations represented on the board. They started backing away from having any sort of elected representation whatsoever. In February 2002 ICANN President Lynn floated a reform proposal which would eliminate the At-Large representation - or rather, it would keep something called "At-Large", that would no longer be elected by the general public but instead appointed by the Board itself. Instead of the general public picking new ICANN Board members, the ICANN Board would pick new ICANN Board members. This was followed by a vote which confirmed ICANN's commitment to eliminating elected representation.

Now the reform proposal is out. There would be two classes of board members:

• approximately eight ex-officio members (members holding the board seat due to some other title or position they hold)
• approximately five to eleven members picked by a Nominating Committee (the Committee to be chosen by the current Board) and perhaps confirmed by the Board

It is important to note how thoroughly captured this process is. Many of the ex-officio seats accrue from positions that are selected by the ICANN Board. So the ICANN Board picks someone to be chief dogwalker, and the chief dogwalker gets an automatic position on ICANN's Board.

The seats selected by the Nominating Committee are also extremely vulnerable to capture. Let me use a real-life example of how nominating committees work to show what I mean: my credit union.

My credit union has a board structure very similar to the one proposed for ICANN: several ex-officio members, and a number of seats elected by the general populace (everyone who has an account at the credit union). This structure is actually more flexible than that proposed for ICANN, since ICANN does not plan any direct elections at all. However, the credit union membership picks from among candidates selected by a Nominating Committee. Every year or two, I get a ballot in the mail. I can choose from among all the candidates selected by the Nominating Committee, and I can check boxes for the candidates that I prefer, up to the number of open seats available on the Board.

I never return these ballots. Why, you might ask? Because the number of candidates is usually identical to the number of open seats. Three empty seats, three candidates to choose from. Six empty seats, six candidates to choose from. I think one year they might have had more candidates than open seats, but it was an aberration.

This system apparently works well for credit unions: would you believe that they pay interest on my checking account? What it does guarantee is that all future Board members will represent the same biases that are present in the Board at the instant the system was instituted. In my credit union's case, this guarantees "fiscal responsibility" or "fiscal conservatism".

For ICANN, what it would do is institutionalize the biases currently present. Whatever biases are there right now, will be there forever, as the system becomes a self-reinforcing feedback loop with no external controls.

The Board's current biases are toward:

• expanding ICANN's mission from a purely technical body to one that is willing to govern the Internet - taking on assorted social/political issues as it sees fit
• running ICANN for private profit rather than public benefit

Neither of these two traits needs reinforcing. Karl Auerbach, one of ICANN's At-Large directors, has his thoughts on a possible ICANN structure.

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 ..."

karm13 writes "The Chaos Computer Club has made a huge display using the 8 top floors of a house in Berlin with 18 windows each as a present to themselves and Berlin for their 20th birthday. You can submit animations on the Blinkenlights project page, and even play pong with a mobile phone!"

Rolo Tomasi writes: "Germany's first online service, BTX (Bildschirmtext) is shutting down. BTX had a history of major security flaws, which made the Chaos Computer Club famous." Non-speakers might want to try a translation.

Leto writes: "Eight years ago, at HEU'93 we stressed the importance of Internet for the masses. Four years ago, at HIP'97, we pointed out the emerging security problems. This year, it is time to sound the alarms about decaying privacy and emerging security problems. What do you get when you gather the Dutch Hacktic veterans, The German CCC, The Bay Area Cypherpunks, The 2600 people, The EFF and the cryptography and security experts from all over the world? A Hackers At Large 2001." (More announcement follows.)

"HAL2001 is a camping event on campus of the University of Twente in the Netherlands. Connected with 15km UTP, 2km fiber, 50 wireless base stations and a 1GB uplink, we're providing 3000 people with probably the most stable hostile network ever.

"Talk to the experts on IPsec, IPv6, Multicast, and be part of the largest public deployment of IPsec and DNSSEC. There will be talks and workshops about GSM security, AI, Lawful and unlawful interception, digital safes, bank security, copy protection, biometrics, IP allocation, intellectual property and anonymity and even an RSI workshop.

"If you can truly celebrate the Internet and embrace new technologies, without forgetting your responsibility to tell others that new technologies come with new risks to the individual and to society as a whole, then this is the place to be this summer."

gleam writes "The guy who cracked the secure Linux box has posted how he did it. It's a rather interesting read, and it does use a crontab exploit that is present in all versions of RH. " Much more detail then the original story had.

A number of people have written in with the news that Cryptonym has found an apparent backdoor for the NSA (called NSAKEY) in all current versions of Windows. However, you can open this backdoor yourself and install your own strong cryto module in place of the built-in one. More details are also online, but to be quite frank, we aren't quite sure on this one-so, if you're more qualified comment, please do so below.Update: 09/03 11:19 by H :Thanks to Jens Hillman for more information from the German Chaos Computer Club. Der Webpage ist auf Deutsch-Babelfish it.

Dirk Wendt writes "the chaos computer club is organizing a three-day hacking open air event for nerds, hackers and phreaks from all over the world. this thing is pretty much in the tradition of HEU and HIP, if you remember those. the camp will take place from august 6th to august 8th, 1999. on a field near berlin, germany. we will provide the infrastructure for a complete and satisfying hacking experience: electricity and ethernet for every tent and on-site facilities for eating and drinking. there will be tents to discuss and hack and a lake along the field invites you to relax. there will be a true high-speed connection to the internet for the whole campnet network. you can bring your computer equipment to the camp site and hook it up to the campnet network and the internet. this is going to be fun! " For more information, check out the camp site.