A proposal for Perl's branding - let's free all the butterflies
Here is a suggestion for Perl's branding: http://nigelhamilton.com/perl-branding-proposal.html
Announce: [SixFix] A weekly dose of Perl 6 delivered to your inbox
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 will write Perl 6 code that helps you code. The first SixFix course is free and is delivered in 7 weekly doses. Sign up for your first SixFix here: http://sixfix.nigelhamilton.com
Re: Logo considerations - 3 logos needed
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., Python, Ruby). This means the Rakudo icon needs to be distinctive at favicon size - but that should be a design objective anyway. (Parrot with speech bubbles in favicon halo)++ 2. Rakudo Camelia is colourful, fun, can look distinctive at favicon size and may act as a friendly mascot - and, unlike a camel, it does not spit or smell[1]. Camelia++ 3. Perl6 = the test suite The current plan is that Perl6 will not have a single implementation but that the test suite is shared by implementations. I think there is a need for a Perl6 = test suite device - ideally it should be possible to visually incorporate it with the implementation logos (e.g., Camelia, Pugs, SMOP etc) - this means it should be graphically *very* simple. This sub-device could capture the distinctiveness of Perl6. Ideas include: [ ] - meta-operator brackets - [ ] - these could surround the implementation logos - test suite as a shield against bugs, strength etc - hmm, not sure, Camelia could look trapped at 16x16? * - whatever- a whatever star could be placed on Camelia's wings - a dog collar on the Pug? - a hyper pattern on Camelia's wings? \* *\- capture whatever? end comment. There is rich visual expressiveness and distinctiveness in Perl6 operators - not to mention functionality - it would be a shame not to use these iconically - I think the Perl6 + Test Suite logo has a chance to do this. If it stays *really simple* the implementation logos can embed it too. What is a Perl6 operator that sums up Perl6 and looks visually distinctive? - this could form the basis of the Perl6 + Test Suite device - which in turn could be incorporated by implementation logos? ... Taken together - these three devices (Parrot favicon speech bubbles, Rakudo Camelia and Perl6 = Test Suite[?]) could interlock and help visually stick the meme complex together ... it's exciting. Nige [1] and best of all is not confusing with other registered trademarks. Larry++
Re: Logo considerations - 3 logos needed
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 shared by implementations. I think there is a need for a Perl6 = test suite device - ideally it should be possible to visually incorporate it with the implementation logos (e.g., Camelia, Pugs, SMOP etc) - this means it should be graphically *very* simple. This sub-device could capture the distinctiveness of Perl6. Ideas include: So iconically speaking the test suite [demarcates] Perl6 - but there can be lots of different implementations (whatever *) - [*] - here is a basic mock up: Perl6 = Test Suite logo: http://t10.com/perl6-test.jpg (basic mock up) Which could be incorporated into Camelia like: http://t10.com/perl6-camelia.png (mock up) And Parrot could speak Rakudo (Camelia): http://t10.com/parrot-rakudo.png As you will see Camelia needs the skillz of a graphic designer to make sure it still works even when rendered at 16x16 as a tiny favicon - but I think you could visually bind the three things together: Perl6 test suite + Rakudo/Camelia + Parrot. Just some ideas Nige
Re: derived class generators and introspection
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 aforementioned, when the working set of data is appropriately small, but just as a hash-doing class can have a disk-tied implementation as well, for scalability and/or persistence so can a relation-doing class. And this is one main reason why Relation etc is a role rather than a class, so people can choose how it works. OK. I can see that a tied-relation could help solve the talking to disk problem. But I wonder about some of the other RBMS things on offer - locking, indices etc? Some of these features are there to assist with getting data efficiently to and from the disk. Although they are not artefacts of the relational model they are important parts of what makes a database work. Could your relational model be tied to an existing physical database? NIge
Re: derived class generators and introspection
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 about pesky problems like: indexing, locking, seek time etc? The days of limitless RAM are yet to arrive - until then databases must rely on the disk - what is the plan for storing the data? NIge In closing for now, I imagine that a lot of this stuff is connected to the meta-model, though doing it well will have clean support in the language syntax as well. Feedback is appreciated.
Re: Exceptuations
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 need a build-in event system on the language level? -- Hear, hear. Isn't just an exception a naughty event? But when you think about it, isn't all programming about suggesting events and handling what happens next? Most of what a programmer does is suggest events to do (e.g., open file) and then handle the 'events' that happen next (e.g., file not found) and then suggest some more events (e.g., die). At the moment the programmer is the top-level event handler (e.g., damn - why didn't that work?) - but maybe some of this hassle could be handed off? Is there a way to turn the exceptions type matching / depth finding problem inside out? From the point of view of the operating system a program is a nasty exception to its normal running environment - your whole program is a kind of big exception! Like someone intruding on a conversation the programmer tries to change the topic of the operating system. Hey can you get that network socket for me? Programmers are constantly trying to change the topic of conversation of the operating system. Hey drop what you're doing. This is important. Get me that file. But some of the nastiest (and exception raising) problems arise from the conversational disconnect between operating system and program (e.g., Sorry that port is blocked, Sorry can't find that file, Socket closed etc). Is there a place in the room for a third party to the conversation? Somebody who could ... Smooth over misunderstandings? Do translation if either party doesn't understand? Queue what should be the next topic of conversation? Remember how topics are meant to be handled? Provide a log of what was said? Is there a way of integrating Perl's natural ability to stay on topic ($_) with exception handling, and event handling? Just some thoughts ... NIge
Re: -X's auto-(un)quoting?
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's a great idea. I like it too. In normal writing ... acts as a kind of 'think back' operator. Even though the writer uses it to signal an afterthought - it also makes the reader 'think back' to what preceded the afterthought. Syntax like .say ..say ...say enables the writer to add an afterthought and the reader to 'think back' to precisely the right scope. It allows you to have N scopes too .say, that would be cool. I hope this doesn't cause trouble for yada yada because I really like that operator too. Nige
Re: .method == $self.method or $_.method?
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, heh. I think we'll need to figure out how to shorten $_.foo instead. Either that, or there has to be a way to explicitly make $_ the invocant of a subblock. What about using the oc idea to shorten $_.foo x.foo How about t.foo --- t for topic? ;-) Nige
Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)
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 hard to use any libraries, because all the libraries have good method-level documentation, but none of them has good interface (conceptual, not Cinterface)-level documentation. I basically have to understand how the library author organized his code in order to use his library. On the other hand, Perl has this wonderful module idiom of SYNOPSIS and DESCRIPTION. SYNOPSIS generally shows you how a very small program would use the library (the thing Java libraries are missing), and DESCRIPTION goes in detail about the things you need to know. The things you don't need to know you can get by reading the code. Hi Luke, I agree that SYNOPSIS and DESCRIPTION sections are really important and I would not want them to be lost - maybe these should be a requirement for uploading to CPAN6? I seldom program in Java too :-) But one of the few things I liked about Javadoc is the ability to traverse the interfaces of classes quickly - and this is tied to hypertext. Forget I used the J word --- what I'd like to see in the documentation system is the ability to quickly browse and traverse the linkages between modules and 'things'. The documentation requirements for Perl6 are a step up from Perl5. Perl6 programs will have 'backlinks' and relationships with a number of things: rules, grammars, classes, methods, roles, subs and traits etc. These in turn may have their own hierarchies. The structural aspects of the contract of a Perl6 class needs to be prominently and uniformly communicated. I think we need a hypertext browsing capability so that we can jump around the distilled contract of a class: both our own modules and each other's. In this way you could traverse the interlinkages between ALL things on CPAN6: What grammar inherits from that? What modules use this grammar? What classes do this role? What programs test this class? What grammars inherit from this grammar? I'm not advocating terse documentation - but I would like to add to the wishlist: * universal consistent hypertext code browsing both locally and on ~~ /CPAN6/. Nige
Re: [Pugs] Closing a file handle surprised the heck out of me
: 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 inspiration here? Not so much for
solving this specific bug - but making easy IO things easy and making file
handle funkiness hard?
Just a meme for the pool ...
Nige
