As I’ve been saying for quite some time, it is architecturally risky to depend directly on frameworks and databases without some form of isolation protecting the app. Parler just learned that the hard way.
-
this does not automatically justify an arbitrary number of layers of abstraction. A cost/benefit analysis must be applied to determine what really works. Most people seem unwilling or unable to do this analysis. In particular, most costs of abstraction are ignored.
Then, benefits are always incorrectly measured. The claimed benefit of a technique is taken to be its actual benefit; people seem unwilling or unable to measure the extent to which the claimed benefit is actually achieved.
-
-
Do the impossible.
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
I agree that over abstraction is costly; but so is under abstraction. I also agree that we should err on the side of under abstraction. Thus we should be on the lookout for abstraction opportunities but careful about applying them.
-
most popular languages are already over-abstracted take one of the simplest, most common, non-trivial actions you can take: = can you even remember *how many* meanings this has in c++ ? Can you name one person that can confidently speak that number?
@stroustrup (hi!)
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.