- the primary idea why glamorous toolkit was started is that developers spend most of their time reading code
- reading code is often implicit—nobody talks about it, so it is not optimized
- software engineering as decision-making business, not constructing business
- (re: code as database)
visualization of class (interface, attributes, links, etc)
- (reminds me of Deep/shallow modules)
- constructing visualization of class usage
- select sub-expression to examine it
- (modern IDEs highlight unused classes and also detect groups of unused classes. this doesn’t cover the whole demonstration but it’s not that bad)
- if “reading code” is implicit, you do just that—read. However, if you start looking into it, you’ll notice that there are very different specific activities that you’re doing. → Reading code is not a goal
- after you have implemented the analysis, you can create a constraint and execute it automatically (e.g., in CI)
- combining constraints into a report with statuses/etc.
gt toolkit seems to mostly use text files and views just enhance them
- (this is similar to how Emacs/org-mode operate, although gt is much more powerful with visuals)
Want to receive my 🖋 posts as I publish them?