6 ms·

Compiles to Tcl byte codes Interesting, I didn't even know there was such a thing. Good to see <> and =~ live on.

simias 6y ago
=~ 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.
- tyingq 6y ago
  I do find <> helpful. Perhaps if it were more descriptive? <ARGVorSTDIN> or similar?
  - simias 6y ago
    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.
    - luckydude 6y ago
      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. I freely admit it's not how everyone would do it.
    - Spivak 6y ago
      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.
  - derefr 6y ago
    In Ruby it's called ARGF (https://ruby-doc.org/core-2.7.1/ARGF.html https://ruby-doc.org/core-2.7.1/ARGF.html) — which, if not perfectly descriptive, is at least evocatively similar to ARGV. 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.
- jiofih 6y ago
  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.
  - simias 6y ago
    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.
  - lizmat 6y ago
    FWIW, that was one of the things that Larry fixed in Perl 6 (now the Raku Programming Language https://raku.org https://raku.org #rakulang). You can bind to a non-existing hash element (even multiple levels deep) and it won't exist until you actually assign to it: my %h; my $c := %h<a><b><c>; say %h<a>:exists; # False $c = 42; say %h<a>:exists; # True
- luckydude 6y ago
  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.
  - hyperpallium2 6y ago
    It's indent by two spaces. Guessing your style: int main(string argv[]) { string buf; while (buf = <>) puts(buf); return (0); }

=~ 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.

tyingq 6y ago
I do find <> helpful. Perhaps if it were more descriptive? <ARGVorSTDIN> or similar?
- simias 6y ago
  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.
  - luckydude 6y ago
    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. I freely admit it's not how everyone would do it.
  - Spivak 6y ago
    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.
- derefr 6y ago
  In Ruby it's called ARGF (https://ruby-doc.org/core-2.7.1/ARGF.html https://ruby-doc.org/core-2.7.1/ARGF.html) — which, if not perfectly descriptive, is at least evocatively similar to ARGV. 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.
jiofih 6y ago
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.
- simias 6y ago
  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.
- lizmat 6y ago
  FWIW, that was one of the things that Larry fixed in Perl 6 (now the Raku Programming Language https://raku.org https://raku.org #rakulang). You can bind to a non-existing hash element (even multiple levels deep) and it won't exist until you actually assign to it: my %h; my $c := %h<a><b><c>; say %h<a>:exists; # False $c = 42; say %h<a>:exists; # True
luckydude 6y ago
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.
- hyperpallium2 6y ago
  It's indent by two spaces. Guessing your style: int main(string argv[]) { string buf; while (buf = <>) puts(buf); return (0); }