> Swift could have easily dethroned Python
No way something that compiles as slowly as Swift dethrones Python.
Edit: Plus Swift goes directly against the Zen of Python
> Explicit is better than implicit.
> Namespaces are one honking great idea -- let's do more of those!
coupled with shitty LSP support (even to this day) makes code even harder to understand than when you `import *` in Python.
Edit 2: To expand a little on how shitty the LSP support is for those who don't work with Swift: any trivial iOS or macOS project that builds fine in Xcode can have a bunch of SourceKit-LSP (the official Swift LSP) errors because it fails to resolve frameworks/libraries. The only sane way to work with Swift in VS Code or derivatives I've found is to turn off SourceKit diagnostics altogether and only keep swiftc diagnostics. And I have the swift-lsp plugin in Claude Code, there's a routine baseline of SourceKit errors ignored. So you have symbols without explicit namespaces, and the LSP simply can't resolve lots of them, so no lookup for you. Good luck.
>No way something that compiles as slowly as Swift dethrones Python.
This must have pushed Chris Lattner towards making Mojo both interpreted and compiled at the same time.
> Explicit is better than implicit.
That's funny. To me magic is implicit by definition and Python strikes me as a very magical language compared to something like Java that is way more explicit.
Until you start using frameworks like Spring and then everything is so painfully magic that no one knows how the program actually runs.
Magical language how? And you should see what reflection based Java monstrosities do in the background.
Plus Swift goes directly against the Zen of Python
The Zen of Python is how we got crap like argparse where arguments are placed in the namespace instead of a dict.
I wouldn't change that in any way. I'd might make it an Arguments class, but I wound't make what parser returns merely a dict.
Yeah, so what happens when you have an option with a '-' in it that isn't valid as a variable name (I know what happens). It's just stupid.
The same thing you'd do yoursef if you wanted to assign it to a namesake local variable even if it was in a dict to begin with: you'd make the dash an underscore.
It would be extremely unlikely that you would replicate the name as a local variable if it was in a dict, but regardless a dict doesn't have that limitation. The namespace thing is atrocious and bad design -- no straightforward way to iterate over them, merging/updating them is awful, collides with keyword methods (keys, items, etc.), and so on; thankfully more modern argument parsing libraries didn't repeat this mistake. It's just a shame this ended up in the standard library, but then Python standard library has never really been any good, e.g. logging and urllib1234567.
>It would be extremely unlikely that you would replicate the name as a local variable if it was in a dict
If you had some feature flag args, you'd keep accessing them via the dict? Highly unlikely...