|
Re: Apocalypse 12
by TimToady (Parson) on Apr 17, 2004 at 00:29 UTC
|
| [reply] |
|
|
| [reply] |
Re: Apocalypse 12
by chromatic (Archbishop) on Apr 16, 2004 at 15:41 UTC
|
No, not yet. It is indeed scheduled for today (16 April 2004), but it's not public and anyone who spreads this link around before 5 pm -0800 GMT has jumped the gun. Slightly.
Update: Now it's out. Enjoy Apocalypse 12.
| [reply] |
Re: Apocalypse 12
by jonadab (Parson) on Apr 16, 2004 at 20:30 UTC
|
Very cool, thanks for the heads up.
I guess I know what I'm going to be doing tonight :-)
update: Ack!...
class Dog is Mammal;
has Limb @.paws;
method walk () { .paws».move() }
Umm, I have some questions here...
What on earth is that character?
A "right-pointing double angle quotation mark", eh?
Wow, that's a mouthful... and here I was thinking
weird non-ASCII quotation marks were a Microsoft
Word foible.- How do we pronounce it? update:
still looking for an answer to this
question
Why is there a character in the basic syntax
of the core language that can't be typed on
a standard-issue us-ascii keyboard? What
am I missing here?- How are we supposed to type it? Can we
just type >> and have it work,
or
are we going to have to find a way to
insert that character? (I know, in Emacs
I can bind a key combination to it, but what
about posting code on web fora, usenet, and
so forth?)update:
A12 does answer this, just not until page 19.
How are we supposed to do stuff with code
containing this character, such as copy and
paste it between applications, store it in
files, and so on?. Oddly, this
stuff seems to work for me using Emacs 21 on
Mandrake 9.2, even storing on a FAT32
filesystem. I'm still a little concerned about
cross-platform support for this, though.Am I overreacting? Can someone reassure
me about this and explain how it's okay?
I guess it's not _so_ bad, considering we
can just type >>
The only keyboard I've seen where I can type the
non-ASCII character in question is the DEC keyboard
used with the VT510, which has a Compose key. On that
keyboard, I can construct the character by typing
compose then > then > -- but that's three strokes,
which makes it at least as bad as a trigraph operator,
and in any case the VMS system in question doesn't
have Perl installed (or much else). I can use copy
and paste from A12 into Emacs and thus bind a key to
insert the character when I'm working in Emacs, but
I won't be able to easily use it in other situations,
e.g., when I'm discussing it on Perlmonks using
Mozilla. This is ultimately a minor annoyance,
since parallel dispatch isn't something I anticipate
using very often (update umm,
but some of the other uses are more important),
but nevertheless I reserve the right to not
like it. IfSince it turns out
that >> will work, I'll be much happier doing it
that way.
On a side note, Page 19 says...
But there is, of course, a hyper version
[of the identity operator]:
@a »=:=« @b
Yeesh. Typed on a standard keyboard, that's a
heptagraph operator. Wow. I thought the
Perl-is-line-noise people were annoying NOW. Wait
till they get a load of this!
;$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}}
split//,".rekcah lreP rehtona tsuJ";$\=$;[-1]->();print
| [reply]
[d/l]
[select] |
|
|
| [reply]
[d/l] |
|
|
| [reply] |
|
|
| [reply]
[d/l]
[select] |
|
|
|
|
|
|
It is an ASCII character
<nitpick>
It definitely isn't an ASCII character. ASCII is only seven bits wide, and never included none o'them wierd "foreign" characters :-).
You will however find it in ISO 8859 (aka ISO Latin 1).
</nitpick>
| [reply] |
|
|
|
|
|
|
|
|
|
|
|
Re: Apocalypse 12
by webfiend (Vicar) on Apr 17, 2004 at 18:22 UTC
|
Ouch. I have a bit of a headache as well, and I am only on page 5. It's okay, it's okay, I can keep going. This Apocalypse has me veering wildly between "this will be really really cool" and "this will be a total nightmare to maintain". Sometimes in the same paragraph. Occasionally in the same sentence.
Okay, break time over. Back to trying to digest this thing...
| [reply] |
|
|
Hmmmmmm. Given that Larry and the rest of us worked very hard to design a syntax and semantics that specifically *improves* the maintainability of OO Perl code, we'd certainly appreciate feedback on those bits you feel will still be total nightmares to maintain. If nothing else, I'd like to get a handle on what people are troubled by in A12, so I can better address their concerns in E12.
| [reply] |
|
|
I think that the main thing that concerns people about A12 is just that there are a lot of pieces involved, and they are not sure what you do and do not have to worry about. One message that people really need to hear loud and clear is that they don't need to understand all of them since the changes DWIM. For instance all of the stuff about lexical namespaces etc can be forgotten since if you don't use it, you won't be burned by anyone else using it, and if you do use it, then it does what you'd expect.
Another major concern is confusion about how traits differ from roles and classes differ from types (really, subtypes, but type is the keyword chosen at the moment). I admit to considerable confusion on traits vs roles until Larry said that a trait is a role on the class. As soon as I knew how the mechanism is supposed to work, I could see the difference. Stated in my own words, A role grants extra methods to objects that are given that role. The role does nothing until you call the methods that it provides, so it is relatively unobtrusive. We say, 'Foo does Bar;' to indicate that you have those methods. But if there is a role on your Class, that role could easily arrange to do whatever it wanted when you were being created. In other words it could have changed what you are, which is why we say, 'Foo is Bar;'. That far more intrusive thing is called a trait. As for classes vs types, while I can describe what a type is, I'm significantly less clear on what practical role is anticipated for them.
As for my areas of actual concern, they exist but I don't think that E12 is going to be able to address them. Here are a few:
- Having read the discussion of how roles will be implemented with multiple inheritance, how well will the role/trait stuff play with people declaring the current inheritance model?
- My major concern about any mix-in kind of design (including inheritance and roles) is that people can wind up having methods available and have no idea where the method came from. I'm hoping that there will be a limited number of very useful traits and roles that are built in (or at least widely used) and people don't go about building too many of their own. That will let me amortize the cost of learning them over a lot of usage. This is not, however, fundamentally a language design issue but an education one.
- I'd like to understand the proposed aliasing mechanism better than I do. I understand the need (particularly when cooperating across languages), but I'd like to understand how it will be done.
- The proposal that we have multiple versions of modules loaded at the same time scares me. I cannot help but think that it is an inherently fragile thing to attempt, particularly if someone does anything dynamic. Problems comes in many flavours, and I'm not sure which bothers me most. Here is a sample.
- How can the feature help if developers have not specified versions for dependencies? I'm in the habit of just saying "use X", so do most people. Most do likewise. If most of CPAN follows suit, then this great feature will never assist me in the real world because I'll depend on some module that requires some specific version of another module, and the specific version was never specified. Relying on developer behaviour is fragile.
- How do you handle versioning of proxied modules? For instance suppose that module A dynamically loads any of a number of modules, including B, behind the scenes on behalf of C. (Consider a plugin architecture to see why someone might do this.) How do you address version dependencies between C and B?
- When will bugs go away? If module X is used by many others, and an annoying bug in it is fixed in module X, people can keep running into that bug until every other module has been updated to say that they work with the newer version of module X. This delay can be rather frustrating for the person who is trying to remove the bug on their local system.
- What code am I REALLY running? When debugging, one of the more frustrating bugs to track down is when the code that you are running is not the code that you are looking at. Been there, done that. When you load multiple versions of the same software at the same time, this multiplies.
- Where's my data? When you load CGI.pm, behind the scenes it can read in all of STDIN. (It has to for a POST.) So now a poor web developer has 2 modules, which require different versions of CGI.pm. One gets the data, and the other gets confused. As does the developer who is trying to figure out why CGI.pm just broke. This becomes an issue any time a module has to interact with external resources.
- What about C libraries? So I'm using a nice XS module, and then go to load 2 versions of it. But each wants a different version of a .dll or .so (either platform, same issue). Unless you figure out how to make the versioning trick work down to the C level, it is going to break on lots of important modules.
- Feeling bloated? While I'm hardly the first to argue for efficiency over everything else, loading multiple versions of the same software at the same time is a problem. Particularly if the module is supposed to do something like hold my database handle so that I don't need extra database connections...
When I first heard about the idea of trying to support having multiple versions of software on your system, I thought that it was a fundamentally broken idea. No, I don't want the added complexity when I think that it will fail, and complicate my life in the process. That opinion hasn't improved with time...
| [reply] |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
My overall first impression is that Perl 6 will be much better than for Perl 5 for building really large systems, so I'd like to see some examples in E12 illustrating how Perl 6 scales better.
So far, I like it a lot. The only thing that has caused me to pull a face is the whitespace-changing semantics in the Methods section where Larry commented:
Yes, this is different from Perl 5. And yes, I know certain people hate it. They can write their own grammar.
This scares me enough to always put parens around function calls (which I mostly do in Perl 5 anyway). So, if you can unscare me, that would be nice. :-)
| [reply] |
|
|
|
|
|
|
To be honest, it's mostly just a reaction to new things. I'm always a little grumpy before I absorb stuff.
- Submethods throw me a little, but I expect to get the hang of it.
- New funny characters ($.instancedata and %:classstuff for starters) throw a little more for the folks who like to refer to Perl as line noise.
- Not drinking enough coffee when you're really used to it can induce mild headaches as well. Doesn't have anything to do with Perl 6, but might have had something to do with my attitude this morning.
The (admittedly somewhat snide) comment about maintainability was not about the look of Perl 6 OO itself, which I am looking forward to using and abusing. The comment was based on thinking about what potential impact this might have on the code of folks who like to use every language feature in every file of code they write. But I've had my coffee now, and I've had time to think about it, and I'm okay.
I just want to get in there and start using Perl 6. Not approximations from the Perl6 modules of CPAN, but the actual language. I think I'll go play with Parrot for a little bit :-)
Update: Yeah, playing with Parrot. Where there's a lovely Perl 6 implementation. The new problem is that it's almost 3am and I really should be in bed. Just ... you know ... disregard pretty much the whole thing.
| [reply]
[d/l]
[select] |
|
|
|
|
I started reading Apocalypse 12, and at first I liked what I saw. Not having instance variables is the root of all Perl5 OO evil, and perl6 will fix that.
Then I read about the whitespace sensitive rules and I said,
yeah, whatever and lost interest. If you want a maintainance nightmare, program in a language where the value of an expression changes depending whether there's whitespace between tokens or not.
Abigail
| [reply] |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
I've been looking forward to A12 for a while and I don't think I'm disappointed. - There's plently of stuff I haven't grokked yet - but the stuff I do really excites me.
The only concern I have at the moment, is the many references to compiler optimizations, as below...
It might be objected that this will slow down the parameter binding algorithm for all methods favored with an implicit *%_, but I would argue that the binding code doesn't have to do anything till it sees a named parameter it doesn't recognize, and then it can figure out whether the method even references %_, and if not, simply throw the unrecognized argument away instead of constructing a %_ that won't be used. And most of this "figuring out" can be done at compile time.
Will Perl6 not still have eval? - Will this not have an impact on any compiler optimizations that I don't explicitly ask for?
e.g. What if the above method's 'extra' arguments are thrown away, but auto-genereated code inside an eval tries to reference it? How can the compiler ever be sure enough to make that optimization except in the most trivial example?
method foo { return 1 }
However, I don't know a thing about compilers, so I don't know what I'm talking about - just giving you feedback on what I'm "troubled by" ;)
| [reply]
[d/l]
[select] |
|
|
|
|