To Perl or not to Perl, that is the question... ;o)

I bow here to experts who use both Python and Perl.
I am au fait with Python and have done loads with it, especially writing code that works from Version 1.4.0 to 3.7.0 on varying platforms, some of it on here...

Well, I have been contemplating learning Perl.
I see many experts on here who have posted Perl code and it looks like it can do much like Python can.
I have '_heard_' bad reports about it however so this discussion will help me decide.

Question: Is it worth me expanding my knowledge to this language or just stick with Python - any version?

If so I may jump in at the deep end and do yet another AudioScope, I have already done the same for Python and much, much more mainly for the AMIGA A1200.
Any decent books you know of to purchase would be of help too.
I love hitting the hardware, ("banging the metal"), and this has to be taken into account for my final decision...

TIA Guys and Gals...

FWIW, maybe not much, I used to program extensively in PERL 20 years ago and at that time I was a huge PERL advocate.

Fast forward to 2019 and I never use PERL for anything, never.

EDIT: Maybe I should? :slight_smile:

1 Like

Banging the metal -

Some Solaris 10 & 11 performance and system analysis code runs using perl interfaces - Dtrace for example. Dtrace also runs on Linux, again perl is a major player.

Because of SciPy and NumPy a lot of scientists like myself use Python - more because of the libraries than for any other reason. For system stuff Dtrace is great.

No matter what you "hear" about any coding environment, there is a huge BS component to it. You should pick the tool that fits your needs - not someone else's perceptions. There have been a nauseating number of threads on UNIX.com in the past - 'What is the best language to learn (or to code in) ?' No language is perfect for everyone. Period.

3 Likes

Anyone who is a �decent� programmer learns and in multiple programming languages.

And ....

Anyone who is a �decent� programmer continually learns multiple new programming languages as time passes and technology changes.

As I said, I used to program extensively in PERL, twenty years ago but not now. Seems my use of PERL in day-to-day operations almost exactly follows the "Google Trends" curve, below:

Others are always free to do as they please, obviously; and for those who want to learn PERL, please do!

