5 ms·

>Code that is optimized to be easy to read often has lots of duplication and very little abstraction. Absolutely wrong and people need to stop pushing this nar

>Code that is optimized to be easy to read often has lots of duplication and very little abstraction. Absolutely wrong and people need to stop pushing this narrative or put their money where their mouth is and use assembly. The people repeatedly saying this have probably experienced bad abstractions and gross OOP spaghetti code and improperly generalized this to "DRY bad, abstractions bad".

pharmakom 4y ago
you missed the posters point. they are advocating for more abstractions, not fewer like assembly would give you. and who mentioned OOP?
dgb23 4y ago
Good abstractions are just really hard to find. It’s much easier to sit down and start typing. And it’s somewhat easy to read that code and know what it does, line by line. Abstractions inherently push away the details that enable this kind of lower level understanding. They have baked in assumptions that may or may not be explicitly documented. Good abstractions provide leverage, but they are mini languages. They have their own vocabulary, their own execution model, extension mechanism and so on. Good abstractions are clear and well factored pieces, but that doesn’t mean they are or should be easy to read without making an effort to understand their meaning. That’s not necessarily what abstractions are about. That’s why tutorials and guides are so important. People need examples to ease into a new vocabulary and mental model. Assembly (and JVM bytecode, WASM etc.) is very easy to read and understand. You learn these languages in what, an hour and a half? But their vocabulary speaks about things you don’t necessarily care about when writing a web app or an ETL pipeline. People use abstractions to express something in a particular mental model or domain. Only in specific cases that means it’s optimized for ease.
- jstimpfle 4y ago
  It's not even well understood what abstractions are, in the first place. It usually ends bad when one starts with the premise of "I must abstract this, I must generalize this" etc. Most "abstractions" are terribly leaky. I find it much more helpful to approach it like "This is what needs to happen, now how do I split this into different parts in a way that minimizes the interactions?".
  - dgb23 4y ago
    I like how A Philosophy of Software Design discusses this issue you described: > An abstraction that omits important details is a false abstraction: it might appear simple, but in reality it isn’t. The key to designing abstractions is to understand what is important, and to look for designs that minimize the amount of information that is important.

pharmakom 4y ago

you missed the posters point. they are advocating for more abstractions, not fewer like assembly would give you. and who mentioned OOP?

dgb23 4y ago

Good abstractions are just really hard to find. It’s much easier to sit down and start typing. And it’s somewhat easy to read that code and know what it does, line by line. Abstractions inherently push away the details that enable this kind of lower level understanding. They have baked in assumptions that may or may not be explicitly documented. Good abstractions provide leverage, but they are mini languages. They have their own vocabulary, their own execution model, extension mechanism and so on. Good abstractions are clear and well factored pieces, but that doesn’t mean they are or should be easy to read without making an effort to understand their meaning. That’s not necessarily what abstractions are about. That’s why tutorials and guides are so important. People need examples to ease into a new vocabulary and mental model. Assembly (and JVM bytecode, WASM etc.) is very easy to read and understand. You learn these languages in what, an hour and a half? But their vocabulary speaks about things you don’t necessarily care about when writing a web app or an ETL pipeline. People use abstractions to express something in a particular mental model or domain. Only in specific cases that means it’s optimized for ease.

jstimpfle 4y ago
It's not even well understood what abstractions are, in the first place. It usually ends bad when one starts with the premise of "I must abstract this, I must generalize this" etc. Most "abstractions" are terribly leaky. I find it much more helpful to approach it like "This is what needs to happen, now how do I split this into different parts in a way that minimizes the interactions?".
- dgb23 4y ago
  I like how A Philosophy of Software Design discusses this issue you described: > An abstraction that omits important details is a false abstraction: it might appear simple, but in reality it isn’t. The key to designing abstractions is to understand what is important, and to look for designs that minimize the amount of information that is important.