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.
-
The problem is that the culture of programming correctly identified a successful pattern, but then extrapolated that pattern way past the equilibrium point, and haven't yet realized they overshot. Yes, assembly language was a good idea. So was FORTRAN/C/etc. But,
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.
End of conversation
New conversation -
-
-
My hypotheses for an experiment: Insufficient abstraction is far more prevalent, and even its unit (not aggregate) cost greatly outweighs the cost of "too much" abstraction.
-
I'd love to do the research, but who's got the time. Many of the prevalent things we do in software dev aren't grounded in research (cubes & solo development, e.g.), and such things are also greatly contextual.
End of conversation
New conversation -
-
-
you think that is difficult. Try interviewing for a job as a java developer. Interviewer will ask you all sorts of questions on ideology propagated by uncle bob..
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
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.