5 ms·
Some gems from the discussion… > Long ago he wrote a book entitled The Design of Everyday Things. It's well worth the read. Within those pages he stated the fo
by wokwokwok 4y ago
Some gems from the discussion…
> Long ago he wrote a book entitled The Design of Everyday Things. It's well worth the read. Within those pages he stated the following rule of thumb: “If you think something is clever and sophisticated beware -- it is probably self-indulgence.”
> You also asked me "why...". To the extent that I have not answered that above, I'll simply turn the question around and point out that it is probably for the same reason that your video was solely focussed on the amplification of performance to the strident denigration of every other concern. To a performance hammer, everything looks like a nail. ;-)
Overall a very amicable and interesting read.
It’s so easy to preach high level architecture without specifics, but also so very easy to cherry-pick a specific example where generic advice doesn’t apply.
I think it’s interesting that there is an almost fundamental disconnect between “easy to understand” and “fast and efficient” …and I’m absolutely 100% with Uncle Bob that bounded contexts for complex code is the solution.
This is the approach rust takes with unsafe code and it has proved to be an extremely effective principle.
- slavik81 4y ago> there is an almost fundamental disconnect between “easy to understand” and “fast and efficient” In my experience, poor performance is often because the code is needlessly complex and does unnecessary work. In that case, there's no trade-off. You can both improve performance and readability by simplifying. There may be trade-offs required to optimize for the absolute maximum performance, but you can get most of the way there without sacrificing anything. The vast majority of programs are nowhere near the pareto frontier between performance and readability.