1. Why are you only using Cookbook stuff? I'd like to solve also
<...> problem, that would be more interesting!

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.

2. The choice of problems gives not really useful solutions. This
project seems suited only for scripting languages!

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.

3. Ok, but then, these questions are mostly solved by using the
proper library.

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.

4. The code is too large on my screen.

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

5. This would be nice if printed in a book!

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.

6. Which code style should I adopt?

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&quot 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)
...

7. What are the steps to become a Pleac contributor?

subscribe on the ML,
review some existing code, this FAQ, and decide if the style and spirit
of the project fit your personal views

begin writing some code (starting from the relevant link labelled
"raw source" on main page); post it on the ML; once reviewed,
the code is integrated into CVS and published on the Pleac website

if you wish to continue contributing and your style doesn't need any
review by one of the CVS commiters, we'll grant you a CVS commit account
and you'll be able to destroy all around ;p

8. Where can I find the explanatory text that goes along the Perl Cookbook, in order to understand well each problem?

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.

9. I'd like to contribute to Pleac using this particular compiler/library

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.

10. Should I rewrite (some of) the explanatory text?

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:

the project completion will last 4 times the current

there will be low quality and low consistence across the
languages

it's more a tutorial/book project than a programming project

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