Apocalypse 2
Larry Wall has written the second article in his "Apocalypse" series about Perl6. If you missed the first article, you might want to read that one first, or see the previous discussion.
← Back to Stories (view on slashdot.org)
This is already a valid perl 5.6 program.
Check 'Programming Perl' 3rd Edition, Chapter 15, where a japanese character is used as a variable (you have to 'use utf8;' though.
For the definitive answer on hyphens, see Elements of Style by Strunk and White.
Hint: They only connect words that are all connected by other hyphens. The main thing is to avoid the problem which occurred when the Chattanooga News merged with the Chattanooga Free Press to become the hyphenated Chattanooga News-Free Press.
Eternal vigilance only works if you look in every direction.
No, Kierkegaard was far too interested in philosophy to worry about ports of yet-to-exist scripting languages to yet to exist hardware. In fact, I don't think he owned any sort of PDA or even knew how to program.
I wouldn't want to use any language that has 'begin' and 'end' instead of { and }. Yuck.
-- Ed Avis ed@membled.com
I had pretty much the same reaction. Except not only is $foo\Q[bar] UGLY, it's bloody confusing looking. I've always tried to distance myself from the argument about how much of perl looks like line noise (regexp's anyone?), but this is definitely a step in the WRONG direction for clarity and lack of line noise, despite the apparent planned elimination of $", $[, and their ilk.
7 November 2006: The day Americans realized corruption and incompetence weren't addressing 11 September 2001
I believe apocalypse 1 addressed the point that simple scripts written in perl 5 will be clearly distinguished from perl 6 and treated as perl 5 appropriately. Which means chances are good you'll still be able to use your old coding style just fine. It's unclear as yet how this will handle the elmination/deprecation of things like $", but Larry's done a good job so far of maintaining appropriate backward compatability, so I have no reason to doubt him going forward.
7 November 2006: The day Americans realized corruption and incompetence weren't addressing 11 September 2001
...does the language proposed in this and the previous Apocalypse resemble Ruby very, very strongly?
Panobjectification with common accessor methods, cleaning up a lot of the syntactit warts, new class syntax...
I like it, personally. Ruby is a pretty neat language. And I have no complaints about Perl evolving towards being like it...
-- Veni, vidi, dormivi
There is an article by Bjarne Stroustrup about the future of C++ where he goes overboard on this idea.
I do hope you realize...
B Stroustrup: Generalizing Overloading for C++2000. Overload, Issue 25. April 1, 1998
(If that isn't enough, there's another similar soundingarticle from 92:
B. Stavtrup: Overloading of C++ Whitespace. Journal of Object-Oriented Programming. April 1, 1992.)
What about the difference in comparing scalars as strings ($a eq 'ham') or numbers ($a == 10)? You could argue numeric context already exists in Perl. This just defines it in a more rigorous way.
My guess in the distant future our descendants will see Perl as this cryptic cult of demon worshipers or something.
Umm, hello; isn't that how most people think of Perl hackers already?
So then the syntax construction is not identical between refering to the variable within quotes or without quotes. Gee... that makes sense.
While I don't expect the syntax to be identical I would expect it to be rather similar.
This space for rent. All reasonable inquiries will be entertained at proprietors discretion.
I thought they were talking about multi-level abstractions (for instance the case of an array of a hash of a hash), and not just 'simple' indexing.
:)
In that case I'm not talking about simple indexing and $foo[$bar] but perhaps something like ${${$foo[$bar]}{$foo2}}{$bar2}
While I'm sure there are probably better ways to write this, and while I wouldn't dream of putting a construct like this into quotes (for lots of reasons). I'm not quite sure I like the idea of the braces disapearing for 'clarity' sake. But then I would be fine with a mandatory "No variables in quotes" so I won't claim consistancy.
This space for rent. All reasonable inquiries will be entertained at proprietors discretion.
Perl. Can't live with it, can't live without it.
All I know is, doing decent OO and well modularized code is hateful in Perl. I pray this will be better in Perl 6. Right now, I use plenty of server side java for web stuff, even though CPAN kicks ass over any services you'll find built into Java and I'd rather cast my lot with Larry than with Scott any day. If Perl were a bit straightforward for compartmentalizing large projects, and if mod_perl made any damn sense, I'd use it, because in my experience, mod_perl is much faster than Java, PHP, ASP, more open, better integrated with OS level functions (try setting permissions on files from Java), etc, etc, etc.
I love it, even though I hate it and it enables the ugliest code in history. I still prefer it to Python's shaven tonsure and vow of celibacy. Perl is the whore of Babylon and you love her.
Boss of nothin. Big deal.
Son, go get daddy's hard plastic eyes.
Expanding a vast wasteland since 1996.
-- Abigail
Considering that outside of quotes a variable name followed by left bracket, something else, and a right bracket and it *not* meaning indexing is a syntax error, your wish for the syntax constructs to be the same inside and outside quotes is utterly meaningless.
If you do want to do indexing, then the constructs inside and outside of quotes *are* the same.
-- Abigail
So what? It's only the second article in what is going to be a long list of articles. The focus of this article lied more with syntax than with semantics. The article also counted more occurances of the letters `e' and `t' than of `f' and `z'. Now what does that mean?
-- Abigail
Ruby looks really cool to me too. I've just downloaded it and installed it, and I'm planning to write a few test scripts in it. Since our server doesn't have a heavy load, I'd rather have our CGI's readable, and Ruby seems to be a good way to do it. I just need the time to go through the tutorial...
"I may not have morals, but I have standards."
"I may not have morals, but I have standards."
Hehe, I actually just sat down with Ruby and wrote a basic Hello World program with a class. I'm very impressed! The whole messaging idea (smalltalk, right?) is very very cool. I'm going to keep playing with it this weekend (or right now!!!! Hahahah!!!!) What kind of libraries does Ruby still need? It'd be nice to have it as feature complete as perl. I really like perl as a utility, and it's a fun language to hack, but I'm pretty impressed with Ruby as is.
"I may not have morals, but I have standards."
"I may not have morals, but I have standards."
Nice troll, comparing perl to BASIC and then calling Java a toy language. You obviously don't know fucking shit and haven't taken the time to learn very many languages very deep. Pretty lame. What is the problem that Lisp and Perl are both aproaching?
This Wiki Feeds You TV and Anime - vidwiki.org
That's funny as hell though. I'd never seen that before.
I very much respect Larry Wall and love reading all the stuff he's written about Perl and languages, and how Perl can be this organic evolving thing. It's all very satisfying from a philosophical point of view, but at the end of the day I don't want to have to spend my time trying to figure out which of 20 ways is correct or if in fact they are all equivalent.
Here's another thought. I'll admit that I'm the type of guy who likes to know all the possiblilites and design choices before I do just about anything. That's often not such a good thing, but that's the way I am. So really using Perl takes me a long time because I feel compelled to find out what those 20 different ways are and try to pick the optimum. I'll grant that maybe not everyone is like that. For the guy who is happy just to get something up and working, maybe Perl makes things easier because he's more likely to stumble upon at least one of the 20 ways to do it sooner. So that guy doesn't need to learn the all the ways it can be done, and maybe he gets work done faster (I doubt it though because the volume of documentation he has to wade through will be larger in proportion to the number of ways to do things).
So good for that guy who (maybe) codes faster using Perl. Unfortunately we don't just work with our own code. The minute you start reading other people's code this TMTOWTDI philosophy bites you -- you suddenly have to be able to recognize and understand ALL the ways to do it if you're going to be grabbing code from people who might be using any of these methods. And this sounds like it's going to get even worse in Perl 6 with plug in syntax modules.
Being able to do things your way and create your own style and form in a programming language is great if you work alone, but most of us don't, and can't predict ahead of time exactly where the code we end up having to work with will come from.
This natural language analogy that Larry always preaches is nice, but I think the purposes of natural language and code have some very important differences. We aren't born speaking any particular natural language, but we HAVE to learn to speak what those around us speak at an early age, well before we are able to make any sort of judgement about the quality of the language we are learning. Heck, if I had been able to wait and make an informed decision, I might have chosen to learn French instead of English. But once you've learned one language, unless you change your geograpic location there's little incentive to learn another (before you flame -- je parle un peu de francais, soshite nihongo mo nakanaka tokui desu.) Learning a human language is a necessity and something you do at an early age without really thinking about it.
But computer languages just aren't like that. They are tools for making the computer do stuff and for sharing with others to show them how to make the computer do stuff. Computer languages are designed. Human languages are not. The prime example of an attempt at designing a better human language (esperanto) was pretty much a failure. In contrast most computer languages were heavily designed. C, C++, Java very popular and successful languages, and they were all designed.
I'm definitely rambling now. But my point is that this "let the language evolve" and "let people use it the way they want" and "let people develop their own communities and dialects" philosophy -- this idea of making a computer language with the same properties as a human language -- is not helping make programming easier or make programmers more productive. The head can hold a tremendous amount of ad hoc syntax and grammar, we all know a ton of little bits of trivia about what is correct and what isn't in our native tongue. But most of us who do actually know a second or third human language are keenly aware that our grasp of the subtleties is not as great with those languages we didn't grow up with. Well learning a computer language is ALWAYS going to be like learning a second language (until people start playing Perl tapes to their babies, and Barnie starts singing Perl songs). So why try to mimic the flexible, ad hoc, crazy syntax of a human language when designing a language that is a tool for people to use? Make it simple and easy to remember! Make it so that you can learn it in a weekend. Make it so the person with two days experience in the language can read a program written by someone fluent in it. Human languages are all much more complex than that, but our programming languages have no reason to be.
If you consider that early in the lifetime of a language the majority of programmers have yet to learn it then it is well worth the extra moment of thought from those who pioneered programming in it.
Naturally this is somewhat subjective and it depends on the bug. I'd say "strict" in Perl is well worth the learning effort, considering how many bugs are obviated by it.
Right now I'm addicted to Common Lisp, and one amusing thing I've picked up is that Perl is approaching Common Lisp in functionality. As an example, a few of my favorite things are closures and CLOS, and Perl has closures now. Perl's OO system (please note that I'm not an expert, and I've only used it in passing) isn't as powerful as CLOS (is anything?), but it's certainly free of the constraints of toy systems like Java.
So Perl and Lisp are approaching the same problem from completely opposite directions. Perl has syntactic sugar splattered everywhere, while Lisp basically has (one (type (of syntax))). This is a good thing, because you can have the same power available to you, no matter what your preferences on syntax and platform organization are. I prefer Lisp, but whatever lets you Get Stuff Done...
--
TO BUY A NEW CAR WOULD MAKE YOU SEXUALLY ATTRACTIVE.
Friends don't let friends use multiple inheritance.
Good point. If Larry would round up a few lawyers, he could probably convince a jury that Python is a rip off of his ideas, and then put them out of business. Then, since it's all open source anyway, he could implement Python within Perl. You're really on to something there.
Bingo Foo
---
taken! (by Davidleeroth) Thanks Bingo Foo!
It goes like this: He wants to overload whitespace, but recognizes that sometimes you want implicit whitespace overloading, such as ab==a*b. So, he proposes limiting all variables to one character. This is possible with unicode, he argues.
The article reads more like science fiction by the time you get to the end. 3-d editors, overloading whitespace along all three spatial axes, etc.
The guy is either a comic genius or completely off his rocker.
Bingo Foo
---
taken! (by Davidleeroth) Thanks Bingo Foo!
'Pursue the Good long enough, and the Bad makes you yawn.' This is not a Christian belief, because it excludes the leap of faith Kierkegaard mentioned. The leap of faith means that we believe no matter how much we pursue the Good, we'll never get there. Our minds are finite, and Good is infinite.
Faith, repentance, baptism, and the gift of the Holy Spirit. Anything else is not Christian.
Applauding capitalism is like applauding a pig for finding a truffle. Pigs find truffles by nature. Applauding a pig for speaking proper English, now that would be something worth applauding.
Close-minded Christians are no different than close-minded anything else. The difference is that Christianity provides a reliable tool to overcome close-mindedness. Surely you are not calling Jesus close-minded? He is our example, not our failing, mortal, neighbors, toward whom we are to express love.
LaVey came and went. Houdini has more credibility than him; at least he was honest about his escapism.
information is immaterial
Python enthusiasts drive me away, for some reason. Perl enthusiasts invite. That's why I choose Perl. I don't give a damn bout your pseudo complex namespaces being preempted. Perl is fun.
information is immaterial
Intelligent.
Open minded.
Sorry, I just can't make the connection. If you truely were so open-minded and intelligent, you wouldn't be a christian.
I am those three, and Open Eyed, as well.
Pursue the Good long enough, and the Bad makes you yawn. Let us applaud LaVey's capitalism; he made a living out of packaging 'evil'. To what real end? Did it amount to much when he met the author of Reality, an operating system that still hasn't crashed?
But you are spot-on when you allude to close-minded Christians. Alas, there is no escaping humanity in this life... :-|
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
Please, Larry, just don't make us set up virtual machines and class paths to make use of all the new OO junk that is creeping into Perl.
The next Slashdot story will be ready soon, but subscribers can beat the rush and slashdot the links early!
Ruby lacks some key features. One example is inline data (multiline strings).
Ruby's string handling is inferior to Perl's in other ways, too. It's a nice language in many ways, but it's not really a replacement for Perl.
--
my $¾ = 0.75;
Just think of the time and space we'll be saving by using Han characters!
Karma karma karma karma karmeleon: it comes and goes, it comes and goes.
These first two had some resemblance to sh syntax for dis-ambiguating variable names:
"${foo[bar]}"
"${foo}[bar]"
This is horrid!!!!
"$foo\Q[bar]"
So much for Perl being like a bit of sh, awk and C!
I thought the same thing at first, but then realized it's only in " " strings.
As for reading what you wrote, sorry, but I can still read every perl script I ever wrote. If you can't, you're doing it wrong.
7 November 2006: The day Americans realized corruption and incompetence weren't addressing 11 September 2001
Perl 6 is to Perl as C++ is to C.
I bet Perl 6 is going to take a _loong_ time to catch on, if at all. Larry's taking one of the most complicated language syntaxes / semantics ever devised and piling on even _more_.
my int $pi is constant = 3.14;
my str $goodness!
Weird brackets
::sigh::
Use of brackets to disambiguate
"${foo[bar]}"
from
"${foo}[bar]"
will no longer be supported. Instead, the expression parser will always grab as much as it can, and you can make it quit at a particular point by interpolating a null string, specified by \Q:
"$foo\Q[bar]"
Okay, I'll admit it, I write Perl code.
I like writing perl code.
Why are they taking away something that let things be unambiguous and adding this? How can you provide nested unambiguous clues useing a two chatacter, non bracket combination?
Maybe its time to go learn Python. I can get used to white space indentation. This? I'm not sure.
This space for rent. All reasonable inquiries will be entertained at proprietors discretion.
No, it doesn't. It just makes it easier to query what the context is. But in perl5 you can make objects that behave differently in different context, including numeric context, boolean context, string context, iteration and the five types of dereferencing. Consult the 'overload' manual page.
-- Abigail
Perl's (and Larry's) "There's more than one way to do it" philosophy is fascinating as programming language theory, but when it comes to really designing something remember this: It's actually easier to write a sonnet than to write free verse. This may seem counterintuitive at first -- there are more rules to constrain you when you write a sonnet. It must be harder to do! But wait, if you're going to design something GOOD it's got to have to have some kind of consistent form and organization in the end anyway. If you write free verse you will have to craft that all yourself, choosing from an infinite possibility of ways to organize words. But if you write a sonnet, that's all taken care of: you just concentrate on the CONTENT, on what you want to say.
Larry might argue here that that's all well and good, but people still write plenty of free verse -- its probably more common today than ever, in fact. That may be true, but there's also probably more BAD free verse poetry today than ever as well. And brining this back to code, presumably we're actually talking about getting work done here, not expressing one's deepest feelings or inner angst with subtlety and tenderness. A good poem should be read a dozen times at least, and you'll get something more out of it on each read. A good program should only need to be read once. Subtlety that requires a dozen reads to notice is not a virtue! Going into an unfamiliar program knowing the form and syntax ahead of time just makes it that much easier to decipher.
So good luck to all you Perl poets out there. I wish you luck. But as for me, I think I'm going to check out Python over the summer. It looks like a language that won't force me to keep on thinking about low level design and syntactical form, but instead free me to think about CONTENT.
I also hear it's a pretty good scripting language for 3D apps (e.g. Alice3D and Disney's recent big switch to it.)
No?
--
TO BUY A NEW CAR WOULD MAKE YOU SEXUALLY ATTRACTIVE.
I too am a christian, your comment brought up many things that have been bothering me lately. I suppose the worst side of anything will be the most publicized, but its disturbing that recently the 'bible belt' had gotten so much attention, and is almost synonymous with christianity. As a christian i believe that these people stand against almost everything christianity is about. They spread hatred, fear and force their beliefs upon others, all three of which are said to be wrong in the new testament. Just as bad is that they put more value into the laws which they have imposed than the laws of God. They somehow mistake victorian morallity with christian morality. In doing this they become hypocrites, on the same level as the pharisees, the antagonists of the new testamate.
All I ask is that people understand that this small group does not represent all christians, most of us are intellegent, open minded people who do not agree with the views of the 'bible belt'.
However, it seems that Perl 6 will extend the concept of "context" still further!
So now you can get the wrong thing by expecting a number but accidentally creating a scalar rather than numeric context! You've got to have a new operator, presumably numeric(), to sit next to scalar()!
Will there be a context for every type, built-in and dynmically created, in Perl? Or will the contexts remain a weird wart on the type system?
I don't know what the right solution is, since Perl 6 would barely be Perl at all without the contexts, but moving away from contexts at least would be good.
I could be wrong here. I'm writing this mainly because for the most part I love Perl, and I'd be interested in being persuaded that context is a good thing and worht the potential for confusion, that it's better to have a distinction between
my $line = <FILE>;
my @wholething = <FILE>;
than having
my $line = FILE.line();
my @wholething = FILE.lines();
I think I'm intellectually inclined to feel that Python does most things the right way, but somehow I still find myself reaching for Perl when I need to get the job done...
--
Xenu loves you!
my $¾ = 0.75;
Perl. Can't live with it, Can't live without it.
Someone you trust is one of us.
Here is my one and only request for perl6:
/DECLSPEC.*\s\**([^\s\(]+)\(/ ) {
When running the 'Configure' script, make the questions a little more difficult. This will effectively weed out serious sysadmins and programmers from the newbies.
The perl6 configure script should keep track of the answers to their questions, and grade them on how many questions they've got correct.
Don't know which version of malloc to use??
Do you want to use vfork()? You sure?
NO PERL6 FOR YOU!!
Come on people, if you don't even know the size of the byte boundy on a double, how are you supposed to understand something like:
if (
Post the users name and email address on a public web site and let others view it. Email the results to their family, friends, and employers! Have a special list for those who ctrl-c before it's finished, call it the "chicken" list.
As a Christian, I have to say it's nice that people like Larry are out there to show we're not all stupid bumbling loonies (it's just Sturgeon's Law cropping up again, you know). If you've read any of his writings, especially his "State of the Onion" addresses, you'll see that he manages to present his thoughts and beliefs in a humorous and intelligent way.
Secondly, I really like the way he manages to make analogies between things. The first year he used sounds, the second year he used pictures, and the third year he used smells. And somehow he ends up with a grand scheme that addresses theology, science, computers, and, of course, Perl.
I think this is great, not just because the subject matter is interesting, but because to be any good at programming, you have to be able to map between different systems. The good ones don't seem to be as focused on depth (although they certainly can be; no one can argue that Knuth isn't good, and he's way hardcore) but on breadth of experience. The more different systems you experience, the more you can abstract the particular thing you have to be working on and actually transcend the implementation language and platform. (Or at least that's what I tell myself, being permanently scatterbrained and distractable :)
Anyway, I don't know how to keep this from sounding hopelessly fanboyish, but ummm Larry Wall is cool and learning new stuff is cool, and I recommend that everybody go read his stuff and then go play with something you've never tried before. Exploration is the One True Way to have fun with computers again.
--
TO BUY A NEW CAR WOULD MAKE YOU SEXUALLY ATTRACTIVE.
After playing with it for a while, I think it could be my new favorite language. My Ruby programs usually come out even more concise than Perl, but just as clean looking as Python.
Ruby needs more library support and some optimization work (I usually get about 4X slower than Perl), but I think that is an extremely promising contender in this space.