I keep coming back to this talk and using it as a foundation to explain the framework for making architectural decisions.. So many tough coding/architectural decisions are simplified when you recast them using abstractness/power vs concreteness/utility model
Great talk! I love the comment regarding how "Not DRY is fine"...In my experience, DRY oftentimes creates tight couplings that slow down development pace.
Amazing talk. I understand the desire for abstractions and seem to run my life looking at how everything is abstracted, not just programming. I personally got destroyed when I was mismanaged thinking I would eventually be assigned the chance to change the abstractions of the projects I was working on. I had kept things too concise where you did not have to drill down through dozens of files to understand what was actually going on. I just felt I needed to comment on your mention of too much abstraction around @31:30
Concerning DRY, I've learned to wait to consider abstracting something until I need 3 or more instances of it, because it is nice to be able to immediately see the structure of what is needed rather than trying to understand the abstraction. He basically said this so this comment doesn't really add much value, but anyway, my experience is the same.
What a talk!! I always had the doubt why the child is 'sub-class' which has more properties (relatively superior). Your Answer makes sense. Thank you :)
Excellent talk!. But just replace "abstraction" and "levels of abstraction" with "simplification" and "levels of simplification" and a wider audience will be able to understand. Engineers have been "simplifying" our interaction with the physical world with many "levels of simplification"; computer scientists have been "simplifying" our interaction with informational systems and ultimately with the physical world. Excellent, excellent!
What power does abstracting view elements to the function level give you? The one I can think of off the top of my head is dynamic reordering of unique elements, but is there another one?
I would say we're seeking more *manageable* ways of using our existing power rather than *principled* ways. Principles naturally arise from the effort to make bugs, performance, and change as manageable as possible, but there will *always* be edge cases where a given principle gets in the way of manageability. For example: the need to denormalize data in certain cases; __dangerouslySetInnerHtml; etc.
19:00 Ah man. That's a great visual. Thank you. Not sure I completely understand what you mean by 'functional level' vs 'declarative DSL', but that's okay. Curious to know if Nix, which to my understanding uses a declarative configuration, would address some of issues of Grunt without being Gulp like. (Total novice btw)
After some time, I have re-watched this and I see a lot of inconsistencies. A basic one is the idea that abstractions contain less properties and apply to more situations (correct), but then saying that frameworks are more powerful and libraries more useful. Old Angular extended jQuery. Remember that? jQuery was more powerful, Angular more useful. jQuery was the superclass.
According to his definition, framework has higher level of abstraction than library. If you consider jQuery as library instead of framework, then the old Angular that extended jQuery should not be considered as framework.
