Re: Is perl still the No.1 language for sysadmin?
Hallo,
* Emanuel Berg [Mon, Apr 03 2023, 02:15:10AM]:
> > The reason Perl gives you more than one way to do anything
> > is this: I truly believe computer programmers want to be
> > creative, and they may have many different reasons for
> > wanting to write code a particular way. What you choose to
> > optimize for is your concern, not mine. I just supply the
> > paint—you paint the picture.
>
> I agree but I think maybe the success of Python, and its
> development speed, is actually because of some of that
> rigidness, yes, including the whitespace lack of freedom.
I don't think so, Sir! Python has certain advantages but the "meaningful
whitespace" is IMHO not one of them.
That said, I have been an active Perl user ~20y ago and for the last
couple of years slowly converting to Python for scripting purposes,
still using Perl here and there.
Therefore, my recent impressions and reflections:
Perl:
PRO:
- still excels on creating quick solutions in a one-liner for many
purposes where string/text input/output and some generic algorithms
count
- great cross-platform availability as long as you don't need CPAN, even
part of Git-Bash and therefore an "obligatory" component
- IMHO clean lifecycle of variables. Means, you can set "strict" and
then be sure that you manage your variables correctly, without much
risk of strange runtime effects
- flexibility in statement writing (although making them sometimes
looking strange and requiring more brackets than you initially wanted)
- a "friendly" API for users who just came from Bash or AWK scripting,
many things would look familiar and need only minor adaption,
especially when one knows "computer science" and understands what is
going on underneath anyway
NEUTRAL:
- true threads are possible... the last time I tried that was great but
unstable, but I think they have fixed it in a rewrite a while ago (not
tried again for years, cannot tell for sure)
CONTRA:
- OOP is awkward, has always been, it just sucks
- still sucky when it comes to complex data structures
- ECO system unfortunately slowly fading away
- error handling (exceptions?)
- sometimes too rigid ways of method calling
Python3:
PRO:
- HUGE and modern ECO system, and mostly good&useful documentation
- Developers listening to user's wishes, recognizing and completing
missing features and seeing modern developments
(things like string interpolation with f-literals)
- flexible ways of method calling with default/optional/... parameters
- a certain level of rigidness keeps your code understandable even if
you touch it a year later, and also for the code from your colleagues
- the uniform usage of certain infrastructure components (like argparse)
became universal in the last few years
NEUTRAL:
- OOP is okay. Good or bad depending on whom you ask. Good because it
allows for "wild west" OO design which still allows the interpreter to
convert it into something useful in the end. Bad because this happens
and runtime and because there are life-saving type checks and no real
interfaces possible with Python.
CONTRA:
- OOP: ... one MUST keep writing "self." prefix all the time. What the
heck, one of the reasons for refactoring to OO style is to have this
shortened because the context prefers local objects.
- "meaningful whitespace" - whoever came up with that concept should maybe
rethink it, and give people alternatives
- no (easy user-controllable) concept of references etc. which always
feels like something causing memory waste
- performance SUCKS when it comes to actual computation (yes, there is
Cython coming as alternative and replacement/completion but it has its
own issues)
- awkward lifetime of variables (yes, they are not variables,
just "assignments" AND YOU GONNA KNOW IT WHEN YOU UNDERSTAND REAL PYTHON,
haha, I know, but still, it's a very unusual model, and unnatural /
problematic to handle for developers who are used to scope driven languages)
- performance (again) of multi-threading... GIL sucks, making regular
Python basically a single-threaded language (considering that
performance gain is the main performance of MT)
So that were my few cents regarding the scripting languages. For a real
n00b nowadays, I would still recommend to learn Bash first. But always
keep in mind that "Bash programming" is a mix of executing commands in
the own language but mixing the result with the external forking of
other programs.
However, the lines between "scripting" and "real programming" languages
are blurry. If one is asking for the later, nowadays I would suggest
learning C# or Rust.
Eduard.
Reply to: