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...
I use wezterm and love it, too - BUT, it doesn't yet support SSH agent forwarding, which are an integral part of my workflow for some machines.
So it's great -- for me -- for local connections, or remote ones where I don't need to pass an SSH agent, but it's not yet there "fully" for me the way KiTTY is.
> You can add 32 of these secrets to a Yubikey device.
I have 45 of those currently in my Authy account, which syncs on two phones for redundancy...
I'd love to use a Yubikey for this, but I'd have to split those accounts across multiple yubikeys, which would be quite a headache to maintain, especially if one wants redundancy...
That's not at all the same thing. Banks loan you money with the expectation of return (interest). Governments build a country that is conducive to economic activity and take some of that economic activity in taxes to fund its activities.
In one situation a party has taken on risk for the expectation of future profit for itself. In the other a party has invested to stimulate activity beneficial to a larger group.
They might seem superficially similar but I don't think you can compare them that easily.
I've tried to use git notes over the years but unfortunately notes are tied to a specific commit hash. It's a blessing and a curse.
Works great for some types of review system, or for "tagging" things related to deploy. Notes on commits on the master/main branch, which doesn't get rebased? Awesome thing, they work.
But you can't as easily use them on branches: the moment a branch whose commits had notes is rebased, and SHAs change, good-bye notes associated with the "previous" SHAs :/
Seems like a standard git thing: have a process that works in a specific, but not a “helpful” way and also have a undiscoverable setting to configure said process.
Is that why people keep building UIs and wrappers for git?
Git has so many users that changing defaults is pretty tricky. They have done it in the past but usually over multiple release cycles with a deprecation window.
Ah yes, like how nginx’s defaults still like to pretend it’s early 2000s, everyone uses dialup, and nobody could possibly want their website to serve more than a handful of requests per hour.
Depends. You can also see those as notes and you want to have them go away after rebase automatically so you have invalidation built in (e.g. preparing changes).
My guess is that it was originally an oversight and this option was added later, but turned off by default to avoid a "breaking change". Would be interesting to dig through the changelogs and commit history to see what the story was.
Yes, it is totally possible to guess it this way. From top of my head reference rewriting while rebase is older thought, but I'd be clueless about it apart from that rebasing is for rewriting commit references in the first place. And everything else - including git-note references - needs to be explicitly configured from that default behaviour. Which follows your argument in a broader sense, as per default no other refs are expected to get rewritten and therefore it shouldn't be different for git-notes, even if they were introduced with the configuration option to rewrite them in the first place.
