> A little bit of a primer one of the biggest motivation of the original > writer of Python was he hated how sloppy Perl programmers were and wanted to > create a language that enforced what he thought were good coding practices.
And then they invented pypi, and "pip install" where the same package of the same name and version on Tuesday has a different checksum, different content, and different dependencies than the same package which pypi allowed the developer to replace without renumbering, and instead invented an unreliable and unpredicatable checksum based indexing to segregate between the different versions. Python, and pypi, and busilly rediscovering many of the same sloppy sins of Perl and CPAN is not a good use of engineering time. Neither is burning hundreds or thousands of man-hours to write complex tools like the "awscli", and getting basic features wrong through complete failure to document, like whether the "sync" command overwrites or makes a local copy and then replaces local files, or misreports "/dir1/dir2/filename" as "../../dir1/dir2/filename" because the author doesn't understand what an absolute directory path means or realize just how badly direcotory symlinks can screw up relative paths. I'm not finding myself impressed with Python development. Spending so much time to rewrite tools that already exist, work better, and have defined interfaces does not seem to me be useful engineering. > As for Python it's become popular and definitely Red Hat's favorite scripting > language. It's got a great following and is used for many things. > > As for modules Perl 5 still has more but many of the are dated, Python is > catching up and it has the benefit of youth and popularity. As a sys-admin over 50 years old, I'm not over enchanted with youth and popularity. > For example Amazon AWS has a Python API, but not a Perl API. I've been > debating about writing one my self and in the Perl tradition there are 2 ways > I can do it build on LWP (lib WWW Perl) to create a native Perl module, or > take the lazy route by create an "XS" module which wraps the C API. The > advantage of the XS method is I can run a script and have a clumsy but > working module in seconds, then spend a couple of hours to make it easy to > use. See above. The awscli and the Python API it partially defines, and is the reference implementation for, are *horrible*. Even such ISO standards as regular expression matching for file and directory names, and ISO standards for dates, are casually ignored without warning. One of the very reasons it's very exciting and "new" is because many of its authors are simply ignoring standards, implicitly and explicitly, and not realizing that they have to deal with even the simplest standards as command line options and error reporting. Code gets more complex and harder to write when you have to handle errors, and it's *very* common for new languages to be faster until actually tested with real uses. > What you will here is Perl is dead, but the truth is most people use it on a > daily basis and don't know it. Perl is still the swiss army chainsaw of > scripting languages. Hear, hear. (And that is how it is spelled, by the way.) > Honestly for support on learning Python is easier. > With Perl if you can get to the point where you really understand the power > of anonymous references, it's still a very fast and flexible language. > > In conclusion > Either one is good. Learn them both at least superficially. Tinker and play > with them and see which one is right for you. I'd suggest learning bash first. Many complex perl, python, php, etc. tools are actually wrappers for a few lines of shell.
