2,548 karma · joined August 15, 2020
Submissions != endorsements
Go has adopted a similar approach to this - they've made it fairly easy to write separate plugins that check stuff like this. The plugins aren't executed as part of the compiler though, they're standalone tools. For example, see golangci-lint, which bundles together a load of plugins of this kind.
Some of these plugins are shipped within the go command directly, as part of the "go vet" subcommand. (including a printf format check, which is similar to what's described in this post, i.e. it checks that arguments are of the correct type).
https://github.com/zsh-users/zsh/blob/47c7bc9b1493c7374f076b... has a comment about this behaviour, but no justification. I think it's just an optimization to save a little bit of time by not forking, and to avoid having the zsh process hanging around taking resources for no reason.
https://github.com/jamespwilliams/strictbash, I wrote this little wrapper a while back that you can use as a shebang for scripts. It runs shellcheck for you before the script executes, so it’s not possible to run the script at all if there are failures. It also sets all the bash “strict mode” [0] flags.
[0] http://redsymbol.net/articles/unofficial-bash-strict-mode/
One funny bit about the talk, which isn’t mentioned in the slides, is that he actually gave the talk at Linaro (the very same company who were called out in the slides as a case study of submitting a particularly bad set of patches)
But I do think we should keep in mind what an incredible project NixOS is. NixOS isn’t just some other Linux distro, repeating pretty much what every distro has done for 40 years. It’s a complete rethink of how a Linux distribution and package manager should work, from first principles, in a way that I don’t think has ever been done before. That’s an incredibly bold thing to do. That alone, as a research project, would be an impressive achievement. But it hasn’t just ended up as some researcher’s PhD thesis. It works in the real world, and it’s built a large community despite its learning curve.
So despite the terrible docs and UX, I have trouble agreeing that it “sucks”!
Yeah, because the ecosystem is dead. The flipside is that the bulk of Perl modules available are stale and don't receive any security updates or bug fixes. If I had a pound for every time I've seen a 10+ year old bug with no comments in the CPAN issue tracker...
> Perl has a small set of core syntax and is very extensible and flexible in adopting new paradigms.
Depends what you call "core syntax". The syntax available to you with a stock Perl install is certainly not small compared to other languages.
> With a great amount of discipline, Perl scripts can be successfully scaled up into large, complex systems.
If you're disciplined, you can write complex systems pretty much as well as you could in Python or any other dynamically-typed language.
However, it requires a lot of discipline and experience, and with other languages you at least have good formatters and LSPs to help with that. Perl sorely lacks this kind of infrastructure.
I also think the lack of static types makes writing complex systems massively harder, but that's not a criticism of Perl in particular.
Project description: If you like (neo)vim and Nix, you might find this interesting: it’s a Nix-based Neovim development shell supporting a bunch of languages (with more to come!). LSPs are used with Neovim’s LSP support to give nice editing features, and treesitter is used for highlighting. Nix makes it possible to try out the shell with a single command (once you have Nix installed).
Contact info: https://jameswillia.ms/contact.html