Hacker News Reader

Comment by iamnotacrook | Hacker News Reader

I used Perl for a bit but switched to Python because I was finding it harder to work out what some code I'd written a year or so ago did than to write it again, a problem I don't have with Python.

View on HN

I used python for a bit but switched to Perl because it

1) Works

2) Is ubiquitous

3) Is stable

4) Is normal (semicolons, braces etc)

> 2) Is ubiquitous

On which systems do you have Perl readily available but not Python?

legacy stuff

Which version of python?

Perl documentation online applys to versions of perl that are installed. Python stuff is all bleeding edge - you'll research why something isn't working and after 30 minutes find it's expecting python 3.7.

The whole concept of "virtualenv" gives me an impression of fragility I don't get with perl.

Wanted to use Python 3 for some processing but the Sysadmin said that only Python 2 was available for that distributions version and "didn't want to frankenstein the box"

What about installing miniconda in your home folder?

How ancient is that system?

Possibly CentOS, which requires python 2.7 even now.

RedHat EL5.

No matter, that system is going to be decommissioned and functions will go over to a new EL7 install.

It just stalls that project till the new server is ready.

> What about installing miniconda in your home folder?

This is not how you deploy software

You are right, but I interpreted it as a one off manual task. I've used miniconda in that way.

The problem with python is some systems have 2, and others have 3. Basically everything has perl 5.

Which one? Python 3.5.x or 3.7.x or something else? Version 3 should be version 3. Anything written in 3 ought to work on every Python 3. Not so in the Python world. And that makes it a mess to use (unless you Dockerize every script).

Perl 5 is Perl 5 everywhere.

Perl 5.001 is really old (25 years or so), and lots has changed since then. v5.10 introduced a barrel-full of new features; other important features like the "use v5.10" syntax for supporting older scripts didn't land until much later (v5.16).

Where I work, a few of our legacy systems are still dependent on ~v5.10, which can be a real pain when trying to port code back to legacy. I agree that the Python versioning problem is perhaps more prominent, but Perl 5 doesn't really get a free pass here.

The "use VERSION" syntax is fundamentally much older. It used to strictly just assert a minimum version. It also, pre 5.6, required floating point versions ("use 5.005"). In newer versions of perl, this syntax will also invoke "use feature <stuff new in your version and all versions before>" which allows the use of incompatible new features in its lexical scope. One example is that "use 5.12;" and above will turn on "use strict" in the lexical scope. I fought long and hard for that one. Makes the language strictly better (pun intended).

It strictly does! :) I knew that "use 5.12" implied "use strict" but I didn't know the mechanism, or that it could enable other features as well. That's pretty cool!

FreeBSD ships perl5 in base, but python is an addon. I suspect other BSDs may be similar. The only thing more ubiquitous is POSIX compatible /bin/sh but that's much less featureful.

Because of the stability of perl5, I barely care what version of perl5 that ends up being. (Perl 5.10 and up is pretty much what I want, 5.8 and 5.6 are a drag if i might need unicode)

OpenBSD ships with Perl (it's used for the package management tools, among - I presume - other things) but not Python, last I checked.

Not that installing Python is especially difficult, but still.

> 4) Is normal (semicolons, braces etc)

What was your first programming language? Because what seems like normal to you mostly depends on you.

> What was your first programming language

QBasic, then Visual Basic for real programs.

Look across a bunch of common languages - Java, Perl, Python, Javascript, PHP, and of course C/C++/C#/ObjC, braces + semicolons. Even Bash and Go have braces.

> Python

    >>> from __future__ import braces
      File "<stdin>", line 1
    SyntaxError: not a chance

Back to the topic, while I don't think its ranking doesn't generally reflect the actual popularity, the TIOBE index [1] is a good definition of "common enough" languages. So let's see... oh! There are 5--7 programming languages out of top 20 that do not generally use both braces and semicolons! (Python [not-so-strictly-necessary semicolon only], Visual Basic .NET, SQL [semicolon only], Assembly language, MATLAB, Visual Basic and Delphi/Object Pascal [semicolon only]). I also happen to know less popular but well-known programming languages that do not use both braces and semicolons at all (ML, FORTRAN, Lua, Forth and of course all lisps). So please allow me to reword your claim: why should braces and semicolons be normal?

[1] https://www.tiobe.com/tiobe-index/

