[HN Gopher] Not Your Grandfather's Perl
___________________________________________________________________
Not Your Grandfather's Perl
Author : djhaskin987
Score : 187 points
Date : 2022-09-08 15:40 UTC (7 hours ago)
(HTM) web link (stackoverflow.blog)
(TXT) w3m dump (stackoverflow.blog)
| ksherlock wrote:
| Please don't blame bare word file handles on "C heritage"
|
| --
|
| Some of the improvements were needed because in places Perl's
| Unix/C heritage shows through a little more than we'd like it to
| in the 21st century. One good example of this is bareword
| filehandles. You're probably used Perl code to open a file
| looking like this:
|
| open FH, 'filename.dat' or die;
| tyingq wrote:
| Maybe the thinking was that Perl's STDIN, STDOUT, STDERR, came
| from c's (well, stdio.h's) stdin, stdout, stderr?
|
| Which then inspired the bad idea of expanding on that?
| ksherlock wrote:
| It's more from sed/awk/shell I suppose.
|
| eg, open FH, "<filename"
|
| vs FILE *fh = fopen("filename","r")
| tyingq wrote:
| For the <,> and variations, sure. Though IO::File has been
| there a long time and looks a lot more like your C example.
| IO::Handle also.
|
| Supports, for example:
|
| $fh = IO::File->new("filename", "r");
|
| Or, as with C, things like O_WRONLY|O_APPEND in place of
| "r".
| johnmc408 wrote:
| Looking forward to v7 and intro docs that only use "even more"
| Modern Perl. For a bigger push, we should all volunteer on those
| "Do X in Y" language sites and add Perl examples. Same with
| Amazon Lambda and other opportunities where pick your language is
| available.
|
| Also a modern OO seems nice, though not sure what is in it. Would
| also like to see a default async library (maybe POE, but I never
| used it and find the name a bit strange for a default...but then
| I like Tokio...) Not my area at all, but an opinionated way of
| async seems nice.
| thesuperbigfrog wrote:
| The current state of Perl 5 for Python fans:
|
| Perl 5: I'm not dead!
|
| TIOBE: 'Ere! 'E says 'e's not dead!
|
| Internet: Yes he is.
|
| Perl 5: I'm not!
|
| TIOBE: 'E isn't?
|
| Internet: Well... he will be soon-- he's very ill...
|
| Perl 5: I'm getting better!
|
| Internet: No you're not, you'll be stone dead in a moment.
|
| TIOBE: I can't take 'im off like that! It's against regulations!
|
| Perl 5: I don't want to go off the chart....
|
| Internet: Oh, don't be such a baby.
|
| TIOBE: I can't take 'im off....
|
| Perl 5: I feel fine!
|
| Internet: Well, do us a favor...
|
| TIOBE: I can't!
|
| Internet: Can you hang around a couple of minutes? He won't be
| long...
|
| TIOBE: No, gotta get to Reddit, they lost nine today.
|
| Internet: Well, when's your next round?
|
| TIOBE: Next year.
|
| Perl 5: I think I'll go for a walk....
|
| Internet: You're not fooling anyone, you know-- (to TIOBE) Look,
| isn't there something you can do...?
|
| Perl 5: I feel happy! I feel happy!
|
| =====================
|
| You can write Perl in Latin: https://metacpan.org/dist/Lingua-
| Romana-Perligata/view/lib/L...
|
| or Klingon: https://metacpan.org/pod/Lingua::tlhInganHol::yIghun
|
| or whitespace: https://metacpan.org/pod/Acme::Bleach
| [deleted]
| IncRnd wrote:
| You can even write perl to dump urls submitted by hn users, as
| this person I found does. [1]
|
| [1] https://gist.github.com/adulau/939629
| [deleted]
| [deleted]
| calvinmorrison wrote:
| I wish there was a callout to Modern::Perl; use
| Modern::Perl;
|
| and you get the lot of those features.
| orf wrote:
| Sorry, but what? The top features they highlight here are a print
| statement that adds a new line, a change to the bonkers default
| of creating some kind of implicit global named variable every
| time you open a file, representing time as an object (with a
| strftime function!) and... function signatures?
|
| I wouldn't call this as "Perl moving forward", I'd call this
| "Perl is still about 20 years behind everyone else".
|
| Wait until they find out that other languages print statements
| let you customise the line ending!
| [deleted]
| wwweston wrote:
| The `print` statement in perl has always behaved more or less
| as it does in the "other languages" you describe.
|
| `say` removes the need for anyone to write their own "I'm tired
| of the manual newline ritual" function and provides a standard
| for where the newline is added. That's a marginal convenience,
| but given the frequency with which people either do write their
| own or newline inconsistency gets encountered (or both), it's a
| reasonable one.
|
| And it's in pieces like this one not because it's a huge thing
| to crow about, but to illustrate the opt-in nature of
| incremental changes or sets of changes to perl.
|
| `say` is also about 15 years old, like Time::Piece. The author
| is not announcing features that are new to the whole world,
| just new to a certain audience, possibly including the author.
|
| This is also true of the filehandle scoping feature (which is
| 22 years old). If you find the old bare filehandle scope
| behavior only notable enough to hurl a drive-by "bonkers" at it
| then I suppose that's one way of advertising that you haven't
| spent much time thinking about unix shell utilities and
| associated features/issues.
|
| Function signatures are slightly younger than typescript, or at
| least, the most familiar syntax for them; both the old and more
| recent means are essentially naming a list of arguments.
|
| In general: perl is an opportunity to think about programming
| languages differently. There's a lot of contexts in which I
| never use it anymore, but it's rare to find people with
| substantial insights who casually disparage it.
| shp0ngle wrote:
| It's a weird feature set to highlight; most of this is
| available for a long time.
|
| I didn't know about the function signatures. It's nice, I
| guess.
|
| But I don't want to write perl again anyway.
| tyingq wrote:
| >"Perl is still about 20 years behind everyone else"
|
| The version of Perl on your favorite Linux distro might be. I
| think that's the point the article was trying to make...that
| distros ship VERY old versions of Perl.
| eduction wrote:
| Ya those were my thoughts exactly, and I used Perl heavily for
| several years.
|
| The number two feature they listed was released more than 22
| years ago.
|
| Perl is fine for certain tasks, I have no problem with people
| who choose to use it, but at a certain point I'd argue it's
| better to learn a new language than try to use Perl for a new
| type of task.
| ibiza wrote:
| The thing that kills Perl for me is its weak typing. Automatic
| variable coercions lead to data-dependent bugs. JavaScript has
| the same problem.
|
| For scripting anything longer than a command line, I'll take
| Python.
| pkrumins wrote:
| I love Perl!
| samiam_iam wrote:
| LordKano wrote:
| When I was an intern, my boss insisted that I learn Perl. I had
| not yet been introduced to the ways of the monks but I learned
| quickly.
|
| Perl is still my go-to language when I need to write something
| quickly.
|
| I have so many purpose driven utilities that I have written in
| Perl, that it saves me several man-hours of work every month.
| cheaprentalyeti wrote:
| Damn Pythonistas! Get off my lawn!
| cheaprentalyeti wrote:
| (Shakes cane at clouds)
| HeckFeck wrote:
| the camel shall crush the serpent
| 1024core wrote:
| I am forced to use Python, and I hate it.
| auraham wrote:
| I skimmed the article looking for a mention of a REPL or a new
| debugger. Perl is a great language but it lacks these tools.
| Sometimes I just want to try a couple of lines of Perl code in a
| REPL, but I cannot. Instead, I need to create a file. Also, when
| debugging with `perl -d`, I cannot use the Up arrow key to get
| the previous command. Not a big deal but the coding experience
| will be significantly improved with those tools.
| 0xbadcafebee wrote:
| I still use Perl whenever I need to get something complex done
| quickly. Whether it's the handy command-line switches and
| features for easier one-liners, or just easier stream text
| processing, or easier external command execution, or the huge
| library of modules that often support things Python doesn't, Perl
| is my "fuck it, I just need to get this done" language.
|
| I can't wait for the day that programming languages as a concept
| are obsolete. It feels exactly like hand-tool woodworking. I
| would love to stop building tables and chairs over and over,
| instead just buy them from Code IKEA.
| csdvrx wrote:
| Even on modern hardware with vectorization, the speed of perl is
| hard to match for stream processing.
|
| I write and deploy brand new perl code in 2022 to replace some
| clunky python and javascript - for real! AMA!
| qsort wrote:
| What's the difference when compared with other scripting
| languages? Is it just all-around faster or it's about some
| particular application?
| csdvrx wrote:
| > What's the difference when compared with other scripting
| languages?
|
| Compared to every other scripted languages I've tried, it's
| always faster - so much that it often rivals compiled code
| (even with extra optimizations as explained before)
|
| > Is it just all-around faster
|
| Yes - also faster to deploy, and harder to break in
| deployment due to dependencies rarely evolving. No need to
| pip install whatever.
|
| Consequently, tracking modules' versions (say in python) and
| their break in compatibility is a thing of the past. Some may
| say it's because it's dead. I guess I'm a necrophiliac then,
| because it makes my life so much easier that I'm loving it :)
| avyjit wrote:
| When you refer to modern hardware with vectorization, are you
| saying perl beats software that makes use of vector
| instructions? If so wow! Afaik perl is a plain old interpreted
| language with no JIT, what makes it so fast? I had an idea of
| perl as in the same performance category as Python, Ruby and
| friends.
| cogman10 wrote:
| My assumption (and I could be wrong) is that whenever you do
| something that's ultimately CPU intense, perl dives into C
| code. The sort of stuff you do with perl tends to be a lot of
| string manipulation and it turns out perl is pretty hyper
| optimized for that sort of workload.
|
| Other languages could do the same, but often they have a few
| more layers before they start running that C code.
|
| I'd be curious to know if the perl grammar also somehow lends
| itself to being fairly optimizable for it's interpreter.
| csdvrx wrote:
| > Afaik perl is a plain old interpreted language with no JIT,
| what makes it so fast?
|
| IDK. I didn't waste time checking why.
|
| My guess is that due to the much smaller code size, it
| reaches a sweetpoint where it fits nicely in the L1 or L2
| cache.
|
| But it's just a hunch, I couldn't prove it.
| kstrauser wrote:
| Perl likely spends a lot more time in C than a lot of other
| bytecode-compiled languages like Python.
| while(<STDIN>) { print $_; }
|
| isn't doing much of its work at the top level.
| clscott wrote:
| 1. What's your top technique for keeping it fast?
|
| 2. Are you hiring?
| csdvrx wrote:
| > 1. What's your top technique for keeping it fast?
|
| Using the stock install as much as possible.
|
| Since a perl interpreter is available about everywhere, this
| makes the scripts cross platform very easily too.
|
| > 2. Are you hiring?
|
| Maybe? You have no email in your profile. Can you please send
| your CV to my nickname at outlook dot com?
| wistlo wrote:
| I'm working in Windows (employer's choice) and need to process
| some huge data files on the desktop.
|
| Perl (Strawberry Perl for Windows) is much faster than native
| Powershell (or CMD) scripts. A few Perl one-liners and I have 2
| GB processed in a couple of minutes.
|
| Big fan of Perl here.
| anthk wrote:
| Perl is the Unix utilities' replacement for Windows. It can
| do awk/sed in one place.
|
| What I miss it's a "strings(1)" replacement for Perl.
| csdvrx wrote:
| > A few Perl one-liners and I have 2 GB processed in a couple
| of minutes.
|
| This matches my experience: my task is IO bound, processing
| tens of GB in a matter of minutes.
|
| > I'm working in Windows (employer's choice)
|
| Work prefers MacOS, Windows is my personal choice :)
|
| Windows 10 and 11 are a pleasure to use: between the Windows
| Terminal and tools like AutoHotKey, there's no Linux
| equivalent, even for a commandline geek.
|
| Using Windows (and Perl, and other weird things I like) may
| not be fashionable, but it's hard to beat.
| hpcjoe wrote:
| > > A few Perl one-liners and I have 2 GB processed in a
| couple of minutes. > This matches my experience: my task is
| IO bound, processing tens of GB in a matter of minutes.
|
| Huh. Windows is usually anywhere between bad to horrible at
| IO compared to alternatives. 2GB processing (usually
| mixtures of regex, summarizing data, summing fields
| extracted) shouldn't take more than a few seconds. Even on
| a slow disk, say 100MB/s, we are talking 20s. On faster
| SSDs, and NVMe, its very snappy.
|
| If you are waiting minutes ...
|
| > Windows 10 and 11 are a pleasure to use: between the
| Windows Terminal and tools like AutoHotKey, there's no
| Linux equivalent, even for a commandline geek.
|
| Huh. I'm happy that $dayjob gave me the option of getting
| off my horrible Dell workstation laptop (8 core, 64 GB ram,
| nvidia graphics) and onto a mac pro m1. While the keyboard
| diff is annoying, karabiner elements fixes most of that. I
| still ask for a linux laptop at ever opportunity though, as
| this is what I'm most functional with. Easily the
| best/fastest experience I've had for dev/admin, and the
| most stable. Mac is a close second.
| wistlo wrote:
| Full disclosure: Work has been Windows centric, but I
| recently moved to a new group with some Mac users. I'll
| have that choice, next time I swap hardware, but probably
| will stay with Windows because
|
| * Would miss too many amazingly useful utilities like
| arsclip.
|
| * Easier to patch into my home network, which is NTFS-
| based.
|
| * Employer is now wedded to Microsoft and Azure, so having
| Powershell and native access to NTFS AD on my native
| desktop is proving more useful.
|
| * I actually like the Windows interface, even with the
| Control Panel and other system utilities caught in a weird
| split between Windows XP and WIndows 10 UIs.
|
| * Some things, like certificate management and hosting a
| personal database, I do in Ubuntu or Debian as a VirtualBox
| guest under Windows.
|
| * Wife uses Windows on her laptop. She doesn't know it, but
| it's actually running as a VM on Debian, very stable, and
| can easily take her Windows to a new machine.
|
| * [I keep coming back to add items to this list] Remote
| Desktop Services have improved vastly, and I can manage
| remote servers or 12 year old client machines at a remote
| site with equal ease. (XP/7-era machines got a second life
| when I converted Windows OS disk to SSD). Also find screen
| sharing via 3rd party VNC (TightVNC) useful.
|
| * The keystrokes have become second-nature. Try as I might,
| I can never get fully comfortable on a Mac OS desktop. Now
| get off my lawn.
| csdvrx wrote:
| > The keystrokes have become second-nature. Try as I
| might, I can never get fully comfortable on a Mac OS
| desktop.
|
| Same, that's one of the biggest reasons - but I also
| agree with the rest of your list: what I like the most in
| Windows is the UI! I run most of my programs fullscreen,
| with shortcuts. I rarely use the mouse, and Windows plays
| along, while I have to fight other systems.
|
| Even when run baremetal, Windows has improved so much
| over the board that once you add RDP/VNC, it's a no
| brainer.
| SighMagi wrote:
| Gives me warm fuzzies to read new Perl articles. Such a fun,
| hackable and eminently practical language.
| HankB99 wrote:
| I've used Perl off and on throughout my career, even working at
| one job that was pretty much exclusively Perl. I've also used
| Java and C/C++. I've done a lot of work with embedded systems
| where C was the order of the day.
|
| But back to Perl. I always thought one of the best things about
| Perl was CPAN. I could nearly always find a module that would
| accomplish a specific task I needed and then I was just left to
| write the glue to implement that function (or functions) for my
| particular needs. I'm surprised CPAN is not mentioned. I wonder
| if it is still active. I also wonder about security of CPAN in
| todays environment. I find stuff like pypi and npm to be pretty
| scary.
|
| I haven't started anything in Perl in quite some time. All the
| cool kids are using Python so I've been sharpening my skills with
| that. (But it's all hobby projects these days.)
| guilherme-puida wrote:
| > But back to Perl. I always thought one of the best things
| about Perl was CPAN.
|
| I'm a younger developer, so I wasn't around when Perl was super
| popular. I listened to the Corecursive episode about CPAN [0]
| and was really impressed. It's a good listen even if you're not
| that interested in Perl anymore.
|
| [0]: https://corecursive.com/tdih-cpan/
| wainstead wrote:
| CPAN was definitely the envy of other languages for many years
| but I feel most have caught up by now.
| forgotmypw17 wrote:
| With function signatures and state variables added in 5.010, I
| consider Perl feature-complete and have not really missed
| anything from it for as long as I've been writing Perl.
|
| What I do appreciate that's missing from many other languages and
| systems is the extreme committment to backwards compatibility.
| The knowledge that the next minor release won't break existing
| scripts is underrated, IMO.
|
| Solo project with ~23K LOC of Perl and counting here. Bless you,
| Larry Wall and Perl maintainers. Keep it up!
| arthurcolle wrote:
| What is your project? Raku has some cool features and
| interesting syntax, I took a look at it before the rename, but
| find myself reaching for Python for basically everything.
| forgotmypw17 wrote:
| Link is in my profile.
| duskwuff wrote:
| Signatures were added in 5.020, and [edited:] were considered
| experimental until 5.036.
| theonething wrote:
| are Perl function signatures the PHP/Python equivalent of
| type hints?
| duskwuff wrote:
| This may shock you, but: historically, Perl functions did
| not have declared arguments. Like, at all. The function
| just got arguments implicitly passed to it as an array
| (@_), and parsing that into individual variables was up to
| the function -- so most functions would start like this:
| sub myFunction { my ($self, $arg1, $arg2) = @_;
| ... }
|
| Or, in older code, you might even see this:
| sub myFunction { my $self = shift; # implicitly
| get the first value from @_ my $arg1 = shift;
| my $arg2 = shift; ... }
|
| Notably, this didn't even check the number of arguments you
| passed. If you passed too many or too few arguments to a
| function which worked this way, the extra arguments would
| silently be ignored, or missing arguments would silently
| show up as undef.
|
| Function signatures turn this into something that'll look
| much more familiar to users of other languages:
| sub myFunction ($self, $arg1, $arg2) { ...
| }
|
| which includes checks to make sure that all the expected
| arguments (and no more) were passed.
| darrenf wrote:
| > and are still considered experimental
|
| No, 5.36 stabilised them.
|
| https://perldoc.perl.org/perldelta#Core-Enhancements
|
| > _The 5.36 bundle enables the signatures feature. Introduced
| in Perl version 5.20.0, and modified several times since, the
| subroutine signatures feature is now no longer considered
| experimental. It is now considered a stable language feature
| and no longer prints a warning._
| duskwuff wrote:
| Ah! Looks like I need to upgrade, then -- I was reading
| from "perldoc feature" in my install, which was still on
| 5.34.
| forgotmypw17 wrote:
| Thanks for the correction. I don't use them anymore (instead
| doing a few lines of sanity-check boilerplate in each sub) so
| that's why I made that mistake.
| yamtaddle wrote:
| > What I do appreciate that's missing from many other languages
| and systems is the extreme committment to backwards
| compatibility. The knowledge that the next minor release won't
| break existing scripts is underrated, IMO.
|
| I don't write much Perl these days and haven't for some time,
| but it's still what I might reach for if I were tasked with
| writing something suitable for a scripting language that had to
| run with ~0 operational or upgrade/maintenance budget for a
| decade or more in environments I wouldn't necessarily be able
| to control or influence, or else [bad thing will happen].
| latchkey wrote:
| Perl needs backwards compatibility given the `write once,
| read never` nature of the syntax.
|
| Imagine trying to upgrade this to some new syntax...
|
| https://github.com/schwern/AAAAAAA
| usefulcat wrote:
| The fact that it's possible to craft deliberately
| obfuscated code in a language doesn't actually tell you
| much about the language.
| TimTheTinker wrote:
| That looks more like write-only naming... but the syntax
| itself isn't bad at all.
|
| Here's the main module: https://github.com/schwern/AAAAAAA/
| blob/aaaaaa/aaa/AAAAAAAAA...
| gerikson wrote:
| See also Acme::Bleach:
|
| <https://metacpan.org/pod/Acme::Bleach>
| yakubin wrote:
| I've had very limited contact with Perl, but for scripting
| purposes it does seem like the best option, so I intend to sit
| down to it and learn it better. It looks like a great next step
| after sed and awk (perl -pe). I love the ability to write terse
| scripts, reasonable speed for a scripting language and, as you
| said, backwards-compatibility (such a stark contrast compared
| to Python).
| stjohnswarts wrote:
| I would argue that ruby as almost all the strengths of perl
| and conciseness with more coherency if you want a perl-like
| fluidity and terseness. I personally like python for anything
| that becomes more than a 100 lines of bash.
| ilyash wrote:
| For that, there is Next Generation Shell. Also works like a
| charm even before 100 lines. For example when structured
| data is needed. Some other advantages over bash are error
| handling, automatic command line arguments parsing (similar
| to Raku, btw), standard library with functions like warn(),
| log(), debug(), retry(), etc that you have likely
| implemented hundreds of times in your bash scripts.
|
| Disclosure: I'm the author.
| btilly wrote:
| Due to poor coding practices (eg monkeypatching) and a
| weaker testing culture (by default Ruby does not run unit
| tests when installing libraries) I've found Ruby to be
| substantially less reliable than Perl.
|
| However the world has moved on to Python. So I curse every
| time I again have to look up how subprocess works for what
| I'd do in Perl with backticks.
| kqr wrote:
| Does Ruby come pre-installed on virtually every Unix-like
| system out there?
| jrochkind1 wrote:
| No, and if it is, who knows what version it is.
|
| I think that's the main thing preventing one from using
| ruby like this. It is otherwise preferable in pretty much
| every way.
|
| Perl is kind of pre-installed on virtually every Unix-
| like system for what are at this point historical/legacy
| reasons. It is unlikely any other language can ever
| achieve this at this point.
| ARandomerDude wrote:
| If it's not installed already, Ruby will be installed
| ASAP on any machine I use.
| someRandoJunk wrote:
| You're confusing perl with ruby there.
| [deleted]
| senorsmile wrote:
| The "Learning Perl" book from O'Reilly is the best book to do
| this (and imho is one of the best written programming books).
| HeckFeck wrote:
| The Modern Perl book is great, it explains a lot of the Perl-
| isms to a modern audience.
|
| http://modernperlbooks.com/ is where you can read it for
| free.
| theonething wrote:
| >Bless you, Larry
|
| I see what you did there.
|
| Edit: for those downvoting me because they don't understand my
| comment, it refers to the fact that bless is function of the
| standard library to associate an object with a class.
|
| If you're downvoting me because you think it's a stupid and off
| topic comment, that is perfectly valid and acceptable to me.
| cryptonector wrote:
| Needs static typing.
|
| I'll let myself out now.
| forgotmypw17 wrote:
| I make up for this by writing short subprocedures and many
| sanity checks.
| MobiusHorizons wrote:
| When was the last time this caused a bug for you? My
| experience of moving from JavaScript to typescript is that it
| takes significantly longer to write many generic things
| because the types can't really express the intended use as
| well. I will certainly admit that types help a lot at the
| boundaries between systems , or for catching errors
| introduced when changing code, but it's not always a clear
| win for types, given how much more verbose, and less
| expressive the language becomes as a result.
| cogman10 wrote:
| While it's not my favorite language. I have to admit that
| function signatures go a long way towards making perl feel
| somewhat normal to work with. I have to imagine they are pretty
| big boons for IDEs.
| singingfish wrote:
| One of my criteria for good tools is that they scale well from
| the smallest possible use case to absolutely massive. Git meets
| this criterion for example.
|
| Anyway I manage a 250kline code base written over 20 years
| which is in surprisingly good shape consider it's age and how
| many people have touched it. Last time we upgraded the perl for
| the first time in a decade - going through the addition of many
| features and major internal changes (e.g. unicode,
| optimisation) the total number of lines of code we needed to
| change was at most 50. And very little having to fiddle with
| underlying cpan libraries.
|
| Back to the point. Throwaway script - perfect candidate. Code
| capable of running the money pump for a billion dollar company.
| Also just as fine as any other similarly capable environment,
| better than some, trickier to manage the team than others.
| superkuh wrote:
| I'd argue perl's major value is from stability in the sense that
| what the perl developers write today can be run on the perl
| available on any machine, new or old. If a lot of perl developers
| end up use'ing lots of these new features that feeling of
| compatiblity will go away.
| cestith wrote:
| If you need new code you write today to run on 20 year old
| systems, don't use the newer features. Perl 5.36 is backwards
| compatible to code written for Perl 5.6 after all. If you need
| 20 year old code to run on new machines, the same thing occurs
| - you hand it to a recent Perl 5 and it works. Compare and
| contrast the last 20 years of PHP or Python.
| csdvrx wrote:
| > If you need 20 year old code to run on new machines, the
| same thing occurs - you hand it to a recent Perl 5 and it
| works.
|
| You're only noticing half of the picture.
|
| If you want to write code that'll still run in 20 years, do
| the same.
| HeckFeck wrote:
| It's not objective, but I find I have more fun in Perl than any
| other language. The initial jump was steep, but it helped that I
| already knew some shell. Now I think in references, I can guess
| what $_ is going to be, I slap in a big, my $val =
| s/<RE_HERE>/other_thing wherever I want, I could go on!
|
| I think $_ belongs to a different era, before levelling
| everything to the lowest common denominator became seen as a good
| thing. I found the limitations of its rivals less than
| compelling, and besides JavaScript is arguably _more_ complex
| than Perl these days.
| shp0ngle wrote:
| ugh $_
|
| I successfully hide away all my bad perl memories and now it's
| coming all back
| forinti wrote:
| Funny thing is: $_ is a valid Java variable name.
| HeckFeck wrote:
| And a JavaScript library! http://underscorejs.org/
| wistlo wrote:
| "Bare bones" seems to be a good thing for Perl. I use Strawberry
| Perl on Windows and it is orders of magnitude faster than
| Powershell for processing large files of text strings using
| regular expressions.
|
| I hope the addition of a "new object-oriented programming
| framework" won't take away the "bare-bones" speed of the current
| release.
| anthk wrote:
| Perl's bindings for Win32 and OLE are amazing.
| csdvrx wrote:
| Would you have some interesting examples?
|
| I love Win32 because it's the closest we have to a universal
| GUI format for software.
| anthk wrote:
| https://metacpan.org/pod/Win32::OLE
| jug wrote:
| Really? This is interesting! I had completely written off
| Perl for Windows due to its heritage. But we still use COM
| objects in our scripts here and while I like PowerShell
| conceptually, I really never got to have fun with it as a
| scripting language. It just has so many quirks like "implicit
| returns" etc. and is just so verbose it's bordering on hard
| to read at times.
| anthk wrote:
| https://metacpan.org/pod/Win32::OLE
| rurban wrote:
| The best OO frameworks Mouse and cperl make it faster. Moose,
| Moo and Corinna signicantly slower. Guess which frameworks are
| recommended
| justinator wrote:
| Corinna is essentially the working spec of the new class
| system in Perl. I'm not sure being performant was ever the
| goal.
| jlv2 wrote:
| I spent the last 16 years of my career using Perl for about half
| of what I wrote.
|
| And I read the article.
|
| The title makes no sense. The article show anything meaningful as
| to why Perl has improved and is "not your Grandfather's Perl".
| Most of what the article talks about has been around for over a
| decade. If anything, it shows that Perl really still has under it
| the same old decrepit beast it always been hiding away.
| [deleted]
| CraigJPerry wrote:
| I don't really miss perl. I do miss the period when perlmonks was
| relevant to me. I haven't really seen a similar community since.
| Maybe rose tinted spectacles on my part but i learned some really
| enlightening algorithms on there specifically in text processing
| and i recall it being a really warm community.
|
| Randall Schwarz used to run a podcast that was a total goldmine.
| Fond memories of listening to that on the train on the way to
| work.
| btilly wrote:
| Most of the people who were on perlmonks are still around
| somewhere. Often with the same or a similar handle. (I added my
| first initial to mine.)
| samiam_iam wrote:
| My grandfather was too smart to use Perl.
| ra88it wrote:
| When I was about 20, I went to the local Barnes and Noble to find
| a book about programming.
|
| Picked up the O'Reilly Javascript book from around 2000. Had no
| idea what javascript was, just wanted to learn how to program and
| trying to pick the most popular language.
|
| $40 later, I got home and started reading! Very confusing, the
| first half of the book covered the language runtime (I think?)
| and the second half covered the browser sandbox, and it took me
| 200 pages to realize that I can't easily read or write to files
| on my machine with this language. Not what I was hoping for!
|
| Back to Barnes and Noble, another $40 and I came home with the
| O'Reilly camel book, Beginning Perl I think? Cover to cover read,
| probably the last time I did that with a programming manual.
|
| Decades have passed, I'm in the same camp as those that prefer
| Ruby now, but man what a breath of fresh air Perl was back in
| 2000.
| pmontra wrote:
| Thumb up for function signatures!
|
| I slowly switched from Perl to Ruby for writing my own text
| processing scripts. A loop with <> is very convenient but I was
| using Ruby for work (still do among other languages) and Perl for
| nothing. I was forgetting how to do stuff in Perl.
| newaccount2021 wrote:
| mikejulietbravo wrote:
| Perl receives such an unnecessary amount of hate
| michaelwww wrote:
| I don't think it's hate. I think it's more "why would I choose
| Perl over Python?" Perl has a painful syntax, Python greatly
| improves on this with easy syntax. I don't want to have to
| relearn the syntax every time I reach for a scripting tool.
| mikejulietbravo wrote:
| Sure, but there are a lot of times where if you care about
| performance you should use Perl. General purpose? Sure,
| Python.
| autoexec wrote:
| > Perl has a painful syntax, Python greatly improves on this
| with easy syntax.
|
| Regular expressions are way better in Perl. I increasingly
| find myself going back to Perl for RE heavy projects because
| it's so cumbersome in Python by comparison.
|
| I'm still undecided on if Perl needing semicolons everywhere
| is only 'as bad' or 'worse' than Python forcing you to worry
| about the exact number of tabs/spaces indenting lines, but
| I'm leaning toward python being easier in that respect.
|
| Still, when I have to get something done quickly, especially
| if it's an immediate need I don't see having to worry about
| later, Perl is what I turn to. Everything in Python becomes a
| "Project".
| lmm wrote:
| Those who've had to maintain someone else's perl tend to find
| that the hate is, if not strictly necessary, very much
| warranted.
| em-bee wrote:
| apparently also some of those that have to edit their own
| code they have not touched for a year.
| djbusby wrote:
| I see this for every language, every project - and across
| domains.
|
| Every new Dev says the previous code is shite. Odd that the
| plumber and electrician do it too.
|
| It's as if nobody can produce good work except for $ME at
| $NOW
| rrwo wrote:
| Badly-written Perl code from the 1990s is not the fault of
| the language.
|
| It's the fault of the non-programmers who read "Learn Perl in
| 2 hours and become a millionaire" books, had a massive s*t on
| a keyboard and started a business with it
| csdvrx wrote:
| > Perl receives such an unnecessary amount of hate
|
| I agree. We might deny it, because we are geeks, not
| fashionistas, but there's such a thing as "cool for geeks" like
| running Rust code on MacOS with some PostgreSQL sprinkled on,
| and such a thing as "uncool" like running Perl code over
| Windows and exchanging CSV files.
|
| Personally, IDGAF: I care about what works the best, not what's
| cool. I care about performance. I care about the code not
| breaking due to weird compatibility issues. I care about
| keeping the stack as simple as possible, because what's simple
| often works better.
|
| If, god forbid, I need something more complicated than CSV, I
| reach for sqlite --- which, unfortunately, is starting to
| become the "cool" option, and therefore might get turned into
| the proverbial hammer that makes all your problems look like
| nails!
| mikejulietbravo wrote:
| This^
|
| If your system isn't performant, it's shit. Performant is
| relative to what you're trying to do and how picky your users
| are, but at some point you're going to be optimizing for
| milliseconds without question.
| [deleted]
| JackFr wrote:
| Maybe I'm missing the point of this piece, but it's probably
| because I'm still reeling from the author's idea that adding
| "say()" which is "print()" with a newline added, is somehow an
| improvement to the language.
| lloeki wrote:
| The point is not about `say` itself (which has been there since
| Perl 5.10, released on 2007/12/18), it's only an example of how
| much Perl uses modularity (via `use`) to enable new features
| while ensuring a) code dependent on a new feature alerts on
| Perl versions without the feature and b) backward compatibility
| of new Perl versions with old Perl code.
|
| Compare: # Perl use feature 'say'
|
| vs: # Python from __future__ import
| print_function
|
| Which at first blush follow the same principle, except that
| Python decides that `from __future__` is a vision into upcoming
| doom, that is a future version of Python for which code that
| preexists becomes incompatible _unless it is ported to the new
| version_.
|
| IOW py2 code doesn't run on py3, barking at you in obscure ways
| if you try, and py3 code doesn't run on py2, barking at you in
| obscure ways if you try. (or worse, partially runs and either
| explodes in mid flight or silently corrupts data).
|
| Whereas Perl code written targeting vX runs on Perl vY as long
| as Y >= X, and if Y < X then Perl tells you "unsupported
| feature foo" or "your perl is too old, update to at least X".
| $ perl5.18 sig.pl Feature "signatures" is not supported
| by Perl 5.18.4 at sig.pl line 1. BEGIN failed--
| compilation aborted at sig.pl line 1.
|
| (yes yes I am aware that with enough effort and trickery you
| could write code that works on both py2 and py3. I did that a
| long time ago; it's a pain, and doesn't solve the problem of
| _preexisting_ code)
|
| And not just that, Perl alters its parser behaviour _live_ (and
| scoped to the module!) so remove ` 'signatures'` from `use` and
| you get: $ perl5.30 sig.pl Malformed
| prototype for main::my_subroutine: $foo, $bar, $baz = 'fury' at
| sig.pl line 7.
|
| But leave it in and there's no parse error. No magic
| preprocessed comments or fake code trickery like JS (which has
| a commitment to backwards compatibility as well) has to do[0]:
|
| _To invoke strict mode for an entire script, put the exact
| statement ` "use strict";` (or `'use strict';`) before any
| other statements._
|
| (They had to make it a string in void context instead of a
| comment because comments are removed by JS obfuscators, but
| it's essentially a magic comment/preprocessor directive)
|
| [0]: https://developer.mozilla.org/en-
| US/docs/Web/JavaScript/Refe...
| hpcjoe wrote:
| This. So much this.
|
| At the $dayjob, writing some python assuming late model
| 3.10.x, and discovering that the API has changed when I have
| to make sure it works on 3.6.x and 3.7.x.
|
| Nevermind important libraries like pandas changing the API so
| some functions you 've used for years just disappear.
|
| I've got 30+ year old perl 5, that just works. And is
| readable. I wish 2 year old python could just work.
| xivzgrev wrote:
| Perl was created in 1987. My grandpa isn't that young!
| mansilladev wrote:
| As if Perl already didn't have a bad reputation for readability,
| that black or dark gray text in that <code> blocks.. phew.
___________________________________________________________________
(page generated 2022-09-08 23:00 UTC)