[HN Gopher] Why Perl?
___________________________________________________________________
Why Perl?
Author : Flimm
Score : 148 points
Date : 2023-06-12 09:13 UTC (13 hours ago)
(HTM) web link (two-wrongs.com)
(TXT) w3m dump (two-wrongs.com)
| jjgreen wrote:
| In my dreams Python has the stability of Perl, then I'm woken by
| an alarm that a Python script I wrote 6 months ago uses a now-
| deprecated feature ...
| Hamuko wrote:
| Deprecation doesn't really mean that your script is broken or
| going to break anytime soon. unittest.UnitTest.assertEquals()
| has been deprecated since 2011-02 (Python 3.2) and is set to be
| actually removed 2023-10 (Python 3.12).
| jjgreen wrote:
| Not always, but for the sake of your sanity you need to fix
| those deprecations, if only so you can see the new ones, one
| of which will break your script at some point.
| andrewstuart wrote:
| This is a new one on me .... Python is unstable?
| KaiserPro wrote:
| One of the things that I noticed when I started python (many
| many years ago) is that it crashed a lot more than perl.
|
| perl you really had to properly abuse it to make it actually
| crash.
|
| Now, some people see that as a feature not a bug (for either
| perl or python's behaviour)
| qsort wrote:
| It's certainly less stable and ubiquitous than Perl. These
| days I'd rather be on Python (better libs, doesn't spook
| colleagues, very common on Linux boxes), but it's not an
| unreasonable position.
| t8sr wrote:
| Very much so, insofar as code written a few years ago
| probably doesn't work anymore. Some of that comes down to
| libraries not being careful about versioning, but a lot of it
| is the language itself making seemingly random changes in
| direction every few years.
|
| 10 years ago: range 5 years ago: xrange Today: range again,
| LOL!
|
| I don't know of any tech companies using Python for anything
| serious anymore, except data/ML analysis, which is usually
| not too much code. If you make me rewrite the thing, it's
| getting rewrote in Go or Rust, not Python again.
| BeetleB wrote:
| > but a lot of it is the language itself making seemingly
| random changes in direction every few years.
|
| Outside of 2 -> 3, I can recall only one or two instances
| of dealing with this in the last 15 years. One was the
| introduction of "with" and "as" as a keyword. The other one
| I can't even remember.
|
| None of the code I have written on my personal PC in all
| these years needed modification due to these changes (all
| of them were in 3rd party code I needed to patch). I still
| have Python 2 scripts continually running! I have Python
| 3.10 installed, and never had to fix a broken script of
| mine since I switched to Python 3 several years ago.
|
| > 10 years ago: range 5 years ago: xrange Today: range
| again, LOL!
|
| Eh? When I began using it heavily (before Python 3
| existed), both range and xrange were heavily in use - one
| was a list the other was a generator. Since Python 3 has
| been stable and fast (circa 2013 or 2014), it's been only
| range.
| telmo wrote:
| > I don't know of any tech companies using Python for
| anything serious anymore, except data/ML analysis, which is
| usually not too much code. If you make me rewrite the
| thing, it's getting rewrote in Go or Rust, not Python
| again.
|
| It is weirdly comforting to observe how certain things
| never change over the years, even in tech. One of them is
| the hyperboles people deploy when attacking programming
| languages that they do not like: "I don't know of any tech
| companies using Python for anything serious anymore". I
| mean, except for being the 4th most popular language
| amongst professional according to last year's Stack
| Overflow survey. Only JavaScript, SQL and HTML/CSS are more
| popular. Yes, yes, I am sure it is dying... any moment now.
| t8sr wrote:
| You just read what you want to read, friend. I don't
| particularly dislike Python, in fact I wrote about 50k
| lines of it a few years ago.
|
| My claim is that the big names don't really use Python
| outside of data pipelines. Where I've worked (including
| an org that had had Guido on it for a while) usually had
| guidance saying "no new Python projects". You can ask
| people at Google, Meta, etc when was the last time they
| wrote production Python code if you don't believe me.
|
| That's not mutually exclusive with web devs on Stack
| Overflow using the language, nor does it take away from
| its success in academia.
| nerdponx wrote:
| > Very much so, insofar as code written a few years ago
| probably doesn't work anymore.
|
| Citation needed? Just a week ago I used a Python library
| completely unchanged from 2013.
|
| > Some of that comes down to libraries not being careful
| about versioning, but a lot of it is the language itself
| making seemingly random changes in direction every few
| years.
|
| "Seemingly random" is both wrong and insulting. The BDFL
| did step down and was replaced with a steering council, so
| maybe that's what you're seeing. I do agree that `match`
| was a bad addition to the language, but that's one small
| example among many supporting the opposite opinion.
|
| > 10 years ago: range 5 years ago: xrange Today: range
| again, LOL!
|
| Huh? Python 3.x has only ever had range(), so it's been
| range() for at least 10 years.
| raverbashing wrote:
| > it's getting rewrote in Go or Rust, not Python again.
|
| Have you ever tried to recompile 1 yr old code in Rust with
| the latest compiler?
| cesarb wrote:
| > Have you ever tried to recompile 1 yr old code in Rust
| with the latest compiler?
|
| I have, more than once; it worked perfectly fine.
|
| The only time it's broken for me is when the code had
| unstable nightly-only features, hidden behind a "nightly-
| only" feature flag, which was rejected by the parser on a
| newer Rust compiler, even though it would not be compiled
| due to the feature flag being disabled (even though it
| wouldn't be compiled, it still had to be _parsed_ ; IIRC,
| it was the change to the inline assembly syntax, and the
| fix was just to change from "asm" to "llvm_asm").
| orwin wrote:
| Why wouldn't you tag your 1 year old code with the
| compiler it was written for?
|
| And same question for grandparents. I'm not a great dev,
| average at best, but at least I control my systems.
| gkbrk wrote:
| Why should you need to? Just use a stable language, or a
| language that has a standard or a specification.
| stonogo wrote:
| If that's what best practices are for these languages, I
| now better understand my collegues who will not move away
| from C/C++. Having to identify a specific compiler
| version for each bit of code sounds like a nightmare.
| zkldi wrote:
| it's very easy. you make a file called `rust-toolchain`
| next to your `Cargo.toml` that contains the version of
| rust you intend this to compile for.
|
| It will then compile for that version.
| bamfly wrote:
| C and C++ projects of any notably complexity & size often
| suffer from those exact same kind of "library or build
| tool or compiler updated--now the project won't build"
| problems. Absent some pretty heroic & unusual levels of
| discipline from all involved, anyway (which is also a way
| to avoid those issues in most other languages that have
| them).
|
| [EDIT] Check out issue trackers for such projects, some
| time. "Build broke due to [thing] being too new" is a
| _routine_ issue to encounter.
| andrewstuart wrote:
| Maybe Perl is stable cause its dead.
| meepmorp wrote:
| Latin and Sanskrit are stable af.
| jjgreen wrote:
| Latin is pretty stable, but not entirely fixed:
| https://www.nytimes.com/2003/05/14/world/vatican-
| introduces-...
| drewcoo wrote:
| I took a medieval Latin course in college that was
| especially challenging because after the empire fell,
| Latin was absolutely not stable.
| rcarmo wrote:
| This goes against my own experience. I moved from Perl 4 to
| 5 and from Python 2.x to 3.x and have dozens of projects
| written in Python that have been constantly updated over
| the past 10 years, none of which broke due to those things
| - and they are not all in the ML space.
|
| Your sample size of one needs expanding.
| Roark66 wrote:
| How about a fortune 300 company I consulted for that uses
| python pretty much exclusively for the deployment processes
| of their 200+ web/cloud apps? Some of those apps have 1 VM
| plus a DB and a dozen users. Some have environments that
| cost PS30k a month and 5k users. Python is the only
| language used for CI/CD. Plus power shell for stuff that
| needs windows server.
|
| 70% is python 2, 30% written/rewritten recently is python
| 3.
| josefx wrote:
| > 70% is python 2
|
| I hope they are paying for security updates since python
| 2 has hit EOL 3 years ago and libraries had been actively
| shamed if they didn't drop support for it long before
| that.
| smcl wrote:
| The criticism is that the Python team will deprecate and
| remove functionality as it's not needed? Boy, you're gonna
| hate PEP-594.
|
| Also Python 2->3 transition was a one-time thing that
| developers had over a decade to perform, it may have been
| painful for some but saying it's a random thing that
| happens "every few years" is a bit dishonest.
| stonogo wrote:
| Are you saying there will never be a Python 4, or are you
| saying that the 2->3 transition was so badly flubbed
| nobody will make that mistake again?
| fullspectrumdev wrote:
| PEP-594 is actually causing me some anxiety - I deal with
| a good amount of code that uses some of those "batteries
| to be removed".
|
| Some of them (telnetlib) I can vendor in, but I wonder
| how many people who use them will be caught pantsless?
| jjgreen wrote:
| Clearly an example of a parallel universe leaking into my
| own, can I come and live in yours? Please?
| kdklol wrote:
| Can confirm, recently written scripts require modification
| pretty much every minor version. Take the limit on the
| default size of BigInts now. Why? Just... why? I had to look
| into every script add the override line at the top (or check
| the entire script it ever assumes unlimited BigInt anywhere).
| No wonder there are still Python 2 scripts in use.
| nerdponx wrote:
| Which feature? Deprecation warnings tend to be in place for
| several years before removal. There's a formal policy for it:
| https://peps.python.org/pep-0387/
|
| > Unless it is going through the deprecation process below, the
| behavior of an API must not change in an incompatible fashion
| between any two consecutive releases. Python's yearly release
| process (PEP 602) means that the deprecation period must last
| at least two years.
|
| In practice, it's usually longer than two years, except on
| features that were considered provisional in the first place.
| dmz73 wrote:
| I wanted to like Python. Every time I tried to use/learn it,
| the "program" I wanted to use had some issue. The very first
| one (some 15 years ago) depended on mutually incompatible
| libraries so I had to spend time not only learning Python but
| fixing the libraries to work together. Next one was a dlna
| server that managed to use up all 4GB RAM available on my NAS
| and make the whole system unusable. Then there was a "compiler"
| that worked on all OS-es except that on Windows it would 100%
| not work due to some path string handling when starting a
| process. How do you even get to that point...that could have
| never worked on Windows and it's not like Windows is some
| marginal never used system so no testing was required. Then I
| tried to write a simple script to transfer some emails via
| IMAP...and Python idea of supporting IMAP is for me to read the
| RFC and build the correct string to sent to IMAP
| server...WTF???? That is the assembler lever of "support" of
| something. I did try to do that and then I ended up with
| multiple pages of something that looked like level of arcade
| game with climbing hills and cliffs of code where it was hard
| to tell if code was meant to end or if someone got bored of
| writing and just gave up. I hate Python.
| anthk wrote:
| Heh. On Python and IMAP, getmail was dog slow against
| isync/mbsync. Same RAM issues.
| tokai wrote:
| What? The Perl 6 debacle has gone down even worse than Python
| 3.
| b1c837696ba28b wrote:
| Really? Was Perl 5 deprecated with prejudice across
| ecosystems, forcing projects to work with a janky, still-
| evolving replacement well ahead of production-grade
| stability? Because the boot marks in my ass from the forced
| march to Py3 are still bleeding.
| wwweston wrote:
| Perl 5 has been usable and improved on continuously over the
| last 20+ years.
|
| Raku / Perl 6 has been the R&D project it set out to be with
| interesting new features and smoothed out syntax.
|
| You can use either freely as meets your needs. If there's a
| "debacle" here it's the misunderstanding.
| G3rn0ti wrote:
| Perl 6 took longer than expected but ,,Raku" is alive and
| well. It even moved into the Tiobe-Index at rank #48
| recently:
|
| https://www.tiobe.com/tiobe-index/
|
| This whole Python/Perl competition was always a bit silly.
| Both languages had and have their place. I would say Python
| is so much more popular because it found a niche in ML
| because of how much more easy it is in Python to interface
| fast C modules. So you get to write simple Python programs
| leveraging blazingly fast math libraries. That was always a
| bit more tricky to do in Perl.
|
| But Python as a language is definitely not as flexible as
| Perl 5. Last time I checked Python didn't even support multi-
| line lambdas because its inventor hates those. Python is very
| much designed in a top-down approach and tries to guide all
| Python programmers into how there are supposed to solve their
| problems. Perl 5 was designed with its famous ,,easy things
| should be easy, hard problems possible to solve" philosophy.
| It allows for meta-programming in all the right places which
| a seasoned Perl developer can reach to when necessary. Perl 5
| is a nice middle way between C and Lisp.
|
| That being said modern JavaScript turned into a powerful
| language that fits well into both the frontend and backend
| side of a web application nowadays and, hence, kind of
| replaced Perl as glue language for the web. It will also push
| Python out of web backends at some point I believe.
| achileas wrote:
| Having used Python and Perl professionally, I'd have to
| agree with really all of this. I just want to emphasize
| Python's niche in ML (since that's what I do with it mostly
| lately) - it was also helped by a large, early set of
| libraries specifically for ML that other languages either
| still don't have or are playing catch-up (Elixir), and its
| ease of use among academics, a lot of whom went straight
| from academia to industry.
| xupybd wrote:
| Does ubiquity still count when you have dependencies?
|
| I find any Perl application of reasonable size collects a few
| dependencies and they can cause pain when installing on different
| systems.
| WesolyKubeczek wrote:
| No it doesn't.
|
| And god have mercy on you when you find a transient dependency
| with an unfixed bug reported a decade ago whose author went
| AWOL.
| jamespwilliams wrote:
| > I can be confident that a Perl script I write today will run
| unaltered 10 years from now, modulo external collaborators.
|
| Yeah, because the ecosystem is dead. The flipside is that the
| bulk of Perl modules available are stale and don't receive any
| security updates or bug fixes. If I had a pound for every time
| I've seen a 10+ year old bug with no comments in the CPAN issue
| tracker...
|
| > Perl has a small set of core syntax and is very extensible and
| flexible in adopting new paradigms.
|
| Depends what you call "core syntax". The syntax available to you
| with a stock Perl install is certainly not small compared to
| other languages.
|
| > With a great amount of discipline, Perl scripts can be
| successfully scaled up into large, complex systems.
|
| If you're disciplined, you can write complex systems pretty much
| as well as you could in Python or any other dynamically-typed
| language.
|
| However, it requires a lot of discipline and experience, and with
| other languages you at least have good formatters and LSPs to
| help with that. Perl sorely lacks this kind of infrastructure.
|
| I also think the lack of static types makes writing complex
| systems massively harder, but that's not a criticism of Perl in
| particular.
| activiation wrote:
| > If I had a pound for every time I've seen a 10+ year old bug
| with no comments in the CPAN issue tracker...
|
| That's common in all large active open source project though..
| like Firefox, Android, etc...
| superkuh wrote:
| Perl was lucky that the Perl 6 diversion happened. If it had
| stayed the course and popularity it would no longer be perl
| like python is no longer python (such bad version dependency
| hell there's actually a layer of package manager hell). Now
| well after the perl 6 diversion Perl 5 activity has come back
| and there are new features. But most perl devs and the culture
| still has the habit of writing for portability and stability
| instead of using incompatible features a month after the
| compiler/interpreter/etc adds them.
| glintik wrote:
| > However, it requires a lot of discipline and experience
|
| That's true for any platform - Java or PHP. Perl has less
| support in modern IDE. Perl 5 to 6 transition failed many times
| so ecosystem lost many talents.
|
| P.S. I wrote and supported large Perl codebases, no rocket
| science to manage it, if you do it right.
| Diederich wrote:
| > Yeah, because the ecosystem is dead.
|
| Is it?
|
| https://metacpan.org/recent
| ajsnigrutin wrote:
| > Yeah, because the ecosystem is dead.
|
| Some of us would call that "mature" or "stable". You don't have
| to change the basics of the language every two weeks and have
| people rewrite everything every three weeks (when the three
| week old version gets removed from ubuntu).
|
| Look at LaTeX for example... ever goddamn academic uses latex,
| but it hasn't really changed for many years now... is it dead?
| Of course not.
| arp242 wrote:
| I don't think there's any mainstream language where the
| basics of the language change every two weeks or people have
| to rewrite things every three weeks.
|
| I realize you're exaggerating and that you don't _literally_
| means 2 or 3 weeks, but I have Python programs I haven 't
| touched in about 10 years that I still regularly use and that
| still work fine. Some of my oldest Go programs from over 7
| years ago still work fine, and I'm pretty sure that if I were
| to try running some of my older Ruby or PHP programs (some of
| which is >10 years old) today it would still work either out
| of the box or with a few small changes (IIRC some of the
| defaults in PHP changed wrt. errors, so that might need a
| little bit of fiddling).
|
| Even JavaScript - the poster child of "rewrite every 2 weeks"
| - is pretty compatible. You don't _need_ to switch to
| $new_js_framework and many people use older stuff just fine.
| The language itself is pretty compatible (almost to a fault,
| arguably).
| tialaramex wrote:
| C is a mature language. If they put out a new standard with a
| few changes once a decade that seems fine. But they do put
| out new versions, this year will see C23.
|
| LaTeX is just packages (which do change, all the damn time,
| it's a curse) on top of Knuth's TeX. TeX, it's true, is
| feature frozen, Knuth has asked that when he dies the version
| is increased from a close approximation of Pi to Pi itself,
| and no further bugs are fixed. At that point TeX will be
| frozen solid, I'd be surprised if it lives another twenty to
| thirty years, its purpose is digital typesetting and er, you
| may not have noticed but we ain't printing so many books
| these days. Once we're not setting type anyway, TeX's purpose
| expires.
| ilyt wrote:
| I dunno, even for maintained ones I've seen far les breakage,
| whether now or decade ago. It always seemed like default choice
| for Perl was getting a warning this way of calling something is
| depreacated, while in Ruby/Python it was "well, we changed our
| mind on that API, fuck you and your code".
|
| The way Py2to3 migration was handled was also some abomination.
| Meanwhile if I need my Perl code to work like old Perl I just
| write _use v5.10_ in header...
| formerly_proven wrote:
| Had a moment a few days ago with a certain distro not
| packaging latexmk. Turns out it's a one-file Perl script.
| It... just works. No dependencies, packaging, deploy process,
| automation, package hubs, no container with an entire OS, no
| private runtime, no binaries. Just half a meg of Perl. And it
| just works, and exactly like it did in the 90s. No fuzz, no
| bloat. We are completely lost these days when it comes to
| software.
| TylerE wrote:
| Counter argument: It's apparently half a meg of source code
| to implement a basic build tool. Not impressed.
| nequo wrote:
| The file is 10,284 lines long. Less than half of it is
| actual code. The rest is comments or empty lines.
| $ cat =latexmk | wc -l
| 10284 $ cat =latexmk | grep -v '^ *#' | grep -v '^
| *$' | wc -l 5982 $
|
| > to implement a basic build tool
|
| This basic build tool comes with a man page that is 26.5
| thousand words long. Not your typical basic build tool.
| cesarb wrote:
| > The way Py2to3 migration was handled was also some
| abomination. Meanwhile if I need my Perl code to work like
| old Perl I just write use v5.10 in header...
|
| To be fair, the way the Perl 5 to Perl 6 migration was
| handled was worse. It got so bad that they ended up renaming
| Perl 6 to something else, after it had already been released
| under the Perl 6 name.
| jinpa_zangpo wrote:
| The sweet spot for Perl is any problem combining text processing
| with Unix system calls. It's a system administrator's idea of
| what a programming language should be. I feel the reason why Perl
| got a reputation as a "write only" language is because it's easy
| to write a simple Perl script, so people with no programming
| background wrote a lot of ugly code. It's simple to write clean,
| maintainable code in Perl with a little discipline.
| nickdothutton wrote:
| Many, perhaps most ISPs in the 90s were built out of Perl,
| including my own. Like any language, there is a world of
| difference between a codebase written by an experienced,
| thoughtful, veteran, and something just cranked out by a 1st year
| student (as we all were once, myself included!). I frequently see
| Perl described as "hard to read" yet have seen many beautifully
| written codebases that are a delight to maintain.
| rcarmo wrote:
| As someone who maintained Radiator (a RADIUS server) at a few
| places, I agree. That piece of software alone was enough
| justification for Perl to be used in critical scenarios, and as
| far as I know some of those instances are still running,
| decades after I left (obviously not the same machines or
| versions).
| worik wrote:
| If only Larry Wall had not promoted "hubris" as a virtue.
|
| As a young impressionable programmer I drank that Kool Aid.
| sharts wrote:
| Why not Ocaml?
| habib_k wrote:
| What is ocaml?
| qalmakka wrote:
| Python and Perl areas of strength do not overlap, IMHO.
|
| Python is great to write well structured programs with modules,
| well defined classes, etc.
|
| Perl is great to glue stuff together in place of shell scripts. I
| see way too often people attempting to write Python scripts to
| accomplish simple tasks and they inevitably end up being full of
| boilerplate, third party modules, stuff that breaks at every
| python update, etc. Perl is changing but it always stays backward
| compatible, it's installed literally everywhere and it has
| unmatched regex support, so it's super easy to run a few commands
| and process their output.
|
| Perl is also arguably a better awk than awk and a better sed than
| sed, imho. I haven't used sed in ages because 99% of the time
|
| `per -pE 's/reg/ex/g' -i <file>` is way more convenient and
| portable than `sed`.
| nerdponx wrote:
| > stuff that breaks at every python update
|
| Eh? Python backward compatibility is excellent.
|
| Most Python 3.3 scripts still run on 3.11. The only big
| breaking changes have been in asyncio, which was explicitly
| marked as provisional for years and if you were using it in
| ~3.6 you knew and were warned that things would change.
|
| Packaging is another story, but we're talking about scripting,
| not distributing software.
| AlexSW wrote:
| I personally have run into breaking changes in Python's regex
| module, which is pretty fundamental to such uses as mentioned
| above.
|
| If I recall correctly, they changed how `re.escape` worked
| between Python 3.6 and 3.8 (I'm not sure which minor change
| exactly) in terms of which symbols received a backslash
| before them, thereby breaking my code.
| formerly_proven wrote:
| Perl 5 had a change there, too, in between the versions
| shipped in RHEL 7 and 8, iirc something about {} changed.
| parasense wrote:
| > Eh? Python backward compatibility is excellent.
|
| Sure, so long as one wilfully ignores the 2.x to 3.x
| transition, that took 10 years. To be clear, to presume
| Python starts at version 3.3 is slightly weird, but we get
| it... One good example here is when pip stopped working for
| old python-2.x.
|
| > Most Python 3.3 scripts still run on 3.11.
|
| I would agree python forward compatibility is pretty good,
| but not so sure about backwards compatibility.
|
| When the walrus operator first appeared, there was a period
| of time where scripts began using the new feature, and the
| version of the python interpreter used in all the places that
| script needed to run. Same thing for type annotations. And
| there have been plenty of breaking module changes.
|
| > Packaging is another story, but we're talking about
| scripting, not distributing software.
|
| That's fair, but avoids a big aspect of the problem
| statement, of when Python updates.
| rcarmo wrote:
| People keep beating the 2.x dead horse. Moving to 3.x was a
| non-issue in 90% of the stuff I've seen "upgraded" written
| as far back as 2010 (at a telco, with a lot of legacy). I
| stopped writing 2.x code in 2013, and 3.5 (the version that
| became the new baseline there since I left, which was
| updated to 3.5.10 in 2020) dates from 2015.
|
| I'm now running mostly 3.10, solely because there are a few
| binary wheels for 3.11 that aren't yet on ARM for some
| reason (mostly ML stuff, which tends to be maintained by
| academia).
|
| Any kind of argument that the 2.x -> 3.x transition is
| still relevant has to take in these timescales for context.
| Otherwise it just looks... dated.
| nerdponx wrote:
| > Sure, so long as one wilfully ignores the 2.x to 3.x
| transition, that took 10 years. To be clear, to presume
| Python starts at version 3.3 is slightly weird, but we get
| it... One good example here is when pip stopped working for
| old python-2.x.
|
| The 2.x to 3.x transition was specifically an attempt at
| making a clean break, bookended by 10 years of
| compatibility before and after, so it doesn't really count
| here.
|
| I deliberately chose 3.3 because that's the earliest 3.x
| version I'm aware of that started to see serious adoption.
|
| > I would agree python forward compatibility is pretty
| good, but not so sure about backwards compatibility.
|
| You're right. Forward compatibility is what's good, but
| that's what the thread here is about. Complaining about old
| Python scripts breaking in new versions is a complaint
| about forward compatibility. Backward compatibility is not
| good, but older Python versions are EoL anyway and if you
| want to use them you're on your own.
|
| > That's fair, but avoids a big aspect of the problem
| statement, of when Python updates.
|
| The relevant aspect here is that older packaging tools
| historically have relied on components of Python that have
| been deprecated for years and/or internals with no
| stability guarantee, which are gradually now being removed,
| and so older packaging tools (e.g. older versions of Pip)
| are finally starting to break. So yes, packages with
| complicated setup.py scripts from 2011 probably won't work
| as-is.
|
| People love to complain about Python packaging tools, but
| the PEP 517 transition is much like the 2->3 transition in
| that most applications are not hard to upgrade, and most
| big open source packages have upgraded already. Python
| packaging was absolutely horrible for years, it's not
| surprise that _something_ has to break in the process of
| making it less horrible. That most non-PEP-517 packages
| still install and work fine is a testament to how good
| forward compatibility actually is.
|
| I get really annoyed when people complain about how Python
| ain't what it used to be. It's _better_ than what it used
| to be, and a little breakage along the way is necessary to
| get there.
| Izkata wrote:
| > I deliberately chose 3.3 because that's the earliest
| 3.x version I'm aware of that started to see serious
| adoption.
|
| That happened because of what they were referring to -
| python 3.0 made a terrible decision with string handling
| that was remedied in 3.3, giving 3.3 significantly better
| backwards compatibility with 2 than earlier versions of 3
| had.
| ilyt wrote:
| I wouldn't call it anywhere near "excellent".
| sgt wrote:
| It's interesting that people say the same about Java and
| Python;
|
| Java is great for well structured programs and scalability.
|
| Python is great for scripts, just don't let the programs grow
| too much in size.
|
| (Not my opinion, I am impressed with how well Python programs
| can scale in size if using a proper framework e.g. Django)
| nerdponx wrote:
| Python is excellent for "medium scale". A little too verbose
| for very simple ad-hoc scripts, a little too unstructured for
| very large applications with a large number of developers
| (but this has improved substantially in recent years).
| ilyt wrote:
| I literally never heard that in 15+ years of my career.
|
| Generic sneering in direction of "scripting languages", sure.
| chuckledog wrote:
| I stopped using Perl 15 years ago, except for this exact use
| case. I still type "perl -pi -e" to wrangle source code or data
| files, at least monthly. The regex syntax is more consistent
| too.
| somat wrote:
| For me the real advantage of awk, and I love me my awk, is that
| the entire reference manual is 10 pages long.
|
| http://man.openbsd.org/awk
|
| Other than that I agree, awk runs out of steam rather quickly.
| Shell runs out of steam fast as well(my cutoff for moving out
| of shell to a better language is the moment I need arrays.) But
| the killer feature of shell, the thing I wish was in more
| languages is pipes. The ability to flow one process into
| another process with a single character. I never did learn
| perl. but doing the equivalent to a pipe in python is a lot of
| awkward wrangling with subprocess and manually assigning
| streams. The way shell can pipe into and out of control flow is
| magical to me.
| qalmakka wrote:
| > pipes
|
| In Perl you can just run commands using backticks or qx// and
| get their output, and so you can pipe them in any way you
| want: my @a = map { chomp; $_ } `ls -1 |
| sort | uniq`
|
| You can otherwise use `open` to spawn shells as if they were
| files, piping either on their left or right:
| open my $output, '-|', 'ls -1 | sort | uniq'; while
| (<$output>) { .. }
| dmd wrote:
| If you want to go beyond those 10 pages, the (also very
| short!) "official" book by Aho, Weinberger, and Kernighan
| ("The AWK Programming Language") is an absolute gem of
| technical writing. It is a _joy_ to read.
| LudwigNagasena wrote:
| With Python the scope of "simple tasks" moves from a bunch of
| shell scripts to eg parsing a webpage, getting images from it
| and running face detection on them. And if it happens so that
| your ad hoc script has to become a full-fledged program, you
| can refactor it, add API endpoints, monitoring and so on.
| qalmakka wrote:
| > your ad hoc script has to become a full-fledged program
|
| The very second a quick and dirty script grows into a full-
| fledged program, it immediately becomes technical debt.
| dkarl wrote:
| If by "technical debt" you mean something that requires
| updates and maintenance, then yes, because it's a living
| language. Perl has the advantage of being frozen in time,
| but it has the disadvantages of not being a living
| language: younger programmers not being prepared or willing
| to touch it, likely less library support for newer
| technologies. That constitutes technical debt as well,
| albeit of a different kind.
| iso1631 wrote:
| > The very second a quick and dirty script grows into a
| full-fledged program, it immediately becomes technical
| debt.
|
| It often becomes a business asset which delivers far more
| value to the business than any maintenance (often very low)
| which is needed
| shubhamjain wrote:
| > Perl has a small set of core syntax and is very extensible and
| flexible in adopting new paradigms.
|
| This is actually a deep flaw, rather than an advantage. There are
| so many ways to do a single thing in Perl that you just give up
| seeing them in the wild. It would take months or years of
| practice to get comfortable with every nuance of Perl. Even
| Google fails to help often (try Googling what "$_%@" means). I
| get it; the terseness can feel for an advanced user, but folks
| like me, the verbosity of Python and Javascript is much more
| preferable.
| nuker wrote:
| What "$_%@" means for the love of god?
| jlokier wrote:
| It doesn't mean anything in Perl. The comment is a
| demonstration of why some criticisms of Perl are unjustified,
| as people love to make up little things like that, then other
| people such as yourself end up with the impression that sort
| of nonsense is ordinary Perl.
|
| (You could imagine at a stretch those characters as part of
| an unrealistic expression, like "print $_%@array" meaning
| "print the value of $_ modulo the length of @array", but you
| can write messy code without spaces like that in many
| languages.)
|
| I used to think heavy criticism of Perl's use of punctuation
| characters were valid, until I looked at PHP, Ruby and Rust,
| and realised that some of the more popular and even loved
| languages are punctuation-heavy too. I prefer languages with
| less punctuation (despite doing expert level Perl), so I
| think the use of sigils ($variable) is not the best design
| space, but I think the criticisms of that kind which single
| out Perl are more like a have-a-go meme than a level-headed
| comparison by now.
| knorker wrote:
| I've seen those three character prefixes in real code. It's
| not unjustified criticism at all. Luckily I've not needed
| to work with perl for ~15 years, but it was something like
| \$@, maybe.
|
| > but you can write messy code without spaces like that in
| many languages
|
| I think it's fair to say that Perl forces these extra hoops
| more than any other language.
| azangru wrote:
| > I used to think heavy criticism of Perl's use of
| punctuation characters were valid, until I looked at PHP,
| Ruby and Rust
|
| The mandatory dollar sign in variable names looks dumb in
| php, I grant you that. As well as the dot for string
| concatenation. But perl insists on the distinction between
| $variable, @variable, and %variable; which is just wild.
| How is it that python works fine without all that noise,
| for chrissake? Or javascript?
| gkbrk wrote:
| Python insists on the difference between 2 spaces, 3
| spaces, 1 tab, and 2 tabs; which is just wild. How is it
| that Perl works fine without all that noise, for
| chrissake? Or Javascript?
| achileas wrote:
| Does Python work fine without all that? If it did,
| validation and type-checking tools like mypy and pydantic
| (or the recently introduced Typing in the standard
| library) wouldn't exist. Or having to write lines and
| lines of checking code because someone else (also me)
| forgot to annotate the expected types of some parameters.
| troglodynellc wrote:
| It's to distinguish between references and non-
| references. pass-by-reference rather than only COW (such
| as in some languages) is quite useful.
|
| You would prefer *ref like in C? You can actually do that
| (it's a GLOB type).
|
| The place people get tripped up is that $scalar can be a
| string, or a ref.
|
| You check that easily with ref $scalar eq 'ARRAY' or
| whatever guard you want.
| donaldihunter wrote:
| I don't think Python "just works" in this regard. It
| blows up in your face if you mistake a scalar for a
| dictionary. In Perl, the sigils are there to help you the
| programmer distinguish your $scalars from your @arrays
| and your %hashes. It still blows up in your face if you
| get it wrong but there's a visual indicator to help you
| get it right.
| forinti wrote:
| The first time I loaded data onto an Elastic index, I used Perl.
| Then I used logstash so that I could do it the proper way. It
| turned out to be about twice as much text.
|
| So this fantastic language was already there and there was
| already an Elastic module in CPAN. I'm biased, but you can't call
| this a dead language.
| cryptos wrote:
| I don't understand the rating in the table. After the Python 2/3
| migration I wouldn't expect compatibility problems for the
| forseable future. And why should Python not work as well for
| shell scripts as Perl? Why should Java not work for shell
| scripts? You can even run Java files without an explicit
| compilation step these days. Why should Python, JavaScript, Java,
| and C# not be extensible?
|
| Honestly the whole post doesn't really make sense to me and it
| looks like someone is just paying homage to a thing of the past.
| You can clearly see the decline of Perl here:
| https://redmonk.com/rstephens/2021/08/05/top-20-june-2021/
| KaiserPro wrote:
| because anything written in 2 wont run as is on 3, anything
| using async will need 3.4(?) anything using type hints of f
| strings needs 3.7( or 8, I get hazy)
| cryptos wrote:
| I already mentioned the Python 2/3 problem, but the other
| things you listed sound like usual new features, which won't
| work on older versions, obviously. However, I'd expect Python
| 3.4 code to run perfectly fine on a Python 3.8 interpreter.
| Sohcahtoa82 wrote:
| > because anything written in 2 wont run as is on 3
|
| Not true. "anything" is too strong of a word. There's plenty
| of simple code that works fine in both 2 and 3. For basic
| scripts, it's not hard to make code that is compatible with
| both, with the only odd thing to do is using parentheses in
| your print calls. You can even use "from __future__ import
| print_function" in Python 2 code to get Python 3's print()
| behavior.
|
| > anything using async will need 3.4(?) anything using type
| hints of f strings needs 3.7( or 8, I get hazy)
|
| What's the alternative? Should a language never receive new
| features?
| lmm wrote:
| TCL seems like a better fit for the listed requirements. Even
| more ubiquitous, more stable, scales up better.
| pjmlp wrote:
| It never had the extent of CPAN, and that makes a big
| difference.
| lmm wrote:
| I don't disagree, but availability of libraries is
| conspicuous by its absence in this person's criteria.
| krylon wrote:
| I learned Perl just as my shell scripts grew into more than ten-
| liners, and I switched happily. I never learned awk or sed, Perl
| is just far too convenient.
|
| And I think it is possible to write very readable, maintainable
| Perl, but one has to really want to and make it a habit. Perl has
| a couple of footguns, and one needs to be aware of those.
|
| The main reason Perl dropped out of favor, IMHO, was the
| combination of the Perl 6 debacle and Ruby on Rails taking its
| place for web development. But in its original niche, Perl
| remains a great choice.
| cglong wrote:
| Extensively discussed 52 days ago:
| https://news.ycombinator.com/item?id=35646612
| Flimm wrote:
| My apologies.
| andrewstuart wrote:
| Friends don't let friends use Perl.
| KaiserPro wrote:
| bah, use perl, its fun and fast.
|
| If you can make readable code in it, then you are a proper
| programmer.
|
| If you can't then you'll need to look at the other code you
| write, because that's probably unreadable as well.
| aduitsis wrote:
| Programming language police, pull over.
| weare138 wrote:
| Try it. It's fun.
| hexo wrote:
| It has some features one should never find in a programming
| language. Like overuse of sigils and that is not fun, but
| more like annoying af.
| [deleted]
| Woodi wrote:
| So, skip over presented facts, use some sentence template which
| _only_ insults and think you do something wise and rational ? I
| don 't think HN was meant that way...
|
| Or maybe you possess some hidden knowledge about Perl ? Some
| NASA backdoors ? RCE's ? Tell us if you know !
| pjmlp wrote:
| From the point of view of security, I rather have UNIX
| userspace stuff being coded in Perl than C.
| habib_k wrote:
| Which one is older C or perl?
| pjmlp wrote:
| Age doesn't play a role in security excuses.
|
| If it did, C authors shouldn't have ignored systems
| languages 10 years older than C.
| olodus wrote:
| I am someone who loves learning new languages (written advent of
| code in lisp, Haskell, APL, Erlang, zig...).
|
| I have thought for a long time to try out Raku as Ive never tried
| Perl and it feels like the modern version might be easier to get
| into as it maybe avoids some of the baggage.
|
| Is this true, or do I miss something by skipping the original?
| kraihx wrote:
| They are completely separate programming languages. Go for the
| original to get the real Perl experience with all the good and
| bad.
| achileas wrote:
| Just go with Perl, IMO. Raku is completely separate, and would
| be more akin to learning Ruby or Elixir to get the Perl
| experience IMO.
| kqr wrote:
| My personal (but very brief) experience of trying to learn Raku
| is that most introductory material I came across assumed at
| least an apprentice-level exposure to Perl concepts and
| vocabulary.
| habib_k wrote:
| Is perl, a programming language?
| MrVandemar wrote:
| Wikipedia seems to think so:
|
| From Wikipedia, the free encyclopedia This article is about the
| programming language. -- snip -- Perl is a family of two high-
| level, general-purpose, interpreted, dynamic programming
| languages.
| eterevsky wrote:
| I think the author favors Perl way too much.
|
| "Scales up": I don't know of any widely used projects written in
| Perl with tens or hundreds thousands lines of code. I know a lot
| of big projects written in Python, JS, Java and C#.
|
| "Compatibility": Author means stability. Last breaking changes in
| Python were in Python3, which came out 15 years ago, and no
| breaking changes are anticipated in the foreseeable future. So I
| would say it's fairly certain that Python programs written now
| would work 10 years from now.
|
| Incidentally, Perl also attempted to make breaking changes with
| the transition to Perl 6. The only difference was that it didn't
| come through.
|
| "Extensible": I don't understand this metric at all. Suppose I
| want to implement a module in C++ or Rust. Is it significantly
| easier to do in Perl than in other languages? I don't think so.
| dagw wrote:
| _Last breaking changes in Python were in Python3_
|
| Python (or at least the standard library) breaks quite often
| compared to some other more conservative languages. For example
| they recently 'broke' dataclasses somewhere between 3.8 and
| 3.11 by changing how initialisation of default values works and
| I had to fix some code.
|
| _Last breaking changes in Python were in Python3_
|
| If you only stick to the core language, then yes. If you make
| use of a lot of the standard library that comes with python by
| default, then all bets are off.
| stefanos82 wrote:
| > "Scales up": I don't know of any widely used projects written
| in Perl with tens or hundreds thousands lines of code. I know a
| lot of big projects written in Python, JS, Java and C#.
| * DuckDuckGo * cPanel * booking.com *
| craigslist
|
| These projects use millions of lines of Perl code and trust me,
| there are lots of other companies, banking infrastructures
| included (!), that use Perl as their backend or in-house
| services.
| eterevsky wrote:
| I stand corrected regarding big projects in Perl. I still
| don't think it's as good for big projects as Java, C++ and
| probably Python.
| rurban wrote:
| much better than java, c++ and python for big projects.
| worked on huge such codebases.
|
| only ruby is comparable, but ruby breaks compat way too
| often.
| Crontab wrote:
| If someone was getting into this today, would you recommend Perl
| or Raku?
| bluetomcat wrote:
| Perl can be seen as a middle ground between AWK (and bash and
| sed) and a more general-purpose language like Python. It
| prioritises brevity of expression over readability. Using regular
| expressions in Perl feels more like a "first-class experience",
| where most other languages treat it as just another library.
| pjmlp wrote:
| Additionally it can be seen as a safer C, as it gives access to
| most UNIX capabilities and C standard library, without the
| memory corruption gotchas.
| oalders wrote:
| Since we're on the topic, the Perl and Raku Conference is taking
| place in Toronto next month: https://tprc.to/tprc-2023-tor/ Lots
| of interesting talks are on the schedule and there's even an
| introductory course for those who want to learn Go:
| https://sched.co/1NIEL (This part may be confusing, but lots of
| folks who work in Perl eventually end up writing some Go as
| well).
| kunley wrote:
| Actually a lot of Ruby's features were like: Perl, but with REPL
| and objects and easy metaprogramming.
|
| I believe Matz intended Ruby to please admins, not only
| programmers, from the very beginning. Following this, me and few
| buddies used it mainly for admin tasks for over a decade, doing
| things somewhat orthogonal to the then-emerging RoR crowd.
|
| Although ofc the author is right about Perl's unbeatable
| ubiquity..
| stevebmark wrote:
| Indeed, Ruby is often called "the bad parts of Perl." Ruby made
| metaprogramming and monkeypatching first class, and somehow
| made the language even harder to statically analyze.
| omoikane wrote:
| Ruby has taken over Perl as my preferred language for small fun
| projects that I don't intend to update very often. The syntax
| is more flexible, the libraries are more convenient, and the
| language just feels more fun overall. It used to be that Perl
| came pre-installed while Ruby is not, but these days Ruby is
| fairly available across the systems that I use.
|
| Much of the fun was due to influence from Yusuke Endoh:
|
| https://github.com/mame
| petesergeant wrote:
| I have a couple of decades of Perl, and used it for everything
| from automating warehouses to building the original BBC iPlayer
| to big data ETL. I've also spent the last five weeks writing
| Python exclusively for a job, and the two years before _that_
| doing TypeScript on the backend.
|
| CPAN is better than its equivalents. The consistent documentation
| style and location, focus on tests, and so on is excellent. Miss
| CPAN.
|
| Python is a fine language. Its type system feels like a toy after
| using TypeScript, but last time I used Perl in anger there was
| nothing. The scoping is weird, and I think makes readability
| worse, but you get used to it.
|
| TypeScript is awesome, but setting up the compile step for a new
| project so it works with testing and so on, weird edge cases
| about which module system you're using, these are irritating.
|
| I love Perl, and I think in Perl, but given its ever-decreasing
| mindshare, I'm not sure what major new projects I'd start in it.
| At both the TS and Python role I've written Perl that acts as a
| superior bash, and it's been excellent for this, long may it
| continue. The big issue is that I'm reluctant to share my Perl
| with the rest of the team because I'm the only one who knows it
| WesolyKubeczek wrote:
| > CPAN is better than its equivalents. The consistent
| documentation style and location, focus on tests, and so on is
| excellent. Miss CPAN.
|
| > focus on tests
|
| ...which at critical moments may turn out to be just LARPing. I
| had to rewrite some tests for a dependency of a dependency of
| my project so that they had any meaning at all.
|
| The test suite was unchanged for a decade and it had been
| talking to some random web services on the internets. There is
| an unanswered bug report that tests have stopped passing
| entirely some years ago.
|
| Another project failed its tests due to a dependency being
| bumped, and there was a fixing suggestion unanswered since
| 2014. I don't know if the author is actually alive.
|
| I guess it's soothing to see an endless output of "ok test x"
| from a test suite, makes you believe the project is real solid,
| or something.
| Solvency wrote:
| On the subject of Perl: I've seen HN'ers vehemently beat down any
| comparison between "serverless" and the old world of /cgi-bin
| perl scripts. But I've yet to see a reason why. Why, exactly,
| aren't people using simple and straight-forward run-once cgi-bin
| scripts? They seem super suitable to so many use cases, even in
| 2023.
| themodelplumber wrote:
| There are so many different web developer audiences...
|
| For example, developers who are really focused on up-to-date
| skills will likely recognize that cgi-bin has had a "scent" to
| it since the early 2000s.
|
| Developers who are of a systems mindset will automatically
| think about contingencies. How will this scale as a system,
| what if I need to hire developers, what if cgi-bin goes away or
| gets expensive for various reasons, what about security, who is
| watching it, etc.
|
| This sounds like enterprise level thinking but a lot of people
| think this way for a hobby, even.
|
| Just like you said, it's really the strict-specification- and
| use-case-focused people who will still benefit from cgi-bin
| still being really cool in its own way.
|
| I'd guess that it's a good idea to have at least some plan to
| move along, or keep one's finger to the cgi-bin wind, so to
| speak, if the project will be used by an audience that's taking
| it seriously. But this perspective can also suck a lot of fun
| out of things... :-)
| fullspectrumdev wrote:
| Most lambda functions and such that I see people write _could_
| just be a CGI script on an 5$ /month box. And it would be way
| cheaper.
| sofixa wrote:
| You might have a different definition of "serverless", but for
| me and many others it's "you don't have to worry about the
| underlying infrastructure". You throw your script/container,
| it's easy to invoke, easy to scale up to millions rps, or down
| to zero. Nothing to maintain or update outside of your own
| code. Useful for unknown or highly variable loads.
|
| cgi-bin scripts have little in common with the above model.
| Sohcahtoa82 wrote:
| > You throw your script/container
|
| If you're using containers, then IMO, you're no longer
| serverless. The reason being...
|
| > Nothing to maintain or update outside of your own code
|
| Unless your Dockerfile uses something like "FROM
| python:latest", you'll find yourself having to update your
| Dockerfile to pull in new images on a regular basis in order
| to get the latest package updates.
|
| People usually like to have reproducible builds though, so
| will instead use something like
| "FROM:python:3.7.16-alpine3.18". Except, sorry, that's out of
| date now. You need to update to "python:3.7.17-alpine3.18."
| sofixa wrote:
| That's where scratch containers come in.
| Sohcahtoa82 wrote:
| Haven't heard of those. Can you tell me more?
| giantrobot wrote:
| To run a cgi-bin you need a host server that will execute the
| bin. That needs to run on a full fledged OS. When you've got an
| update to the script you've got to deploy it to that server.
| Every one of those things takes a little bit of time to manage.
|
| The utility of "serverless" is it rolls up all the deployment
| and execution in automation. All of the infrastructure is
| managed externally and automatically for you. You also get auto
| scaling for free.
|
| With a VPS you've got some minimal cost to leave it running.
| With "serverless" you're only paying for invocations. If you've
| got a handful of hits a day it costs so little you might not be
| charged for months. If you get a spike of traffic with
| thousands of hits you don't need to scramble to scale up your
| "simple" CGI server to handle the load.
| jarym wrote:
| Because developers want to believe they're using something NEW
| and SHINY. Comparisons to decades old technology doesn't fit
| into that belief system so some will be hostile towards such
| suggestions.
| TylerE wrote:
| Because they really aren't. Things like not being able to reuse
| DB connections really hurts. Building the world on every
| request, 99 times out of 100, is dumb.
| treis wrote:
| This is my one big problem with Postgres. Their heavy
| client/thread model prevents these sort of architecture where
| you may have a large number of connections. PGBouncer helps a
| lot, but it's not quite the same.
| Tepix wrote:
| For many, Perl is great for system administration related tasks
| that are more than two or three pages of bash.
| DonHopkins wrote:
| Perl's usefulness has a narrow peak like the Balmer curve,
| because Python is better for system administration related
| tasks that are more than four or five pages of Perl.
|
| And everyone knows how system administration scripts always
| grow to more than five pages, so it's better to just start in
| Python.
| ilyt wrote:
| It's a blessing if you need to manage a range of legacy
| systems, because Perl "just works" while Python is crapshoot.
| nocman wrote:
| That might be true if you already don't like writing Perl,
| but I have many years of experience writing system
| administration scripts in Perl, and I'd pick it for that task
| over Python any day.
|
| I can understand why someone who prefers Python would go that
| route, but it is definitely not more capable than Perl in
| that domain.
| troglodynellc wrote:
| Most of the bickering about this or that programming language is
| no different than "should I buy the bosch or craftsman table
| saw".
|
| Use whatever has the lowest TCO to you that lets you get the job
| done.
|
| Perl is usually that tool for me, but yanno TIMTOWTDI. Basically
| every programming language is quite expressive and has adequate
| tooling to profile, test, cover, format and lint & run thru CI
| these days.
|
| I have noticed pretty much everyone using X language _still_
| thinks the others _don 't_ have said features though. Good for a
| chuckle in dev chats.
| eYrKEC2 wrote:
| > "should I buy the bosch or craftsman table saw"
|
| Good question!
|
| https://www.garagejournal.com/forum/threads/table-saws-recom...
|
| I too care about my tools. Some feel good in the hands. Some
| get the job done better. Some I reject outright, despite their
| ability to get the job done. I care deeply about my tools.
| [deleted]
| tenderfault wrote:
| >It is installed by default everywhere. I don't need
| administrative privileges to deploy Perl code almost anywhere.
| That is extremely empowering.
|
| Not true anymore. FreeBSD dropped it from base.
|
| >With a great amount of discipline, Perl scripts can be
| successfully scaled up into large, complex systems.
|
| History shows different. Perl was never designed for this.
|
| >I can be confident that a Perl script I write today will run
| unaltered 10 years from now, modulo external collaborators.
|
| I concur. I also have 10-ish lines perl scripts running on my
| systems since 10-ish years, doing exactly what it was written to
| do. And if the data protocol changes I will just drop 10-ish
| lines of code and write new 10-ish lines of weird looking,
| compact and efficient code. I never care understanding my code.
| If i ever read it again it's just to have a "wow, what does this
| even do" moment at my own code. For me, write-only is a feature.
|
| >Perl can be used nearly as a shell replacement for very quick
| scripting.
|
| Yet there is no generally available shell (like Bash or zsh)
| written in Perl. This is a weird thing I'm still trying to cope
| with in 2023. It may be because the term "shell replacement" is
| used wrong. Did you mean "shell programming"?
|
| >Perl has a small set of core syntax and is very extensible and
| flexible in adopting new paradigms.
|
| ... I don't know. 27 years later, I still like to flex my
| reptilian brain reading perlsyn manpage. I like to think of perl
| syntax as a set of loose rules which you can bend to your liking.
| And the things you can come out with... oh, boy.
|
| Perl is good tool for coming up with a solution really quick. And
| most of the times, you will just keep running that code for ten-
| ish years to come. Also, Perl is more of a philosophy than a
| programming language, like Forth is.
|
| Its biggest disadvantage was the community itself. They just kept
| using it wrong, over and over, trying to serve the greed of a
| corporate world. The proof of this is Perl 6, the community
| rewrite of Perl. Looks cool. Won't use it. I think that's why
| it's now mostly referred to as "raku" instead of "Perl 6". It's
| not a Perl.
| justinator wrote:
| I learned Perl without any math or computer science background.
| My highest math class was intro to trig. I think I remember the
| gist of the Pythagorean Theorem. I put myself through school
| making money writing free software (I can't sell water in the
| desert, either). But Perl made enough sense to get some work
| done, after reading a few O'Reilly books. Strings in, strings out
| - made sense.
|
| That was a good, "Why Perl?" for me. YMMV.
| gwd wrote:
| My biggest issue with both perl and python (apart from no static
| checking) is third-party libraries:
|
| 1. I definitely want to use third-party libraries, so I don't
| have to re-invent the wheel
|
| 2. I hate having to install and manage third-party libraries on
| all systems where I might want to run something.
|
| After using golang and rust, it's really painful to go back.
| donaldihunter wrote:
| Golang and Rust are not any better at scale. Just try resolving
| go dependencies in a Kubernetes ecosystem project.
| superkuh wrote:
| >2. I hate having to install and manage third-party libraries
| on all systems where I might want to run something.
|
| I feel the same way. Rust is pretty bad in this sense because
| you have to install an entire third party compiler and
| toolchain from outside of your repositories. Usually recommend
| in the form of,
|
| >curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
|
| And if you don't install the third party rustc from out of
| repos your rustc is only able to compile code written $now till
| about $now + 3 months. After using perl it was really painful
| to try to compile random rust code I found. It's not that it's
| impossible to write forwards compatible rust, it's just that
| rust devs are mostly hostile towards it. Reactions to this
| comment will be, "3 months is too old to expect things to
| compile. You're holding back progress." And that's a legit POV.
| But one I'm glad Perl doesn't share.
| inferiorhuman wrote:
| Typically I dislike having to be forced into a package
| manager's version of a given language. For example I recently
| upgraded ansible on my old MacBook and brew decided that it
| had to install its own version of rust which meant compiling
| it from scratch. 12GB later and I got ansible installed.
| Yuck.
|
| Likewise I've found CPAN to usually get out of my way... but
| at least in FreeBSD land I've not had to fight perl packages
| too much. And I've definitely been missing having Perl in the
| FreeBSD base system recently. And if you
| don't install the third party rustc from out of repos your
| rustc is only able to compile code written $now till
| about $now + 3 months.
|
| If you're not doing things that rely on nightly you generally
| get a lot more than three months. The catch is, of course,
| that a lot of things depend on nightly.
| philote wrote:
| You could always use a tool that compiles your Python or Perl
| program into a standalone executable.
| constantcrying wrote:
| My father is an extensive Perl user, which still is somewhat of a
| mystery to me. But it seems to be a language very much suited for
| IT related tasks.
| bayindirh wrote:
| Perl is the undisputed god of text processing and manipulation.
| Most of the "IT related tasks" are essentially "Get the output,
| understand what it means, and act upon it", which makes Perl a
| perfect fit for the situation.
|
| You can convert an IP to its hex representation and change a
| symlink in one line. That's a superpower.
| louwrentius wrote:
| Sounds more like something that is difficult to
| read/understand. Code readability, being able to understand
| code 6 months from now is much more important to me.
|
| Cramming things in one line can sometimes be neat but Perl
| took that concept and went bananas, and now Perl has because
| the punchline to many jokes, justified or not.
| bayindirh wrote:
| Well, the exact code is as follows:
| $hexip = sprintf("%02X%02X%02X%02X",split('\.',$ip));
| system ("cd <REDACTED_PATH>; ln -fs $boothd $hexip");
|
| That's all.
|
| I think, in this case, perl being hard to understand is the
| joke itself.
| zkldi wrote:
| What happens if `boothd` contains a space? or a
| semicolon? or any character the shell might interpret?
| bayindirh wrote:
| It's a static variable in our case. Hence when the code
| runs once, it runs forever.
| nuker wrote:
| If the joke fits in one line, there is nothing to justify,
| no paragraphs.
| kdklol wrote:
| I discovered Perl basically by accident. For scripting/systems
| administration its simply unmatched. It's been clearly designed
| for speed and utility which is what I always wanted and I'm a bit
| disappointed nobody ever mentioned it to me. I'm 20-something
| btw, so it's not just ravings of an old man. I think the
| catastrophe happened when people mistook this it for a backend
| development language... and it somehow worked. Not well, but it
| did, which is it's own quality. I slowly started learning it half
| a year ago and it's been really useful for scripts. It's indeed
| more robust than POSIX shell which tends to have baked in
| assumptions about the system which may not transfer well onto
| different platforms. No regrets - the grey beards were right!
| tenderfault wrote:
| i am a grey beard. i confirm "the catastrophe happened when
| people mistook this it for a backend development language"
| jqcoffey wrote:
| I suppose I'm a grey beard (in industry is 96ish) and I mean,
| it's fine as a backend language in so far as dynamically (or
| even loosely) typed languages go. It's just as easy (or hard)
| to write modular well tested code as in any number of other
| languages in wide use for backend services, in my XP.
| HybridCurve wrote:
| Yes, it's a great language for this application.
|
| Make sure you read Damian Conway's book "Perl Best Practices"
| as a guideline for crafting consistent and readable code.
| People's biggest gripes about this language generally revolve
| around poorly written code that is hard to read. Also, when
| writing regexes it helps to paste one or more example lines or
| matches above the regex so there is no question about what you
| are trying to do. 9/10 times I've found debugging SA perl
| scripts comes down to an unhandled pattern in a regex and this
| is what helps the most when re-writing it to ensure it doesn't
| break anything else.
| cjohnson318 wrote:
| Can you recommend any free resources that amount to an
| "effective minimal core" or crash course for Perl? I'M a
| Python dev, but I use sed/cat a great deal, and maybe Perl is
| a better solution. (Take me to the Dark Side.)
| HybridCurve wrote:
| Difficult to say.
|
| I picked up a bunch of info from perl.org:
| https://perldoc.perl.org/perl#Tutorials
|
| Perlmonks was a good source for certain specifics.
|
| Doing is better than reading IMO. Open files, parse log
| data or such with regexes, sort them into a hash, and
| return that by reference. Perl has different ways of doing
| things that aren't common in some languages such as how it
| deals with binary data (see pack/unpack).
|
| Coming from python, I would say forego the delving into OOP
| aspect of perl as it is more of an afterthought than a core
| feature. Focus on understanding data management with
| scalars, lists, hashes, and the core functions (Perl has
| native functions for things like sorting which are quite
| useful).
|
| I managed to go from C to perl over a weekend but it takes
| hours of practice to improve.
| drivers99 wrote:
| edit: you said "free", but this isn't technically free
|
| For me, going through the llama book (Learning Perl) and
| actually doing the exercises was great. I would think I got
| it after reading the chapter, but when I went to do the
| exercise, I realized I had to look up the info again.
| Putting it into practice was great for internalizing the
| information. I can't believe there's an 8th edition now
| (from 2021!). I must have used the 2nd edition (1997) at
| the most, so I'm assuming it's still good.
|
| Since you know sed/awk, you're going to see where a lot of
| the ideas came from.
| kdklol wrote:
| Thank you everyone in this thread for suggestions.
|
| I personally learn by practice. Writing stuff. I've read
| good things about the "Modern Perl" but I'll check out
| Conway if people here are vouching for it. Also, Perl's
| manpages actually teach you the language - another
| advantage of an older language from a time when people knew
| what manpages were and how to write them. They're not
| OpenBSD quality, but they're pretty good from my
| experience.
| serallak wrote:
| I'd suggest the last edition of Modern Perl.
|
| It is dated but it's free online:
|
| http://modernperlbooks.com/books/modern_perl_2016/index.htm
| l
| clscott wrote:
| I recommend this blog post to all devs I work with that
| need to pick up Perl: https://qntm.org/perl_en
| donaldihunter wrote:
| http://modernperlbooks.com/books/modern_perl_2016/index.html
| is also a good read.
| 0x445442 wrote:
| > Make sure you read Damian Conway's book "Perl Best
| Practices"
|
| Extend this to any media you can by Conway. He's in my top 3
| of tech presenters and I'm really not that into Perl.
| inferiorhuman wrote:
| The problem with Perl isn't that you cannot write good,
| comprehensible code it's that doing so is difficult.
| uhtred wrote:
| Lol, what? Why? Are you that bad at programming that you
| can't structure code well without guardrails?
| inferiorhuman wrote:
| If you'd like to spend your time thumping your chest, go
| right ahead. I'd rather code.
| LanceH wrote:
| Lots of bad code was written in Perl by people who didn't
| know how to program. This is a feature, though. Tons of
| valuable software was created with the assistance of a
| language that attempts to get things done more than it
| tries to hold people to the implementor's dogma.
| [deleted]
| HybridCurve wrote:
| It's not so difficult to do, it's difficult to get people
| to do it.
|
| Some of perl's features use syntax which is either very
| concise or uses implied operations or operands. Things like
| regexes, sorting, subroutine arguments, special variables
| can all be used in a manner which makes things more
| cryptic. In many instances you can be explicit (for
| instance with arguments):
|
| _my ($filename, $data_ref) = @_;_
|
| Rather than , randomly in code somewhere:
|
| _my $filename = shift;_
|
| If you cannot express something more explicitly in syntax
| to be clear you really should be using comments to
| elaborate.
|
| Arguably this problem is the same across _all_ languages.
| The issue with perl is that the brevity and flexibility of
| the language can exacerbate the grief one experiences when
| working with unfamiliar code.
| kdklol wrote:
| I think this sort of argument misses the point of my
| comment. I really don't want to write serious software with
| Perl, I want something more powerfull than AWK, but not as
| cumbersome as a more "structured" language. I literally use
| AWK daily for random stuff I'm most likely gonna throw away
| or put it in a script which I'm gonna throw away happily
| the moment it breaks. Sometimes, AWK is not enough, and for
| these usecases, in my short expirience, Perl is unmached.
| Solvency wrote:
| Can someone explain the use of "modulo" here?
|
| > I can be confident that a Perl script I write today will run
| unaltered 10 years from now, modulo external collaborators.
|
| ChatGPT says "modulo" means "except for, not accounting for" in
| this context.
|
| I always thought modulo was explicitly a math term to mean the
| remainder after dividing one number by another.
|
| Where did this other "not accounting for" definition / usage come
| from...?
| _flux wrote:
| I don't have an answer for that, but it's been in The Jargon
| File as accessed by dict atleast since 2003, so it's not a new
| idiom.
| jwilk wrote:
| Backdated to 1981:
|
| http://www.catb.org/jargon/oldversions/jarg1-81-MM-DD.txt
| bikenaga wrote:
| * * *
| darrenf wrote:
| It's been used that way for a _long_ time - it has an entry in
| the Jargon File: http://catb.org/jargon/html/M/modulo.html
| _dain_ wrote:
| It's used in the same sense as "up to".
|
| https://en.wikipedia.org/wiki/Up_to
| cies wrote:
| I found Ruby to be an acceptable Perl. Easier on the mind. Easier
| on the reader. Still hard on the IDE (since it's dynamically
| typed, so hard to implement IDE hints based on the type -- I know
| some typing is available now).
|
| The I found Kotlin to be an acceptable "typed Ruby". :) It's a
| bit steeper in the learning curve, but apart from that it fits
| the bill pretty well. Though Ktor is not nearly as rich in
| ecosystem as Rails is.
| remote_phone wrote:
| Perl is the worst language I had the displeasure to work with and
| I'm glad it's basically dead.
|
| The thing I hated most about it was that it had several ways to
| the same thing, which made it extremely hard to read code because
| you had to understand the nuances and could cause bugs. For
| example I vaguely remember that Perl had 2 ways to specify "or"
| but they had different preferences. The fact that scalars and
| vectors had different namespaces meant that you could get absurd
| looking code like $a[$a].
|
| I'm glad that Perl is all but dead.
| bandrami wrote:
| There are Perl scripts I wrote in 2000 that are still in
| commercial use today. This is what annoys me about languages that
| don't care about backwards compatibility ( _cough cough_ )
| knorker wrote:
| I have the same with C code. Yet I'm not going to recommend
| anyone starts a new project in C, outside of very specific use
| cases like some embedded thing. And even then I'd say a C++
| subset.
| Qem wrote:
| Raku Just entered TIOBE rank top 50 languages. Just a statistical
| fluke, or does it hint at a recovery of Perl family languages?
| Roark66 wrote:
| I don't know... I used to use perl as my "default scripting
| language" over a decade ago. Once I was required to learn python
| for a new job I had no need to look back.
| aduitsis wrote:
| If you feel more comfortable with Python for the task at hand,
| why not use it?
|
| That's good and it's actually the Perl way, Perl was always
| about helping getting stuff done.
| jgrahamc wrote:
| The general joke about Perl is that it's "write-only". When I
| wrote POPFile I spent a lot of time ensuring that the code was
| readable and maintainable. I hope it's still understandable:
| https://github.com/jgrahamc/popfile/blob/trunk/engine/Classi...
| greyman wrote:
| It's not a joke, it's true. Your code is nice, but the problem
| is, that Perl doesn't enforce any kind of readability; some
| other languages also don't but Perl is worst in this aspect,
| and that makes it unusable for anything bigger. New programmer
| will not understand the code or his colleague at the first
| glance, and at least in corporate environment, there are always
| new and junior programmers.
| gmiller123456 wrote:
| What are some examples where languages enforce readabity?
| greyman wrote:
| Golang is quite good in this regard: - language itself is
| quite simple - default coding style was defined at the very
| beginning - usually there is one standard way to do
| something - the language do not have so-called "syntactic
| sugar"
| forinti wrote:
| This readability requirement is a bit overrated. It's best to
| rely on comments and documentation so that you can rewrite
| something if you have to.
|
| I see lots of Java that's written in a simple and direct
| manner, but that has no documentation/comments and where it's
| a pain to find the execution flow in between so many classes
| and layers (especially when there's dependency injection).
| 0x445442 wrote:
| > Especially when there's dependency injection
|
| If it were just dependency injection it would be one thing
| but when you have all the opaque behavior that comes with a
| framework like Spring you get a bunch of spooky action at a
| distance code that can't be followed simply by traversing
| the call stack.
| fullspectrumdev wrote:
| With Perl there's always the temptation to completely eschew
| any readability by using its incredibly powerful and loose
| syntax to create programs that are indistinguishable from
| line noise.
|
| You can write some absurdly powerful, really terse programs
| that make absolutely no fucking sense to anyone else.
|
| Some people see this as a point of pride - Perl golfing etc.
| calvinmorrison wrote:
| the issue is Perl made TMTOWTDI a core value. So there's a
| hundred ways to express something differently. Compactly,
| verbosely, etc. Until you're familiar with your peers code,
| it can be a pain. Once you understand the style adopted
| internally it's not so bad.
|
| Compare that to PHP where theres generally one way to do
| something right.
| throwaway173738 wrote:
| It's even worse because not only is there more than one
| way, each way gets added and then deprecated, or worse
| there's some big caveat like not being compatible with
| references or with values. This leads to all kinds of
| insane syntax that won't make sense without a very careful
| reading. And because everything changes meaning depending
| on where it is, what functions were last called, and what
| it is being applied to there is no way to be sure of the
| effect of a function or a piece of syntax without having a
| deep amount of context from careful reading of the code
| before the call site. Context sensitivity sounds great in
| principle but leads to a lot of unpredictability in
| practice.
| achileas wrote:
| All this means is that teams have to enforce readability.
| It's not good or bad, just a different shifting of
| responsibilities - and this is something that you still need
| to do for other languages, there's just more tooling (like
| flake8 and black for Python).
|
| I worked on (and modernized) a distributed ETL system all in
| Perl some time ago, and applying the long-codified ideals of
| Modern Perl made it one of the cleanest codebases I've ever
| worked in.
| uhtred wrote:
| You can write shit code in any language. That's why teams
| have code reviews.
| sidlls wrote:
| So Brainfuck would be an acceptable choice for a language
| to use?
|
| My point is that there are extremes here that are worth
| considering: and Perl is on the bad side of any exchange
| involving the question of readability. The community
| doesn't help, either: they're as bad as the Rust Evangelism
| Strike Force, but in different ways.
| rcarmo wrote:
| I wrote a _lot_ of Perl 4. Really a lot, mostly for Radiator (a
| RADIUS server), and then upgraded it to Perl 5, and then moved
| to Python.
|
| I can still _read_ Perl code (and used to read PerlMonks for
| the koans), but it is definitely an acquired taste when
| whomever wrote it decided to golf a bit to save typing or do
| some clever re-use.
| izietto wrote:
| Personally, I find it very readable. My only criticism is that
| its syntax looks "weird" nowadays. I mean, a newborn language
| would never go with `my` as local variables declaration prefix,
| or `->` for object method call, or `sub` for function
| declaration. I think Perl would benefit of a transpiling
| approach, like what Elixir is to Erlang.
| masswerk wrote:
| Bit of nitpicking: This is, because `my` doesn't declare a
| local variable (you do this with `local`), but a lexically
| private variable, which is something different. Expressing
| that something "belongs" to a private scope by `my` isn't
| much weirder than, say, referring to an object in its own
| context as `me`, as seen in HyperTalk.
| no_wizard wrote:
| This is I think in large part that Larry Wall[0] is a
| linguist and I think this influenced both Perl and its
| descendant Raku[1]. Thats why it has this almost natural-ish
| looking syntax in alot of ways, and relies on symbolism. I
| also think this is why Perl is legendary for regular
| expressions
|
| [0]: https://en.wikipedia.org/wiki/Larry_Wall
|
| [1]: https://www.raku.org/
| nerdponx wrote:
| Ironically these features make Perl feel very _far_ from
| natural language, much moreso than other programming
| languages, even some symbol-heavy ones like Java. It feels
| more like IPA pronunciation notation than anything
| naturally derived. Raku I can 't speak for because I
| haven't used it beyond "hello world", but it has a huge
| pile of symbolic infix operators in the standard library
| and that makes me squirm, because it's probably my most-
| disliked Haskell feature and IMO a substantial design
| mistake.
| ilyt wrote:
| I dislike same thing in Rust and it is much worse on
| that.
| zimpenfish wrote:
| > Personally, I find it very readable.
|
| A lot of Perl can be readable. But sometimes you get a
| backend where someone with , let's say, a "unique" view of
| software development writes a huge monolithic monstrosity by
| creating their own ORM and object model with almost zero
| documentation in or out of the code and hoo boy, that is not
| going to be a fun time 10 years later when basically nothing
| has changed because no-one has the time or energy to parse
| out what they've "crafted".
| simcop2387 wrote:
| ... You worked with POOF too? https://metacpan.org/pod/POOF
|
| Maintaining that in house codebase that used it was such a
| pain. I had to help keep that ORM up to date with the new
| data models after the acquisition.
| zimpenfish wrote:
| Nope, not POOF. From what I can see, it didn't make it to
| CPAN because it was entirely in-house work (and/or was
| too horrible even for there.)
| motogpjimbo wrote:
| The mistake was to think Perl was suitable for those types
| of applications in the first place. Perl was designed for
| writing small scripts to glue C programs together in a more
| convenient way than using shell scripts and AWK. A lot of
| its idiosyncratic design decisions make sense in that
| context. But when Perl advocates starting pushing it for
| writing large applications with OOP (with, of course,
| multiple competing object systems) it was the beginning of
| the end. Add in the vapourware that was Perl 6 and it was
| game over.
| jlokier wrote:
| _> A lot of Perl can be readable. But sometimes you get a
| backend where someone with , let 's say, a "unique" view of
| software development writes_
|
| I agree. Perhaps Perl culture encouraged that kinds of
| development. But I've a seen number of monstrosities in
| other, better known languages that are "crafted" that way
| as well. I'm currently working with a large commercial
| product in C that would undoubtedly be easier for the
| 50-strong team of devs to work with if it was written in
| Perl (though they would still complain), and ironically it
| would probably run faster in Perl too (and be _much_ more
| secure).
|
| I don't think the problem is the language really, as Perl
| can be written in a modular and fairly clean way too
| (compared with many other languages) if the developers are
| minded to. I think it's the culture in which those large
| projects were developed. Or rather, the lack of software
| engineering culture for long-term maintanence, and a
| disinclination to use frameworks and patterns that would be
| familiar to new developers coming in later, especially from
| other environments. It may be that Perl's rise and fall was
| a product of its timing relative to software-at-scale
| culture as much as anything.
|
| Despite its origins as a glue language, Perl 5 is a Lisp-
| like once you see past the syntax. Perhaps that's part of
| its problem: Lisp encourages creative and unique approaches
| to large projects too, and also isn't widely used any more.
| zimpenfish wrote:
| > I think it's the culture in which those large projects
| were developed.
|
| Definitely you can keep your Perl under control with a
| strict(ish) culture but that tends to be the kind of
| culture Perl acolytes traditionally chafe against. I do
| somewhat blame the "there's more than one way to do it"
| Perl culture - that definitely encourages a, uh, "cowboy"
| approach to development that I've seen a lot in Perl
| houses (compared with, e.g., the Go houses that I now
| deal with because Go has a definite "one way to do it"
| culture.)
|
| But yeah, pretty much any language can be twisted into a
| monstrosity if you let the devs run wild.
| Solvency wrote:
| I'll never understand this Perl readability sentiment.
|
| Any time I've ever tried to look into <insert random open
| source C project>, I typically find the most esoteric and
| tersely named functions inhumanly imaginable. Variables
| like gt, pn, r8, _on, etc. I mean terse to a point of
| cruelty. And yet these projects often have hundreds of
| contributors who are happy to gloss over said
| unreadability, or at least forgive it more than Perl.
| tyingq wrote:
| Looks readable to me. Though you had the advantage of not being
| forced into using Perl for really complex data structures.
|
| I love Perl, but that's the part I don't like. If you, for
| example, have to parse a very deeply nested piece of JSON,
| you're very quickly into that weak spot. Lots of crazy sigils,
| braces, etc...all mushed together. Worse if you're having to
| use refs, globs, etc.
| kqr wrote:
| I would argue if you "have to parse a very deeply nested"
| data format you should have subroutines or objects with
| methods for that specific task, and not rely on generic
| language container types.
|
| What you're running into is insufficient modeling of the
| problem, not a deficiency unique to any language.
| tyingq wrote:
| But a Perl object underneath is a hash, or list, or
| whatever. That abstraction doesn't save you from Perl's
| "sigil per type" and other oddities. It maybe encapsulates
| it, but...
| kqr wrote:
| A Perl object is a reference, meaning it will only ever
| present itself as a scalar (using sigil $).
| tyingq wrote:
| To the outside yes.
___________________________________________________________________
(page generated 2023-06-12 23:02 UTC)