Feel free to add your own, or fears you heard about!
If you don't have committer access, ask Autrijus for it, or just reply
to this message.
The current list of fears is:
: Frequently heard Perl 6 fears
:
: Fears end in exclamation marks for extra drama and silliness.
:
: Later, we can add responses below each listed fear. For now, I'm mostly
: collecting fears. Feel free to add responses, though.
:
:
: FEAR: Perl 6 has too many operators!
:
: FEAR: I will never be able to type Unicode ops!
:
: FEAR: Unicode ops cannot be read by me!
:
: FEAR: My Perl knowledge will be useless!
:
: FEAR: All my existing code will have to be rewritten!
:
: FEAR: Perl 6 is hard to learn!
:
: FEAR: Perl 6 will never be released!
:
: FEAR: A language or VM this powerful can never be fast!
:
: FEAR: Perl 6 is not Perl! Perl 6 does not look like Perl!
:
: FEAR: The new features won't be used by people!
:
: FEAR: Perl 6 will not be used as much as Perl 5 was!
:
: FEAR: Junctions will be abused!
:
: FEAR: The development process will implode into a giant ball of ego and
: misery!
:
: FEAR: Perl 6 will be too much like Haskell!
:
: FEAR: Perl 6 has too many features just for completeness, rather than
: utility!
:
: FEAR: Implementing unnecessary features will delay development!
:
: FEAR: Perl 6 makes golf (and obfuscation) hard and thus ruin culture!
:
: FEAR: Perl 6 is made for big programs, not for oneliners and short
: scripts!
These fears were collected on IRC.
Only if we know what people are afraid of, we can help people overcome
it and accept Perl 6 for the programmer friendly language that it is.
And perhaps some people are right. In that case, we can use this list to
do something about it before it's too late.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
FEAR: I will need a lobotomy before I can make sense of Perl 6!
--
Stop the infinite loop, I want to get off! http://surreal.istic.org/
Paraphernalia/Never hides your broken bones,/ And I don't know why you'd
want to try:/ It's plain to see you're on your own. -- Paul Simon
The documentation that can be written is not the true documentation.
On Oct 24, 2005, at 07:20 , Juerd wrote:
> I've created pugs/docs/quickref/fears, a list of Perl 6 fears.
>
> Feel free to add your own, or fears you heard about!
> [snip]
> : FEAR: Perl 6 has too many operators!
FEAR: Perl 6 has so many operators that it runs out of Unicode
character repertoire :)
# Time to learn (Hanzi|Kanji) for that?
> : FEAR: I will never be able to type Unicode ops!
FEAR: I will need to hack an input method just to type those ops!
> : FEAR: Unicode ops cannot be read by me!
FEAR: Unicode ops cannot be read by the compiler!
> : FEAR: Perl 6 will be too much like Haskell!
Perl 6 will be too much like Ruby!
# IMHO it already is and I love it!
> : FEAR: Perl 6 is made for big programs, not for oneliners and short
> : scripts!
FEAR: Unicode ops of Perl 6 ought to make short scripts easier but
how the heck can I type in those on shell?
Dan the Perl 6 User -- Whatever that Means
This falls under "hard to learn".
Fear: Perl 6 will not attract enough interested developers and
companies to gain momentum. People will continue to be excited about
digital watches and PHP 5.
Regards,
Christian
--
cr...@web42.com - http://christian.web42.com - http://www.web42.com/crenz/
"If God were a Kantian, who would not have us till we came to Him from
the purest and best motives, who could be saved?"
-- C.S. Lewis, The Problem of Pain
That's already expressed in:
FEAR: Perl 6 will not be used as much as Perl 5 was!
Also, I'd like to keep the fear descriptions short :)
FEAR: Perl6 internals will be just as inaccessable as p5
FEAR: The Perl6 process is driving away too many good developers
FEAR: Perl6 will not be as portable as p5
FEAR: Perl6 will not be able to fix the stigma of "just a scripting
language" or "line noise"
FEAR: Perl6 is un-necessary and the time, money, and resources is impacting
p5.
FEAR: There is too much misinformation surrounding Perl6 for people to feel
comfortable.
This last fear is likely the reason why you are collecting this list. I
think the biggest problem is accessability and visibility for the casual
observer. Unless you are devoted to the list and the IRC channels and the
conferences your perception of what "is" and "isn't" Perl6 is out of date.
We don't have a single source where people can go for relatively "up to the
minute" facts concerning the project.
Juerd
Cheers,
Joshua Gatcomb
a.k.a. Limbic~Region
I think Autrijus has the right idea that Perl 5 CPAN modules
should just work in Perl 6 without change.
Just as Perl 6 is the community rewrite of Perl 5, moving
a module from CPAN to 6PAN should not be done as a hasty
make sure everything is moved over kind of event, but rather
should be done as a way of choosing the best features out of
the various Perl 5 modules on CPAN and peoples merging in the
experience people have gained from using them as well as the
experience people gain from *using* Perl 6.
So, that is both good news and bad news - the good news is that
CPAN will be just as useful for Perl 6 right from the start;
the bad news is that the community rewrite of CPAN won't
happen overnight but could take as long for CPAN as it did
for Perl 6. (In fact, depending upon how you measure it, it
will take longer because some modules will never be rewritten,
but of course, those will be the modules that no-one feels a
sufficiently pressing need to rewrite; while for other modules,
the Perl 5 CPAN version will fit in well enough that there
is no urgency to convert it, even though it is being used,
until a few years done the road a rewrite allows additional
Perl 6/6PAN capabilities to be merged in.)
--
"Perl 5 was my rewrite of Perl. I want Perl 6 to be the community's rewrite
of Perl and of the community." - Larry Wall
I think a lot of people that would contribute, myself included, are put off
by the fact that it is nearly impossible to get a clear decision rendered on
the list. Threads spin off tangents and typically end not in an answer, but
in a loss of energy in trying to get back to the original question.
My contribution to Perl6 has primarily been in advocation. I have
contributed tests and code examples to Pugs as well as asked questions on
the list. I would do more if getting answers was easier.
Two full years ago I purchased and read "Perl 6 Essentials". That lead me to this list which I have enjoyed but never felt competent to contribute much.
Pretty much all of what I leaned in Essentials has been mucked with, or so it seems.
I fear that Parrot will not come into widespread use until perl 6 is released.
As a rocket scientist, who started before the first FORTRAN compiler was released, I like assembly language and the portability of the Parrot interpreter appeals to me. But perl magic cookies in an assembler? Will it ever fit into a 68HC11? Can it attract the attention of hardware manufacturers?
--
--> Halloween == Oct 31 == Dec 25 == Christmas <--
I see modules being ported for a few reasons:
1) The module needs to be written in native P6 so that what was in XS
now targets Parrot or the P6 grammars
2) Features are either easier or just plain old possible with P6.
3) The class is better written as a role.
For example, having CGI written in Parrot ASM would be very nice.
Having CGI written so that it's not as crufty would also be really
nice. DBI being native P6 would be good. DBD's being roles that a DBI
object does would be really nice.
Rob
These are at the top of my list. Sooner or later big Perl advocates
(like myself) are going to look for other languages because the future
is too uncertain and unstable.
Also, in terms of module rewriting: This is a massive effort. I don't
know if anybody's looked at the internals of stuff like Class::DBI and
its derivatives, but it's huge.
The fact that there's not alot of active p5p'ers on this list should
alarm people more.
-Nate
I don't know about the other Perl 6 lists, are they as p5porterless?
It does not alarm me that they are not *here*, this being a list where
we mostly discuss the language. Perl 5's language is set in stone. It is
inflexible, almost any conceivable change will be backwards incompatible
in some way. P5p deals with implementation, and that too is mostly set
in stone. Perl 5 has no detailed spec, so the implementation implicitly
is the spec, which means that you can't just change something.
We're very lucky to have some people here who care about both
implementation and language. They form the bridge between the two. I
personally care about the language, but not much about the
implementation, as long as it gets implemented.
What does alarm me is the number of people who are very familiar with
Perl 5's language and guts, who hate Perl 6 and use every opportunity to
whine about it. We cannot and probably should not do anything about
this, but it is very alarming. It means that the Perl 6 community is not
the same as the Perl 5 community is now.
My take on that is that it is because Perl 6 is not a new version of
Perl 5. I still think "Perl" is a misleading name, and mostly hurts the
image of the language that is created here.
I have. Module rewriting should be look at in terms of implementing
something completely new to fit the current spec, at least in the
beginning. Modules like CDBI are good because they have a lot of
tests. So, you run the tests in P5 and have them access the P6
classes. Add new tests to test new P6-only features, like roles, and
you're good to go. You don't need to read the internals to port the
module.
Plus, rewriting is going to happen over the space of 1-2 years, which
is just fine. Remember, there's still Perl4 code out there, and that
was over 10 years ago. In 10 years, there will still be Perl5 code out
there, and it will run just fine on Parrot (and whatever other VMs are
out there).
This is the point I think you're missing - you can write pure native
Perl5 in a Perl6 environment and call Perl6 modules, without a single
issue. You can call Perl5 modules from Perl6 without a single issue.
Everything else is icing.
> The fact that there's not alot of active p5p'ers on this list should
> alarm people more.
Why? They're focused on Perl5, not Perl6, as it should be.
"Doug McNutt" <doug...@macnauchtan.com> wrote:
> I fear that Parrot will not come into widespread use until perl 6 is
> released.
>
Parrot might not be ready to come into widespread use until Perl 6 is
released - there's some stuff missing yet. But encouragingly, a number of
people are working on compiling other languages to Parrot. The Ponie
project covers Perl 5, there's quite a lot of work going on with a Tcl
compiler, an Eiffel-like scripting language compiler is being developed and
there's more. Personally, I'm working on translating .NET stuff into Parrot
intermediate code (my thesis, though a good excuse to spend more time doing
stuff on Parrot that's more generally useful).
> As a rocket scientist, who started before the first FORTRAN compiler was
> released, I like assembly language and the portability of the Parrot
> interpreter appeals to me. But perl magic cookies in an assembler? Will
> it ever fit into a 68HC11? Can it attract the attention of hardware
> manufacturers?
>
I don't think the goal ever was to get Parrot implemented in hardware. From
what I've heard about Sun's efforts to do this with their JVM, it doesn't
work out too well. Yes, to some degree Parrot is a software CPU, but
virtual machines for high level languages tend to deal with stuff that a
software CPU doesn't. They provide support for much higher level stuff than
hardware does (continuations, co-routines, objects, types). For common HLL
features, making a large number of compilers deal with that kinda stuff
isn't greatly efficient when you can implement it once in the VM.
PMCs are an example of one of the things a HLL VM provides that a software
CPU wouldn't. They're called Parrot Magic Cookies rather than Perl ones;
the point of them is that they support an abstract set of operations that
you could want to perform that are invoked via a v-table mechanism. This
means that you can implement language specific behaviour for operations
while still keeping inter-language operability.
Hope this helps,
Jonathan
> On 10/24/05, Juerd <ju...@convolution.nl> wrote:
> >
> > > >Feel free to add your own, or fears you heard about!
>
>
> FEAR: Perl6 internals will be just as inaccessable as p5
paradox. Many people don't find perl5 inaccessible at all
> FEAR: The Perl6 process is driving away too many good developers
From what?
> FEAR: Perl6 will not be as portable as p5
I will subscribe to that fear, but only for now.
> FEAR: Perl6 will not be able to fix the stigma of "just a scripting
> language" or "line noise"
perl5 has never been "just a scripting language"
> FEAR: Perl6 is un-necessary and the time, money, and resources is impacting
> p5.
very untrue. And this does not sound like a FEAR, but more like an opinion
> FEAR: There is too much misinformation surrounding Perl6 for people to feel
> comfortable.
>
> This last fear is likely the reason why you are collecting this list. I
> think the biggest problem is accessability and visibility for the casual
> observer. Unless you are devoted to the list and the IRC channels and the
> conferences your perception of what "is" and "isn't" Perl6 is out of date.
> We don't have a single source where people can go for relatively "up to the
> minute" facts concerning the project.
> Juerd
My only current fear is that I won't live long enough to be able to use and
understand the full richness of what perl6 is going to offer me.
(Oh, and that perl6 will never be able to upgrade my scripts that use
'format', but I'm aware of the plan to make that `obsolete' as in: the
perl526 translator will dump core on those)
--
H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/)
using Perl 5.6.2, 5.8.0, 5.8.5, & 5.9.2 on HP-UX 10.20, 11.00 & 11.11,
AIX 4.3 & 5.2, SuSE 9.2 & 9.3, and Cygwin. http://www.cmve.net/~merijn
Smoking perl: http://www.test-smoke.org, perl QA: http://qa.perl.org
reports to: smokers...@perl.org, per...@perl.org
>> FEAR: Perl6 will not be able to fix the stigma of "just a scripting
>> language" or "line noise"
>
> perl5 has never been "just a scripting language"
But sadly enough it is often _perceived_ as such. And also like "line
noise", as the person you're answering to correctly states: an opinion we
all beg to differ, I suppose, but a widespread one indeed...
Michele
--
you'll see that it shouldn't be so. AND, the writting as usuall is
fantastic incompetent. To illustrate, i quote:
- Xah Lee trolling in clpmisc,
"perl bug File::Basename and Perl's nature"
> My only current fear is that I won't live long enough to be able to use
> and
> understand the full richness of what perl6 is going to offer me.
>
> (Oh, and that perl6 will never be able to upgrade my scripts that use
> 'format', but I'm aware of the plan to make that `obsolete' as in: the
> perl526 translator will dump core on those)
Those were not my fears. They are comments and concerns I see made day in
and day out in various online forums over the last 3 years. Juerd's whole
point to collecting these fears was to point out that, by and large, they
are unfounded. Stating that plenty of people find p5's internals very
accessible isn't going to allay the concerns of the people with the fear.
Stating that p5 has never been "just a scripting language" isn't going to
change the perception of those people that hold that opinion.
IIRC, Andy has taken up the Perl6 PR hat. I think Juerd should like be
working with Andy on this one. The rebuttals to these fears needs to be well
thought out and convincing because from my personal experience they are
prevalent.
--
> H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/)
>
Cheers,
Joshua Gatcomb
a.k.a. Limbic~Region
I'll work with anyone, but I do believe in collaborative editing. That's
why I put it in pugs' svn, so that everyone can help.
If this list of fears is ever used for more official purposes (not my
original intent), like putting it online as an article, of course PR
people must be involved.
For now, if Andy wants to change anything, he is free to do so, like
everyone else. If he thinks I shouldn't continue without his approval,
he knows where to find me.
So far, most of my subprojects have been undiscussed before they
started. It has all worked out well. If anyone objects, please do let me
know. But if you want me to discuss things beforehand, people better be
reachable and responding, because I generally lose interest if I don't
get started within a few days. That kind of thing has been a problem
with other projects, and I love how Perl 6 development is so open and
free, focussed on fun and a common goal, rather than bureaucracy and
people wearing very specifically coloured hats :)
Who? Do you know anybody who hacks the regex engine?
> > FEAR: Perl6 will not be able to fix the stigma of "just a scripting
> > language" or "line noise"
>
> perl5 has never been "just a scripting language"
Yeah, but he's talking about the cultural stigma, which is definitely
present. However, given the increasing number of high-level design
constructus, I think that this fear will never realize itself. The
only way it could is from the name "Perl", and once anybody uses it,
it will go away.
> My only current fear is that I won't live long enough to be able to use and
> understand the full richness of what perl6 is going to offer me.
>
> (Oh, and that perl6 will never be able to upgrade my scripts that use
> 'format', but I'm aware of the plan to make that `obsolete' as in: the
> perl526 translator will dump core on those)
I wonder how hard it would be to actually convert perl 5 formats to
Perl6::Form. Having never used the former myself, I wouldn't really
know the order of magnitude of this problem.
Luke
japhy. Though, granted, he's on a whole new level of insanity.
Rob
It happens that Merijn does, partly as a side effect of being an active Perl
5 committer. But assuming that you're questioning his use of "many", then
I agree with you. Few people find perl5 accessible. Mostly as a side effect
of banging their heads at it until it starts to change from inaccessible to
accessible.
And inaccessibility is something that both perl6 and parrot should actively
strive to avoid. Having looked at src/hash.c today, I fear that currently
parrot is showing signs of failing in this.
> I wonder how hard it would be to actually convert perl 5 formats to
> Perl6::Form. Having never used the former myself, I wouldn't really
> know the order of magnitude of this problem.
It's probably easier to implement strict perl5 formats as a compatibility
module, using the exiting Perl 5 source and parrot's NCI.
Nicholas Clark