Slashdot Mirror
Apocalypse 3
rob_99 writes: "The third installment of the Apocalypse is out!" You may have missed the first or second Apocalypses. This one is roughly "all about operators".
← Back to Stories (view on slashdot.org)
← Back to Stories (view on slashdot.org)
"Breaking out of your culture is also important, because that is how we understand other cultures. As an explicitly multicultural language, Perl has generally done OK in this area, though we can always do better. Examples of cross-cultural exchange among computer cultures include XML and Unicode. (Not surprisingly, these features also enable better cross-cultural exchange among human cultures -- we sincerely hope.)"
It is for statements like this, that I am drawn into studying and using Perl. Many designers try to design a langauge which develops its own internal culture; it becomes static and internally consistent, but not very adventurous. Larry Wall seeks to develop a language which has built-in the fact that we like to explore, making his task more difficult, but a language which moves and flows with the evolution of our culture readily.
Keep up the great work!
information is immaterial
Perl gets around some of these problems by keeping track of whether it is expecting an operator or a term. As it happens, a unary operator is simply one that occurs when Perl is expecting a term. So Perl could keep track of a unary = operator, even if the human programmer might be confused.
This seems to be a seriously smart way to do sytax checking. Is this drawn from an existing implementation in a different language or is it a new development that he thought up?
Speaking from my own experience as a non-developer coder, I'd love to see more of this kind of "artificial" intelligence in programming languages. I really love the power of languages such as c/c++ but keeping track of every possible way I can fsk stuff up is just impossible. I definately think having more checks in place (within reasonable limits) would certainly make for better code all around.
He stresses the importance of good huffman coding, then goes on to change the string concatenation operator "." to a three character sequence " _ "
...instead of:
$a . $b . $c
you'll say:
$a _ $b _ $c
String concatenation is such a commonly used perl feature that it deserves a single character operator. Discriminating between operators by the existence of white space before/after the character is an incredibly ugly kludge. Larry seems to admit it, too: This is to be construed as a feature
At least we don't have to use "+", like in JavaScript!
I never really thought about how valuable perl really is. I use it constantly. I use it based on the syntactic rules set fourth in the cammel book. I never considered evaluating changes to the language (well, not to any great degree anyway. While I find Larry Wall's series of articles interesting, I just can't get excited about changing the language in it's next incarnation. It works. It's an effective tool. That's good enough to me. I'm not saying don't change it, so much as in it's role as a tool I find it valuable, but when given the opportunity to provide feedback on how to change it I'm at a loss.
Now, I consider my job to be 'Intranet Systems Arhitect' as distinct from 'Programmer'. Perhaps that's why I can't get excited about changing a tool I've come to depend on in it's current form. Perhaps true programmers might find the prospect fascinating. perhaps you could liken it to the difference between an army officer and a gunsmith. While both make use of guns at various times, only the gunsmith is inclined to take the gun apart, examine it and make a better one.
Or perhaps I'm just not showing the proper community spirit, and I should dive in and offer my two cents on how to make the language better. Maybe I'm just lazy (then again, isn't that why perl is such a great language...)
--CTH
--Got Lists? | Top 95 Star Wars Line
How perl 6 will fare is another issue. The language is going to change radically - will developers follow Larry into perl 6, just use perl 5 compatibility mode, or move on altogether?
Let's face it, perl is absolutely great for its original intention - fast, easy, write-and-forget scripting. But as I see the plans for Perl 6 unfold, one thought comes to my mind - Yuck. The language they propose is bloated and convoluted beyond words; it's clearly evident that Wall and his fellow "designers" are struggling vainly to make Perl "grow up" -- something that it has absolutely no need to do. There are other languages out there to fill the other niches; languages which try to do everything doom themselves to failure. Ambition kills.
Loneliness is a power that we possess to give or take away forever
And as to perl's infamous illegibility, it's true that the code's readability has a lot to do with the author and only a bit to do with the language. But I'll tell you right now that most of the perl fanatics I've met and all of the perl coders with whom I've worked came to the language from little or no programming experience. This means that nearly all the code I (and they) encountered was written by someone who had, at the time of authorship, only the vaguest of notions about legibility.
Remember, dude, just because you like a particular thing doesn't mean it doesn't have flaws.
Oh, go on, check out my job.
Most of the Perl coders you have experienced might have been bad, but that says nothing about whether Perl is good or bad. If whatever language you prefer suddenly gets an influx of really poor programmers, will you switch?
There once was a hacker named Wall
To maintain his own scripts, his downfall
He released to the world
A wonder named Perl
You can write code, but never recall!
of course perl has such extensive string interpolation and other capabilities that this doesn't strike me as a humongous problem.
I, too, hate the whitespace kludge, but then i've always put whitespace around my dots too because print $this . $that just seems more readable to me than print $this.$that, which looks disturbingly like some kind of slightly funky method call.
"Biped! Good cranial development. Evidently considerable human ancestry."
$a = $b.$c;
print "Hello: ".$you."\n";
becomes
$a = $b _ $c;
print "Hello: " _ $you _ "\n";
It is definitely more readable, but I dislike significant whitespace. shrug
But as to the rest of the proposed changes, I can't wait.
"Avast! Prepare for the rodgering!" THWACK! "Arrr.. me nards.."
'a' + 'b' = 'Ã'
(char and char results in another char by adding their ASCII values)
"a" + 'b' = "ab"
(string and char results in a string by concatenation)
'a' + "b" = "ab"
(char and string -- order does not matter, so see string and char above)
"a" + "b" = "ab"
(string and string results in a string by concatenation)
To summarize, if a string is involved, then the char(s) is (are) promoted up to string(s) and the result depends on concatenation. If all operands are chars, then no promotion occurs and they are added by ASCII value.
This is similar to the numerical addition rules of C, C++, and a number of similar languages. One simple example: If an int and a float are added, the int is promoted to be a float and the result is a float. If an int and an int are added, the result is an int and must by cast (either explicitly or implicitly) in order to be a float value.
I'm not too familiar with Perl, but this seems to be the most sensible behavior. If I'm missing something and there's a valid reason not to use an addition sign for concatenation, please reply and let me know.
-- Imagine how much more advanced our technology would be if we had eight fingers per hand.
Before I begin, I know that Perl is Larry's baby and he can do with it what he likes. But I wouldn't be so vocal about this if I didn't care. ;-) That said...
Maybe it is just me, but the more and more I see what is going on in the perl world, the less and less I want to have anything do with it. The whole
hyper-operator conecpt is a good example. My thoughs? Just use a fscking for loop. That is what they were designed to do. Larry seems to be going through *great* pains to include as many bizzare syntactic short cuts as you can reasonably string characters on the keyboard to represent. This is not terribly innovative.
It's starting to diverge from "Practical extraction and report(ing) language"
and towards "pathetically Eclectic rubbish lister". Personally, I aim a little more towards practical. That was what made it so popular to begin with. Make difficult things easy and hard thing possible was a nice concept. Perl 5 did that well. IMNSHO, Perl 6 seems to be making 100 ways to do the same simple thing all so the developer can opt to use the method with the verbosity level he/she desire, and not making the hard things any easier.
</rant>
--
For example, Haskell parses f 0 + f 1 as: f(0) + f(1) (In a less obvious way, it also parses f g x as f(g, x), but that's another story...)
For all of those people who want to jump ship from perl6, all I can say is I'd give it some time. I've been playing around with the syntax in perl6, and I think people are giving it way too much short shrift, without thinking no less. Here, for example, are a couple of equivalent programs in perl6 and perl5:
// $b // 'default';
Concatenating two arrays together:
perl5
my $biggest_index = (@array1 > @array2)? @array1:
@array2;
for ($index = 0; $index $biggest_index; $index++)
{
$array1[$index] += $array2[$index];
}
perl6:
@array1 ^+= @array2;
Comparing all of the elements in an array to one another for equality:
perl5:
for ($xx = 0; $xx @array1; $xx++)
{
($notequal = 1, last) if ($array1[$xx] ne $array2[$xx]);
}
if (@array1 != @array2)
{
$notequal = 1;
}
else
{
$notequal = 0;
}
Perl6:
$notequal = (@array1 ^!= @array2);
Perl5: setting an element to the first defined item:
my $element = (defined($a))? $a : (defined($b))? $b: 'default';
perl6:
my $element = $a
etc, etc. I could go on, but I'll leave it to damien && his exegesis...
Now, you could argue that things like the above don't belong in the language proper, and that it would be better to write functions to do them, but believe me, there are a hell of a lot of different low level functions that you can write, all with a little wrinkle here or there that makes them *slightly* different from the functions that you've written before - like doing cmp instead of ==, and so on.
So don't bolt before you see the final result.. I think its going to be really cool, especially being built on top of parrot....
Ed
(ps - as for the OO, I'd *also* hold my tongue if I were you. I've used the OO features of perl5 extensively, and its exceedingly flexible. There are aspects that I don't like (like no type checking of attributes as they are in a hash) but even this can be used to your advantage in programming.
so its definitely *not* worthless, and definitely something worth checking into. 50,000 line APIs don't just spring up overnight...
It'll be so great to be able to use expressions like "x y". Of course, you'll have to define for yourself what an eight teardrop-spoked propeller asterisk does...
Hmm... slashdot doesn't seem to like my character. Gonna make it hard to ask about my programs...
In responding to the previous poster my first inclination was to defend my perl programming prowess but instead of descending into such a ridiculous debate of an issue that would only be of interest to my clients and myself, I'll just clarify my point which was more that I have never found anything that I wasn't able to do in perl more easily than I could have done in C and that I wasn't able to find any specific single item in Larry's article that would make my use of perl significantly more convenient or effective. That's not to say that I'm against making changes to perl. If it can be improved, so much the better.
--CTH
--Got Lists? | Top 95 Star Wars Line
Ah, right. Yes, if I do the right thing, *then* slashdot doesn't like my character. Of course (❊) seems to work (maybe), but it's a pain to type decimal character values for unicode characters.
Hey, I was just thinking yesterday that there really oughtta be something like ?= - though I was working with php at the time (which is slowly getting replaced with eperl).