edit: I don't know enough to write a web server with the full stack, but a web application. corrected that typo
Now that I'm through the first semester and have three days to gather my bearings and prepare for the next one I decided to jot down some of my conclusions here.

When I heard that we would do networking and security related programming in python I was kinda miffed. As some here might now perl was my first scripting language and the fondness that I have for it is in no small part due to the number of libraries and the ease of building new things from them. And of course its wonderful way of handling text analysis.

After a day of two of brooding I decided to give it a go (really I didn't have any choice, still the teachers quips about me already being old for using perl bothered me quite a bit).
He did not say perl was useless mind you, he admitted to not having followed it's recent development and being mostly interested in the use of the scapy python library.

So here I went, full of expectations. I had heard much about python, how it was gentle on the beginner, object oriented and made you write nice code... How wrong I was.

Yes, you HAVE to indent. After I got to working on a project with someone else who (even after we discussed coding conventions) kept using tabs instead of a set number of spaces, I understood why so many people complained about the rigidity of obligatory indentation. I mean if I wanted to code in whitespace I'd have chosen whitespace. This is not a python problem but rather a programmer's own issues there, it didn't really bother me at any time, thanks to an airtight vimrc.

Now onto the next issue. 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.

Interface with other languages: I found doing C code unit testing in python very easy and I hear that calling java or c++ from python isn't that hard either, so that's a very good thing for me.

To sum it up I'm glad I've learned a bit of python this semester (enough to be able to code web applications, udp/tcp custom servers or simple AI algorithms) because it gave me another point of view on the topic of interpreted languages. I recommend anyone using perl to give python a try just to have that alternative point of view (the same way I'd recommend that any programmer use a functional language at least once just to see how it feels). but in the end? I think that for me perl's TIMTOWTDI approach is best, because it allows me to really express myself. I don't think it's the language's job to make me respect other programmer's work by sticking to discussed APIs and using coding standards. I do so by my own free will and what this semester has proven to me is that another neophyte can be using the exact same constraining language without giving a proverbial flying one about coding standards and end up with a steaming pile of unreadable code. Could have happened with perl too, albeit with a lot more $, @ and other #.

Replies are listed 'Best First'.
Re: Perl vs Python revisited
by eyepopslikeamosquito (Bishop) on Jan 06, 2017 at 22:29 UTC

    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

      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:

        A reply falls below the community's threshold of quality. You may see it by logging in.

        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 +);

        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);

        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
Re: Perl vs Python revisited
by stevieb (Canon) on Jan 06, 2017 at 14:58 UTC

    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.
Re: Perl vs Python revisited
by perldigious (Priest) on Jan 10, 2017 at 15:04 UTC

    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. :-)

    Just another Perl hooker - Yes, I'll do really dirty code, but I charge extra.
      "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.

Re: Perl vs Python revisited
by hippo (Chancellor) on Jan 06, 2017 at 09:24 UTC
    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.
Re: Perl vs Python revisited
by karlgoethebier (Abbot) on Nov 30, 2017 at 11:58 UTC
    "...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

    «The Crux of the Biscuit is the Apostrophe»

    perl -MCrypt::CBC -E 'say Crypt::CBC->new(-key=>'kgb',-cipher=>"Blowfish")->decrypt_hex($ENV{KARL});'Help

Re: Perl vs Python revisited
by Anonymous Monk on Jan 06, 2017 at 18:47 UTC
    The only thing that sucks worse than Python is the Perl community itself for allowing Python to win its market share.