With 23061, the docs are pretty darned clear:When a constant is used in an expression, perl replaces it with its value at compile time, and may then optimize the expression further.It doesn't get a whole lot simpler than that. Granted, there is some wiggle-room left, but the perimeter of that wiggle room is clearly defined, and below that (just as below the definition of much of C's setjmp and longjmp) you enter implementation-specific regions.
It is certainly reasonable to submit enhancement requests around such things if you think perl is implementing Perl in a way that is counter-intutive, but any program that implemented the spec according to the documentation above would be conformant.
As for #23140 you are complaining that something that behaves EXACTLY as documented is not the way you want it. I understand that, but the documentation is clear on what happens to $1..$9 when you enter a new regex...
It seems like you're saying that because there are well documented edge-cases that can be confusing to programmers that the implementation and the documentation aren't in sync. I would disagree strongly with that assessment.
Mind you, I'm not disagreeing with your assertions in either of those bugs (I haven't thought either one through enough yet), but you seem to be upset about something that isn't quite the content of your bug report....
That's just wrong. Plain wrong. Unless you can show me at least a casual proof of that, I'm going to assume you just don't know what you're talking about.
Of course, if you just mean "I think Perl syntax is ugly," that's your perogative, but don't go stating it as fact, much less as a fact regarding what is or is not possible. You could argue that certain aspects of context-aware lexical transition in and out of quote-like operators constitute a degree of semantic obfuscation and build from there, but that's such a small aspect of the language that it's really not worth quibbling over, and certainly not the basis for such a broad assertion on your part.
Other than that we seem to have come down to differneces in taste and personal experience. Like I said... carry on.
Sounds cool. I think there was something like that for pod at one point too. I suspect it was abandoned because Perl already has a comprehensive build and test system and integrating the unit testing with the POD documentation would have meant removing a lot of the flexibility of the testing system or inserting a lot of hair into the POD documentation (thus defeating it as Plain Old Documentation).
I can see the merits of both approaches. Good to see There's More Than One Way To Do It...
I have to admit that figure shocked even me... over 6000 modules available for Perl?! Wow!
Ok, so I dug some more and I believe that number now. Here's a summary of the most popular top-level namespaces in which many of these modules live:
Summary:
305 Apache
254 Net
178 XML
166 Text
151 Class
150 HTML
135 Lingua
133 CGI
131 Tie
127 Math
108 File
107 Tk
101 Mail
101 Bundle
100 WWW
99 Data
95 Acme
92 DBIx
89 Crypt
67 POE
And the stunning thing is that that doesn't even cover many of the things I use every day (PDL, Gimp, CPAN, Parse, Time, MLDBM, etc.) as well as modules that ship with Perl (threads, strict, IO, Storable, etc.)
Man, I just love CPAN.... imagine your joy when it's all available to you in whatever language you please through Parrot!
that's sort of an uncharitable assessment of the stewards of the java servlet api and reference implementation, isn't it?
No, it's an uncharitable assessment of Sun's treatment of them.
Bottom line: there are 6752 modules on CPAN. I invite you to tour them and evaluate the quality of documentation relative to that available for all of the Java stuff... it's a stark contrast the depth and clarity that you get when you don't force people into a box. If you don't see the box, that's cool... carry on.
I've never come across any example of what you describe. I've certainly seen people relying on bugs or "features" that crept in by accident, but the same is true for gcc. I've never seen real Perl functionality that isn't in the docs... at least not in a production release.
What's more is Perl has a history of slapping people down for relying on such things by deprecating them and then removing them (e.g. the recent discovery that some people were relying on "my $foo = 1 if 0" to behave like a static initializer!
Rely on anything that's not documented in the perl documentation, and you WILL get burned.
"You couldn't write a compatible perl implementation using just the manual pages"
That's both true and false. I would consider any program which implemented everything that was in the Perl documentation to be "compatible" (you have to understand what a behemoth undertaking that would be...), but Perl has never had a formal specification, and as such... just like every other language for which that's the case... there is a great body of code that relies on bugs, undocumented features and other implementation-specific aspects of the reference implementation. Your compiler would be "compatible" with Perl, but not with perl (note caps) and so would be of use only to those who were willing to test against it or modify existing code to work with it.
Perl 6 is evolving a complete specification to address that among other concerns, but... what exactly were YOU trying to solve for? Did you want to write a Perl 5 compiler, or were you just looking for something to complain about?
Perl 5 DOES do what you asked... it docuements (perlop, perlref, perlsyn, etc) all the way down to the gory details of the C implementation (perlguts, perlapi, overload, etc) what happens when you $a=$b+$c so I don't see what the problem is.
you mean like "man ls"? i thought we were creating documentation websites...
Sure that too, or PDFs or command-line extraction form installed modules or whatever. There should be no difference. Docs are docs, and it should all come from the same source, no?
Me: Javadoc is not just simple text[...] You: could you explain further[...]
Sure, here's an example from the Javadoc site:
/**
* A class representing a window on the screen.
* For example:
* <pre>
* Window win = new Window(parent);
* win.show();
* </pre>
*
* @author Sami Shaio
* @version %I%, %G%
* @see java.awt.BaseWindow
* @see java.awt.Button
*/
Ok, start with the fact that there's embedded HTML. Mistake. HTML makes it bulky to write docs. HTML is also not abstract enough to easily convert into, say, TeX or PS without a full rendering engine to get it right.
Second, it's not free-form, so my doc might not fit into the Way that Javadoc wants me to approach such things.
Let's look at POD for roughly the same thing (I am going to start at an odd place because the above was just a snippit of a presumably complete document):
=item Window
A class representing a window on the screen. for example:
Window win = new Window(parent);
win.show();
Ok, now you might have at the bottom of that document:=head1 AUTHOR
Sami Shaio
=head1 VERSION
$Id$
=head1 SEE ALSO
L, L
=cutAre you seeing the differences here? Free-form to accomodate the vast array of needs, high level of abstraction from both the content AND the medium for ease of translation to just about any format (Perl ships with translators to nroff/man, HTML, LaTeX, and plain text but there are dozens of other converters out there).
This difference suffuses the Java and Perl mindsets. Java has its own way of doing things and doesn't need to bow to local system standards. Perl finds a way to do its own thing in powerful ways while also adapting to the local culture.
You also mentioned Jakarta, which while very cool, is a sort of rebelious subculture within the whole of the Java community. I would point you back at Jakarta for an example of how the model that Perl, Python, Ruby and many others follow has been forced upon Sun's Java community because it's the right solution.
Again, I want it to be clear: I respect Java, the JVM and Java's documention. It's just that I feel there's even better tools available (and no reason you can't document your Java code using POD!)
Furthermore, the Java VM instruction set is easily flexible enough to support other programming languages, although the VM performs some safety checks that might make things like out-of-bound memory references hard (not that you'd want to). Computationally, it's complete.
vi is computationally complete (in the turing machine sense), but that doesn't mean it's the right platofrom on which do develop code in a certain style. Java's VM is aimed at running Java, and that means that doing MI, deferred finalization and many other things that are commonplace in modern programming techniques require bulky emulation in the JVM. In Parrot, you will be able to choose your programming paradigm to a much larger extent. Its stack management is also much more condusive to implementing a wide variety of exception-handling techniques.
When you have to drop down a level and write code in Parrot (and you will sometimes, mostly in order to interface to C without imposing any given language's calling convention overhead), I guarantee it will be a night-and-day difference from suffering through interaction with the JVM directly.
As for your other points:
being widespread -- matter of time. Parrot is pre-release right now, so of course that's true, but if all of the Perl installations in the world upgrade to Perl 6/Ponie/Parrot in the next 10 years, then I think you'll see more Parrot than JVM in the world.
machine-specific optimizations -- The JIT for Parrot is pretty damn good about being portable to multiple platforms and yet hand-tunable, so I don't think that'll be a problem for more than 6 months to a year while people discover what sort of optimizations they need.
The JVM was a great step forward and really changed people's minds about how efficient a virtual machine could be. That's a good thing, but it also had some serious design limitations that CLR and Parrot are addressing.
"have you not seen Javadoc? it does precisely what you describe"
And yet the vast majority of Perl programs and modules I run into are faithfully documented in detail while the same is not true for most of the Java that I've tried to use (I will note that that's not NEARLY as much as I've been exposed to Perl over the last 13 years).
As far as I can tell this is because:
1. Javadoc isn't well suited to man-pages 2. Javadoc is NOT just simple text with occasional markup 3. Java doesn't have a strong culture of collaborative development communities which lead to good documentation
I guess, in short, it's just a cultural difference compounded by some unfortunate design choices.
Still, it's good that Java has something. Most languages don't.
"I realize that Perl is a good glue but not very "industrial"."
You're wrong, but that was kind of my point. You've learned a sort of pigeon dialect of Perl and THAT is not "industrial" (whatever industrial means)... I assure you that Perl is as robust a language for small and VERY large-sclae projects as any other once you really understand it.
One of Perl's greatest strengths AND weaknesses however is that people who don't know the language that well can write a hell of a lot of working code in it. Compare this to C++ where your code will break A LOT until you really understand the language, and you begin to see why Perl gets a rep as a toy language. It's a poor craftsman, however, who blames his tools, and just as you would expect someone who only knows the basics of carpentry to misuse a hammer in building a house, so too you expect someone who only knows the basics of Perl programming to misuse THAT tool.
"It's fun and all but when i look at the Rexx coder across the room, i wonder if Perl will not eventually end like Rexx, something mostly useless & readable only to old timers..."
Rexx is a great systems toolish language, but it was proprietary and fairly platform bound. Its failing was not that it was "fun".
"And all the Perl 6 fuss with smart ass names (apocalypse, exegesis, jeez...) isn't going to make me feel more confident about it !!"
I'm sorry that those names make you uncomfortable, but I assure you that Larry (who is a linquist by training) does not use words lightly, and he means exactly what he says. To quote from A1:
"People get scared when they hear the word Apocalypse, but here I mean it in the good sense: a Revealing."
-Larry Wall, Perl 6 Apocalypse 1
I think you need to actually look at Perl 6, and not just at your preconceptions about the names of the specification documents. Look at the code in the languages/perl6 subdirectory of the Parrot distribution. That gets you some good grounding in where Perl 6 is going and where it's remaining the language that you have found "fun" all along.
More to the point (though you're right ichimunki), those essays exist in clear, well-written form as "perlref", "perlsyn", and many other "man pages" (actually POD documents which get turned into man pages by pod2man) which are all described in the "perl" man page which serves as an introduction and table of contents for the rest of the core docs.
Very few people will ever learn Perl 6, just as very few learned Perl 5. What they will do is absorb the basics of the language from examples they've seen an write a basic subset. This is what happens to all languages.
The good things about Perl 6 are a) you have a rich and powerful language at your disposal that provides everything from dynamic grammar construction to advanced functional programming concepts and b) parrot will allow you to use libraries written in any other Parrot client-language.
Documentation is far and away the thing that sets Perl apart from other languages. There are some bad things you can say about Perl's documentation, but most of them are criticisms that you can't even begin to make of other programming languages because they simply aren't in the same ballpark.
I blame POD for this. POD is just a simple set of markup controls you can add to a plain text document to make it easy to translate it into other documentation and markup formats. It's so simple in fact that there's really no mental hurdles to sitting down and writting the docs for your program, module, language feature, etc., and so people do! Just about every peice of code uploaded to CPAN has a full suite of documentation for every module it provides for this reason. What's more, you can type "perldoc Foo" on any system with the "Foo" module installed and get a copy of that documentation ready at your fingertips.
I even use Pod at work. it's an easy format to teach to people, and what could be simpler than writing a simple text file documenting a procedure you want people to follow. Then it's automatically turned into HTML and added to our internal Web site. Would that the rest of my job was that easy...
No one is joking on the Parrot side. Check out the Pie-Thon
Parrot will run Python before it runs Perl, *that* should demonstrate how commited Parrot is to not just being Perl 6's back-end.
You'll be able to create a class in Python as a sub-class of a Perl 6 class which further derives from a Ruby class, and then call a method on such an object which is defined all the way up in Ruby.... no problemo. Parrot is going to change the way we choose programming languages for the tasks at hand....
Yep, all good stuff. I respect Java quite a lot, though I don't enjoy programming in it.
I look forward to the Java port to Parrot for many reasons, not the least of which is being able to provide all of CPAN (or CP6AN or whatever we end up calling it) to Java, Python, Ruby, Scheme, etc., etc.
Imagine being able to grab a piddle from PDL (Perl Data Language), sub-class it in Java to add some interesting network abstraction, and then pass it to a Python class that someone else wrote. No more choosing the language for anything other than your personal preferences for semantics, grammar and syntax. Total programming freedom....
I thought this sounded like a rather unrealistic pipe-dream until I went to a talk by Parrot's author. Dan made it clear that he wasn't interested in just producing Perl 6's back-end and demonstrated in fairly amazing detail how he felt it could be accomplished.
From looking at the source, and having tested it out a bit, I'd say he's about 2/3 of the way there (that is: to producing a viable 1.0 release that accomplishes is basic goals). There's a LOT of work to do, but it's now at the stage where I feel he's to be taken seriously. The Pie-Thon should show us clearly how much we can really expect from Parrot.... I'm pretty psyched about OSCON this year, for that very reason.
I have nothing against Guido, but if he has to take a pie in the face to demonstrate the power of Parrot to the world, I'm happy to see him get creamed;-) Dan has made some very interesting comments about Guido's confidence including,
"
Parrot is an order of magnitude faster than perl 5 doing equivalent things. Without enabling any extraordinary measures.
You know how Python's performance rates against Perl 5.
There's several probelms with that theory. First off, the Java VM is designed to run Java and not much else. This means that if you want to write JAVA, but in and assembly-like way you're all set. Parrot by contrast is designed to run any dynamically typed programming language, so you can write whatever you like for it.
Also, the JVM is not really a very good development environment. It is, for the most part, only used as a back-end. Parrot is designed from the beginning to be programmed in because there will be many times that it makes sense for a library to target Parrot with chunks in C for performance reasons.
To this end Parrot provides a paper-thin abstraction called IMCC which allows you to write code without having to worry about register spilling, etc.
Give Parrot a try, and when you have I guarantee playing with stone knives and bear-skins won't seem nearly so appealing anymore.
Second, he posted (as you can see from the link above) a full outline of Perl 6's specifications-to-be and explained that he's been spending a lot of time on A12. That's right, he's skipping over A7 (delegated to Damian) and A8-A11 (which he'll return to later) and doing the chapter on objects. This is an important part of the language, and really did need to be covered before the rest could be fleshed out. It seems that he expects most of the rest of the spec to be about as much work as A12 is alone, and he claims that's just a few days or weeks at most away from being finished.
That said, keep in mind that the cryptic things you see on p6l are the result of reading code snippits written in a language that doesn't exist yet. Every time Larry steps in and explains things, the picture gets a bit clearer (partly because Larry is a great communicator but partly because he's quite capable of and willing to cut away a lot of noise and render some signal from its remains).
Perl 6 is, as far as I can tell a lovely evolution of Perl... it's perhaps more orders of magnitude more evolved than I would have suggested as the next step, but looking at the good work it has resulted in for Parrot, I'm not sure I'd turn back.
It doesn't seem to destroy anything for me... first off, most of them fall dead against my SPF milter; then many are tagged and bagged by SpamAssassin (which doesn't really look for viruses, but catches many anyway; and then the ones that I get don't seem to do anything when I run the Linux version of unzip on then... sigh, I've been left out:-(
No, IMAP is just for message storage [...] If you want to share [...] address books, you need to use something else [...]
If you want a single 'client' at all locations, you probably want to use webmail.
Or you could use evolution, which solves this all quite nicely by speaking to all of the various protocols involved and presenting a single UI (which, while highly derivative of Outlook, improves on it in a huge number of very helpful ways).
Evolution can also talk to unified groupware suites such as Exchange (via Ximian's proprietary connector) or to Open Exchange (SuSE provides a connector). You can also write your own connector for whatever groupware suite you like.
1) Manages many remote or local mailboxes seamlessly 2) Talks just about every popular protocol 3) Doesn't rely on someone's web site working 4) Has an off-line mode that works great 5) Can dice multiple remote mailboxes into "virtual mailboxes" that aggregate them in various ways WITHOUT moving the mail 6) Has a great inline spellchecker (most things do these days, but worth mentioning) 7) Really fast 8) Super-easy-to-use global searching 9) Can CC outbound mail to a local or remote folder of your choosing 10) Can virtualize remote folders other than INBOX if you need 11) And just to stress: virtual mailboxes are ESSENTIAL (I actually liked the implementation in Emacs' VM better, but Emacs has its own problems).
Probably. I ran into Taco at Geek Pride in Boston way back when Slashdot had just been sold to Andover and I asked him why Slashdot didn't have a spell-checker. At first he thought I was complaining about his spelling, but when I explained that *I* wanted a spell checker for my own postings, he just kind of shrugged verbally.
I've written a spell-checker for the web, it's not that hard. When Slashdot has one, then I'll hang my head in shame at such typos. Until then, feel free to point things like this out, but ain't no way I'm gonna cut-and-paste postings to Slashdot between my browser and something with a spell-checker. Just not worth my time.
Well, to be fair, Firefly got half a season where the other two you mentioned went quite a lot longer. Family Guy got 3 seasons and Futurama a full 5! Getting pulled off the air after 5 seasons may be dissapointing to fans, but it's a good run by any realistic measure, and most shows don't go 3 seasons for that matter.
EvA was wildly different. In that, the media companies were saying, "look, you've given us extensions for a long time now, and Eldred just wants to come along and rip the rug out from under us! We're not prepared for the massive damage this would do to our current IP!"
Database firms on the other hand could say, "we would like this new feature even though it's not something that the framers ever envisioned or wanted and has never been provided in the history of copyright law... it's just nifty for us, though."
Yeah, right. The Supreme Court can be swayed by commercial interest in so far as it might have significant impact, but not when someone just wants a new shiny thing.
Slashdot Mirror
Well, let's look at those:
With 23061, the docs are pretty darned clear:When a constant is used in an expression, perl replaces it with its value at compile time, and may then optimize the expression further.It doesn't get a whole lot simpler than that. Granted, there is some wiggle-room left, but the perimeter of that wiggle room is clearly defined, and below that (just as below the definition of much of C's setjmp and longjmp) you enter implementation-specific regions.
It is certainly reasonable to submit enhancement requests around such things if you think perl is implementing Perl in a way that is counter-intutive, but any program that implemented the spec according to the documentation above would be conformant.
As for #23140 you are complaining that something that behaves EXACTLY as documented is not the way you want it. I understand that, but the documentation is clear on what happens to $1..$9 when you enter a new regex...
It seems like you're saying that because there are well documented edge-cases that can be confusing to programmers that the implementation and the documentation aren't in sync. I would disagree strongly with that assessment.
Mind you, I'm not disagreeing with your assertions in either of those bugs (I haven't thought either one through enough yet), but you seem to be upset about something that isn't quite the content of your bug report....
there's less obfuscation possible in java syntax
That's just wrong. Plain wrong. Unless you can show me at least a casual proof of that, I'm going to assume you just don't know what you're talking about.
Of course, if you just mean "I think Perl syntax is ugly," that's your perogative, but don't go stating it as fact, much less as a fact regarding what is or is not possible. You could argue that certain aspects of context-aware lexical transition in and out of quote-like operators constitute a degree of semantic obfuscation and build from there, but that's such a small aspect of the language that it's really not worth quibbling over, and certainly not the basis for such a broad assertion on your part.
Other than that we seem to have come down to differneces in taste and personal experience. Like I said... carry on.
Sounds cool. I think there was something like that for pod at one point too. I suspect it was abandoned because Perl already has a comprehensive build and test system and integrating the unit testing with the POD documentation would have meant removing a lot of the flexibility of the testing system or inserting a lot of hair into the POD documentation (thus defeating it as Plain Old Documentation).
I can see the merits of both approaches. Good to see There's More Than One Way To Do It...
Ok, so I dug some more and I believe that number now. Here's a summary of the most popular top-level namespaces in which many of these modules live:And the stunning thing is that that doesn't even cover many of the things I use every day (PDL, Gimp, CPAN, Parse, Time, MLDBM, etc.) as well as modules that ship with Perl (threads, strict, IO, Storable, etc.)
Man, I just love CPAN.... imagine your joy when it's all available to you in whatever language you please through Parrot!
that's sort of an uncharitable assessment of the stewards of the java servlet api and reference implementation, isn't it?
No, it's an uncharitable assessment of Sun's treatment of them.
Bottom line: there are 6752 modules on CPAN. I invite you to tour them and evaluate the quality of documentation relative to that available for all of the Java stuff... it's a stark contrast the depth and clarity that you get when you don't force people into a box. If you don't see the box, that's cool... carry on.
I've never come across any example of what you describe. I've certainly seen people relying on bugs or "features" that crept in by accident, but the same is true for gcc. I've never seen real Perl functionality that isn't in the docs... at least not in a production release.
What's more is Perl has a history of slapping people down for relying on such things by deprecating them and then removing them (e.g. the recent discovery that some people were relying on "my $foo = 1 if 0" to behave like a static initializer!
Rely on anything that's not documented in the perl documentation, and you WILL get burned.
"You couldn't write a compatible perl implementation using just the manual pages"
That's both true and false. I would consider any program which implemented everything that was in the Perl documentation to be "compatible" (you have to understand what a behemoth undertaking that would be...), but Perl has never had a formal specification, and as such... just like every other language for which that's the case... there is a great body of code that relies on bugs, undocumented features and other implementation-specific aspects of the reference implementation. Your compiler would be "compatible" with Perl, but not with perl (note caps) and so would be of use only to those who were willing to test against it or modify existing code to work with it.
Perl 6 is evolving a complete specification to address that among other concerns, but... what exactly were YOU trying to solve for? Did you want to write a Perl 5 compiler, or were you just looking for something to complain about?
Perl 5 DOES do what you asked... it docuements (perlop, perlref, perlsyn, etc) all the way down to the gory details of the C implementation (perlguts, perlapi, overload, etc) what happens when you $a=$b+$c so I don't see what the problem is.
Sure that too, or PDFs or command-line extraction form installed modules or whatever. There should be no difference. Docs are docs, and it should all come from the same source, no?
Me: Javadoc is not just simple text[...]
You: could you explain further[...]
Sure, here's an example from the Javadoc site:Ok, start with the fact that there's embedded HTML. Mistake. HTML makes it bulky to write docs. HTML is also not abstract enough to easily convert into, say, TeX or PS without a full rendering engine to get it right.
Second, it's not free-form, so my doc might not fit into the Way that Javadoc wants me to approach such things.
Let's look at POD for roughly the same thing (I am going to start at an odd place because the above was just a snippit of a presumably complete document):Ok, now you might have at the bottom of that document:=head1 AUTHOR
Sami Shaio
=head1 VERSION
$Id$
=head1 SEE ALSO
L, L
=cutAre you seeing the differences here? Free-form to accomodate the vast array of needs, high level of abstraction from both the content AND the medium for ease of translation to just about any format (Perl ships with translators to nroff/man, HTML, LaTeX, and plain text but there are dozens of other converters out there).
This difference suffuses the Java and Perl mindsets. Java has its own way of doing things and doesn't need to bow to local system standards. Perl finds a way to do its own thing in powerful ways while also adapting to the local culture.
You also mentioned Jakarta, which while very cool, is a sort of rebelious subculture within the whole of the Java community. I would point you back at Jakarta for an example of how the model that Perl, Python, Ruby and many others follow has been forced upon Sun's Java community because it's the right solution.
Again, I want it to be clear: I respect Java, the JVM and Java's documention. It's just that I feel there's even better tools available (and no reason you can't document your Java code using POD!)
Furthermore, the Java VM instruction set is easily flexible enough to support other programming languages, although the VM performs some safety checks that might make things like out-of-bound memory references hard (not that you'd want to). Computationally, it's complete.
vi is computationally complete (in the turing machine sense), but that doesn't mean it's the right platofrom on which do develop code in a certain style. Java's VM is aimed at running Java, and that means that doing MI, deferred finalization and many other things that are commonplace in modern programming techniques require bulky emulation in the JVM. In Parrot, you will be able to choose your programming paradigm to a much larger extent. Its stack management is also much more condusive to implementing a wide variety of exception-handling techniques.
When you have to drop down a level and write code in Parrot (and you will sometimes, mostly in order to interface to C without imposing any given language's calling convention overhead), I guarantee it will be a night-and-day difference from suffering through interaction with the JVM directly.
As for your other points:
being widespread -- matter of time. Parrot is pre-release right now, so of course that's true, but if all of the Perl installations in the world upgrade to Perl 6/Ponie/Parrot in the next 10 years, then I think you'll see more Parrot than JVM in the world.
machine-specific optimizations -- The JIT for Parrot is pretty damn good about being portable to multiple platforms and yet hand-tunable, so I don't think that'll be a problem for more than 6 months to a year while people discover what sort of optimizations they need.
The JVM was a great step forward and really changed people's minds about how efficient a virtual machine could be. That's a good thing, but it also had some serious design limitations that CLR and Parrot are addressing.
"have you not seen Javadoc? it does precisely what you describe"
And yet the vast majority of Perl programs and modules I run into are faithfully documented in detail while the same is not true for most of the Java that I've tried to use (I will note that that's not NEARLY as much as I've been exposed to Perl over the last 13 years).
As far as I can tell this is because:
1. Javadoc isn't well suited to man-pages
2. Javadoc is NOT just simple text with occasional markup
3. Java doesn't have a strong culture of collaborative development communities which lead to good documentation
I guess, in short, it's just a cultural difference compounded by some unfortunate design choices.
Still, it's good that Java has something. Most languages don't.
You're wrong, but that was kind of my point. You've learned a sort of pigeon dialect of Perl and THAT is not "industrial" (whatever industrial means)... I assure you that Perl is as robust a language for small and VERY large-sclae projects as any other once you really understand it.
One of Perl's greatest strengths AND weaknesses however is that people who don't know the language that well can write a hell of a lot of working code in it. Compare this to C++ where your code will break A LOT until you really understand the language, and you begin to see why Perl gets a rep as a toy language. It's a poor craftsman, however, who blames his tools, and just as you would expect someone who only knows the basics of carpentry to misuse a hammer in building a house, so too you expect someone who only knows the basics of Perl programming to misuse THAT tool.
"It's fun and all but when i look at the Rexx coder across the room, i wonder if Perl will not eventually end like Rexx, something mostly useless & readable only to old timers..."
Rexx is a great systems toolish language, but it was proprietary and fairly platform bound. Its failing was not that it was "fun".
"And all the Perl 6 fuss with smart ass names (apocalypse, exegesis, jeez
I'm sorry that those names make you uncomfortable, but I assure you that Larry (who is a linquist by training) does not use words lightly, and he means exactly what he says. To quote from A1:I think you need to actually look at Perl 6, and not just at your preconceptions about the names of the specification documents. Look at the code in the languages/perl6 subdirectory of the Parrot distribution. That gets you some good grounding in where Perl 6 is going and where it's remaining the language that you have found "fun" all along.
More to the point (though you're right ichimunki), those essays exist in clear, well-written form as "perlref", "perlsyn", and many other "man pages" (actually POD documents which get turned into man pages by pod2man) which are all described in the "perl" man page which serves as an introduction and table of contents for the rest of the core docs.
Very few people will ever learn Perl 6, just as very few learned Perl 5. What they will do is absorb the basics of the language from examples they've seen an write a basic subset. This is what happens to all languages.
The good things about Perl 6 are a) you have a rich and powerful language at your disposal that provides everything from dynamic grammar construction to advanced functional programming concepts and b) parrot will allow you to use libraries written in any other Parrot client-language.
Documentation is far and away the thing that sets Perl apart from other languages. There are some bad things you can say about Perl's documentation, but most of them are criticisms that you can't even begin to make of other programming languages because they simply aren't in the same ballpark.
I blame POD for this. POD is just a simple set of markup controls you can add to a plain text document to make it easy to translate it into other documentation and markup formats. It's so simple in fact that there's really no mental hurdles to sitting down and writting the docs for your program, module, language feature, etc., and so people do! Just about every peice of code uploaded to CPAN has a full suite of documentation for every module it provides for this reason. What's more, you can type "perldoc Foo" on any system with the "Foo" module installed and get a copy of that documentation ready at your fingertips.
I even use Pod at work. it's an easy format to teach to people, and what could be simpler than writing a simple text file documenting a procedure you want people to follow. Then it's automatically turned into HTML and added to our internal Web site. Would that the rest of my job was that easy...
No one is joking on the Parrot side. Check out the Pie-Thon
Parrot will run Python before it runs Perl, *that* should demonstrate how commited Parrot is to not just being Perl 6's back-end.
You'll be able to create a class in Python as a sub-class of a Perl 6 class which further derives from a Ruby class, and then call a method on such an object which is defined all the way up in Ruby.... no problemo. Parrot is going to change the way we choose programming languages for the tasks at hand....
I look forward to the Java port to Parrot for many reasons, not the least of which is being able to provide all of CPAN (or CP6AN or whatever we end up calling it) to Java, Python, Ruby, Scheme, etc., etc.
Imagine being able to grab a piddle from PDL (Perl Data Language), sub-class it in Java to add some interesting network abstraction, and then pass it to a Python class that someone else wrote. No more choosing the language for anything other than your personal preferences for semantics, grammar and syntax. Total programming freedom....
I thought this sounded like a rather unrealistic pipe-dream until I went to a talk by Parrot's author. Dan made it clear that he wasn't interested in just producing Perl 6's back-end and demonstrated in fairly amazing detail how he felt it could be accomplished.
From looking at the source, and having tested it out a bit, I'd say he's about 2/3 of the way there (that is: to producing a viable 1.0 release that accomplishes is basic goals). There's a LOT of work to do, but it's now at the stage where I feel he's to be taken seriously. The Pie-Thon should show us clearly how much we can really expect from Parrot.... I'm pretty psyched about OSCON this year, for that very reason.
I have nothing against Guido, but if he has to take a pie in the face to demonstrate the power of Parrot to the world, I'm happy to see him get creamed
There's several probelms with that theory. First off, the Java VM is designed to run Java and not much else. This means that if you want to write JAVA, but in and assembly-like way you're all set. Parrot by contrast is designed to run any dynamically typed programming language, so you can write whatever you like for it.
Also, the JVM is not really a very good development environment. It is, for the most part, only used as a back-end. Parrot is designed from the beginning to be programmed in because there will be many times that it makes sense for a library to target Parrot with chunks in C for performance reasons.
To this end Parrot provides a paper-thin abstraction called IMCC which allows you to write code without having to worry about register spilling, etc.
Give Parrot a try, and when you have I guarantee playing with stone knives and bear-skins won't seem nearly so appealing anymore.
I asked the same thing recently on the p6l mailing list. Larry responded with some interesting news. First off, I had not realized that he had taken a lot of time off last year for health reasons.
Second, he posted (as you can see from the link above) a full outline of Perl 6's specifications-to-be and explained that he's been spending a lot of time on A12. That's right, he's skipping over A7 (delegated to Damian) and A8-A11 (which he'll return to later) and doing the chapter on objects. This is an important part of the language, and really did need to be covered before the rest could be fleshed out. It seems that he expects most of the rest of the spec to be about as much work as A12 is alone, and he claims that's just a few days or weeks at most away from being finished.
That said, keep in mind that the cryptic things you see on p6l are the result of reading code snippits written in a language that doesn't exist yet. Every time Larry steps in and explains things, the picture gets a bit clearer (partly because Larry is a great communicator but partly because he's quite capable of and willing to cut away a lot of noise and render some signal from its remains).
Perl 6 is, as far as I can tell a lovely evolution of Perl... it's perhaps more orders of magnitude more evolved than I would have suggested as the next step, but looking at the good work it has resulted in for Parrot, I'm not sure I'd turn back.
It doesn't seem to destroy anything for me... first off, most of them fall dead against my SPF milter; then many are tagged and bagged by SpamAssassin (which doesn't really look for viruses, but catches many anyway; and then the ones that I get don't seem to do anything when I run the Linux version of unzip on then... sigh, I've been left out :-(
No, IMAP is just for message storage [...] If you want to share [...] address books, you need to use something else [...]
If you want a single 'client' at all locations, you probably want to use webmail.
Or you could use evolution, which solves this all quite nicely by speaking to all of the various protocols involved and presenting a single UI (which, while highly derivative of Outlook, improves on it in a huge number of very helpful ways).
Evolution can also talk to unified groupware suites such as Exchange (via Ximian's proprietary connector) or to Open Exchange (SuSE provides a connector). You can also write your own connector for whatever groupware suite you like.
Try out evolution...
1) Manages many remote or local mailboxes seamlessly
2) Talks just about every popular protocol
3) Doesn't rely on someone's web site working
4) Has an off-line mode that works great
5) Can dice multiple remote mailboxes into "virtual mailboxes" that aggregate them in various ways WITHOUT moving the mail
6) Has a great inline spellchecker (most things do these days, but worth mentioning)
7) Really fast
8) Super-easy-to-use global searching
9) Can CC outbound mail to a local or remote folder of your choosing
10) Can virtualize remote folders other than INBOX if you need
11) And just to stress: virtual mailboxes are ESSENTIAL (I actually liked the implementation in Emacs' VM better, but Emacs has its own problems).
Did you mean "Amnesia"?
Probably. I ran into Taco at Geek Pride in Boston way back when Slashdot had just been sold to Andover and I asked him why Slashdot didn't have a spell-checker. At first he thought I was complaining about his spelling, but when I explained that *I* wanted a spell checker for my own postings, he just kind of shrugged verbally.
I've written a spell-checker for the web, it's not that hard. When Slashdot has one, then I'll hang my head in shame at such typos. Until then, feel free to point things like this out, but ain't no way I'm gonna cut-and-paste postings to Slashdot between my browser and something with a spell-checker. Just not worth my time.
Well, to be fair, Firefly got half a season where the other two you mentioned went quite a lot longer. Family Guy got 3 seasons and Futurama a full 5! Getting pulled off the air after 5 seasons may be dissapointing to fans, but it's a good run by any realistic measure, and most shows don't go 3 seasons for that matter.
EvA was wildly different. In that, the media companies were saying, "look, you've given us extensions for a long time now, and Eldred just wants to come along and rip the rug out from under us! We're not prepared for the massive damage this would do to our current IP!"
Database firms on the other hand could say, "we would like this new feature even though it's not something that the framers ever envisioned or wanted and has never been provided in the history of copyright law... it's just nifty for us, though."
Yeah, right. The Supreme Court can be swayed by commercial interest in so far as it might have significant impact, but not when someone just wants a new shiny thing.
I'm beginning to wonder in all this... does SCO own part of Groklaw? Why else would they be feeding them such juicy stories all the time?! ;-)