> Here is a suggestion for Perl's branding:
>>
>> http://nigelhamilton.com/perl-branding-proposal.html
>>
>
> I like your proposal.
>
>
:-)
> But its details would need fleshing out more, particularly at the end,
> where it says this:
>
> Perl $new_runtime_name_for_perl5_goes_here (tm)
> Perl $n
Here is a suggestion for Perl's branding:
http://nigelhamilton.com/perl-branding-proposal.html
SixFix is a weekly email with something new to learn about Perl 6. But there's
a catch! Each email includes a coding challenge and a question about Perl 6
you must answer to receive your next SixFix.
SixFix helps you learn Perl 6 with practical coding exercises (approx 1/2
an hour each week). You
>
>
> But IMHO there is a need for three logos:
>
> 1. Combined Parrot + Rakudo
>
> (Parrot with speech bubbles in favicon halo)++
>
>
> 2. Rakudo
>
> Camelia++
>
>
> 3. "Perl6 = the test suite"
>
> The current plan is that Perl6 will not have a single implementation but
> that the test suite is
I like the "Camelia" it's colourful, fun - it even has an embedded, sideways
reference to a "Camel".
But IMHO there is a need for three logos:
1. Combined Parrot + Rakudo
I like the suggestion of having cartoon "speech bubbles" around the Parrot
that contain favicons of the language icons (e.g.,
Rather, the proposal is focusing on what users of these data structures
would / could see. The idea is that relational structures have the same
ease of use and flexability that things like hashes or arrays or sequences
or sets do now. They can of course just be stored in RAM like the
aforemen
HI Darren,
Generally I really like the idea of fixing the relational/OO
mismatch problem by swallowing the relational model whole. :-)
But I wonder if we are ready to say goodbye to the tyranny of disk
seek? How will your proposed system use the disk? And if it does use the
disk what abou
And handling user errors in a GUI application is a task for event handling,
*not* exception handling. I agree that both mechanisms share large parts
of the infra-structure supporting them. But I make a strong conceptual
distinction between them.
Which leads to the question, does Perl6 have or n
I've been reading the Perl6 "type" and method dispatch discussions with
some fear and trepidation.
Just following the linear flow of control through a program can sometimes
be a mind bend. The type inferencing and dispatch system for Perl6 seems
very funky. Throw in some autothreading and Junc
What about . for each level up you want to go?
instead of 1.say, 2.say, 3.say
you use .say, ..say, ...say
(Ok, I'm just kidding.. really!)
I read your message after I suggested the same thing (I'm too impatient
to read all new messages before sending replies).
Why were you just kidding? I think it'
On Thu, Mar 17, 2005 at 03:59:43PM -0800, Michael G Schwern wrote:
: What it doesn't solve is the $.method vs .method issue. They look
similar
: but one works on the invocant and one works on $_. Still a trap.
Yes, and that's probably the killer of the "oc" idea. So much for
Sleep Brain, heh,
I agree. I think the biggest mistake Perl 6's documentation system
could make is to make it Javadoc-style automatic. This is one of those
weird, backwards, cultural decisions, where we actually want to make the
programmer's life a little harder.
When I (seldomly) progam in Java, I find it very ha
: Given this Pugs program, t.p6:
:
: my $fh = open(@ARGS[0]);
: my @lines = =$fh;
: $fh.close();
: for @lines { print"$_" }
:
: running:
:
: pugs t.p6 t.p6
:
: produces no output. Move $fh.close() to after the for
: loop and all is well. Is this a bug?
I wonder if IO::All could provide some inspira
13 matches
Mail list logo
