I program for an embedded system with 64K of on-chip RAM and 256K of external RAM. There is less than 256MB of RAM shipped per 3 months of sales. There is also FLASH memory in our system but only a few megabytes.

The great thing about more RAM is that programming gets much easier. But many, many things are still possible with tiny amounts of it. At the lowest end of microcontrollers is the likes of the PIC10F200, which has just 375 bytes of program memory and 16 bytes of data memory. Real multi-tasking isn't possible at that level but a few orders of magnitude above it is often not just desirable to have real multi-tasking but necessary.

Apple must trade off the hardware cost vs. the development cost. For them each cent trimmed off the hardware cost is enough to hire a few more software developers to work-around the limitations imposed.

Jonathan Paton

I wrap as much of my code to 80 columns as possible but I may be doing the wrong thing.

The main problem is that 80 columns can be a fight between meaningful variable/function names and actually getting anything done on a line of code. Just changing a variable name can mean spending time getting everything back under the 80 column self-imposed limit. And that's a problem if you've done A=B+C and can't do much more to shorten the line without using +=. Rigid use of a small column limit may lead to less readable code.

The diff tool is another battle ground: shorter lines help when differencing files (e.g. 3 files side by side) but at the same time a shorter column limit often means more changed lines.

I think that the goal in programming is to write obviously correct code. Whatever achieves this is the right approach. Which is why programmers often can't agree on anything because there isn't one correct approach (except their own!).

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.