> `strfmt` uses the experimental `concept` feature with weird symbol binding > rules. You cannot blame macros for this.
TIL, thanks. Are concepts a bit like interfaces in other languages, then? > Note that I had to import `write` to make the `Writer` concept happy. What does one need to do to deduce that this is what was needed? Just always keep `--reportConceptFailures:on`? If so, how come that isn't the default setting? > By this reasoning Python is far worse than Nim (dynamic field lookups > everywhere, no static typing/information) Worse in the sense that there is less error checking before runtime, allowing type errors to creep in more easily, but not worse for readability / navigability in the sense you described. If I see `x.foo["bar"]` in Nim code, how do I know where `proc foo*(x: XType)` is defined? Or perhaps it isn't defined anywhere, if `foo` is a field of the `x` object. And it needn't be in the "obvious" place, where the type of x is declared (wherever that is) - just in _one_ of the imports. Similarly for `proc `[]`(s: string)`. Given Python's dynamic nature, it is clearly possible to come up with pathological Python cases with non-obvious navigation. But in practice this doesn't seem to happen, and conventions are generally established and adhered to, which reduces the cognitive load on readers. The ability to add operators anywhere is useful, no question - just like C# extension methods - but it seems to have the potential to hurt readability. Maybe tooling can help when developing, but not when browsing. Even browsing the extensive Nim docs is harder than it needs to be for a newcomer like me, since definitions aren't hyperlinked and one has to keep going to the Search box when navigating definitions (unless I've missed something).
