Most folks who say Perl is ugly are talking about one of two things (or both): Sigils or Regular Expressions.
Regular Expressions have turned out to be so useful that they've been slurped into every modern language (and using the Perl interpretation of regex to boot), so it's pretty much a null statement to say that Perl is ugly because of regular expressions...because it means every language is ugly. This is usually what people mean when they call Perl executable line noise...but is it really the fault of Perl that folks write regexes that are longer and more complex than is readable? Perl just happens to be a culture that is steeped in UNIX history, and sometimes we reach for a regex before other more readable tools...it's a failing of the developer, rather than the language. I find regexes in Python quite ugly, myself, since they're in the ghetto of a library rather than a first class part of the language. In Perl, you can take a reference to a regex, or turn it into an object, and of course, you can use regexes extremely concisely and in one-liners and quick throwaway scripts. I consider this a worthwhile tradeoff.
Sigils, on the other hand, are core to the language and Perl uses them more heavily than almost any other modern language (PHP and Ruby both use them to some degree, but nowhere near the degree of Perl), so if it's not the sort of thing you like, then Perl is not the sort of thing you'll like. This one, at least is a point of real difference.
I don't find sigils particularly offensive or particularly nice; I'm pretty much indifferent to them. Though I am happy to know that the inconstant sigils of Perl 5 are going away in Perl 6, as they've been a source of confusion for me on many an occasion (though less so when I'm working with Perl a lot--I haven't written a bug in weeks due to that particular quirk, and I don't think I've ever written one that the compiler didn't catch immediately). References are also problematic, and will also be made prettier in Perl 6 (in particular, function references are automagic when it is apparent that's what you want to happen).
My first dynamic language (if I don't count tinkering with ARexx on my Amiga when I was a kid...and I don't) was Perl, and I worked with it for several years. Then I went to work in a Python shop, luckily with some of the best Python developers in the world working on some of the most interesting Python code going (if you use Python, you use some code written by several of the folks I was working with), and I really enjoyed working in Python and found it "cleaner" than the Perl I was accustomed to.
After a few years with Python, I found myself working with Perl again...and I set myself the task of learning it a bit more systematically then I had the first time around. Turns out, Perl is a quite pretty language...and I like it better than Python. Both are very fine languages, but Perl suits me better. I was merely judging some extremely nice Python written by masters of the language vs. random snippets of Perl found on the Internet, and unsurprisingly Perl fared poorly in the comparison.
Ruby, on the other hand...I might actually find it prettier than Perl--it has a lot of the things I love about Perl, and very few of its rough edges. Though I'm not fond of the seeming standard usage of "end" for blocks. You guys know you don't have to use those, right? I mean, it's not Pascal. You can use curly braces, and it'll work just fine...and bouncing on % works. I'm also not fond of the occasional verbosity of Ruby that seems to be a function of its "everything is an object" philosophy.
Anyway, beauty is in the eye of the beholder...and conciseness is one of my primary "beautiful" qualities. And, if Perl is anything, it is concise (at least, it can be, and for almost any task).
I agree that this approach is deranged. It all stems from the decision to distinguish between values and references. That decision comes from the available hardware and typical programming background at the time of Perl 5's development (early 90s). At that time computers weren't abundantly fast for most programming goals, and storing all variables as references (or objects) was a pretty serious "extreme OO" position. Plus, anyone who called himself a hacker would have to be competent with pointers in C, and Perl references were substantially easier than that. So Perl layered on ways to reference and dereference values, and @{$array->[1]{"foo"}} was born.
You really believe that? I simply can't believe anyone would find working with complex data structures in C easier than in Perl. It just doesn't make sense, but obviously a few people agree with you. Have you actually worked in Perl (and C)?
C pointers make sense to me because they represent what's going on in the machine. The syntax and the rules behind it are simple enough that they click, for me.
Perl references seem to carry a lot of historical baggage that leads to the expressions mentioned elsewhere in this thread. The rules behind them always seemed arbitrary and I have never felt like I had a grip on them.
Now that said, I'm still more likely to blow my foot off with C than with Perl, thanks to the do-it-yourself memory management. But at least when it happens it's for the right reasons.
Now that said, I'm still more likely to blow my foot off with C than with Perl, thanks to the do-it-yourself memory management. But at least when it happens it's for the right reasons.
You're my hero, and I mean that.
I'm glad we cleared that up, and I'll readily agree that complex data structures via references is among the most glaring warts in Perl. It's obviously more complicated and error-prone than it ought to be, and moreso than other similar languages.
I've got this theory that the thing that people talk about most in any language or technology is the thing that is actually most broken about the language. People talk a lot about references in Perl, and I know they're broken by design. Similarly, I've got my suspicions about monads in Haskell, since people spend so much time trying to explain them...seems like there must be some fire under all that smoke. But I could be just imagining it, and I think I probably need to spend a lot more time with Haskell before I can accurately detect bogosities.
It handles lists that way because of the braindead idea of sigils which, in order to be semantically consistent, cannot have as an element of a list being a list.
I'd like to see you back that up. $a[0][0] does exactly what it looks like it should do: it takes the first element of the list at $a[0]. (Incidentally, this is exactly the same as the gp's $a[0]->[0].) The only problem sigils introduce is the -> in expressions like $a->[0]. ($a is a reference to a list, and you can't write $a[0] in this case because it will look at the list @a.)
I'm not entirely sure why perl doesn't have good support for nested arrays and hashes, but I'm pretty sure it's not to do with sigils.
It's historic. In The Beginning...Perl was a different language, a simpler language built to take the place of awk/sed/grep/shell in one mostly consistent package, and when it later obtained complex data structures, they were implemented on top of the existing semantics, which involved arrays and hashes that could only store scalars.
I don't think anyone thinks list-flattening is a good idea, these days. And, of course, Perl 6 gets better handling of complex data structures...if I recall correctly, it gets an explicit "slurpy" sigil that provides the flattening behavior, but I don't actually work in Perl 6 yet, so I'm not sure of that.
Short answer: Don't write $a->[0]->[0]->[0]->[0]->[0], write $a->[0][0][0][0][0]. It does the same thing.
Long answer:
As for writing code, however, you don't need to write $a->[0]->[0]->[0]->[0]->[0]. After the first dereference (if any), you can omit the '->'s because arrays and hashes only store scalars so perl knows you're talking about a reference. You can use all the arrows for backwards compatibility.
> Most folks who say Perl is ugly are talking about one of two things (or both): Sigils or Regular Expressions.
Regular expressions are expensive. I find a lot - actuially, most - of the things I'd do with RegExs in Perl can be replaced with string methods in Python.
Additionally, it's also common for Perl users to use RegExs to do things like modify markup languages, which is extremely fragile - use a tree data structure and paths. Python has even has element trees built it in recent versions.
> Anyway, beauty is in the eye of the beholder...and conciseness is one of my primary "beautiful" qualities.
You're not the beholder. You're the author. Is your work so limited it has no purpose after you leave ? Code should be written for the people who have to maintain it.
Your beholders value simple code rather you selfishly saving a few keystrokes.
Regular expressions are expensive. I find a lot - actuially, most - of the things I'd do with RegExs in Perl can be replaced with string methods in Python.
They are not that expensive. In perl, you pay for executing opcodes. If you can do with one regex what would require 10 "fast" string manipulations, then the regex will nearly always be faster.
I imagine Python is similar; there is bookkeeping to be done every time you call a core string function. If you can condense the operation into one call into the core, then you save yourself the bookkeeping overhead.
Additionally, it's also common for Perl users to use RegExs to do things like modify markup languages, which is extremely fragile - use a tree data structure and paths. Python has even has element trees built it in recent versions.
This has nothing to do with Perl. You can write bad code and use bad techniques in any language. I'll bet a Google Code Search will reveal tons of hand-built parsers written in Python. Most people don't know there is a better way to solve a problem, so they use whatever they think of first.
Code should be written for the people who have to maintain it.
When you write code, expect that you will be the primary maintainer forever. You will spend more time reading your own code than anyone else will, so optimize it for yourself.
Your beholders value simple code rather you selfishly saving a few keystrokes.
If you can't read Perl, perhaps it's because you don't know Perl. I can't read Python. Why? Because I never bothered to learn it. Does that make it intrinsically "unreadable" or "unmaintainable"? No; it just means I am dumb. Don't blame the language for your own ignorance.
And even if they were remarkably more expensive, I'd still take "has an awesome implementation of regexes" over "does not have an acceptable implementation of regexes, but does have a few limited string processing methods that are fast". Luckily for Pythonistas, Python does have a reasonable regex implementation (pretty much the same as Perl in most regards, though not as nice to use), so it's not a problem.
But, I'm baffled that someone would suggest that a language is better because you can use more limited tools that might be marginally faster than extremely powerful and flexible tools. And, I'm also a little concerned that the previous post seems unaware of Perls other string processing tools...regexes are not the only tool in the toolbox. Perl is a monster for text processing. Regexes are the teeth...but there are also claws and horns and a pointy tail. I think Perl 6 also has laser eyes and breathes fire, but that might just be a rumor.
> But, I'm baffled that someone would suggest that a language is better because you can use more limited tools that might be marginally faster than extremely powerful and flexible tools
Because Python has both, and so much data is already split on common delimiters, and having a fast way to handle them is awesome?
Because Python has both, and so much data is already split on common delimiters, and having a fast way to handle them is awesome?
I know, and I said so. But, so does Perl (one of several "fast ways" of processing text in Perl is to use regexes, but it's not the only way). That's why I'm confused that you seem to think you're making differentiating statements about the two languages. That's all.
I happen to like Python, I just don't think it makes sense to present Python as a better text processing language than Perl...when, by most measures, including performance, it probably is not.
> If you can do with one regex what would require 10 "fast" string manipulations, then the regex will nearly always be faster.
Agreed, but most of the time I only need one string manipulation, and from what I can tell, the code behind split and endswith etc. are faster than using RegExs in the same place. Recently I've had to convert something back to Python 1.5, which lacks string methods, but has regex's, and it's noticeably slower.
>>It's also common for Perl users to use RegExs to do things like modify markup languages, which is extremely fragile - use a tree data structure and paths
>This has nothing to do with Perl.
It has something to do with Perl - Perl lacked these data types in the mid 90s Perl boom. So people who learnt Perl then see no problem with using what's always 'worked for them'. I agree it's nothing to do with the language as it stands now.
> When you write code, expect that you will be the primary maintainer forever.
Would you hire someone that said that to work on your startup?
>> Your beholders value simple code rather you selfishly saving a few keystrokes.
> If you can't read Perl, perhaps it's because you don't know Perl.
That's a troll. I can fix a problem with a blank editor and Perl, and I can read and debug most people's Perl. Not being able to understand someone's sloppily indented bracket abortion-code isn't because I don't 'know' the language.
Actually, that's mostly not true. I work on a 450,000 codebase, and I wrote almost none of it. I read far more Perl than I write, as with any language used in a project that isn't a throwaway.
Your beholders value simple code rather you selfishly saving a few keystrokes.
You've got it backwards. I'm selfishly thinking of myself when I read it, not when I write it. I'm selfishly looking to save time while I read by having more functionality in the same amount of lines of code--a map or a join, for example, is far more concise than explicitly iterating over a data structure and operating on it. You may not prefer to read the single line map or join version over the multiline block of code in a loop, but I certainly do.
>Actually, that's mostly not true. I work on a 450,000 codebase, and I wrote almost none of it. I read far more Perl than I write, as with any language used in a project that isn't a throwaway.
Er, you've just proved it true. Other people wrote that code, hopefully to make it easier to maintain by those who come after them.
Like you say, code is read more often than it's written.
Most folks who say Perl is ugly are talking about one of two things (or both): Sigils or Regular Expressions.
I think it is ugly because of its haphazard attitude to default behaviors. Sure the default is usually what you want, but if it isn't, there's no way to derive what you do want from principles, you just have to know it. The Perl documentation is littered with references to "magic" and so on. Whereas with (just for an example) Tcl, once you know the very basic principles, everything else can be determined logically from there.
Ah, yes, I suppose if Tcl is the pinnacle of beauty, then Perl would represent ugliness.
I've found only a few gotchas that really get me in Perl. Mostly its DWIM (Do What I Mean) philosophy really does what I mean. References, as I mentioned, are a source of trouble for me, but almost nothing else in Perl is.
OK, I'll bite. I know Perl. Perl is versatile. Perl is powerful. But Perl is Ugly with a capital 'u'. Give me Python or Ruby any day.