Yes, Perl is still relevant to a number of software developers and systems administrators.

It is an ideal language for software developers who want to use metaprogramming techniques (code generation; domain specific languages), text processing or data conversion, or automation of software development process. Perl 6 will have a full grammar engine (for parsing - like having YACC/BISON built in) which will make text processing even easier than before. The use of a scripting language for these tasks leaves the source code more accessible than compiled languages, which is an advantage to software developers who can adapt the code more readily than a compiled project.

Whether Perl 6 will be used much for primary software development I don't know. My day job is C programming for embedded systems where Perl is not suitable. Desktop programming is more likely to be in C++ or C# where the standard libraries are huge and the software development ecosystem is more developed.

The primary audience for new Perl, in my opinion, is expert software developers who need a powerful/succinct language to implement solutions to problems in the manner they think. Perl 6 therefore supports just about every programming paradigm known to mankind. What makes Perl great for software gurus is what makes it an awful language for programming newbies.

I will be learning Perl 6, not because I will use it much, but because I will discover new ways to think about problems. Oh, and it'll be fun.

Jonathan Paton

So all the binary data etc. that is required to build an application should be managed seperately? Our GUI code is generated by a third party tool which stores its information (e.g. fonts) as part of a binary database. This belongs with the source code because the code needs to be modified in step with it. Having the log message is very helpful as it would take hours to work out the changes made between two of these files, because diff isn't useful. The files are 15MB in size.

SVN may not be the best choice for binary data but at least it is possible to put binary data into it. I would rather endure SVN's slowness than have to manually manage binary files. I believe that revision control could be better supported by operating systems. Two copies of every file are managed by a SVN checkout - the base file and the working file. If the filesystem could store these together then the cost would be halved (if the working file referenced the base file until the working file needs to be changed). The SVN tools would then be able to work much faster because the need for file comparison would be less common.

Unless the revision control system's performance is dreadful I think that all files should be in revision control.

I would drop unimportant items from my inventory on the floor as I go from room to room. I would not assume that the maze layout made any sense whatsoever. And I would pay careful attention to any variances in the textual descriptions.

As for the punch-cards the sieve of Erastothenes method sounds like a great way to solve the problem. Do I get a hole-punch? A computer? Or the bits to make my own computer? Since those are the items YOU have could I not just write a short program on my RPN calculator instead?

Given that I'm only two and a half decades old either: (a) these screening questions aren't hard enough; or (b) I know more than the average for my age.

If I was interviewing I would want to know that the person understands version control. I would expect them to demonstrate that they could understand the user's needs (e.g. interface design). And I would want to know that they weren't hostile to development processes (e.g. code reviews).

One problem - it's non tactile. But with some further programming the system could be operated like a joystick.