7 ms·
This feels inevitable to me. All software engineering problems can be solved by the addition of another layer of abstraction. Why not abstract away the "how" l
by _ea1k 3y ago
This feels inevitable to me. All software engineering problems can be solved by the addition of another layer of abstraction.
Why not abstract away the "how" layer and focus completely on the "what" layer?
For a lot of data processing and integration problems, this would both eliminate a lot of work and increase reliability.
- ModernMech 3y agoBecause a lot of the time, exactly how is very important. The devil is in the details.
- pombo 3y agoI would say that it depends. Python and JS, two of the most used programming languages, abstract away memory management and threading details that most of the time you don't need, but you can "drop down" to write code that does pay attention to that within the language (building an object pool and reusing it, or memoization, etc) and if that's not enough, go to the "deeper" language like C/Rust to handle those cases with first-class primitives.
- _ea1k 3y agoThat's what all the C engineers told me about manual memory management. Of course, there are cases where they were right.
- pombo 3y agoI'm not sure I agree with the fact that an abstraction is always the answer, but your last sentence outlines precisely one of our motivations behind Marsha. You can specify an imperative set of steps in the description of a function/program, or you can (in the future) write a Python function that you use from Marsha
- _ea1k 3y agoThe first sentence was a little tongue in cheek, so I'm glad that you didn't 100% agree with it. :) But it was a all-too-common paradigm in my early years as a Java developer.