3 ms·

this. properly made abstractions are actually more maintainable and easier to manage. for ex, take anybody learning programming about writing to a file, if you

this. properly made abstractions are actually more maintainable and easier to manage. for ex, take anybody learning programming about writing to a file, if you write your code using ruby, it would be a lot safer and maintainable than the C counterpart even though the latter is more powerful.

rudedogg 3y ago
Abstractions hide details, and you'll likely need to interact with something the abstraction hides eventually. So then you end up doing one of two things: 1. Learning every detail of the abstraction and the thing it's abstracting, fighting it until you persevere and get it to do what you want 2. Write something from scratch that does exactly what you need Going the #2 route from the start isn't such a bad idea, and has a lot of advantages IMO. The hard thing about all this is that abstractions are beautiful at first. It's not until you're far into a project, or doing something unusual that it all falls apart.
- Conscat 3y ago
  Uh oh I wrote C code and just multiplied meters by yards and now the program exploded help
- gpderetta 3y ago
  C has plenty of abstactions. Are you saying that the set of abstractions provided by C are optimal or nearly so?
  - rudedogg 3y ago
    No, sorry, I don't know C well. I was just advocating against abstractions in general. Using primitive types and designing around the data – not higher-level language abstractions – is a nice approach that doesn't get enough attention. Instead conferences are filled with talks about how some new abstraction is the silver bullet for all your problems. I just wanted to challenge the "more and higher abstractions are good" narrative, since using them has ate up a lot of my time and I hate to see other people repeat the mistake. Obviously every abstraction is different and unique in its value.
    - runald 3y ago
      > I was just advocating against abstractions in general No, you are advocating against particular kind of abstractions, and dismissively pretend that most abstractions are bad. Otherwise, you won't be using high-level programming languages and just stick to assembly or punch cards instead. You shouldn't even be interfacing with the operating system, write your own OS every time you need to do something with the computer. Also, since you don't like abstractions, please also avoid using higher maths or any kind of formalized systems that build upon layers of layers of abstractions. Define your own axiomatic system from first principles every time you need to reason about anything. While you are at it, consider moving out of the civilization, and avoid any kind of recent technologies such as computers, as they are built on the idea of "more and higher abstractions". I'm being absurd, but I hope you get the point.
    - PartiallyTyped 3y ago
      I think you have a misunderstanding of what an abstraction is. An abstraction is a simplification, something that hides the details to provide a simple interface to access. Data Types merely pack data and provide soundness in how you process it. You can pack the data as you want, show everything and be fine. OOP Languages pack objects and use them to build abstractions, that's it. A strong type system doesn't mean you need to hide implementation details and build babushkas of abstractions. It simply means that the type system reduces the number of programs you can write by making sure your code adheres to some soundness checks.

rudedogg 3y ago

Abstractions hide details, and you'll likely need to interact with something the abstraction hides eventually. So then you end up doing one of two things: 1. Learning every detail of the abstraction and the thing it's abstracting, fighting it until you persevere and get it to do what you want 2. Write something from scratch that does exactly what you need Going the #2 route from the start isn't such a bad idea, and has a lot of advantages IMO. The hard thing about all this is that abstractions are beautiful at first. It's not until you're far into a project, or doing something unusual that it all falls apart.

Conscat 3y ago
Uh oh I wrote C code and just multiplied meters by yards and now the program exploded help
gpderetta 3y ago
C has plenty of abstactions. Are you saying that the set of abstractions provided by C are optimal or nearly so?
- rudedogg 3y ago
  No, sorry, I don't know C well. I was just advocating against abstractions in general. Using primitive types and designing around the data – not higher-level language abstractions – is a nice approach that doesn't get enough attention. Instead conferences are filled with talks about how some new abstraction is the silver bullet for all your problems. I just wanted to challenge the "more and higher abstractions are good" narrative, since using them has ate up a lot of my time and I hate to see other people repeat the mistake. Obviously every abstraction is different and unique in its value.
  - runald 3y ago
    > I was just advocating against abstractions in general No, you are advocating against particular kind of abstractions, and dismissively pretend that most abstractions are bad. Otherwise, you won't be using high-level programming languages and just stick to assembly or punch cards instead. You shouldn't even be interfacing with the operating system, write your own OS every time you need to do something with the computer. Also, since you don't like abstractions, please also avoid using higher maths or any kind of formalized systems that build upon layers of layers of abstractions. Define your own axiomatic system from first principles every time you need to reason about anything. While you are at it, consider moving out of the civilization, and avoid any kind of recent technologies such as computers, as they are built on the idea of "more and higher abstractions". I'm being absurd, but I hope you get the point.
  - PartiallyTyped 3y ago
    I think you have a misunderstanding of what an abstraction is. An abstraction is a simplification, something that hides the details to provide a simple interface to access. Data Types merely pack data and provide soundness in how you process it. You can pack the data as you want, show everything and be fine. OOP Languages pack objects and use them to build abstractions, that's it. A strong type system doesn't mean you need to hide implementation details and build babushkas of abstractions. It simply means that the type system reduces the number of programs you can write by making sure your code adheres to some soundness checks.