Twitter | Pretraživanje | |
Paul Biggar
Software engineers spend a lot of time promoting abstraction. I've found concretization to be far more understandable and maintainable, esp in a rapidly changing codebase
Reply Retweet Označi sa "sviđa mi se" More
Mikaeil Orfanian 6. sij
Odgovor korisniku/ci @paulbiggar
Can you expand on what you mean by concretization as opposed to abstraction?
Reply Retweet Označi sa "sviđa mi se"
Paul Biggar 7. sij
Odgovor korisniku/ci @mikaeilo
Making something "concrete" is the opposite of making it abstract. So I guess inlining the abstraction and removing everything no longer required
Reply Retweet Označi sa "sviđa mi se"
Mike Sallese 6. sij
Odgovor korisniku/ci @paulbiggar
Completely agree. I'll only introduce a new pattern to my code base if it makes things more simple, which is quite rare. I'll also duplicate code far before I try and refractor it. Most of the time it ends up being changed anyways.
Reply Retweet Označi sa "sviđa mi se"
Paul Biggar 7. sij
Odgovor korisniku/ci @MikeSallese9
Yeah, I'm reading through some old "abstractions" that should have been duplicated for each purpose
Reply Retweet Označi sa "sviđa mi se"
Ben Ford - Commando Development 6. sij
Odgovor korisniku/ci @paulbiggar
Not all abstractions are created equal though right? If you have a community with very fundamental, universally understood abstractions built in - recognising and naming those (e.g. Functor, Applicative from FP) is a means of clarity.
Reply Retweet Označi sa "sviđa mi se"
Paul Biggar 7. sij
Odgovor korisniku/ci @commandodev
Right, I think there are a few of those, though probably not as many as people think.
Reply Retweet Označi sa "sviđa mi se"
BrendanEich 6. sij
Odgovor korisniku/ci @paulbiggar
I first added JS ("Mocha") to Eric Bina's Netscape rendering engine and was flummoxed by lack of abstractions for hooking (e.g., that one place where events from the user commit to have effects; or even one place for all kinds of form submissions). But his code was super-robust!
Reply Retweet Označi sa "sviđa mi se"
BrendanEich 6. sij
Odgovor korisniku/ci @paulbiggar
There were some triplicated bugs to fix, but ebina was almost like an ASIC designer: when I put those gates *there*, I knew exactly what they should do & no more" (my paraphrased memory of long-ago conversation). Has its merits in fast-changing codebase vs leaky abstraction hell.
Reply Retweet Označi sa "sviđa mi se"
Kristian Dupont 7. sij
Odgovor korisniku/ci @paulbiggar
I might agree with you. But somewhat ironically, this statement is so abstract that it's hard to know exactly what you mean :-D
Reply Retweet Označi sa "sviđa mi se"
defer sandy() 6. sij
Odgovor korisniku/ci @paulbiggar
"most problems can be solved with another layer of abstraction" "most problems of performance can be solved by removing a layer of abstraction"
Reply Retweet Označi sa "sviđa mi se"