4 ms·

Why? Oh, I understand. There are two kinds of engineers: the lumpers and the dividers. The lumpers like to build one single massive engine that does everything

by bregma 5y ago

Why? Oh, I understand. There are two kinds of engineers: the lumpers and the dividers. The lumpers like to build one single massive engine that does everything, and the dividers prefer many small engines that do one thing, do it very well, and can be composed with other small engines in new and innovative ways and provide redundancy, maintainability, and scalability. Obviously I count myself in the latter group. So the question for me is, what possible advantage would consolidating everything into one tool give me? Consider that I'm a software development toolchain engineer by trade in your reply.

pm215 5y ago
The major benefit to "tool is part of the compiler" is that vastly more people will use it and maybe fix the errors. There's a Google paper from 2018 (https://m-cacm.acm.org/magazines/2018/4/226371-lessons-from-building-static-analysis-tools-at-google/fulltext https://m-cacm.acm.org/magazines/2018/4/226371-lessons-from-...) about their experience with static analysis tools, and what they found was that the better the analysis was integrated with the existing developer workflow and the earlier the issues were noted, the more likely they were to actually be fixed. So "existing compiler reports the errors" is better than "tooling reports the errors as comments in the existing code review system" is better than "tooling files bugs in the existing bug tracking system after new code is already committed" is better than "tooling has its own separate dashboard that nobody looks at". I don't care whether under the hood the implementation is fully part of one big "compiler" engine or not, in the same way I don't care that when I run 'gcc' it's really running a compiler, assembler and linker which are all self-contained programs -- I do care that when I say "build my code" in the usual way that that is when analysis happens.
- htfy96 5y ago
  the downside of this is that companies with locked compiler versions won't be able to use the static analysis tool. Up-to-date compiler versions, according to my observation, is more like a privilege of BigTech and startups. Tons of firms are still using the bundled compiler in RHEL and only upgrade every 3-5 years, though in this case the off-tree decision more likely came from the intent of bypassing compiler repo code reviews for faster iteration (very typical at BigTech when you need KR every quarter)
  - secondcoming 5y ago
    They can continue to use their existing analysis tools, no?
  - pjmlp 5y ago
    Lint exists since 1979, they certainly have newer toolchains.
pjmlp 5y ago
Basically because since 1979 the dividers keep failing to use lint. "Although the first edition of K&R described most of the rules that brought C's type structure to its present form, many programs written in the older, more relaxed style persisted, and so did compilers that tolerated it. To encourage people to pay more attention to the official language rules, to detect legal but suspicious constructions, and to help find interface mismatches undetectable with simple mechanisms for separate compilation, Steve Johnson adapted his pcc compiler to produce lint [Johnson 79b], which scanned a set of files and remarked on dubious constructions. " https://www.bell-labs.com/usr/dmr/www/chist.html https://www.bell-labs.com/usr/dmr/www/chist.html
cudgy 5y ago
Lumpers probably account for 90% of the market and users. Dividers like to tweak and usually have to fix problems with the many tweaked fixes to get disparate tools to work together. Lumpers like to focus on their problem domain and not fuss with perfection and ultra-optimal solutions that deliver unquantifiable cost/benefit returns. I say this fondly though as a recovering Divider who still appreciates the pioneering spirit of Dividers.

by bregma 5y ago

pm215 5y ago

The major benefit to "tool is part of the compiler" is that vastly more people will use it and maybe fix the errors. There's a Google paper from 2018 (https://m-cacm.acm.org/magazines/2018/4/226371-lessons-from-building-static-analysis-tools-at-google/fulltext https://m-cacm.acm.org/magazines/2018/4/226371-lessons-from-...) about their experience with static analysis tools, and what they found was that the better the analysis was integrated with the existing developer workflow and the earlier the issues were noted, the more likely they were to actually be fixed. So "existing compiler reports the errors" is better than "tooling reports the errors as comments in the existing code review system" is better than "tooling files bugs in the existing bug tracking system after new code is already committed" is better than "tooling has its own separate dashboard that nobody looks at". I don't care whether under the hood the implementation is fully part of one big "compiler" engine or not, in the same way I don't care that when I run 'gcc' it's really running a compiler, assembler and linker which are all self-contained programs -- I do care that when I say "build my code" in the usual way that that is when analysis happens.

htfy96 5y ago
the downside of this is that companies with locked compiler versions won't be able to use the static analysis tool. Up-to-date compiler versions, according to my observation, is more like a privilege of BigTech and startups. Tons of firms are still using the bundled compiler in RHEL and only upgrade every 3-5 years, though in this case the off-tree decision more likely came from the intent of bypassing compiler repo code reviews for faster iteration (very typical at BigTech when you need KR every quarter)
- secondcoming 5y ago
  They can continue to use their existing analysis tools, no?
- pjmlp 5y ago
  Lint exists since 1979, they certainly have newer toolchains.

pjmlp 5y ago

Basically because since 1979 the dividers keep failing to use lint. "Although the first edition of K&R described most of the rules that brought C's type structure to its present form, many programs written in the older, more relaxed style persisted, and so did compilers that tolerated it. To encourage people to pay more attention to the official language rules, to detect legal but suspicious constructions, and to help find interface mismatches undetectable with simple mechanisms for separate compilation, Steve Johnson adapted his pcc compiler to produce lint [Johnson 79b], which scanned a set of files and remarked on dubious constructions. " https://www.bell-labs.com/usr/dmr/www/chist.html https://www.bell-labs.com/usr/dmr/www/chist.html

cudgy 5y ago

Lumpers probably account for 90% of the market and users. Dividers like to tweak and usually have to fix problems with the many tweaked fixes to get disparate tools to work together. Lumpers like to focus on their problem domain and not fuss with perfection and ultra-optimal solutions that deliver unquantifiable cost/benefit returns. I say this fondly though as a recovering Divider who still appreciates the pioneering spirit of Dividers.