Python will make you write nice code. I call bull on this one. Sure you'll have to indent your loops so they work but that won't make you write nice code. I have a hefty slab of absolutely unreadable UI code sitting in a repository on a university server to prove it.

Indeed. I'm still surprised by how many folks, who don't know either language particularly well, claim that "Python is more readable", or that "Perl looks like line noise" -- to which, I normally reply that Russian is "unreadable" if you don't know Russian.

I sometimes further challenge folks who claim magical code readability powers for Python, to please explain how using Python ensures that they:

• Make sound domain abstractions.
• Decompose their programs wisely into highly cohesive, loosely coupled modules.
• Choose descriptive, explanatory, consistent and regular names.
• Write useful comments.
• Minimize the exposure of implementation details.
• Avoid duplication (DRY).
• Don't use magic numbers in their code.
• Create interfaces that are: consistent; easy to use correctly; hard to use incorrectly; easy to read, maintain and extend; clearly documented; appropriate to audience.
• Write components that are testable in isolation.
• Establish a rational error handling policy and follow it strictly.

That is, far more important than "readability" is "maintainability", so that programmers who know the language can come to the code later in its life and understand its construction and intentions and change it comfortably and confidently.

See also: list of similar Perl v Python questions

Update: See also a later, more comprehensive version of this reply at: Re: Some Help for a Report About Perl (Readability vs Maintainability References)

I agree with your post, your point, and your list 100%; but I have a question...

Define "magic number"? Preferably with real examples. Thanks.

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority". The enemy of (IT) success is complexity.

In the absence of evidence, opinion is indistinguishable from prejudice.

I don't see a huge benefit in nailing down a precise definition of what is, and what is not, a magic number. We don't have hard and fast rules about magic numbers at work. Zero and one, for example, will usually survive a code review (though perhaps not if used with bools). There is room for common sense, negotiation and programmer discretion. The focus is on simplicity, clarity and maintainability.

For example, a magic number like 7.4269 that may change in the future being sprinkled all over the place would not survive the review; you'd be asked to choose a meaningful name for it, $customer_interest_rate for example. Even if the number is PI, and so won't ever change, the code will usually be clearer if you use $pi rather than 3.14159.

To be honest, I don't feel strongly about magic numbers and can't ever remember them being a big issue during a code review. There are bigger fish to fry, things like:

• Is the component testable in isolation?
• Is the component interface well-designed?
• Has the programmer gone berserk with unnecessary cleverness?
• Is there a coherent error handling policy?
• Are there gaping security violations?
• Is the program easy to support and troubleshoot remotely?

Obligatory references:

• magic number (wikipedia)
• magic number (stack overflow question)

You've already got the answer you wanted, but an amusing (to me and one workmate at least, although not amusing to another) example may be appreciated.

A workmate and I were working through refactoring and understanding some code (C++, but not really relevant to the story) that another workmate had written. The code concerned used circular buffers at the end of a calculation chain for feeding samples into a digital to analog converter. Getting the size of the buffer right is a critical part of making the system work correctly. We encountered a few lines that were used to configure the buffers and looked something like:

mOutBuffer = CreateBuffer(baseBufferSize+3*2*k10HzKneeSampleBufferSize
+);
[download]

We couldn't figure out what the 3 * 2 was doing in there and there were no comments to give any clue so we changed it to:

#define PI 3.1415 // Circular buffers

mOutBuffer = CreateBuffer(baseBufferSize + 2 * PI * k10HzKneeSampleBuf
+ferSize);
[download]

which we at least thought amusing. We hoped that the other workmate would appreciate the joke then provide some sort of sensible name for the constant and perhaps a useful comment. Instead, at the next scrum he noted that someone had added a PI constant "probably they thought it was amusing" and it wasn't right!

Sadly the PI constant is still in the code and we still don't really know why that particular value is used. There was no doubt a clue in the value being written as 3 * 2, but it escaped us.

So, that's a classic magic number. It's critical to correct operation of the code, but provides not obvious rational for its selection.

And if you read a little friction in the team between the lines, you are right. The person who wrote that part of the code is very bright, but I think he has trouble appreciating that not everyone understands stuff in the way he does.

