Perl was originally written at JPL, which is the epitome of government-funded research, and for the first many years of its life most of its numerous contributors were at one or another government-funded research institution, because people who weren't didn't have internet access.
That does sound right, since I vaguely recall an interview with Wall talking about JPL.
-----
I think there's still a difference because Python was literally funded as a research project by CNRI, a government research institution. It wasn't created there, and it was funded by different entities afterward, but I think that's the period when contributors with a scientific background like Travis Oliphant, Jim Huginin, and David Beazley started working on Python's libraries and infrastructure.
At best it seems like Wall worked at JPL for a short time and started Perl there. It also matters what kind of research it was. Perl is aimed much more at text processing and not linear algebra, while Python is more general purpose in this respect.
Also, if my memory is right, by early 2000's JPL had jobs in Python, and python.org said JPL was a user. I could be wrong but I don't think Perl ever caught on as much as Python did at JPL.
Unfortunately Google has decided to remove the ability to view source from Google Groups, so we can't see the return-path for https://groups.google.com/g/comp.lang.perl/c/t4RumjajsXA/m/7..., one of the earliest messages he posted from netlabs.com, so we can't see what NNTP server he was using at the time. (I guess that's what we get for letting Google take the responsibility for "making information universally accessible": we have no recourse when they decide that means making previously public information inaccessible.)
The Wikipedia article says he released the first version of Perl when he was still at Unisys, citing the first edition of Programming Perl, which I don't have. The second edition (01996) is silent on the question. It also cites https://www.oreilly.com/pub/au/148, which does say that and presumably is at least subject to Larry's veto.
So, at any rate, JPL was funding Perl development from at least 01987 to 01991, four years, almost the same amount of time that Guido van Rossum was working at CNRI, 01995 to 02000. But you're probably right that Guido had to write grants and write progress reports on Python, and Larry didn't on Perl; he had the discretion to just do it. Also, I suspect this was true when Guido was at CWI too, as you say. AFAICT the only research paper Guido published at CNRI that was about Python was the CP4E paper.
I don't think it's accurate to say, "Perl is aimed much more at text processing and not linear algebra, while Python is more general purpose in this respect." PDL/perldl is from 01996, just the year after Numeric in 01995, and Perl 5 offers pretty much exactly the same set of facilities as Python for this sort of thing (dynamically loadable language extensions, operator overloading, dynamic typing --- though I guess at least Python's indexing syntax is more comfortable, because x[i:j, ..., 3] is a valid Python expression that preserves all that indexing structure, and has been since at least 1.5.2).
If memory serves, PDL was a lot better at 3-D plotting than Numeric was when I first tried it in about 01998; it could pop up a rotatable 3-D plot in an X window, and Numeric couldn't.
I think what happens is that a lot of people started working on Numeric (including those you mention --- although keep in mind dabeaz was also working on Perl's libraries and infrastructure!) and so it started getting better faster than PDL. Part of this was that Python is just a more pleasant, less clumsy language, so people chose it when Perl didn't have a killer advantage, like native mutable strings or a relevant CPAN module. But that's not about Python being well-suited for linear algebra; its only linear-algebra-specific feature is Python 3's @.
I think it would be very hard to find anyplace in 01995 or later that had Unix systems and didn't have huge piles of Perl. You're probably the person in the world most aware of the shortcomings of the primary alternative in the early 01990s (ksh/pdksh/bash). But it's also true that lots of Perl-heavy sysadmin shops never got into writing "real programs" in Perl like Slic3r, Perlbal, Movable Type, and Frozen Bubble, and so Perl didn't show up in their job descriptions. And nowadays most of those huge piles of Perl are sort of regrettable, and regretted.
OK I went down a rabbit hole and also realized how terrible Usenet search is. I tried to Google for Usenet search engines and ended up with mostly spam :-( Seems like Hacker News is sadly a better search for these kinds of things.
Anyway I agree with most of what you say, EXCEPT I think Perl's focus on text vs. Python's more general purpose focus can be seen from the creators' very early release announcements!
One thing I've realized while working on shell is that the "bones" of a language are set in stone VERY early. Then comes 10-50 years of compatible changes that necessarily must obey many early design decisions.
Also I'm not saying the focus on text is bad -- in fact a big motivation for Oil is that Python is not convenient enough for text processing :) (and that it's awkward for process-based concurrency)
Perhaps my experience with Oil shows me all the stuff I'm NOT doing to support scientific computing. Even basic stuff like exponentiation x^0.2 is a huge bit of code, as well as scanning and printing floating point numbers, all of which shells lack. Oil should have proper floats but not in the initial versions. (Early in the project I also thought it would have efficient homogeneous vectors, before understanding why Python settles on heterogeneous lists and punts the rest to extensions)
From your link:
Perl is a interpreted language optimized for scanning arbitrary text
files, extracting information from those text files, and printing
reports based on that information. It's also a good language for many
system management tasks. The language is intended to be practical
(easy to use, efficient, complete) rather than beautiful (tiny,
elegant, minimal).
This is Python, an extensible interpreted programming language that
combines remarkable power with very clear syntax.
This is version 0.9 (the first beta release), patchlevel 1.
Python can be used instead of shell, Awk or Perl scripts, to write
prototypes of real applications, or as an extension language of large
systems, you name it.
This is very revealing! And prescient! The intent of the creators does seem largely borne out. Perl was extended to more domains but I'd argue that the "bones" prevented it from evolving as Python did.
optimized for scanning arbitrary text files, extracting information from those text files
to write prototypes of real applications, or as an extension language of large systems, you name it.
> Anyway I agree with most of what you say, EXCEPT I think Perl's focus on text vs. Python's more general purpose focus can be seen from the creators' very early release announcements!
Oh, I agree with that part, too; Perl's growth into a general-purpose language was very uncomfortable and surprising. I just think they were about equally terrible at linear algebra to begin with.
What would make a language good at linear algebra? I think you'd want, as you say, efficient homogeneous vectors, and also multidimensional arrays (or at least two-dimensional), non-copying array slicing, different precisions of floating-point numbers, comma-free numerical vector syntax (maybe even delimiter-free, like APL), zero division that produces NaNs instead of halting execution, control over rounding modes, arguably 1-based indexing, plotting, and infix operators that either natively have linear-algebra semantics or are abundant and overrideable enough to have them. Python didn't have any of those built in, and a lot of them can't be added with pure-Python code.
You'd also want flexible indexing syntax (that either does the right linear-algebra thing by default or can be overridden to do so), complex numbers, infix syntax for exponentiation, and a full math library (with things like erf, gamma, log1p, arcsinh, Chebyshev coefficients, and Bessel functions, not just log, exp, sin, cos, tan, atan2, and the like). Python 0.9.1 evidently didn't have any of those (you can do x[2:] or x[:5] but even x[2, 5] is a syntax error), but they were mostly all added pretty early, though its standard math library is still a bit anemic. Like Perl, though, the first version of Python did have arrays and floating-point support (arithmetic, reading, printing, formatting, serializing) from very early on; unlike Perl before Perl 5, its arrays were nestable. (Perl 5, in 01994, also added a slightly simplified version of Python's module and class systems to Perl. I forget if "use overload" was already in there, but it seems to be documented in the 01996 edition of the Camel Book, so I guess it was in Perl 5 from pretty early versions.)
Numeric and Numpy added most of these things to Python, and IPython, Matplotlib, and SciPy added most of the others. Adding them to Perl 5 would have been about the same amount of work and would have worked about as well, but the people who were doing the work chose to do it in Python instead. It isn't the choice I would have made at the time, but I'm glad they had better technical judgment than I did.
Nowadays, for a language to be good at linear algebra, you'd probably also want automatic differentiation, JIT compilation, efficient manycore parallelization, GPGPU support, and some kind of support for Observablehq-style reactivity. Julia fulfills most of these but they're hard to retrofit to CPython.
A shell is sort of an "orchestration language", in the sense that a shell script tells how to coordinate fairly large-grained chunks of computation to achieve some desired effect. We've seen an explosion of such things in the last ten or fifteen years: Dockerfiles, Vagrant, Puppet, Chef, Apache SPARK, Terraform, Nix, Ansible, etc. Most of these are pretty limited, so there's a lot of duplication of functionality between them. And most of them don't really incorporate failure handling explicitly, but failures are unavoidable for the kinds of large computations that most need orchestration of large-grained chunks of computation. I wonder if this situation is optimal.
Lua does support operator overloading:
Not sure if that was true 20 years ago.