4 ms·

I don't think that this post really explains much about how to judge the fitness of a feature for software engineering. From the article, `gofmt` supports autom

I don't think that this post really explains much about how to judge the fitness of a feature for software engineering. From the article, `gofmt` supports automated tooling around source code, which is good for software engineering; but scattering import paths throughout the source tree instead of centralizing them in something like `package.json` obviously makes automated tooling around import paths harder, so why aren't local import paths bad for software engineering? The whole viewpoint seems to just add a sort of high-handed argument from authority to your typical subjective arguments over programming features.

waisbrot 8y ago
I don't know Go, but I think that automated code-fixes are more difficult than gathering imports. For example, `grep -R -o 'import ".*"' | sort | uniq` gets me a centralized list of imports for the cost of one pass over the code, so maybe it's worth it to side against automated tooling there. But refactoring code is quite hard so a win there is worth the cost.
AnimalMuppet 8y ago
I read it as a statement on intent, and a rationale for certain choices in view of the intent. I don't think it's useful to question the intent; that gets too close to accusing people of bad faith. I think the useful questions are: Did your choices actually achieve your intent? And, in doing so, what new problems did you introduce? (You always introduce some new problems.)
pcwalton 8y ago
Exactly. To elaborate on that, much of the speed difference between systems like Cargo and dep is that Cargo only has to look at metadata in one file. Surely that is a software engineering advantage!
deleted 8y ago
[deleted]
skybrian 8y ago
I agree that it's not explained clearly. One possible reason: import statements in source code can be analyzed regardless of which build system you're using. In the case of Go, there are at least two important build systems ("go build" and bazel), so analysis tools would need to support both. On the other hand, if a package.json file were just as universally used as Go source code, it would effectively be part of the language.

waisbrot 8y ago

I don't know Go, but I think that automated code-fixes are more difficult than gathering imports. For example, `grep -R -o 'import ".*"' | sort | uniq` gets me a centralized list of imports for the cost of one pass over the code, so maybe it's worth it to side against automated tooling there. But refactoring code is quite hard so a win there is worth the cost.

AnimalMuppet 8y ago

I read it as a statement on intent, and a rationale for certain choices in view of the intent. I don't think it's useful to question the intent; that gets too close to accusing people of bad faith. I think the useful questions are: Did your choices actually achieve your intent? And, in doing so, what new problems did you introduce? (You always introduce some new problems.)

pcwalton 8y ago

Exactly. To elaborate on that, much of the speed difference between systems like Cargo and dep is that Cargo only has to look at metadata in one file. Surely that is a software engineering advantage!

deleted 8y ago

[deleted]

skybrian 8y ago

I agree that it's not explained clearly. One possible reason: import statements in source code can be analyzed regardless of which build system you're using. In the case of Go, there are at least two important build systems ("go build" and bazel), so analysis tools would need to support both. On the other hand, if a package.json file were just as universally used as Go source code, it would effectively be part of the language.