Premature optimization is the root of all job security

SO: What is a magic number, and why is it bad?

I code in Python at work, but all of my open source software is written in Perl (well, C, C#, Javascript/JQuery too, but I digress).

Python is a very good entry level language, but it is also extremely powerful and easy-to-use language for very large projects with many developers.

Although I favour Perl even if it didn't have them, the two most important features of Perl that I can't get anywhere else is the CPAN, and the extreme ease in which unit tests can be written and run, as well as how simple it is to find out exactly what's wrong and where. Unit testing is not so simple in Python, and given that my unit test suite contains usually > 10 times the amount of code my projects do, I need it to be easy.

I'm still fiddling with the unittest python module, so far it hasn't been overly verbose but I only have tested very simple code. Once I get my hands really dirty with BCH encoding I might have to revise my judgement.

still the teachers quips about me already being old for using perl bothered me quite a bit

Why would this bother you? I'd be half tempted to do a couple of assignments in Perl as well just to demonstrate how fantastic it is.

Which O/S is the teacher/class using?

That's the fun part. Everything is done under linux, specifically alpine linux which comes without python preinstalled (at least in it's docker image). What I did find bothersome is what I perceived as a dismissive attitude toward a perfectly valid choice for scripting/administration purposes.

I really appreciated reading this and getting your opinion on the differences, especially given your particular situation. I'm still constantly perplexed by the common preference for Python over Perl and in many cases the even more caustic view that, "Perl is bad, you shouldn't use it," usually because of vague reasons being reiterated from some biased author at a trade magazine or blog. I've had several arguments with the VP I work under where that's his belief and he refuses to budge on it, which is made funnier by the fact that all the new automated metric tools he loves and raves about I wrote... in Perl. :-)

Not too long ago we were interviewing a potential new engineer, and part of that process involves taking them around and introducing them to a bunch of members in our little group here so each of us can give a quick overview of the increasingly random list of things we work on for the company. She had almost that exact response of, "Perl is bad, you shouldn't use it," and I was really surprised she said that after I told her I used it and motioned to a stack of Perl books on my desk. Good that she's willing to state her opinion, although obviously not particularly tactful about it in this case. When I asked why she felt that way, she said that's what her colleagues at her previous employer (Atmel) all more or less thought and told her. I gave a shoulder shrug, suggested not necessarily taking other peoples opinion at face value, and more or less said "a tool is a tool and as long as it gets the job done, great." I'm just glad my tool happens to be a Swiss Army Chainsaw. :-)

Almost everyone I work with codes in Python, lots of Rat Books around, but honestly most of them just dabble and do little quick hacks with it, only one of them uses it to the extent I use Perl at work (though he is admittedly a lot more knowledgeable on just about everything Computer Science than I am). He's not opposed to me using Perl anymore than I'm opposed to him using Python, we occasionally zing each other for fun, but I accept that he just likes Python and he accepts that I just like Perl. We even haphazardly try to help debug each others code from time to time.

What does miff me is the often smug and superior attitude of many that prefer Python. I shudder at the thought of having to learn Parseltongue in the future out of necessity to get a job with a Snake Cult. I just really like Perl, I'll use it over something else as long as I'm allowed.

Humor Tangent: My inner six year old was absolutely delighted to discover you are in fact at the time of posting, a French Friar. :-)

"I shudder at the thought of having to learn Parseltongue..."

If you've been coding Perl for any length oftime and have a reasonable understanding of OO, Python is exceptionally easy to grasp, particularly in the case you mention that most of your peers use it for simple things. Here's a pretty decent intro.

One problem with Python I've found at work, is sometimes people go way too crazy with significantly ridiculous levels of inheritance that oftentimes don't even have a proper hierarchy (think 10 levels with cross-pollution). I suppose that happens in Perl as well, I've just never seen it.

I feel that it's handy to at least have some working knowledge of languages that are widespread, even if only for a single reason: porting a library or portion of code to Perl ;)

