=~ is nice and convenient but I really don't think <> was worth bringing back. I'm sure people who never used Perl could figure out what `buf =~ /${regexp}/` does, but I wonder if they'd be able to figure out the `while (buf = <>)`.
Perl has a lot of good ideas and things I find myself missing a lot when I use Python or JS (autovivification being probably #1) but IMO these one or two symbol magic variables would generally be improved if they were more descriptive, with maybe one exception for $_/@_.
Although I must admit reminiscing about this made me realize how much I miss Perl now that I'm forced to use Python for work.
Autovivification was one of the most painful features I’ve had to live with - in a large codebase it completely erases trust on any kind of defined() check and breaks all sorts of things unexpectedly.
Yet another horrible hack in Perl that for some reason is advocated for. Optional chaining / null propagation is a much, much better idea and shouldn’t have been any harder to implement.
I see how that can become a problem but I think the pros outweigh the cons. Maybe the problem is because of a "very large" codebase, my general hot take is that dynamic languages like Perl and Python should be used primarily for scripts. The lack of static typing makes dealing with very large codebases rather painful in any case, in my experience.
Null propagation is nice too, but it doesn't address all the uses cases of autovivification when you have, say, a hash table of arrays and you want to insert a new entry in an array, creating it if it doesn't exist. In python you have to use setdefault which I always found clunky.
I wrote most of my first source management system (NSElite, mentioned elsewhere in this thread) in perl4. I was learning perl at the time and my first and second efforts were awful. Perl really lets you get sloppy and create unmaintainable code.
My 3rd rewrite was very stylized and, I felt, maintainable. Which proved to be true as I had to fix bugs in it.
I did weird stuff like using $whatever as the index into the
@whatever array.
But I digress. On the <>, Little has argv so you can do
int
main(string argv[])
{
int i;
string buf;
FILE f;
if (defined(argv[1]) && streq(argv[1], "-") && !defined(argv[2])) {
while (buf = <STDIN>) bputs(buf);
} else {
for (i = 1; defined(argv[i]); i++) {
if (defined(f = fopen(argv[i], "r")) {
while (buf = <f>) puts(buf);
fclose(f);
} else {
fprintf(stderr, "unable to open '%s'\n", argv[i]);
}
}
}
return (0);
}
but why would you want to when all of that is
int
main(string argv[])
{
string buf;
while (buf = <>) puts(buf);
return (0);
}
I mean, come on, that's cat(1) in 8 lines of code.
edit: I need to learn hacker markup. My code looks like crap.
If you're already aware that ARGV exists, you'll guess that ARGF might be used in relation to it, and so when writing a CLI program that uses ARGV, you might wonder if ARGF could simplify your code and look up what it is/does.
Yeah to be clear it's not the functionality that bothers me, it's just the syntax. Ideally since it's not even a proper variable since it changes after reading it should probably look like a function call.
These ultra terse shorthands make some sense in the shell because it's meant for interactive, write-only commands but a scripting language should be a little more verbose and consistent IMO.
I'm a huge fan of preserving knowledge and building on it. Most people, at the time at least, knew what
while (buf = <>)
did. So I didn't want to invent a new syntax, there is way too much of that going on, I like C, I like perl, pull the useful stuff from each and move on.
There’s a balance because people really seem to like ? as null coalescing, => for lambdas =~ for regex match, etc..
I think <> as a fancy readline and _ as a default/throwaway variable does really improve readability and lowers the mental load of understanding programs.
Perl has a lot of good ideas and things I find myself missing a lot when I use Python or JS (autovivification being probably #1) but IMO these one or two symbol magic variables would generally be improved if they were more descriptive, with maybe one exception for $_/@_.
Although I must admit reminiscing about this made me realize how much I miss Perl now that I'm forced to use Python for work.