We cannot hide it that Perl code is littered with the $ characters and, compared to the original well rounded Latin letters, that went through the thousands of years of tweaking to please the human eye, compared to them, $ is just an ugly hack. Unfortunately this is what people see when they first look at Perl code - lots of $ signs (by the way @ looks a bit better - maybe we should use more arrays?) - and this is how unconsciously they form the first impression about our language. This is not fair, this is so superficial - but the way the human mind works dictates that this first impression colours every information about Perl that comes later. People don't like to change their minds, and they always will find something to support what they thought initially, even if, or maybe the more so when, that initial thought was just an unconscious impression.
What can we do then? Changing the typeface of $ in the most popular web and editor fonts does not seem like a practical solution, but maybe if we show the sheer shallowness of judging the language by the shape of the typeface of some used character - maybe this would have some impact?
Update: Bear in mind that I don't advocate to get rid of $ in Perl - I find it very useful. The point is that the type face ugliness of $ can project a shadow on the whole language completely independently from it's usefulness as language construct.
Monday, January 10, 2011
Subscribe to:
Post Comments (Atom)
14 comments:
Perl code is only as ugly as you make it.
Personally, I really like the sigils used and find it hard to understand programming languages that don't use such conventions. Perl is only ambiguous where ambiguity makes sense, and unambiguous where ambiguity makes no sense, as opposed to many other languages.
@ido50 - The ugliness of the typeface of the $ character is not something that we could change by writing our programs in a different way and it also does not have anything to do with understanding Perl programs. This really my point - people look at lots of $ and they unconsciously classify the code as ugly - then they shift the meaning of 'ugly' from this pure aesthetics of shapes to the field of 'understanding' code.
Okay, I understand what you mean, and I guess the $ character isn't very pretty, though I don't find it "ugly" in my code, perhaps I'm just used to it.
I like $var makes sense to me, I've said it before though and I'll say it again. I wish $var couldn't be a reference. &var is a function so it can't be that. maybe ^var ? idk, I like sigil's they tell me what things are without looking, except references. Even better 1 for reference ^var and one for object *var or something like that... then I can look at the code and say aha! I know what is. ugly be damned.
If I had to choose one thing, the semicolon would be my pick instead. Python, Ruby, and JavaScript also do not require semicolon between statements if they are already separated with newline. I've accustomized myself writing JavaScript without semicolons, and it does feel somewhat "prettier"/cleaner.
Personally; I consider perl "ugly" due to the "There's more than one way to do it" mantra. More than one way means more flexibility at the cost of readability imo. (Again; at the discretion of the actual coders specific implementation of course)
Can we make sigils less visible color with syntax highlighting in editor or webpage ?
Its the syntax, not the typeface that makes PERL ugly (and rather than "ugly" its "unreadable")
PHP also uses $ and doesn't look nearly as ugly. I think Perl looks ugly because of idiosyncratic syntax and 1-letter commands.
Actually, I think you are correct. It does make a difference, as intellectually silly as that may seem.
For example, I preferred Java over C for many years, because, honestly, C looked 'ugly', and complex. As you may know often C code looks like some giant regular expression code. That made me literally 'turn away' from C.
Many years later, after I realized how simple, and direct C is, it was much nicer to work with. But, I had to gather the experience necessary to see through the typographic ugliness.
Anyway, I'll end my anonymous Internet commenter rant, but I just wanted to say, this read at least, validates your assertion.
I don't think Perl's unwieldiness comes from any piece of syntax in isolation. It's the combination that can makes things look messy. Contrived example:
for (@{ $ONE_THING{$this}{$that} }) {
push @{ $ANOTHER_THING{$_->[0]}{$_->[2]} },
$_->[1];
}
Sure, this code could be cleaned up somewhat, but there's only so much syntax you can remove and get the same semantics.
Even so, I think this problem is blown out of proportion. There are plenty of people using Perl to do lovely things despite its sometimes unescapable ugliness. The ecosystem is alive and well.
To me, the sigils always seem to indicate laziness on the part of the language designer. They seem to say "I couldn't be bothered to parse your code to decide whether you're using a scalar or an array or an array element, so I will make you tell me every time you use a variable how you are using it".
I used Perl for a long time before moving to Python and I have never missed sigils. Also, it is one reason why I moved to Python instead of Ruby.
I'm not sure that changing the glyph of the dollar-sign character ($) would help. When I read text that includes a double-ess (ß), an eth (ð) or thorn (þ), or even accented letters, my american eye is snagged every bit as much as seeing a dollar-sign, percent-sign, or at-sign.
I do think you're on to something though. I often want my sigils to line up vertically. I think that is nicer looking.
To Anonymous - think about it not as laziness of the compiler but rather laziness for the people that read Perl code, the sigils simplify reading code. They might have ugly glyphs - but their idea is beautiful. The problem is that people shift their first impression of ugliness from the glyphs to everything about the language. Sure there are other ugly places in Perl - and I also wish that 'strict' was default etc - alas nothing is perfect and no system starts perfect - we hope that the steady pace of new Perl releases will gradually fix some of the problems. And we hope that Perl6 will some day fix others.
Post a Comment