3 ms·
Beautifully put. It resonated with me about not over abstracting too early. Abstractions usually come earlier in the design cycle than optimization for me and
by kjeetgill 8y ago
Beautifully put. It resonated with me about not over abstracting too early.
Abstractions usually come earlier in the design cycle than optimization for me and the wrong one makes that later stage harder.
> I do find dynamic languages make such mixing and matching easier, though, because they are less hard-wired to a specific type or iteration interface: less converting needed to re-glue. I've yet to get as much re-use in type-heavy languages, but not ruling it out.
I go back and forth. I mostly develop in a mix of Python and Java. Python may give me a lot of room to explore ideas, but I find refactoring a fragile nightmare. Java's type system is fairly simple and lets me quickly pull up all use sites and trivaly catches misspellings.
It lets me back out of and refector the wrong abstraction much more simply.
- tabtab 8y agoI don't know why there are not more code analysis and refactoring engines for dynamic languages. Sure, it takes more guessing on part of the tool, but I see no reason why they can't identify and help with a large portion of such tasks. It shouldn't be an all-or-nothing thing. Sure, the more "meta" your programming, the harder it is to automate analysis, but only a portion of an application typically requires high meta.
- gowld 8y agoBecause the refactorings are generally impossible. At best the automated tool could tell you everywhere it thinks a change might be necessary, but has to ask you want you want to do there. And it would likely greatly over or underestimate the number of changes needed. It's rather akin to saying "why can't the system implement my functions for based on their signatures?"