Pascal, Forth, Postscript, Lisp.

There is no "normal" syntax. There is more to languages than those inspired by C.

> 1) Works

Almost anything can "work"

> 2) Is ubiquitous

So is awk, don't write software in it.

> 3) Is stable

This will become questionable as Perl slips into non-maintained mode.

> 4) Is normal (semicolons, braces etc)

Perl syntax is very far from "normal"

Perl is a general purpose programming language. The Perl interpreter and language are stable, it's not going anywhere soon. Perl and its syntax have been around a lot longer than most other languages and is very similar to C, C++, JavaScript and PHP. What do you consider normal syntax?

The most obnoxious parameter passing in existence? The magic variables everywhere? Perl code is an unreadable heap of spaghetti, I’d much rather be figuring out unallocated memory bugs in C then read Perl.

Don't forget sigils. Because the difference between @foo and $foo is obvious, right?

That difference is indeed obvious. The issue is sigil variance.

Highlighting sigil variance was my point, poorly stated.

Perl5 does not have "sigils", BASH, BASIC and Perl 6 have sigils.

Perl 5 has dereference operators, which got called "sigils" by lazy documentation and book authors.

Not to someone who doesn't know Perl. But this is the same for every language. No one should be picking up a new language and working with it if they don't know it.

EDIT: To clarify, I mean there should never be the expectation that you can start working in a language in earnest without properly learning it.

@ → A → array

$ → S → scalar

That's how I learned and remember them.

What makes that less obvious is when you work with references to arrays; the reference itself is a scalar, so it gets the scalar sigil. You can dereference it, though, by sticking an array sigil in front of it, thus telling the interpreter "hey, this is a scalar reference to an array".

But why obnoxious? Do you know how old Perl is? Have you written shell scripts before? My point is, some of choices Larry and others made wouldn't necessarily be made today, but there's a history, a lineage, a reason for all of this. I actually like the magic variables, but as I said in my other comment, you need to learn it first. X language is an unreadable heap of spaghetti if the programmer writes X language in an unreadable way.

Python only postdates Perl by 3 years.

Perl5 - which is what people refer to as "perl" - came out in 1994.

Python3, which is incompatable with python2, came out in 2008.

Way to move the goal posts into separate area codes.

If you're going to judge python by python3 you should at least hold perl to 5.020

> Do you know how old Perl is?

Same age as Haskell.

Is its function parameter passing really more obnoxious than python, which lets you mutate the default parameter across calls:

def foo(bar=Bar(1)):

Unless bar is a primitive type, in which case each invocation gets the same value?

def foo(bar=1):

Perl wears its idiosyncrasies as badges of honor. Python keeps them hidden so they can sneak up on you when you least expect it.

"Vell, zis is perfectly normal behaviour for a python", to rephrase Gag Halfront.

> Almost anything can "work"

Yet after yesterday's attempt to get a small cherrypy webserver running, python doesn't.

If 1 out of 100 people fail to do a thing, it doesn't mean that thing is bad...

1 out of 100 might be understating it, though. Or it might be overstating it. Who knows?

As another data point, I've had very few good experiences with Python. The primary exception has been with PyQt5, and chiefly by going with Qt's conventions instead of Python's (i.e. being as Qt-like and un-Pythonic as possible).

Here's a perfect example of the python community

https://stackoverflow.com/questions/54831915/python-3-5-2-in...

> I want to run this on a production Server with ubuntu 16.04. My Sysadmin tells me that I shall not use pip or github repository, because of ... something wrong with using anything but apt ... he says.

Sysadmin is right.

First response?

> sudo apt-get install python-pip

Now there are ways to convert modules to debs (or rpms on redhat style machines) so they can be managed cleanly across an estate, but that's not the python way.

I used Perl for many years, and still do. My bias is now toward Python for scripting, because the young all seem to know Python. But for example to write a script to be run on Linux that will talk to SQL Server, I will use Perl, since DBD:Sybase works, and I don't feel like fussing around to find and configure a Python equivalent.

I miss Perl. I love Perl still and would reach for it for any project I could. That said, I switched to Python because going into recent interviews and doing the white board or online assessment, Perl isn't necessarily an option. At least it's not a popular option. I do miss Perl and will happily without shame admit it.

Reply on news.ycombinator.com