It's written. I've seen it work. But it's apparently still awaiting approval from the Klingon Language Institute, who are taking their own sweet time over it.
Can anyone explain why tied variables are better than pure objects with proper accessor methods, btw?
Not better, just different. And Perl's had tied variables for longer than it's had OO. Tying, say, your aliases.db to a perl hash in a simple maintainance script can be a very effective and natural way of working. For larger, more formal work, you're often better off with a more formal interface, but tied variables have their place.
Re:How Object-Oriented is Perl
on
Ask Larry Wall
·
· Score: 1
Personally, I'd go so far as to say that Encapsulation is a somewhat overrated virtue. But then I would say that; I'm busy working on an Object Persistence tool for Perl. Because encapsulation is virtually nonexistent in Perl OO I can get the information I need directly from the object without the author of that class having to do anything special (but he can if he wants to.)
One of the things I like about the current perl 6 process is Larry's gleeful appropriation of all sorts of useful stuff from everywhere else. It's great. Look at the features of functional languages that you picked out:
Macros: In a sense, that's what Apocalypse 5 is paving the way for; the ability to manipulate the current grammar and add new language features is a small step. Okay, so they're not going to be as clean as lisp/scheme macros, in part because Perl itself is nowhere near as clean as lisp/scheme.
Tail call optimization: According to discussions on perl6.language it looks like it's going to be possible to have at least some (I'm hoping for lots) tail call elimination.
Continuations: (I assume that's what you meant given that you talk about call/cc (personally I prefer let/cc, but hey)). Again, it looks like perl will be getting these (at last), the capability will certainly be there in the underlying VM.
Now, you may not like perl's syntax, but having these capabilities in the language is going to be great. And hell, you can always morph the syntax into scheme if you like, just make yourself a new grammar and a few supporting functions. I'll probably beat you to that, I've already got the makings of a perl6 scheme interpreter, now to make an A5 based parser for it.
I wondered how many emails saying "No you idiot, it's like this..." you got? Maybe none, maybe loads...
None so far. Although the author of Coro wrote to tell me he wasn't inspired by the Perl 6 process, he just had an itch he needed to scratch.
And a couple of people complained about a Buffy spoiler or reckoned I'd got Willow's traits wrong.
And Larry appears to have changed his mind about NaN since I wrote the article. Currently it looks like an unnumfiable value will give 'undef' not NaN.
I think that comment in the text of the article was intended more to point out that there really isn't a whole lot to add to a language besides syntactic sugar, since perl is already Turing-complete.
I don't think the author intended for a comparison out of resentment.
CGI/mod_perl is an inappropriate place for OOP? Have you seen the current slashcode? It's completely OO. Almost every serious mod_perl based system I've worked on in the past n years has been OO. It just fits.
Re:Comment from a real PERL programmer
on
Perl6 for Mortals
·
· Score: 1
This might be valid Perl6:
%b{@a}:= ^-x @a ^_ '.c';
Well, it sort of is, but you'll end up with a bunch of '.c' entries in your hash where something wasn't executable, and there's really no need to use:=
It'd be better written as
for my $basename (grep -x, @a) {
%b{$basename} = $basename _ '.c';
}
Even if you're the only person on the project and it's private code, the 'other guy' is just you in a couple of weeks/months time. But it looks like you know this.
Re:Just what Perl needs - more syntax
on
Perl6 for Mortals
·
· Score: 1
Gah! You're right. Must read more closely. I don't tend to use $_ if I can help it.
Re:Seems like the article wasn't for you
on
Perl6 for Mortals
·
· Score: 3, Informative
It's a functional programming thing, named for Haskell Curry. The basic idea is that if you have a function with two arguments, f, and you call it passing in only one argument with value x, you get back another function f' such that f'(y) is equivalent to f(x,y). If you call f with a different value of x, then you get back a different f'.
This sort of thing is, if not exactly commonplace, a feature of the likes of Haskell, Lisp, Scheme, Perl 5 (if you did the hard work by hand), and various other programming languages that support closures. The perl 6 syntax is simply about making currying easier to use.
Re:Just what Perl needs - more syntax
on
Perl6 for Mortals
·
· Score: 1
Seems like the article wasn't for you
on
Perl6 for Mortals
·
· Score: 1
I wrote it for an audience of people who already use perl, and who had read the apocalypses and exegeses describing what Larry has done so far. If I'd taken the time to explain the syntax then I'd've spent the majority of my article rehashing the references. Thank you, but no.
The particular example you cite is a currying parameter, using one introduces a currying context.
And you are so much the wiser already aren't you. But if you go and Read The Fine Apocalypse, you'll see that it's explained, with pointers to a more in depth explanation if you need it. Throwing up your hands in horror because you don't understand it and it looks weird seems a little extreme.
Re:Pros and Cons of Perl
on
Perl6 for Mortals
·
· Score: 2, Interesting
Now there I have to disagree with you. I think that the changes in Perl as we move to Perl 6 are going to make it easier to write clearer code. The new function definition semantics for instance will move all the code for dealing with function arguments out of the body of the function, so someone reading/maintaining that code can concentrate on the meat. Replacing $self->foo with.foo is nice too. The emphasis gets shifted to the things that are important.
Of course, many of these tools will allow criminal bastards who shouldn't be allowed anywhere near a production codebase to perpetrate monstrosities. But they can do that already in any language they choose to pollute. And Larry has been making noises about allowing folks to write their own versions of things like strict, which, when taken hand in hand with the more accessible parser should mean that sites that want to can enforce their own rules for coding.
If you want to be good, Perl 6 is going to let you be better.
Well, as I wrote the article and I'm reasonably confident I'm not a fool, I guess I'd better respond.
Larry hasn't finished yet. There's another 30 Apocalypses due. So that means some things are conditional, and I've got to guess which way Larry is going to jump. So I do. And if I'm wrong, so what, it's still fun trying to read the tea leaves.
Slashdot Mirror
It's written. I've seen it work. But it's apparently still awaiting approval from the Klingon Language Institute, who are taking their own sweet time over it.
Not better, just different. And Perl's had tied variables for longer than it's had OO. Tying, say, your aliases.db to a perl hash in a simple maintainance script can be a very effective and natural way of working. For larger, more formal work, you're often better off with a more formal interface, but tied variables have their place.
Personally, I'd go so far as to say that Encapsulation is a somewhat overrated virtue. But then I would say that; I'm busy working on an Object Persistence tool for Perl. Because encapsulation is virtually nonexistent in Perl OO I can get the information I need directly from the object without the author of that class having to do anything special (but he can if he wants to.)
I'm sorry, but patenting a stool would be a really shitty thing to do.
Can I suggest writing something that duplicates the oraperl interface using DBI and DBD::Oracle, and using that to run your scripts?
It'd probably make your life easier. In the long run.
Check out camelbones and see if that scratches your itch.
Oraperl? Or do you mean DBI + DBD::Oracle. oraperl, sybperl and all those other monstrosities have been unsupported for ages.
Um... 'Pumpking' isn't a typo. It's the standard perl hacker title for the holder of the Patch Pumpkin.
- Macros: In a sense, that's what Apocalypse 5 is paving the way for; the ability to manipulate the current grammar and add new language features is a small step. Okay, so they're not going to be as clean as lisp/scheme macros, in part because Perl itself is nowhere near as clean as lisp/scheme.
- Tail call optimization: According to discussions on perl6.language it looks like it's going to be possible to have at least some (I'm hoping for lots) tail call elimination.
- Continuations: (I assume that's what you meant given that you talk about call/cc (personally I prefer let/cc, but hey)). Again, it looks like perl will be getting these (at last), the capability will certainly be there in the underlying VM.
Now, you may not like perl's syntax, but having these capabilities in the language is going to be great. And hell, you can always morph the syntax into scheme if you like, just make yourself a new grammar and a few supporting functions. I'll probably beat you to that, I've already got the makings of a perl6 scheme interpreter, now to make an A5 based parser for it.That's proves in the sense of 'tests'.
Well, that's my excuse. And I'm sticking to it.
None so far. Although the author of Coro wrote to tell me he wasn't inspired by the Perl 6 process, he just had an itch he needed to scratch.
And a couple of people complained about a Buffy spoiler or reckoned I'd got Willow's traits wrong.
And Larry appears to have changed his mind about NaN since I wrote the article. Currently it looks like an unnumfiable value will give 'undef' not NaN.
Indeed so. But it does an awful lot more.
I think that comment in the text of the article was intended more to point out that there really isn't a whole lot to add to a language besides syntactic sugar, since perl is already Turing-complete.
I don't think the author intended for a comparison out of resentment.
You hit the nail on the head there.
CGI/mod_perl is an inappropriate place for OOP? Have you seen the current slashcode? It's completely OO. Almost every serious mod_perl based system I've worked on in the past n years has been OO. It just fits.
Well, it sort of is, but you'll end up with a bunch of '.c' entries in your hash where something wasn't executable, and there's really no need to use
It'd be better written as
for my $basename (grep -x, @a) {
%b{$basename} = $basename _ '.c';
}
open my $fh, $file or die;
will give you a nice shiny, lexically scoped filehandle.
And yeah, $| = 1 is a historical PITA. It's going away in Perl 6 though. Hurrah!
Even if you're the only person on the project and it's private code, the 'other guy' is just you in a couple of weeks/months time. But it looks like you know this.
Gah! You're right. Must read more closely. I don't tend to use $_ if I can help it.
It's a functional programming thing, named for Haskell Curry. The basic idea is that if you have a function with two arguments, f, and you call it passing in only one argument with value x, you get back another function f' such that f'(y) is equivalent to f(x,y). If you call f with a different value of x, then you get back a different f'.
This sort of thing is, if not exactly commonplace, a feature of the likes of Haskell, Lisp, Scheme, Perl 5 (if you did the hard work by hand), and various other programming languages that support closures. The perl 6 syntax is simply about making currying easier to use.
If that's supposed to be perl, you mean:
/([a-z]+) ([a-z]+) (\d+)/i
my($firstname,$lastname,$age) =~
I wrote it for an audience of people who already use perl, and who had read the apocalypses and exegeses describing what Larry has done so far. If I'd taken the time to explain the syntax then I'd've spent the majority of my article rehashing the references. Thank you, but no.
The particular example you cite is a currying parameter, using one introduces a currying context.
And you are so much the wiser already aren't you. But if you go and Read The Fine Apocalypse, you'll see that it's explained, with pointers to a more in depth explanation if you need it. Throwing up your hands in horror because you don't understand it and it looks weird seems a little extreme.
Of course, many of these tools will allow criminal bastards who shouldn't be allowed anywhere near a production codebase to perpetrate monstrosities. But they can do that already in any language they choose to pollute. And Larry has been making noises about allowing folks to write their own versions of things like strict, which, when taken hand in hand with the more accessible parser should mean that sites that want to can enforce their own rules for coding.
If you want to be good, Perl 6 is going to let you be better.
Well, as I wrote the article and I'm reasonably confident I'm not a fool, I guess I'd better respond.
Larry hasn't finished yet. There's another 30 Apocalypses due. So that means some things are conditional, and I've got to guess which way Larry is going to jump. So I do. And if I'm wrong, so what, it's still fun trying to read the tea leaves.