I think there’d be an interesting study about why that happened, and why languages like Perl peaked and declined so quickly.

Anecdotally, I noticed a lot of people who missed some feature from Lisp, C, etc. but generally decided that Python made everything else enough easier that they didn’t mind very much. There’s probably an interesting discussion of language usability in that.

Engineering culture played a big role. Python was quite conservative. Additions to the language had to be proposed in a PEP, implemented, and demonstrated to carry their weight. Perl was extended quite haphazardly by comparison.

Perl 5 was abandoned largely because extending it became so painful, and Perl 6 was this crazy waterfall design process for the first few years. Perl had mostly lost all momentum, by the time Perl 6 development started to get traction.

My experience was that discourse around Python also tended to be more civil and humane, and that came from the top (Guido & Tim.) I think that played a role in or was otherwise somehow connected to the better engineering discipline.

> Perl 5 was abandoned

It's all relative. Perl 5 is more active now than at any time in its history.

Python has expanded 20x in the last 20 years. So Python has in relative terms eaten Perl's proverbial lunch and overshadows Perl so much that it's easy to think Perl just died. But it's actually successfully scavenging and growing nicely in the shadows despite the 20 year long drumbeat of pronouncements of its death.

From my perspective it does look like extending Perl 5's core is painful but that hasn't stopped it growing to a half million lines of change a year (and many millions a year in the upper reaches of the CPAN river and tens of millions further downstream) and folk writing ever more powerful pan ecosystem tools as, eg, described in this report from a couple days ago:

http://blogs.perl.org/users/preaction/2018/05/cpan-testers-a...

(That all said, I'm personally more focused on Perl 6 which is a new ball game even while it's also an extension of the old one in the sense that it cohabits in the same ecosystem and culture.)

perl5 is not abandoned, it's just currently not fashionable. There's nothing I can't do server-side in perl that I can't do in any of the other important dynamic languages.

Over the last couple of weeks I've been training people who've been stuck in svn for far too long to use git. My go to three sentences to help orient them has been "git is like perl. It's extremely useful and there's nothing you can't do with it. The problem is there's lots of different ways of achieving the same thing."

I'm not sure your argument that 'top down decisions are good' is why is valid. And the whole 'whitespace is syntactically meaningful' thing in python gives me the heebeejeebies. On the other hand when I decide I need to learn more maths, python and sympy is the tool I reach for.

Pining for the fjords, eh?

I think it was one of the first (possibly the first) to introduce serious package management and that had a lot to do with its sudden popularity. Suddenly developers could build upon each other's work really easily. That was definitely the jesustech of its day.

Perl's weak type system and cryptic syntactic muck probably had a lot to do with its decline.

One of Perl 5’s big flaws was not having an object system in the language. Different people wrote different modules on CPAN, which was deservedly popular in those days, but it often meant you’d have to kludge interfaces between multiple third party systems and other things people hacked together.

That and the syntax were why I added Perl to my bash policy that any program big enough to require scrolling would be ported to Python. Usually the richer standard library also meant that the new version ended up considerably smaller, too.

Perl 5 does have an object system, one that was based in no small part on Python.

About the biggest difference is the built-in constructor `bless` is simplistic, and should be wrapped in a method.

  class Person:
	def __init__(self, name):
		self.name = name
	def sayHi(self):
		print 'Hello, my name is', self.name

  p = Person('Swaroop')
  p.sayHi()

In Perl 5

  #!/usr/bin/perl

  use v5.12;
  use warnings;
  use feature 'signatures';
  no warnings 'experimental';

  # Allows for Python style constructor syntax
  sub Person {
    Person->new(@_);
  }

  package Person {
    # this could be added to a base class instead
    sub new($class, @args){
      my $obj = bless {}, $class;
      $obj->__init__(@args);
      $obj;
    }

    sub __init__($self, $name){
      $self->{name} = $name;
    }
    sub sayHi($self){
      say 'Hello, my name is ', $self->{name}
    }
  }

  my $p = Person('Swaroop');
  $p->sayHi();

From a structural point of view, there is almost no difference. What little semantic difference there is could be put into a module.

Not that I would write it that way when Moose-like class modules exist

  # Allows for Python style constructor syntax
  sub Person($name){
    # use the default constructor
    Person->new( name => $name );
  }

  package Person {
    use Moo;
    no warnings 'experimental'; # subroutine signatures

    has name => ( is => 'ro' );
    
    sub sayHi($self){
      say 'Hello, my name is ', $self->{name}
    }
  }

  my $p = Person('Swaroop');
  $p->sayHi

Moose was based on an early design for classes in Perl 6. (and is apparently so good there are implementations of Moose in Python and Ruby)

  class Person {
    has $.name;
    method sayHi(){
      say 'Hello, my name is ', $.name
    }

    # Allows for Python style constructor syntax
    submethod CALL-ME($name){
      self.new( :$name )
    }
  }

  my \p = Person('Swaroop');
  p.sayHi();

Whenever you are rewriting code, you will see ways of making it simpler and more concise. So there are probably just as many instances where if you translated from Python to Perl 5 it would come out shorter. (Or even Python⇒Python, Perl5⇒Perl5)