6 ms·
Tbh, for me it was a source of regex knowledge, in retrospect. Remove regexes from perl, what’s left? I can name: dynamic scoping, implicit filehandles, implic
by wruza 2y ago
Tbh, for me it was a source of regex knowledge, in retrospect. Remove regexes from perl, what’s left?
I can name: dynamic scoping, implicit filehandles, implicit $_, strange contexts, keyword-like list functions. That’s basically it, and while it sounds fun, it doesn’t do much in a sense of code reduction.
$. $? $$ etc, well you can split lines with .split('\n'), get status as a part of result, call os.getpid().
<>, you can open() or createReadStream().
$_ is just a kids toy. “print if /…/“. Cool.
Lots of global modes under dynamic scoping is questionable. Value semantics and corresponding sigils are horrible, really. Bless is ugh. Subs are meh.
It’s all just regex. Add regex as a language construct and you get the power of perl in it. /…/.test(s), s.match(/…/), s.replace(/…/, '$&') that’s 90% of Perl. Regex saves most lines of code, everything else is just esoteric extra that doesn’t do much. Also no GC.
- akoboldfrying 2y agoI use Perl for one-liners all the time -- nothing can top it there. But when the task at hand grows just slightly bigger, to the point where I know I'll need to pass filehandles to/from my own functions, my skin starts to literally itch because of how bad the filehandle situation is. It's not plain "open F, ..." any more... Is it "*F"? Is it "\*F"? Are those the same thing? (What the hell is a "typeglob"?) Wait, can't I just use "open my $f" and everything works the way it obviously should? Well, kinda, unless you want to be able to store an existing filehandle like STDIN in there, then you have to do something different again... Do I need IO::Handle instead? (Why does that need to exist...?)
- deleted 2y ago[deleted]
- mst 2y agoPlain perl: open my $fh, '<', $filename or die "Couldn't open ${filename}: $!"; Nicer: use File::Open qw(fopen); ... my $fh = fopen $filename; (and File::Open is simple pure perl code so if I need to distribute the script to random machines I throw App::FatPacker at it to produce a bundled version)
- akoboldfrying 2y ago"my $fh" works fine if you only want to work with files you open() yourself, but what if you want to write a function that, based on some test, returns either that or the preexisting STDOUT filehandle?
- shawn_w 2y agosub foo { if (whatever) { open my $fh, ...; return $fh; } else { return \*STDOUT; } } will do the job.
- akoboldfrying 2y agoThanks. I feel certain that I tried exactly this a long time ago, and it didn't work as expected, but I may be misremembering. I'll give this a shot the next time I'm in front of a keyboard -- if it works, it will be nothing short of healing.
- mst 2y agoSlight oddities converting it into a one-liner but here's a copy and paste from a shell session running in my local WSL slice: demeisen=; perl -e 'my $in_fh = (defined $ARGV[0] and $ARGV[0] ne "-") ? do { open my $fh, "<", $ARGV[0] or die "Failed to open $ARGV[0]: $!"; $fh } : \*STDIN; print "Line: ".<$in_fh>;' HELLO Line: HELLO demeisen=; perl -e 'my $in_fh = (defined $ARGV[0] and $ARGV[0] ne "-") ? do { open my $fh, "<", $ARGV[0] or die "Failed to open $ARGV[0]: $!"; $fh } : \*STDIN; print "Line: ".<$in_fh>;' - HELLO Line: HELLO demeisen=; echo 'HI' >tmp/hi demeisen=; perl -e 'my $in_fh = (defined $ARGV[0] and $ARGV[0] ne "-") ? do { open my $fh, "<", $ARGV[0] or die "Failed to open $ARGV[0]: $!"; $fh } : \*STDIN; print "Line: ".<$in_fh>;' tmp/hi Line: HI demeisen=;
- meltyness 2y agoyes, trailblazing. yes, enables brevity. yes, probably comprehensive offline std docs. ,... https://perldoc.perl.org/perldiag https://perldoc.perl.org/perldiag should set off some alarms.
- AnimalMuppet 2y ago$_ is not just a kid's toy. Let's say I'm talking to a human programmer. I say, "Read in a line of text. If it ends in a newline, remove the newline." Cool. But when I talk to a computer, I can't talk that way. It says, "If what ends in a newline?" It doesn't understand "it". Except in Perl. In Perl, $_ is "it". It's what we're talking about if I don't specify something specific. It's where the line of text gets read into if I don't specify a destination. It's where the newline gets removed from if I don't specify a variable. It lets me ignore specifics when I don't care about those specifics. It makes Perl much closer to how we talk to each other instead of how we talk to computers.
- wruza 2y agoIt’s also where you (or your adhd colleague, or future self) introduce a subtle bug if one of your subs reads another stream and you forgot to local $_ in it. And you realize that you don’t always understand what “it” is either and that it is a bad idiom for formal systems. Isn’t worth it in the long run, especially in implicitness-ridden code that perl encourages. Write out your “line” and assign it back: if (line ~= /\n$/) { line = chop(line) } Or use a library with helper functions akin to chomp(). This sentence-like code with $_ is a sign of wrong level of abstraction which solves small tasks with smaller components. If a language claims text processing capabilities, it should provide a function or a generator that does “read this <enc=utf-8> file and split by <what>[ omitting empty ones but keeping original line numbers in the emitted records][ also erase /\s*#.*$/-comments][ keep original lines too]” among other common tasks. All this $, $. $/ $_ could be just a couple of functions that accept a config argument with few optional callbacks for custom needs. You don’t have to create a whole language to read lines split by newline then by separator. Same for matching vars, could be just a sliding context arg to a properly designed matching api. You may argue that other languages don’t have it either, well that’s true. Standard libraries usually suck compared to what perl does out of box.
- kamaal 2y ago>>Remove regexes from perl, what’s left? qw, qr, references, multiline regexes, a far advanced OO ecosystem, Data::Dumper, map, grep, pack/unpack, DBM, ``, top class unicode handling, given/when, functional programming etc etc. In fact I've barely scratched the surface. You must grok Perl more.
- AnimalMuppet 2y agoOO is the part of Perl that I grok the least. What about it makes it "far advanced" compared to, say, Java or C++ versions of OO?
- kamaal 2y agohttps://metacpan.org/pod/Moose https://metacpan.org/pod/Moose Moose is definitely what I go for when I have to use OO with Perl, this more than a decade old and stable for production use cases. Its based on Class::MOP, which is in turn based on Meta Object Protocol, the same concepts on which CLOS(Common Lisp Object System) is based on. Its always nice to have CLOS goodness in Perl. For eg- https://metacpan.org/dist/Moose/view/lib/Moose/Manual/MethodModifiers.pod https://metacpan.org/dist/Moose/view/lib/Moose/Manual/Method... these methods like before, after, around do fix need for design patterns to a large extent. But of course the more you explore, the more you discover the possibilities with this. To a large extent I think Perl brings OO and functional paradigm in a far better package than Python does. Perhaps HOP needs a new chapter for OO given how few people are aware of this.
- arunix 2y agoThe key idea in CLOS is multi method dispatch, which Moose does not provide. Moose out of the box has its own set of problems, leading to other workarounds, e.g. Moo (a similar but much less bloated solution) MooseX::Extended - Moose with more sensible/correct defaults https://metacpan.org/dist/MooseX-Extended/view/lib/MooseX/Extended/Manual/Tutorial.pod https://metacpan.org/dist/MooseX-Extended/view/lib/MooseX/Ex...
- arunix 2y ago