Michael Murdock doesn’t believe in anti-Perlism. Of course he has to indulge in some of his own.
“Every developer with whom I have discussed this issue says roughly the same thing: It’s very difficult to pick up a piece of Perl code, even when it’s your own, and be able to quickly understand the gist of it.”
I find it hard to understand French but I don’t go round saying it is a speak-only language.
You couldn’t make it up. Or was the irony intentional?
I’ve been developing using Perl for over 10 years and the only, ahem, “developers” that I’ve ever heard say that are, on closer inspection, those who never really bothered to learn the language or learn how to use CPAN.
Perl is a language that’s very easy to get started with and become productive but I think people who get past those initial milestones suddenly believe they have mastered the entire the language (typically the same people that call it a “scripting” language). Why? I don’t know. The language is really rich and CPAN is as well. Developers who have learned the language and how to use CPAN write very readable production code.
Software I wrote 10 years ago I can pick up and immediately know what I did and all of my colleagues that are proper Perl developers can do the same, so I’m not sure what Mr. Murdock is saying he didn’t sample enough Perl developers.
Gosh knows how many times I’ve had to work with a horribly written piece of Java, Python, or (gasp) PHP code. Bad programmers write bad programs in every language they touch, no language is spared.
How easy is it supposed to be? Start out with the understanding that it is ALWAYS going to take some effort to understand code, even your own. The problem is only exacerbated by the nature of our typical syntactical construction which is the mutation of states within a finite state machine. This will always be a struggle to understand even when we’re used to it. The more functional and/or declarative it gets – where the code says what it is doing instead of being a sequence of derivative mutation operations that result in the goal – the more obvious it is what the code does. You don’t have to figure out ‘what does this pattern of changes result in’ – it is stated. Find the innermost function that doesn’t return what its supposed to, and you’ve got the location of the problem.
Essentially, we create our own comprehension problems by trying to express the solution in terms of its operations instead of in terms of its logical constructions.
I’ve seen some beautiful Perl code, in articles, books, tutorials.
I’ve seen some ugly code in production, usually old code that has been maintained with a “priority speed”, “cut-paste-modify” attitude. Among other things, the code was characterized by “revision control by commenting out old code”.
I’ve seen some reasonable code from teams who discuss standards, where more experienced members share with newer people, where there is a vision of what the code should become, and every revision is an opportunity to evolve in the right direction.
Wouldn’t the argument be that French is a “Speak Only” language? My wife used to describe her French as being able to perfectly ask a question and not understand the answer.
That certainly sounds like my experience with Python.
@Leandro – Well said.
I assumed that Murdock and his chums put the same effort into learning Perl as I did into my french (5 years study and I can’t remember a word of it)
@David – I’m not sure functional programming is a panacea. Sure many developers tend to overuse state now, but will removing the state get rid of the fundamental complexity of a particular program?
Having said that, I tend to understand the code I wrote better than other people’s code, even after the magic 3 month period. I rarely have a problem recalling what I was thinking at the time.
@Tom – you mean to say that Python doesn’t magically fix crufty cut-and-paste code?
And yes, even my own code quality is adversely affected if it is required in production ASAP. I don’t have a problem understanding it though. It’s more I groan when I need to extend it to do something far from what was intended.
@Perigrin – yes you’re right. Calling French a “speak-only” language is closer to a write-only programming language. I was thinking that listen-only was even further down on the scale. I can listen to chinese without understanding a word for example. Mind you, some folks seem to be able to write perl without understanding a word too
@Jared – yes. Few are sure, that is why few use it and reap the benefits. A shame. It will reduce the fundamental complexity to units of a size that are manageable. That may not reduce the fundamental complexity, but it does reduce the complexity you have to deal with at any particular moment. Low point complexity leads to quick comprehension.
This is nonsense. I very often take a look at strange Perl code — usually peeking under the covers of a CPAN module, to see how it does stuff, to see if it has undocumented features, to fill in gaps in the documentation. I can get the gist of what’s going on almost immediately, and the details with a few minutes’ study.
Granted, I’ve used Perl for many years, but come on — Perl’s idioms aren’t bizarre or obtuse (for the most part!). Read The Perl Cookbook and Effective Perl Programming, and you’ll be able to grok 75% of CPAN in short order.
It’s like anything else: The more you use it, and the more you read others’ code, the easier it becomes. And if you’re a professional software engineer with half a clue about effective, efficient style, your code will be readable to others (and to yourself) as well. This goes for any modern language — or, I daresay, the classics of the previous generation (C, Lisp, Forth, Pascal, etc).
The lady doth protest too much, methinks. No one goes on and on about how unreadable Python, Java, C#, etc. are. It’s mainly perl and php. So I wonder… is the problem everyone else, or is it these two languages?
I do not know Perl, but I’ve had to modify some existing, non-authored scripts at work at times (and outside work, as well). At first it always looks unreadable to me with the ‘$’s, but once my eyes adjust to that, its very easy to read and understand – as is using CPAN.
I know I am very guilty of writing a lot of less than easily understandable Perl in the early 90s. Coming from a systems programming background, I was very terse and used a lot of complicated regular expressions that I didn’t factor cleanly. A lot of it also ported from sh/sed/awk/grep/find for performance which were complex in syntax and approached train of thought programming.
I suspect many folks just starting out at the same time with similar backgrounds.
@Perigrin: My experience with Python has been similar.
I know plenty of languages and have been programming for close to 30 years, but write mostly Perl. I’ve spent about 30 hours with Python for a client project (running on Google App Engine), and have come to the conclusion that Python is indeed a write-only language.