> trying to guarantee backwards compat for all the legacy code
Not "all", as there are indeed deprecations added over time, but _most_.
I really, really like that I can, more often than not, take a program I wrote decades ago and it will still run properly.
> I really, really like that I can, more often than not, take a program I wrote decades ago and it will still run properly.
That wouldn't have changed with Perl 7, because Perl 5 would have been put into "long term maintenance mode". In fact, backward compatibility would have been even stronger, because all the changes would have gone into Perl 7.
That depends on "which version" of "Perl 7" you're saying, as IIRC there were various "factions" that had varying ideas about what ought to happen when "perl7" runs programs that didn't specify a "use v..." or that specified a specific "5.something" version.
I'm personally of the idea that enough backwards compatibility _should_ be preserved, but not _so_ much as to inhibit new/better syntax constructs and the like.
But honestly it's the sort of thing that is more like "I'll know it when I see it" more than anything.
Re "long term maintenance mode", there's the not so small matter of how many people can, in fact, actually develop perl. The codebase is large and full of many traps. It's a difficult, but not impossible, codebase to contribute to.
My sincere hope is that enough things will get out of "experimental", including quite a bit more of the "class" feature, for the end result to be enough to be called "7" and we'll go from there.
Basically... mostly a marketing thing, as today's 5.40 is way, way different (and better in so many respects) than 5.8 or 5.20 or even 5.32... but the (minor) version number doesn't show that.
> Re "long term maintenance mode", there's the not so small matter of how many people can, in fact, actually develop perl. The codebase is large and full of many traps. It's a difficult, but not impossible, codebase to contribute to.
Yeah, and that was one of the main reasons cited when they announced Perl 6, back in 2000. 24 years have passed and it's still an issue.
> I really, really like that I can, more often than not, take a program I wrote decades ago and it will still run properly.
"Cool kids" languages like Python and Rust really put in the mind of people that a program written two weeks ago must be upgraded to run on the new version of the compiler or interpretor. Meanwhile there always have been languages like C# or C where a codebase from 15 years ago will compile and run just fine.
Tangent: I wish more projects/build systems had a distinction between modes of “I'm the developer” vs “I’m just a poor soul trying to compile this”. -Werror is appropriate for the former but not the latter. It sucks when some random dependency stops building because they put -Werror in their makefile and the compiler added a new warning at some point that didn’t exist when the code was written.
I’d actually go even further and say that the only appropriate time to use -Werror is when running tests for code that hasn’t been merged yet… once it’s “released” you don’t want to use -Werror any more.
Ditto automatically running unit tests/etc too. (Perl is actually a major offender here… last time I used Perl, installing a module from CPAN would run its unit tests by default. Why do I, some random person installing this module, care if the tests pass now? The tests should have been run prior to this being published! I have horrible memories of the DBD::MySQL package failing to install because it ran tests that assumed localhost was running a MySQL server with anonymous auth enabled and the whole module failed to install if that wasn’t the case.)
> Why do I, some random person installing this module, care if the tests pass now?
Because running those tests in your environment ensures that... that module can run in your environment.
By way of example, if a module requires a specific library installed to actually run, running its tests will ensure you catch the problem, and install it, so it can then actually run. Else you'd only find out at runtime that something's missing.
Note also that not all tests are the same, and (unfortunately!) not all modules' tests are the same, either: there's tests that ensure the module works "generally", and there's some author/development tests that on a _properly written_ module are only ran by the author/developer, and skip running when the modules are instead installed by mere users, for whom instead the "standard" "will this module work in this environment?" tests are the only one that get ran.
> I have horrible memories of the DBD::MySQL package failing to install because it ran tests that assumed localhost was running a MySQL server
I believe that got fixed, IIRC, as I've had no trouble installing that module (and running its tests at install time, natch). I said "fixed" as that seems like the sort of test that makes sense for the module's authors/developers to run, and not mere users of it.
I think what you describe fits JS better. Already migrated your router library for your react project, this month? What, still not migrated!? No one is building things for X any longer! You need to switch to Y asap!
I am not aware of anything in current Python 3, that has broken backward compatibility to an earlier Python 3.
Some dependencies are implemented in ways, that will require you to use newer Python versions. Often those are packages, which are glue for lower level libraries. Like tensorflow.
Perhaps I am describing the same thing as in JS ecosystem. But for some reason neither have I migrated to another way of defining my API routes in Django lately, nor have I had any need to in the last couple of years. I guess in the JS world there is just so much more half-backed stuff that gets hyped to no end, and this job guarantee is celebrated as "quick evolution".
Not just that, but cook kids change their languages weekly! HN is full of threads named: "<existing software> written in <language of the week>", and we all know how many people use that emacs fork written in ruby today, and how many will use the one written in Go in 10 years.
What does `Ctrl + [` send to the terminal for you if not esc? In my experience these are always the same, so Vim shouldn't be able to tell the difference unless it's a GUI-integrated version like gVim.
Try to run `xxd` and then press Ctrl-V and either Ctrl+[ or Esc, then Enter and Ctrl+D. Typical terminal setups will show the same codes both times (1b0a for esc and \n).
Alt+Space (or Alt+J Alt+K Alt+B to go up, down, left one word from current position after returning to normal mode) is what I often do which should work universally.
I had a long battle with making kitty work with tmux. I settled on the following in ~/.tmux.conf, before moving to wezterm for good. Maybe it fixes things for you, too:
I tried the first line and in some situations (specifically with some remotes, i.e. kitty -> ssh -> tmux with that 1st line) it still won't fix it.
I gave up kitty because the author obviously don't like tmux and is advising users not to use it. So it is more like a choice between kitty and tmux. Giving up kitty is easier for me in terms of features and time for retraining.
What's your reason to migrate from kitty to wezterm?
> What's your reason to migrate from kitty to wezterm?
My reason to no longer using kitty is simple: I don't like having to copy kitty's terminfo data to every single system I connect to in order to have my terminal work.
It's fine for those few systems I very often connect to, of course.
But I also connect to ephemeral systems, sometimes for a short session, and the toil and friction inherent in having to do that just isn't worth it.
Sure, "kitty +kitten ssh ..." can work in most people's scenarios. Didn't quite work in mine, due to various intricacies about my ssh setup - multiple ssh keys, handled mostly by ssh-ident.
wezterm Just Worked for me. As I got "back" to also using other systems like Windows and MacOS, it Just Worked there, too. No fiddling with terminfo, no fiddling with $TERM, either.
I tried your solution using one remote server that I had trouble with before and it works! That's really great. This probably solves enough problems with kitty for me that I can use it until I find a better solution. (I am using Alacritty at the moment but it has other problems so that I have to use kitty as fall back for some situations.)
I scanned the updates hoping for this exact same thing, but alas did not find it there. I am not comfortable disabling SIP to fix this issue personally.
If you're not concerned about losing other animations, you can enable the Reduced Motion setting in Accessibility preferences. It completely removes that animation.
Looks like there's a bunch of stuff that might opinably fit, depending on who those 10 clients were or what your company does.
- Regulated industries such as: Financial products and services / Investment and brokerage services
- Money transmitters, currency exchange services and other money services businesses
- Neobanks / challenger banks
- Other financial institutions
- Credit card and identity theft protection services
- Other age restricted goods or services
- Virtual and cryptocurrencies, non-fungible tokens (NFTs), and mining services
- Sale of stored value or credits maintained, accepted and issued by anyone other than the seller
- Businesses where sellers get their revenue both from selling items and from signing up new sellers
- When you sign up for Stripe Issuing, you share with Stripe the location of your business, the physical address of your beneficial owners, and the jurisdiction in which your business is registered. Stripe requires that the physical location of your business, its jurisdiction of registration, and the physical address of at least one of your beneficial owners all match. Furthermore, you must use Issuing cards primarily in the same jurisdiction
- Use of Stripe's services for any dealings, engagement, or sale of goods/services linked directly or indirectly with jurisdictions Stripe has deemed high risk, such as Cuba, Iran, North Korea, Syria, and the Crimea, Donetsk, and Luhansk Regions, or persons Stripe has deemed high risk, such as those individuals or entities named to a restricted person or party list of the U.S., United Kingdom, European Union or United Nations, including the sanctions lists maintained by the U.S. Office of Foreign Assets Control or the Denied Persons List or Entity List maintained by the U.S. Department of Commerce, is prohibited. Additionally, it is prohibited to use Stripe's products and services to directly or indirectly export, reexport, sell, or supply accounting, trust and corporate formation, management consulting services, architecture services or engineering services to any person located in Russia. Further, it is prohibited to use Stripe’s products and services directly or indirectly related to any goods prohibited by law (e.g. luxury goods) from Russia.
From a cursory search of email, name, company... I find it plausible that something above might've matched. Or maybe it's a matter of who those 10 clients were, and where they're located. Iran? Cuba? Crimea? Russia? That might do it.
Maybe your competitor also matches, which might be ground for -- if Stripe doesn't want that kind of business on their platform -- for shooting them off, too.
Or maybe it's not a matter of the business type, but of where the clients reside.
Moose is one of those things I always mention when people ask what Perl did right.
It wouldn't hurt other languages to have a higher order object templating system.
Other things it did right is the taint flag to keep user supplied data from hitting sensitive functions by way of the type system. (In Rust you can declare your own type to achieve this, and it's actually enforced.)
The unicode system was actually decent in ways nothing else is, at least until the Go and Rust generation. Python 3 wasn't nearly as complete despite being more than a decade later.
If people ask what Perl did wrong, the dereferencing syntax is at the top of my list. Not having multidimensional arrays as a first class type probably did more to scare people away than anything else.
And in the new class syntax, when it's done, that's (roughly):
class Point {
field $x :param :reader;
field $y :param :reader;
method as_string() {
return "($x,$y)";
}
}
my $origin = Point->new( x => 0, y => 0 );
say $origin->as_string;
I know which of the two I'd rather write :)
The main limitation is that we don't have the `isa => 'Int'` check. That's largely because adding types is something for the entire language, not just this new syntax, so it had to be delayed.
Perl continues to flourish into its fourth decade thanks to a vibrant community of users and developers. The following people are known to have contributed the improvements that became Perl 5.38.0:
Alex, Alexander Nikolov, Alex Davies, Andreas König, Andrew Fresh, Andrew Ruthven, Andy Lester, Aristotle Pagaltzis, Arne Johannessen, A. Sinan Unur, Bartosz Jarzyna, Bart Van Assche, Benjamin Smith, Bram, Branislav Zahradník, Brian Greenfield, Bruce Gray, Chad Granum, Chris 'BinGOs' Williams, chromatic, Clemens Wasser, Craig A. Berry, Dagfinn Ilmari Mannsåker, Dan Book, danielnachun, Dan Jacobson, Dan Kogai, David Cantrell, David Golden, David Mitchell, E. Choroba, Ed J, Ed Sabol, Elvin Aslanov, Eric Herman, Felipe Gasper, Ferenc Erki, Firas Khalil Khana, Florian Weimer, Graham Knop, Håkon Hægland, Harald Jörg, H.Merijn Brand, Hugo van der Sanden, James E Keenan, James Raspass, jkahrman, Joe McMahon, Johan Vromans, Jonathan Stowe, Jon Gentle, Karen Etheridge, Karl Williamson, Kenichi Ishigaki, Kenneth Ölwing, Kurt Fitzner, Leon Timmermans, Li Linjie, Loren Merritt, Lukas Mai, Marcel Telka, Mark Jason Dominus, Mark Shelor, Matthew Horsfall, Matthew O. Persico, Mattia Barbon, Max Maischein, Mohammad S Anwar, Nathan Mills, Neil Bowers, Nicholas Clark, Nicolas Mendoza, Nicolas R, Paul Evans, Paul Marquess, Peter John Acklam, Peter Levine, Philippe Bruhat (BooK), Reini Urban, Renee Baecker, Ricardo Signes, Richard Leach, Russ Allbery, Scott Baker, Sevan Janiyan, Sidney Markowitz, Sisyphus, Steve Hay, TAKAI Kousuke, Todd Rinaldo, Tomasz Konojacki, Tom Stellard, Tony Cook, Tsuyoshi Watanabe, Unicode Consortium, vsfos, Yves Orton, Zakariyya Mughal, Zefram, 小鸡.
In my experience most metal musicians can hold their own with the best of them when it comes to hard core music nerding with thing like idiosyncratic time signatures and unusual chord and key changes.
Maybe your Berkeley grad metal practitioners like Dream Theater and probably a lot of metal in the last decade or two (since the internet and YouTube) but I imagine a lot of garage metal bands from the 70’s and 80’s were probably just playing/writing by feel and a loose understanding of music theory. I’m sure producers helped bring it all together on the album.
Yea, I think we can roughly split metal into pre-90s and post-90s, with 'modern' metal being a lot musical and precise. Just looking at all the people I know that have been in bands, the more into music theory they are, the more likely they are to be in a metal band.
It’s even more obvious when you consider Metallica’s particular songwriting process at the time: James would mess around making cool riffs, record them into a riff track (just a big pile of his favorite riffs put into one big tape in no particular order), then he and Lars would sit down and listen to it, pick the best ones, and build a song around them.
The 5/8 “stutter” in the verse almost certainly came from the original riff track, and when Lars had to add a drum beat to it, he simply mirrored what James was doing, and that’s how it made its way into the song. It’s not really rocket science.
Maybe based on demos and sheer number of bands we've never heard of. This album in particular certainly was not though. Sweet Silence Studios was a little more state of the art...
There's https://metacpan.org/dist/perl/view/pod/perlclass.pod, which (granted) is experimental, but it's actively being worked on.
> Still no working exception handling!
There's https://metacpan.org/dist/perl/view/pod/perlsyn.pod#Try-Catc... which is now (5.40) no longer an experiment, _aside from_ the use of `finally`, which warns.
> trying to guarantee backwards compat for all the legacy code
Not "all", as there are indeed deprecations added over time, but _most_. I really, really like that I can, more often than not, take a program I wrote decades ago and it will still run properly.
reply