This is maybe the most frequently asked question. Probably because people find that their favourite programming language is not enjoying very much problems with need of regexp, IOs, text processing, and so on.
The answer is: this goes beyond the scope of Pleac. There is already much work to do if we want to write a Pleac implementation in, say, the 20 most used programming languages on earth. When we're finished with that objective, we can think of Pleac#2, with even more problems to solve. In the meantime, if you feel that your favourite language would demonstrate its strength better by solving complex parsing problems, compiling problems, AI problems, etc, you're free to begin another project by your own, or to start a Pleac#2.
Ok, a variation of question 1.
Actually, the choice of problems do suggest a scripting language. But you encounter these kinds of problems in every language. For example, how do you access environment variables? how do you access program arguments? how do you get the list of files in a directory? This is still interesting and useful questions for every languages.
Yes, one can think of Pleac as a project to show syntax differences and how to use the default library. For some languages, we can afford using an external library that brings a lot of missing features, for example the pcre regexp library in OCaml.
I have to admit it's hard to satisfy all browsers on all platforms. Currently, if I choose a smaller proportional font for the code, it is unreadable because too small using Netscape/Linux. I don't have a viable solution for the moment (you can mail me one if you have one).
For the moment, the project is too young for that kind of questions. Also, keep in mind that the code is mostly written by non-experts, so solutions probably have bugs and are not optimal, or not elegant, or not efficient, etc. I mean, we try to do the best we can, of course.
One thing will always remain: this project will stay under the Gnu Free Documentation License.
I think it is important that we try as much as possible to keep a consistent style across the implementations, and across the solutions inside an implementation. In other words, we should try to keep an homogeneous level of complexity, of obfuscation, of detailing, of commenting, and of "tutorialing".
I think one will agree that we should stay close to the spirit of the Perl Cookbook. It's obvious that the Perl Cookbook doesn't aim at Experts, nor at Real-Beginners. Its target is people interested in the Perl language, curious to know what is the best way to solve a "real-world" problem. We should stick to this spirit: we should not pollute the code with too much commenting and documentation (this goes to a general course in the language), and we should not optimize in the "obfuscation" way.
That is, as in translating human language, capture the intent and style of a solution. That is, don't solve a completely different problem, and don't solve the problems in a completely different way, but don't do a word for word translation.
Also, it is -very- important that we solve the same problems as in the Cookbook. Under the term "problem" I mean the title and explanation of the problem in each section, not necessarily each Perl code snippet, because some of them may apply only to Perl.
For example, opening a file ignoring potential errors would be the following in Perl:
open F, $file ...
But it's harder to achieve that in exception based languages:
try
f = open($file)
...
except IOError:
pass
So unless the example's meaning is really to show how to not care about errors, in that situation we simply do it with slightly different semantics (possibly adding a small comment on it), using only:
f = open($file) ...
To my knowledge, the whole Perl Cookbook is not free material, nor is it available "free of charge". Only the source code is available (see main Pleac web page). And if you're not an expert in the Perl language, it will probably be a bit hard to fully understand the profound meaning of each problem...
Well, if you're a student, you may borrow (or make them buy) the book from your University Library.
Else, you may buy it... why not? :-) It's an excellent book, and if you need only possess one book talking about the Perl language (which indeed is very important among the free software community) this is probably the one.
Great!
But, please double-check that this compiler/library is released under a free (as explained by GNU, not free of charge) license, as we won't accept code only usable under a non-free OS/compiling environment.
Then please refer to the second bullet of the "Contribute" section of the homepage.
Actually the project began as an idea to translate the code into other languages, for the sake of showing differences between languages, learning a bit more on interesting languages, etc.
When I decided that we could really begin an official project, I contacted O'Reilly (this is indicated on main web of Pleac) in order to not infringe their rights as a publisher. Because we were not so interested in the "text" part (we didn't want to publish a book or a tutorial; we wanted to work on a pure "programming" project; I believe that the Perl Cookbook's text is 90% of what's interesting to say in each chapter), I asked O'Reilly the permission to "quote" the Perl Cookbook in the project name and description, and to reuse verbatim the Chapters and Sub-Chapters titles.
Now, if we want to write some text for the other languages' implementations, I think that:
So the project infrastructure is not currently ready for such a thing. Obviously, if you look at existing stuff, you will see a bunch of comments that are here to clearly state the difference between the chosen language and what was used in the Perl Cookbook... when necessary. I believe that if the comments are as long as (or more than) the code, it's too much (as explained upper in this FAQ).