Front page | perl.bootstrap |
Postings from July 2000
Re: Why we're here
July 24, 2000 10:33
Re: Why we're here
Message ID: email@example.com
On Mon, Jul 24, 2000 at 05:32:55PM +0200, Jesús Quiroga wrote:
> At 15:57 24/07/00, you wrote:
> >Jesús Quiroga (lists.bootstrap):
> > >We are about to change the language, in fact :-) Why not introduce some
> > >changes to help the marketing strategy that Perl should have in order to
> > >grow?
> >Because Perl is about programmers. Programmers have been Perl's number
> >one priority. There's no number two priority. It's about working the way
> >programmers do. Programmers aren't always easy to work with, so why
> >should Perl be? The day Perl starts being about what sells is the day
> >Perl dies.
> You are completely right. In fact, we agree. Perl is for programmers.
> That's the number one priority. I program with Perl, so how could I
> disagree? I wouldn't want to use a watered-down Perl.
> Now, the only thing I meant is that nowadays many programmers program
> with other languages, having refrained themselves from using Perl for
> one reason or another. Being Perl the best language around, why not
> attract them to Perl? Yes, even tweaking bits of the language to
> entice them (without ever alienating any existing Perl programmers,
> of course, I know the rule).
I am sorry, but I don't believe in the myth "the best language around".
There is no best language.
For certain projects, there just might be a "best language", but that
will always be a little, domain specific, language. For general purpose
languages, like Perl, Python, Java, C, Ada, Eiffel, etc, it is the
people doing the project that will decide what the best language is.
For some people, Perl is a very good language to program in. For others,
it isn't. It all depends on the mindset of the programmer.
In a recent Usenet posting, I wrote:
++ Perl is written with the human thought process in mind, and less the
++ compiler or interpreter. It makes the compiler/interpreter bend over
++ to serve the programmer, and the programmer doesn't have to bend over
++ to satisfy the compiler. This however divides mankind in four groups.
++ 1) "I know Perl, and I love it".
++ 2) "I know Perl, and I hate it".
++ 3) "I think I know Perl (but I don't really), and I hate it".
++ 4) "I don't know Perl".
++ If your project has to be done by people from 1), than Perl is very
++ suited. If your project has to be done by people from 2), pick another
++ language. If the people in the project are in 4), you would have to
++ ask yourself whether it's worthwhile to advocate Perl and have people
++ learn Perl. After all, they might end up in group 2). And if your people
++ are in group 3), then it probably isn't worthwhile to spend the effort.
By turning Perl into something else, something "less complex", you will
lose the people from 1), the backbone of the Perl community. With lots of
PR work, you might attract new people, from the categories 2) and 3).
But, you will still drag the tainted name "Perl" with you. And since it's
a new language, aiming at different people, you're better off calling it
> They are programmers too. Therefore they are covered by the first
> priority. The problem is that they don't think/feel/see/know that they
> need Perl. I think it's worthwhile to rewrite Perl for them too,
> reconciling their needs/wants/preferences with ours.
No. They are *NOT* the first priority. The first priority is the
backbone of the Perl community, the current Perl programmers.
I don't think it's appropriate to decide for non-Perl programmers that
they are better off programming Perl. We don't like Sun telling us that
we're better of using Java either, do we?