|
@paulbiggar | |||||
|
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
|
||||||
|
||||||
|
Mikaeil Orfanian
@mikaeilo
|
6. sij |
|
Can you expand on what you mean by concretization as opposed to abstraction?
|
||
|
|
||
|
Paul Biggar
@paulbiggar
|
7. sij |
|
Making something "concrete" is the opposite of making it abstract. So I guess inlining the abstraction and removing everything no longer required
|
||
|
|
||
|
Mike Sallese
@MikeSallese9
|
6. sij |
|
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.
|
||
|
|
||
|
Paul Biggar
@paulbiggar
|
7. sij |
|
Yeah, I'm reading through some old "abstractions" that should have been duplicated for each purpose
|
||
|
|
||
|
Ben Ford - Commando Development
@commandodev
|
6. sij |
|
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.
|
||
|
|
||
|
Paul Biggar
@paulbiggar
|
7. sij |
|
Right, I think there are a few of those, though probably not as many as people think.
|
||
|
|
||
|
BrendanEich
@BrendanEich
|
6. sij |
|
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!
|
||
|
|
||
|
BrendanEich
@BrendanEich
|
6. sij |
|
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.
|
||
|
|
||
|
Kristian Dupont
@kristiandupont
|
7. sij |
|
I might agree with you. But somewhat ironically, this statement is so abstract that it's hard to know exactly what you mean :-D
|
||
|
|
||
|
defer sandy()
@TheSandyWalsh
|
6. sij |
|
"most problems can be solved with another layer of abstraction"
"most problems of performance can be solved by removing a layer of abstraction"
|
||
|
|
||