3 ms·

> That’s nice, but it just highlights that the coding style isn’t sufficiently intelligible by itself. We can’t and shouldn’t rely on a static analyzer to be ac

> That’s nice, but it just highlights that the coding style isn’t sufficiently intelligible by itself. We can’t and shouldn’t rely on a static analyzer to be active to make code intelligible everywhere code is displayed (pull requests, diffs, ...). Yes, we absolutely should rely on that. Why would programmers, who are basically tool-builders, reject tools that help us write and analyze our programs? This is not the 1970s, and bare-bones text editors are not the only option. Why should we, who build tools for others, restrict ourselves to a self-imposed unreasonable simplicity? You are free to use Vi or whatever, but don't complain when everyone else uses better tools to improve their productivity, and if the code they write is better suited for those tools that is perfectly fine.

layer8 4y ago
I’m all for IDEs for writing software, but not as a prerequisite for reading source code, because the latter happens in all kinds of different contexts. E.g. a software like GitLab shouldn’t require an integrated static analyzer for any or all programming languages. That would only increase the barrier to entry for all software that happens to display source code. If source code can’t be read and understood as-is anymore, that just impedes interoperability and universality of tooling.
- twblalock 4y ago
  Surely you must understand that the functionality provided by the tools will impact how the code is written, tested, reviewed, and deployed. There is no ideal world where we can use tools to write code and it would be perfectly readable for people who don't use those tools. Embrace the modern ecosystem, or build something better, or take a time machine back to the 1970s where there were no IDEs, source control, or CI/CD. Do you really think that would be better?
  - layer8 4y ago
    I disagree, because it reduces the freedom of choice and variety of tools available for software development, and increases the dependency on bespoke tooling. Using a more sophisticated word processor shouldn’t reduce the readability of the text produced. If anything, IDE features should be helping to increase the readability of the resulting source code, instead of promoting a coding style that decreases it. This is about decoupling. The same way one should be able to freely pick a VCS and CI/CD system of choice, one should also be free to pick the IDE, or any other system concerned with source code, of choice. Those should remain loosely coupled, and should each be easy to replace. The more requirements you impose on how source code has to be marked up for intelligible display, the more you restrict the choice of tools it can usefully work with, and the more laborious it becomes to create new adequate tools in that field.
rocqua 4y ago
We should reject tools that only help us understand code that we are writing. Put differently, we should avoid relying on functionality that isn't present in most places where we need to understand code. Hence, static analysis should be present in many more places than just the IDE. Merge requests, commit diffs, and perhaps code blocks in discussions are prime targets. I think this might be one case where the CLI is truly limiting us. No opportunity for contexts menus or pop-ups makes presenting the results of static analysis much harder.

layer8 4y ago

I’m all for IDEs for writing software, but not as a prerequisite for reading source code, because the latter happens in all kinds of different contexts. E.g. a software like GitLab shouldn’t require an integrated static analyzer for any or all programming languages. That would only increase the barrier to entry for all software that happens to display source code. If source code can’t be read and understood as-is anymore, that just impedes interoperability and universality of tooling.

twblalock 4y ago
Surely you must understand that the functionality provided by the tools will impact how the code is written, tested, reviewed, and deployed. There is no ideal world where we can use tools to write code and it would be perfectly readable for people who don't use those tools. Embrace the modern ecosystem, or build something better, or take a time machine back to the 1970s where there were no IDEs, source control, or CI/CD. Do you really think that would be better?
- layer8 4y ago
  I disagree, because it reduces the freedom of choice and variety of tools available for software development, and increases the dependency on bespoke tooling. Using a more sophisticated word processor shouldn’t reduce the readability of the text produced. If anything, IDE features should be helping to increase the readability of the resulting source code, instead of promoting a coding style that decreases it. This is about decoupling. The same way one should be able to freely pick a VCS and CI/CD system of choice, one should also be free to pick the IDE, or any other system concerned with source code, of choice. Those should remain loosely coupled, and should each be easy to replace. The more requirements you impose on how source code has to be marked up for intelligible display, the more you restrict the choice of tools it can usefully work with, and the more laborious it becomes to create new adequate tools in that field.

rocqua 4y ago

We should reject tools that only help us understand code that we are writing. Put differently, we should avoid relying on functionality that isn't present in most places where we need to understand code. Hence, static analysis should be present in many more places than just the IDE. Merge requests, commit diffs, and perhaps code blocks in discussions are prime targets. I think this might be one case where the CLI is truly limiting us. No opportunity for contexts menus or pop-ups makes presenting the results of static analysis much harder.