50 ms·
> 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
by oefrha 7mo ago
> 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.
- bossyTeacher 7mo ago> 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.
- vovavili 7mo ago>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.
- deleted 7mo ago[deleted]
- commandersaki 7mo agoPlus 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.
- coldtea 7mo agoI 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.
- commandersaki 7mo agoYeah, 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.
- coldtea 7mo agoThe 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.
- commandersaki 7mo agoIt 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.
- coldtea 7mo ago>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...