3 ms·

by process, you mean call stack or series of event handoffs? I think you're right that that's one of the key ways that devs (esp noobs to the codebase) need to

by process, you mean call stack or series of event handoffs? I think you're right that that's one of the key ways that devs (esp noobs to the codebase) need to navigate, and must be supported. I think 'stack graphs' are supposed to do that[1], but have never tried them. but there are other navigation modes we need to support as well -- like if you're deleting something, or upgrading something, 'find all references'. if you're inventorying use of a DB type, you might want to audit field types in all models. I sometimes wonder if the future is tagging code as 'belonging to a feature', but they can live wherever -- because devs have different needs on different days. [1] https://dcreager.net/talks/2021-strange-loop/ https://dcreager.net/talks/2021-strange-loop/

kerblang 5y ago
By process I typically mean "business process", as in: Bob wants to ship all the widgets to the South Warehouse, and this pile of logic right here is going to do that for him, end-to-end (or mostly end-to-end). The best option I've found for "find everything that references this database table and see if it will be affected by this thing I need to change" is to give database tables really unique names (like "tbl_user" instead of "user") and just grep the hell out of everything. Also if I'm writing large programs I'm going to use a compiler. I mean if a linter can tell you "Hey this python won't work because you removed this function" then good for python, otherwise bad for python. And if I'm going to include 100 open-source libraries then god help me if my build system can't tell that one of them went missing or that the author removed a function I'm using in version 1.2.3.4.b. But all of that is about dependencies, and dependencies kill teams. That's why I want the scope of any logic as tightly constrained and enforced as possible. I'm sure you could design a multi-dimensional behavioral categorizer/IDE/language system that blows everybody's minds and wouldn't that be cool, but I doubt anyone would use it, because behavioral categorization really doesn't solve problems. It just looks nice. But any rate, at the very minimum, back to this point: Don't try to compensate for the failure of behavioral categorization with microservices when you could have just packaged things along the same lines of division.
- awinter-py 5y ago
  100% with you on greppability as an underrated design skill interested in 'library versions as types' and have been thinking about this problem on and off. version numbers are a proxy for the combination of: 1) call signature, and 2) internal semantics linters / typesystems are good at (1). If we had a system that could do (2), version numbers would be less necessary and compatibility could be proof-based. (Well, to the extent that the semantic assertions are valid).

kerblang 5y ago

By process I typically mean "business process", as in: Bob wants to ship all the widgets to the South Warehouse, and this pile of logic right here is going to do that for him, end-to-end (or mostly end-to-end). The best option I've found for "find everything that references this database table and see if it will be affected by this thing I need to change" is to give database tables really unique names (like "tbl_user" instead of "user") and just grep the hell out of everything. Also if I'm writing large programs I'm going to use a compiler. I mean if a linter can tell you "Hey this python won't work because you removed this function" then good for python, otherwise bad for python. And if I'm going to include 100 open-source libraries then god help me if my build system can't tell that one of them went missing or that the author removed a function I'm using in version 1.2.3.4.b. But all of that is about dependencies, and dependencies kill teams. That's why I want the scope of any logic as tightly constrained and enforced as possible. I'm sure you could design a multi-dimensional behavioral categorizer/IDE/language system that blows everybody's minds and wouldn't that be cool, but I doubt anyone would use it, because behavioral categorization really doesn't solve problems. It just looks nice. But any rate, at the very minimum, back to this point: Don't try to compensate for the failure of behavioral categorization with microservices when you could have just packaged things along the same lines of division.

awinter-py 5y ago
100% with you on greppability as an underrated design skill interested in 'library versions as types' and have been thinking about this problem on and off. version numbers are a proxy for the combination of: 1) call signature, and 2) internal semantics linters / typesystems are good at (1). If we had a system that could do (2), version numbers would be less necessary and compatibility could be proof-based. (Well, to the extent that the semantic assertions are valid).