Can't resist adding my 2c On Mon, Apr 03, 2023 at 11:20:26PM +0200, Eduard Bloch wrote: > 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.
Google adopting python early on has something to do with this, too. > 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 I'm surprised to hear this. What is not cross-platform about CPAN? > - 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 I'm not sure about the connection with managing variable lifecycles, perhaps you can explain. This pragma *does* catch a class of typos that python is vulnerable to. Perhaps python IDEs take care of this. > - 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 For writing any code it helps if you understand the underlying concepts. > 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 Well, it doesn't make much point to discuss it here, but I'll note that there are legitimate criticisms and solutions for those who want them. Also, I seem to recall perl borrowed its OO design from python. Checking... yes. "I don’t really know much about Python. I only stole its object system for Perl 5. I have since repented."(*1) There is a new object system being cooked up, based on decades of experience with OO in perl and other languages. There is already more than enough OO goodness for me to get my work done :-) > - still sucky when it comes to complex data structures Well, maybe this is not the place to discuss it, but I'm curious if it's the syntax or the implementation that bothers you. > - ECO system unfortunately slowly fading away I would say the most highly depended-on distributions in CPAN are well maintained and new contributions continue. Sometimes I encounter a project (like Prima, a cross platform GUI) that has been around for years and only now come to my attention. As part of developing new perl releases, the entire of CPAN is checked to make sure new features do not break existing code. > - error handling (exceptions?) Of course this can be improved. The basic behaviors are sufficient, tho. > - sometimes too rigid ways of method calling Perl is rarely accused of this. Using it's the other way around-- too many ways. Do you have a specific example? Otherwise I don't really belong comparing the two languages as haven't done significant work with python. Have fun with whatever language :-) Joel > 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. > 1. https://www.perl.com/pub/2007/12/06/soto-11.html/ -- Joel Roth
