>>18,19
Stop trying to tell me what syntax you think looks nicer. It's the same exact thing just more compact.
As long as you still indent that statement there is no problem.
Ugly way of extracting function arguments inherited from shell languages, ugly improvised characters like -> for essential operations, ugly pseudo shortcuts like $_ which most of the time aren't even shorter, $ aka the ugliest ascii character all over the code for no good reason, ugly syntax for class declarations because OO is tacked on etc.
Sigils are especially horrendous with lots of short variable names, e.g., in array based algorithms as seen in this snippet from rosettacode:
sub permute (&@) {
my $code = shift;
my @idx = 0..$#_;
while ( $code->(@_[@idx]) ) {
my $p = $#idx;
--$p while $idx[$p-1] > $idx[$p];
my $q = $p or return;
push @idx, reverse splice @idx, $p;
++$q while $idx[$p-1] > $idx[$q];
@idx[$p-1,$q]=@idx[$q,$p-1];
}
}
If you don't think this is ugly you should have your eyes checked.
>>25
You might want to brush up Perl: ~$ re.pl
$ my $perl;
$ $perl == "ugly";
Argument "ugly" isn't numeric in numeric eq (==) at (eval 271) line 6.
>>25
That example is indeed ugly, on the other hand don't you find it rather odd that all Scottish sheep are black?
Name:
Anonymous2012-01-20 18:45
>>29
There's nothing special about that snippet. It's not like i handpicked it from a code obfuscation contest. All code with lots of short variables looks about equally ugly.
The code was obviously somewhat golfed, and the C version probably reads much the same anyway. On the other hand, if you'd care to prove that it can't be written much more clearly then you can make your point.
>>38
Sure they do. That doesn't have anything to do with Perl though.
Name:
Anonymous2012-01-20 21:32
>>39
Well yes, they look ugly because of sigils. In average perl code maybe 4% of all characters are THE UGLIEST A$$ KEY CHARACTER while in one-letter variable heavy code that number goes up to maybe 20%.
It's also harder to tell $i, $j and $l apart than i,j and l or at least it is for me.
>>40
I once read a very compelling argument that special characters serve to help the readability of code. I didn't want to believe it since I try to avoid scripting languages, but the evidence was fairly strong.
As far as sigils go, all I can say is "deal with it." Ranting about it like you are is just stupid.
I like being able to put the statement of a single statement loop on the same line as the conditional operator, but without parentheses. I like to use as little space as possible on the screen, not for obfuscation but so that more of the code is on screen at any given time.
I personally don't see what's wrong with @, or $ in courier, but in times or arial or whatever the fuck the posts are published as by default they are indeed hideous (because the font itself is hideous to begin with). In fact I rather like how @ and $ look in courier.
And how subjective is the claim of any ascii character being any more or less than another when they vary between fonts? What are you writing in? Verdana? And as if just because you think the character in whatever font you use is the ugliest character known to man, doesn't mean anyone else will feel the same way or care when they don't even use that font or hold your concept of beauty.
Maybe you should make a thread for inventing the most beautiful programming language, >>40.
I don't think the sigils are ugly. And I appreciate the mnemonic of what context a variable is used in when reading someone else's code in particular.
Name:
Anonymous2012-01-21 9:00
>>46
Most of the time if you don't know what a variable holds you must look it up anyway. Just knowing whether it's a list or hash isn't very useful.
Sure, in some rare cases it is, but there's no way that compensates for the loss of readability from cluttering the whole code with dollar signs.
I like to use as little space as possible on the screen, not for obfuscation but so that more of the code is on screen at any given time.
That's exactly why sigils are horrible. They blow up the code for no good reason.