For the Rasperry Pi work I've been doing lately, oftentimes I refer to existing Python code when I'm writing a new module for specific devices/sensors etc. I read the datasheet, harvest and/or write C code, the review the Python of known good existing libraries as a comparison to how I'm thinking I want my API to work. Python is king in the Pi world (well, C is really, but the majority just want it "easy" so they use RPi.GPIO), so understanding Python has made it a bit easier for me to help provide Perl users the same benefits that the Python kiddies already have.

As a pure acolyte for the past ten years, when I finally took note of the need to have a good scripting language for my online business, and began writing perl spaghetti code to get simple jobs done - recently I had an epiphany.

I was having difficulty with a Perl text parsing script that 'normally' works but was utterly recalcitrant at renaming some files.

Now, please understand that I am not a programmer. Typically I hack scripts as templates to get them to work. And after enough time they normally always do. This script was an exception. Homegrown.

I tried for about two hours oin Python to get it to work. No luck. Tried Ruby, and in a few minutes it was working fine. It was my one and only time I have ever written a Ruby script.

I realized that I had a lot of programming to do in the future. I am planning on coming out of semi-retirement (assuming the economy improves) and overhaul my web sites, as well as creating a specialized library catalog for over half a million etexts.

But at that fateful moment with Ruby I had a sudden enlightenment. I have dabbled with trying to learn a host of other languages. C is simply monstrous and needlessly repetitive for my needs - its Assmebler with labels.

Java is someting I have come to hate. I have worked in multiple Java projects, only to find it pointlessly confusing and bloviated.

There is something likable about Python, but its hopelessly cracked for me. Its main strength lies in what people have done for it (modules), rather than what it can do technically, at least as easily with Perl. Mind you I speak as a dabbler, and not a pro.

Ruby showed me outright that i needed to spend as much time and effort as possible mastering Perl. Which I have been doing for the past two weeks. Relearning it from v5.10 basics. To me at least, Ruby is Perl Lite geared for OO. I have very little need for OO, which I see as needlessly complicating for non-production scripts.

My point in this meandering gibberish is this: In the past few years Perl has arisen from the dead, and nobody noticed. But most importantly, unlike Ruby and Python which seem to have decent, if not strong neophyte communities, for Perl the only site with sufficient traffic to avoid continuous necroposting is here, Unfortunately this site can be a bit intimidating for new users.

I spent the majority of last night looking for a simple forum to ask dumb questions on perl. Sorry but IRC and mailing lists are simply out for me. No way, no how. I also noticed the forums with the heaviest traffic seemed to be PHP. My experience with my web site and its support forum is that the majority of PHP users are not programmers. Hells bells, even apparently the majority of web site *designers* are not programmers.

The average person does not understand what TIMTOWTDI(sp?) means and the utter personalization of styles that Perl allows, allowing one to write utterly obfuscated, to essentially GW BASIC code. I proudly use the GOTO statement, for example. I do not write my scripts for peer review. However when I do share code, Perl allows me to spiffy it up, and become more easily readable by non-programmers. Its syntax, when not using unnecessary shortcuts is actually quite readable. Even a few *years* later. Larry is after all a linguist....

An humble suggestion would to create here amongst the giants, a *playground* where strict and warnings are left at the gates, and new folks are encouraged to play around with the code and grow with it, and even personalize it to their languages and cultures. Even a MyBB type subforum for those who find the interface here a bit inscrutable, like I did for many years.

I also believe the playground should include Rakudo, especially as with it, Perl does not seem as cracked as the forks of Python. I dont use any 'fancy' techniques in my scripts so I dont forsee any problems with Inline::Perl5, but then again I am still installing it. Its repo is painfully slow.

"...first semester..."

BTW, yet another destructive post: One thing to consider with that Python hype in the academic world is that it is probably much easier to teach than Perl. Because it has no such thing called TMTOWTDI . Hence it is much easier for the lazy lecturers to prepare/maintain their boring Powerpoint presentations, scripts, exercises, examination questions etc. Yes, now i feel much better ;-)

Best regards, Karl

I give up... I'll never be able to resist.

Just another Perl hooker - Yes, I'll do really dirty code, but I charge extra.