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…
Perl 7 is going to be Perl 5.32, mostly
261–270 of 573 posts
Re: Perl 7 is going to be Perl 5.32, mostly
#262This 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…
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
#263Earlier 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?
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
#264Earlier 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.
Re: Perl 7 is going to be Perl 5.32, mostly
#265Earlier 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.
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> > 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?
Re: Perl 7 is going to be Perl 5.32, mostly
#267This 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.
Re: Perl 7 is going to be Perl 5.32, mostly
#268I 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…
Re: Perl 7 is going to be Perl 5.32, mostly
#269Re: Perl 7 is going to be Perl 5.32, mostly
#270Once 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
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