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".

Comments

Breaking out of your own culture

[Water Paradox]

"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!

Concatenating strings

[seanadams.com]

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!

As I sheepishly back away...

[hillct]

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

don't jump to conclusions:

[Anonymous Coward]

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:

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 // $b // 'default';

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...