Perl 7 is going to be Perl 5.32, mostly

Post by runamok » Wed, Jun 24, 2020, 8:39 PM UTC

ugexe wrote: post #29

benbristow wrote: post #27

Earlier quoted context omitted.

I used to work for a company that used Perl as their primary language. The codebase was millions of lines long, modules (pm files) with like 1000 methods and 10,000 lines, a total mess and it had 0 unit tests too. Almost beyond salvageable. Left a bit of a sour taste. They're trying to migrate to AWS but AWS don't even natively support Perl in their libraries. There's a few third party libraries in CPAN but nothing a…

Your opinion on Perl is based on one code base you worked at on one job?

Post by zem » Wed, Jun 24, 2020, 8:44 PM UTC

Grinnz wrote: post #267

zem wrote: post #215

Earlier quoted context omitted.

it's likely a lot easier to do all that in the perl7 branch, so that backwards-incompatible changes can be made if needed.

It's not my understanding that the "Perl 7" idea suddenly gives license to be backwards incompatible. Instead, features that have been made available and gated in previous releases can be made default in a new major version.

Post by marcosdumay » Wed, Jun 24, 2020, 8:50 PM UTC

staycoolboy wrote: post #116

jes5199 wrote: post #48

Earlier quoted context omitted.

huh. I spent a couple years writing perl professionally, I guess that was around 2006, and I couldn't agree less. Its object system is so bizarre compared to any other language - it's like it doesn't really have an object system, it has parts of a system that you can try to assemble, but no matter what you do you end up with something weird. And on top of that, the sigils, refs, and `wantarray` systems means that fig…

Perl was my first encounter with regular expressions. To this day, no language I've used does it better and cleaner. This includes Python, Boost/C++, Java, JavaScript, LISP, Go and Rust.

Post by cutler » Wed, Jun 24, 2020, 8:55 PM UTC

tomku wrote: post #210

cutler wrote: post #141

Earlier quoted context omitted.

Perl 5: #!/usr/bin/env perl use 5.026; open my $fh, ' ) { chomp; say if /\b\w{15}\b/; } close $fh; Python 3.8 #!/usr/bin/env python import re with open('logs1.txt', 'r') as fh: for line in fh: if re.search(r'\b\w{15}\b', line): print(line, end='') Why isn't it a fair comparison? The startup time is generic and string parsing is a major feature of, say, web development. I didn't say Perl5 numerics match Python's but e…

It doesn't account for anywhere near the whole difference, but in a tight loop like that Python's going to be spending a good chunk of its time re-compiling the regex from the raw string literal every iteration. Hoist the regex definition out of the loop like so and it'll probably run about 30% faster: #!/usr/bin/env python3 import re with open('logs1.txt', 'r') as fh: regex = re.compile(r'\b\w{15}\b') for line in fh…

    time ./index.pl  0.258s
    time ./index.py  0.609s

Post by Spivak » Wed, Jun 24, 2020, 8:59 PM UTC

gkfasdfasdf wrote: post #276

I still use Perl every now and again for powerful one-liners and I'm really glad it's around. Here is a bash function I use which takes args and merges and deduplicates PATH-like expressions: merge-args () { perl -e 'print join ":", grep {!$h{$_}++} split ":", join ":", @ARGV' "$@" } And I use as follows: export PATH="$(merge-args "${SCRIPT_DIR}"/clang-tidy-ex /usr/local/opt/llvm/bin "${INSTALL_DIR}"/{,samples/}bin "…

    merge-args() {
        local res
        for i; do
            case ":${res}:" in
                *:"$i":*)
                    ;;
                *)
                    res=${res+$res:}$i
            esac
        done
        echo $res
    }