Live data from Hacker News

Perl 7 is going to be Perl 5.32, mostly

perl.com

261–270 of 573 posts

Re: Perl 7 is going to be Perl 5.32, mostly

#261
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…

I think you should revisit perl. My first job writing perl was in 2005 or 2006, and it was not a good language for an eager idiot without guidance. After a couple years, I started getting it, and it became one of my favorite languages. I think it was my coworker who told me to read https://hop.perl.plover.com/ and it blew my mind and made me start to rethink how I was approaching code. With the languages that I'd bee…

it looks to me like HOP is mostly teaching traditional LISP concepts. I could write those same functions in Javascript, and they'd be more readable

Re: Perl 7 is going to be Perl 5.32, mostly

#262
post #64

This is just bad maintenance. Just pick all the stuff people are complaining about and fix it! 1. Improve threads 2. Improve C API support 3. Give local::lib, cpanm by default ... multiple perl versions by default 4. Give direct support for coroutines / async await 5. Mark experimental features as non-experimental (attributes, signatures) 6. Pick an OO system, package system 7. Make switch cool again 8. Get more core…

>get rid of format.

You shut your mouth. I can't even count th number of my scripts that'd break. I like format for output.

Re: Perl 7 is going to be Perl 5.32, mostly

#263
post #16
post #5

Earlier quoted context omitted.

I do. Efficient, cheap and stable. Ported to about everywhere.

What do you mean by cheap? Also, perl is incredibly inefficient: it's even slower than Python. Also, how is Perl any less stable than other languages? Are you saying the language doesn't change much or that it doesn't crash?

> Also, perl is incredibly inefficient: it's even slower than Python.

That's debatable for single-threaded workloads (they're typically pretty comparable in my observation), and highly unlikely for multi-threaded workloads (Python has a global interpreter lock whereas Perl does not AFAICT; you can work around that in Python, but it typically involves spawning entirely separate processes, thus introducing IPC overhead that wouldn't be present in a Perl equivalent).

Looking at some comparative benchmarks (https://benchmarksgame-team.pages.debian.net/benchmarksgame/...), Perl seems to be faster in a slight majority of cases, and in nearly all cases has a lower memory overhead. Not that benchmarks really matter anyway, given that they're usually a poor indicator of real-world performance, but still.

Re: Perl 7 is going to be Perl 5.32, mostly

#264

Earlier quoted context omitted.

The Moose library is a pretty advanced OO library that was inspired by Common Lisp's CLOS & Smalltalk I think. Most Perl developers I know use a large amount of libraries as the language itself is lacking in many areas. A lot of people are fine with that, but I prefer kitchen-sink languages which are fairly opinionated.

I'm sorry, Moose is a pig. Its startup time is atrocious. Its run time overhead is non-trivial. People who use Moose in my experience just showboat that they can do OO. Does it help? Maybe. But what it surely does is it makes a program run and startup significantly slower.

Things have moved on. Moose is a bit of kitchen sink. These days you would generally choose Moo first unless you really needed the meta object features. Or to get incremental Moo(se) features you’d use Role::Tiny, Class::Method::Modifiers And Type::Tiny

Re: Perl 7 is going to be Perl 5.32, mostly

#265
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…

> And on top of that, the sigils, refs, and `wantarray` systems means that figuring out what syntax you need to invoke something correctly is confusing mental overhead that you have to keep in mind for every function call That's just badly written libraries that exist in pretty much every ecosystem. By now it seems we have settled that after a couple of args the way to pass multiple arguments is via a hash.

I speak as someone who has programmed in Perl for over 20 years and at one point was the top poster on Perlmonks.

The wantarray feature is a problem with Perl, and not libraries. It has nothing to do with how you pass your arguments, but rather how the data comes back. Every single function has to deal with the potential of context. Every choice you make has downsides. The choices made around wantarray tend to age poorly. And many Perl programmers are deeply confused about the difference between these lines:

    my $bar = foo();
    my ($baz) = foo();
I firmly believe that context is one of the worst ideas in Perl. There is a good reason why it was not borrowed by other languages. It is far better to expand arrays like Ruby does with * instead.

Re: Perl 7 is going to be Perl 5.32, mostly

#266
post #171

> > use utf8; > there’s still much to be done to make Unicode the default Why's that? If that's something someone with zero Perl experience can easily understand. Isn't this only about the source code? Or does this mean all strings are unicode?

This[1] explains it. Essentially, to support unicode probably, you have to do extra work in your own code. (How do you handle invalid unicode? Should regex character classes match the unicode versions, or just the ascii versions? etc.) Additionally, certain builtin functions don't already support unicode, and modifying them to do that would be a breaking change. For more info, see the py2->py3 unicode change, and how much of a mess that caused.

1. https://stackoverflow.com/questions/6162484#6163129

Re: Perl 7 is going to be Perl 5.32, mostly

#267
post #215
post #64

This is just bad maintenance. Just pick all the stuff people are complaining about and fix it! 1. Improve threads 2. Improve C API support 3. Give local::lib, cpanm by default ... multiple perl versions by default 4. Give direct support for coroutines / async await 5. Mark experimental features as non-experimental (attributes, signatures) 6. Pick an OO system, package system 7. Make switch cool again 8. Get more core…

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.

Re: Perl 7 is going to be Perl 5.32, mostly

#268
post #48

I was part of a team that wrote significant parts of Amazon's payment processing systems in Perl in the late 90s. I really loved the language. It's object system was so flexible and powerful. Once you understood how write idiomatic perl. It was a joy to use. I'm looking forward to trying out Perl 7.

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’s core object system isn’t really an object system, it’s a toolkit for building object systems. Of course this leads to too many ways to do it, so if starting fresh just use Moo

Re: Perl 7 is going to be Perl 5.32, mostly

#269
I had hope there would be a merging (with some compatibility layers and wrapper binaries) allowing to use Raku the same way Perl 5 was used (should not have been _that_ hard, just adding familiar options and special variables)... Now I'm seeing this goes in a total different direction.

Re: Perl 7 is going to be Perl 5.32, mostly

#270

Once this is out, I'll be interested in any well written guides or books, it has always felt like "the one that got away" to me. Back in 2002 I had to choose between learning between Python and Perl for a project, but "everybody knew" Perl 5 was soon going to be replaced by a new shiny different Perl 6, so I chose Python. It will be interesting to see where Perl can live and gain new users nowadays. Python has so muc…

The Osborne effect for languages. Now there's no risk in announcing version 7 since effectively everyone who was going to choose Perl already chose Python (or Javascript). https://en.wikipedia.org/wiki/Osborne_effect

There's also the Ozzy Osbourne effect for programming languages:

    I've listened to preachers
    I've listened to fools
    I've watched all the dropouts
    Who make their own rules
    One person conditioned to rule and control
    The media sells it and you live the role

    Mental wounds still screaming
    Driving me insane
    I'm going off the rails on a crazy train
    I'm going off the rails on a crazy train
Post reply on HN