I used to love PERL for sure. As for me, I am definitely not into �tech nostalgia� (that's just me); but then I do not collect stamps or old cars; but that is just me :slight_smile: I am more of a �zen programmer� and toss out unused tech in favor of the new. But as I said, that is only me. Others are obviously free to do as they like, of course; and that is how it should be.

I would not describe other's ideas and opinions here about "personal likes and dislikes regarding programming languages" at unix.com as �nauseating� as MadeInGermany just did. Everyone is entitled to use any programming language they like and it is normal for most humans to have passion about things they like and dislike.

When someone asks for an opinion then everyone, rookies to "experts" are free to chime in as long as they follow the long standing forum rules. Here they are (again) as a reminder:

I had a lot of experience with perl, however I understood that perl is dying. Hence I would not recommend it to any beginner.

1 Like

"Dying" is hyperbole. By that metric I'm sure awk has been dead for half a century. It still persists where its feature set is useful, as does Perl.

One thing that makes Perl especially useful is its excellent - and several - libraries for dealing with Excel files. If your question ends with "...with Excel files in Unix", 9/10 times the solution will involve Perl somewhere.

But the main thing I see Perl used for these days is DNA. Makes sense to throw the most featureful string language there is at the longest string there is...

2 Likes

I'm not a great perl hacker either. It was my first Scripting Language after bash in Linux ~20 years ago. The syntax is uncomfortable to me. It's quite fast. It's a usable general purpose scripting language, that scales a lot beyond shell scripting. I hadn't been using it for real work for a long time now.

I would not say it is a must learn. It has some unique points in it's purpose of using. So I will probably use it, if those points matter.

  • great stability of syntax (stick to version ~5.00x if you like to have that)
  • great availability(still available in the newest systems)

Some people still use it for current code(e. g. Proxmox, great open source virtualization management solution and mail filtering solution).

If you like to generate good code, you may do in perl too(or even the opposite - if you like).

The version number rised considerably in the last years and wikipedia mentions that features of the not-really-used perl 6 are being integrated zu perl 5 step by step. Maybe those features are worth a look?

Perl 5 version history - Wikipedia

Its Anti-Hype atmosphere appears kind of cool to me.

1 Like

As a side note, when I was the lead guy during the once famous "Langley Cyber Attack", where my work in an epic "email reply spam battle" happened over two decades ago, long before spam filters became of age, we wrote all our email anti-spam filters and detection algorithms in PERL.

Edit: For anyone interested in the early days of "cyberwar" in the 1998/1997 timeframe:

E-Mail Bombs and Countermeasures: Cyber Attacks on Availability and Brand Integrity
April 1998IEEE Network 12(2):10 - 17
DOI: 10.1109/65.681925

https://www.researchgate.net/publication/3282628_E-Mail_Bombs_and_Countermeasures_Cyber_Attacks_on_Availability_and_Brand_Integrity

That PERL code "way back when" was "very crude" by todays standards, but it was very effective and fast. PERL was the best tool for that job "way back when". I was a huge PERL advocate back then, and would write all scripts in PERL, even when PERL was not needed. I loved PERL so much back then that I tried to get everyone to learn it and use it.

Sometimes old guys like me forget that the younger generations may not have had the chance to develop code in PERL and other "out of favor" programming languages these days. But when I read this discussion it brings back wonderful memories of some of the best "tech days" of my life, defending the US Air Force against hackers with PERL scripts in real-time.

wisecracker, I say "go for it" if you or anyone reading this has the time or interest to learn PERL. I would love to see a lot of people posting PERL problems here. Perhaps that would jog even more great memories from decades ago from the deep trenches of cyber warfare battles when the web was but an infant.

Yeah, however --C, LISP and Perl are not fads and even though tech changes rapidly there are some tech like C programming that is a mainstay. I would say a hacker needs a good understanding of C/C++,Python, Perl, Java and LISP. For hackers, learning Perl is good practically as it is the language used on many active web pages. Even though a hacker might not use any Perl code it is important to know how it should be read. And just to clarify I could be talking about grey hat and white hat hackers here just so I don't get banned.

However, that latter point is tricky as Python has clearer to read syntax. Perl leaves more room for artistic programming expression and 'there are many ways to skin a cat' which can make it difficult to read. Perl is basically like sed/awk but on steroids that is what makes it so good for tools like libwhisker/nikto for parsing through port 80 web insecurities.

I see you used google chart statistics and while obviously dramatic I'm sorry to say they are not as authorative as the Tiobe index.

Perl is still hanging on within the top 20 most popular programming languages which is pretty impressive given how long it has been around. LISP is not even on the list but I would learn it before some of the more fly-by-night trendy programming languages on there as it helps you think differently as a hacker. LISP is a challenging language to learn and requires more from the hacker with each interaction. For a hacker this is excellent news because it means that a continuous effort is being placed on their developing skill. The advantage of using LISP is that it has one result, it will make you a better hacker in the long run even though you it is unlikely to be used regulary. If you don't believe me about LISP read the book The Structure and Interpretation of Computer Programs it is a computer science textbook by Massachusetts Institute of Technology (MIT) professors Harold Abelson and Gerald Jay Sussman with Julie Sussman.

It will still make you a grand master computer programmer today even though written in 1985 and updated in 1996. You know people still read K&R The Programming Language and use C programming too don't you know ?

P.S. Sorry, for going off topic with LISP but this guy already dived in head deep with making an Oscillograph with PERL so I decided to make this post for other readers who are interested in cybersecurity and also make the moral of the story that trendy new shiny languages are not always better although I am not denigrating Python here.

1 Like

a 20 years ago I wrote a very large and complex server in perl. That PERL code wasn't "very crude", but fits to all todays standards,
That server still is running 24 hours each day. It never stops, never shows any bugs or 'features', and performs very fast and secure. I would write it again if it wouldn't exist already.

2 Likes

Hi DracoSentien...

I assume you mean me, I jump in at the deep end with something like Oscillo[scopes/graphs] as I know far more about measuring gear than programming so I know what I want from the language.
I did al[l]sorts using Python from versions 1.4.0 to 3.7.4 and now include 3.8.0.
Python is soooo easy that I now dedicate my Python code to work for the AMIGA Python 1.4.0 to 3.8.0 on __all__ platforms.

This is my 'pièce de résistance' all hosted on this site, in case you have never seen it, I wanted to learn bash and it is a huge read and the ADMIN allowed it to be hosted here:

The Start Of A Simple Audio Scope Shell Script...

AND follows on here:

AudioScope Project.

I have a much later version but not uploaded yet but the thread can remain closed until I am ready.

You might like this in pure ksh93, a Discrete Fourier Transform, oh the pleasure of floating point:

DFT using pure ksh ONLY!

I don't think you will ever see anything like these anywhere else, and I still haven't found the limits of bash yet, and certainly not ksh93!

As for LISP, I watched several episodes of this whilst at work, (shhhh), and got a mild grasp of the language, this is the very first video, MIT:

YouTube

1 Like

Having "said all that" and "read all that" .... and now veering off topic ....

I have always admired people who "do" versus those who talk about "doing". Everyone "talks".... but "doing the talk" is a whole different story. That is why I never recommend being "certified" and always promote "building projects and applications".

So, when someone writes code to solve a problem, automates some process, or processes some data (what ever it is), in any language, especially beginners - I think that is much more interesting that the person who comments and critiques the work of others, touts one programing language over another, pushes commercial driven "standards" at every instance, but rarely actual creates nor releases any software of "operational value".

The "engineering ethic" (at least the one thought in the universities I attended way back when) is that engineers design and build for the benefit of society; and there is no "ethic" that the code must be written in PERL or Python, KSH, Bash, Javascript, PHP, using "this or that rigid design philosophy" or whatever. Nor is there any "ethic" that all artists use the same media or painters all paint with the same colors and brushes.

Like many here, I code for production applications nearly every day (even if only for an hour in a single day). This weekend I worked on a Javascript-based application and a PHP-based app. I enjoyed both. Both were production apps used by millions of users every year, in one way or the other. It does not matter for me if I was building the feature from scratch, reverse engineering a good idea, bug fixing an app, or upgrading one. It is all "constructive fun" and good for the mind, soul and spirit.

For those reasons and more, I like when wisecracker and others post their creative work, regardless of the programming language they choose. It's all the same to me, for the most part: reading and writing files (data), conditional branching and loops, pattern matching and extraction, etc. it's like ordering food. If I the menu is in English, Thai, French, Chinese or German, it is still "food", at the end of the day,

Everyone should follow their own dreams and learn as much as they can (all the time, everyday); and unlock their own creative abilities and interests. Most of all, we should stop worrying about what others say or do; because in the end, what matters is what we do (ourselves), not what other people, especially those of strong opinion and forceful voice, do. Always keep the mind of the "beginner" even when you are very good at many things.

Keep up the good work wisecracker, the world needs more talented, creative people like you; and thanks for sharing your creative work here at UNIX.com.

1 Like

Hi,

short notice from my side:

For a current project I decided to use Perl. The platforms are Linux / Red Hat 5/6/7/+future Versions. The reason I chose it, where:

  • Available on all target platforms without the need to increase software stack
  • A lot faster than shell scripting
  • Perl is quite fast when it comes to log processing, since this it is its initial purpose, compared to other scripting languages

After using it for a while now, the language itself is not that appealing because of those reasons to me:

  • I do not like Variable sigils: On Sigils
  • Function parameters not defined within the function definition(sub), but that's doable in a similar looking way
  • Some functions do not return a value but just modify it, like that:

    text # Desired: $line = chomp($orig_line); # $line got the value from chomp; # $orig_line is not modified # Perl: chomp($orig_line); # $orig_line is now modified The desired version makes it easy to nest or chain commands like that(ruby example): orig_line.strip.split("\t").map. ....

But overall perl is ok. It does the job. It provides a good overall basic toolset. I try to avoid modules when possible, especially when not contained in perl core and thus giving up comfort, reimplementing things which are done in a better quality, for reducing Installation efforts needed and keeping Codebase small. (If you use modules, you may end up with other dependent modules).

3 Likes

my server uses ~ 20 modules. I never experienced any problems within 20 years.I used to install them by CPAN, however experienced recently, that they all are part of the Fedora repository, thus I'l switch to it in a near future.
The modules are made for being used. Never reinvent the wheel!

Quote stomp:

This is precisely the reason I use, (occasionally now), Python. It is useful enough with its builtin libraries. I try to steer clear of those libraries that could be dependencies for any project, especially for the AMIGA.
I have not ignored this Perl project I will follow on soon with a drawing routine to join up the dots.